拡張モニタリングを使用した柔軟な解像度の Amazon RDS OS メトリクスのリアルタイムモニタリング

Amazon Relational Database Service (Amazon RDS) では、オペレーティングシステムのリアルタイムメトリクスにアクセスできるようにすることで、RDS のリソースをさまざまなプロセスやスレッドがどのように使用しているかを監視できます。Amazon RDS コンソールで、インスタンスごとに監視したいメトリクスを管理できます。Amazon CloudWatch は AWS のネイティブモニタリングツールです。すべての AWS サービスとワークロードの主要な監視ツールとして、お客様に広く使用されています。

しかし、RDS には、CloudWatch と組み合わせて使用できる拡張モニタリングと呼ばれるアドオン機能があります。テレメトリーの追加レイヤーが提供されるため、より高い解像度の監視データが必要な調査に役立ちます。CloudWatch メトリクスのみに依存するトラブルシューティング手法では、これらの重要な指標を見逃す可能性があります。そのため、拡張モニタリングのきめ細かなメトリクスと CloudWatch メトリクスを併用することで、インスタンスのパフォーマンスをより包括的かつ正確に把握でき、問題解決のための効果的な意思決定が可能になります。RDS インスタンスを作成すると、拡張モニタリングはデフォルトでは無効になっています。しかし、インスタンスの作成時に有効にするか、既存のインスタンスを変更して有効にすることもできます。この記事では、拡張モニタリングが提供するさまざまな機能について説明します。

拡張モニタリングは次のデータベースエンジンで使用できます。

Amazon RDS for MariaDB
Amazon RDS for MySQL
Amazon RDS for Oracle
Amazon RDS for PostgreSQL
Amazon RDS for SQL Server
Amazon Aurora MySQL-Compatible Edition
Amazon Aurora PostgreSQL-Compatible Edition
（訳注：Amazon RDS for Db2 (2023 年 11 月 27 日に一般提供が開始) でも使用可能です）

拡張モニタリングは、db.m1.small インスタンスクラスを除くすべての DB インスタンスクラスで使用できます。この記事では、Amazon RDS for MySQL を使用した拡張モニタリングの機能について説明します。

拡張モニタリングの概要

RDS インスタンスを監視する場合、拡張モニタリングには次の利点があります。

CloudWatch メトリクスや Amazon RDS Performance Insights と一緒に使用できるモニタリングのもう 1 つのレイヤーが追加されます

注: ここでの CloudWatch メトリクスとは、RDS サービスが、追加費用なし、 1 分単位で CloudWatch に公開する、デフォルトの標準的なメトリクスのことを指します。

CPU Nice、空きメモリ、アクティブメモリ、ロードアベレージ (1、5、15 分)、スワップイン、スワップアウト、などを監視するための、サブコンポーネントレベルのメトリクスのグラフを提供します
CloudWatch の標準的な 1 分よりも解像度が高く (1 秒、5 秒、10 秒、15 秒、30 秒、60 秒) 、パフォーマンスやリソース関連の問題の調査やトラブルシューティングに役立ちます
DB インスタンスのデータストレージボリュームにおける、それぞれのディスクのメトリクスを示す、物理デバイスレベルのグラフを提供します
Amazon CloudWatch Logs アカウントにログが配信され、CPU 使用率、メモリ、ディスク IO、ネットワーク、物理デバイス IO などのメトリクスを表示して調べることができます。
DB インスタンスで実行されているプロセスの詳細を含む、オペレーティングシステムのプロセスリストを提供します

この記事では、次のことについて説明します。

Amazon RDS for MySQL で 1 秒単位の拡張モニタリングを設定する方法
RDS for MySQL インスタンスにテスト用の負荷をかける方法
CloudWatch コンソールと RDS 拡張モニタリングを使用してメトリクスを分析する方法
拡張モニタリングの追加機能
CloudWatch ロググループ RDSOSMetrics を元にした、拡張モニタリングログの表示
監視のための OS プロセスリストの表示

RDS インスタンスでワークロードを実行し、CloudWatch メトリクスと拡張モニタリングメトリクスの両方をモニタリングします。拡張モニタリングのメトリクスは CloudWatch メトリクスではなく CloudWatch ログに保存されます。拡張モニタリングにかかる費用は、RDS インスタンスから転送されるデータ量、拡張モニタリングの解像度、ログファイルの保持ポリシーなどの要因によって異なります。詳細については、「拡張モニタリングのコスト」を参照してください。

前提条件

テストでは、次のインスタンスとストレージ構成を使用しました。

Amazon RDS for MySQL エンジンバージョン — 8.0.32
インスタンスクラス — db.t2.medium
ストレージタイプ — gp2
ストレージサイズ — 20GB
クライアント — RDS インスタンスと同じ VPC にある Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでホストされている MySQL Workbench (バージョン 8.0) ツール

Amazon RDSで拡張モニタリングを設定する

拡張モニタリングには、OS メトリクス情報を CloudWatch Logs に送信するための、 AWS Identity and Access Management (IAM) ロールが必要です。このロールは、拡張モニタリングを有効にするときに作成することも、事前に作成することもできます。RDS インスタンスの拡張モニタリングを有効または無効にするには、次の手順を実行します。

Amazon RDS コンソールでインスタンスを選択し、インスタンスが既に存在する場合は [変更] を選択します。

新しい DB インスタンスを作成する場合も、以下の手順は同じです。

[追加設定] を展開します。
モニタリングセクションで、DB インスタンスの [拡張モニタリングの有効化] を選択します。

モニタリングロールでは、Amazon RDS が CloudWatch ログと自動的に通信できるようにするために作成した IAM ロールを選択するか、デフォルトを選択して、Amazon RDS に rds-monitoring-role という名前のロールを作成させます。

[詳細度] では、DB インスタンスまたはリードレプリカのメトリクスが収集される時間の間隔を秒単位で選択します。このパラメーターは、1 秒、5 秒、10 秒、15 秒、30 秒、または 60 秒に設定できます。

または、AWS コマンドラインインターフェイス (AWS CLI) コマンドを使用して拡張モニタリングを有効にすることもできます。詳細については、「拡張モニタリングのオンとオフを切り替える」を参照してください。

RDS for MySQL インスタンスでワークロードを実行する

このテストでは、10,000 件のレコードを 2 つのステップ (それぞれ 5,000 件) で 5 秒の遅延を挟んで挿入します。この目的は、RDS for MySQL インスタンスの急激な負荷上昇をシミュレートし、後で拡張モニタリングのメトリクスからスパイクを調べることです。こういったスパイクは、RDS サービスがデフォルトで CloudWatch にパブリッシュするデフォルトのメトリクスでは観察できない場合があります。

MySQL Workbench などのクライアントから MySQL 用 Amazon RDS に接続します。

MySQL Workbench から Amazon RDS for MySQL に接続する方法については、「MySQL Workbenchからの接続」または「Amazon RDS で MySQL データベースを作成して接続する」を参照してください。

次のコマンドを実行して、MySQL Workbench または他のお好みのクライアントを使ってデータベースを作成します。

Create database testdb;

テーブルを作成します。

use testdb;
create table test1 (
id int not null auto_increment primary key,
col1 varchar(10),
col2 varchar(10)
) engine = InnoDB;

次のスクリプトを実行して、5 秒ごとにテーブルにデータを挿入します。

Drop procedure if exists testdata;
delimiter //
create procedure testdata (in num int)
begin
declare i int default 0;
while i < num do
insert into test1 (col1,col2) values ('col1_value','col2_value');
set i = i + 1;
end while;
end //
delimiter ;

call testdata (5000);

DO SLEEP(5);

Drop procedure if exists testdata;
delimiter //
create procedure testdata (in num int)
begin
declare i int default 0;
while i < num do
insert into test1 (col1,col2) values ('col1_value','col2_value');
set i = i + 1;
end while;
end //
delimiter ;

call testdata (5000);

メトリクスの比較

このセクションでは、CloudWatch にパブリッシュされたデフォルトのメトリクスと RDS 拡張モニタリングによって生成されたメトリクスを比較して、前述のワークロードの主要なメトリクスをいくつか調べます。

WriteIOPS: CloudWatch

10,000 件のレコードが、5 秒の遅延をはさんで 2 回にわけて RDS for MySQL インスタンスに挿入されたとき、次の CloudWatch グラフに示すように、CloudWatch メトリクスでは WriteIOPS が約 530 であることが示されました。Amazon RDS は、メトリクスデータを 1 分間隔で CloudWatch に送信することに注意してください。そのため、グラフには 1 分未満の急上昇があったとしても表示されません。

WriteIOPS: 拡張モニタリング

同じワークロードにおいて、拡張モニタリングでは WriteIOPS が約 1600 と表示されます。これは、このデモでは拡張モニタリングの解像度が1秒に設定されているため、拡張モニタリングのアドオン機能が提供する最も詳細なデータが得られるためです。次のスクリーンショットは、拡張モニタリングの解像度が高いために1分未満のスパイクが発生している、拡張モニタリングによる書き込み IO/秒を示しています。ディスク I/O とファイルシステムの集計グラフを表示する場合、rdsdev デバイスは、すべてのデータベースファイルとログが保存されている /rdsdbdata ファイルシステムに関連付けられます。filesystem デバイスは、オペレーティングシステムに関連するファイルが保存されている / ファイルシステム ( root とも呼ばれる) に関連しています。

CPU 使用率: CloudWatch

同じワークロードでの CloudWatch の CPU 使用率についても同じ傾向が見られます。1 分の精度で最大値は約 12% と報告されます。次のスクリーンショットは、CloudWatch からの CPU 使用率を示しています。

CPU 合計: 拡張モニタリング

一方、拡張モニタリングでは、より短い1 秒単位の解像度の機能により、CPU 使用率が約 50% と報告されています。次のスクリーンショットは、拡張モニタリングによる CPU 合計を示しています。

CPU Nice:拡張モニタリング

インスタンス上の、ユーザのワークロードによる CPU 使用率を意味する CPU Niceなどのメトリクスを確認したい場合、拡張モニタリングでは次のグラフが表示されます。同様に、アクティブメモリ、空きメモリ、空きスワップ、スワップイン、スワップアウト等々のグラフも表示されます。

観察のまとめ

拡張モニタリングは、OS レベルのきめ細かな1分未満の解像度のメトリクスを監視するのに役立ちます。拡張モニタリングのこの解像度の機能は、Amazon RDS が 1 分間隔で平均化したメトリクスデータを CloudWatch に送信するため、CloudWatch ではキャプチャされない、1 分未満の間でスパイクするワークロードを監視する場合に便利です。たとえば、テストの結果より、CloudWatch では WriteIOPS の使用率が高い（ピークは 1,600 IOPS）ことは確認されていません。ReadIOPS が同様のレベルまで上昇したとしても、同じ現象が予想されます。このため、拡張モニタリングを CloudWatch のデフォルトメトリクスと組み合わせて使用すると、包括的かつ詳細なトラブルシューティングを実行するのに役立ちます。

さらに、CPU Nice グラフに見られるように、拡張モニタリングからさまざまなメトリクスのサブコンポーネントのグラフを確認することもできます。拡張モニタリングのダッシュボードに表示するグラフを選択するには、[グラフを管理] タブを開いてサブコンポーネントを選択します。

拡張モニタリングのその他の機能

RDSインスタンス上でデータがストライピングされるボリュームの数を知る必要がある場合があります。この情報は、スロットリング、レイテンシー、およびその他のパフォーマンス関連の問題に対するトラブルシューティングに役立ちます。

次のスクリーンショットの中で、RDS インスタンスに 4 つのボリュームがアタッチされていることがわかります。Amazon RDS for SQL Server では、サイズに関係なくアタッチされるボリュームは 1 つだけです。アタッチするボリュームのタイプに応じて、それぞれのスループットと IOPS の制限が適用され、Amazon RDS のパフォーマンスにおいてに大きな役割を果たします。

次のスクリーンショットは、拡張モニタリングによる物理書き込み IO/秒を示しています。

CloudWatch のロググループ

拡張モニタリングでは、ロググループ RDSOSMetrics 上で、生成されたログが保持されます。これらのログには JSON 形式のデータが含まれており、CloudWatch コンソールと AWS CLI で表示できます。ログストリームの各ログには、RDS インスタンスに関連するデータの配列が含まれています。ロググループ RDSOSMetrics で生成された RDS インスタンスログを表示するには、次の手順に従います。

CloudWatch コンソールのナビゲーションペインで [ロググループ] を選択します。
RDS インスタンスに対応するログストリームを選択します (ログストリームは RDS DBリソースIDと同じ名前です)。
時間範囲のフィルターに基づいて調査に必要なログを選択します。

次の例には、cpuUtilization:nice、memory:buffersなどのすべてのメトリクスの詳細な値が含まれています。

{
    "engine": "MYSQL",
    "instanceID": "yyyy",
    "instanceResourceID": "xxxx",
    "timestamp": "2023-05-01T20:36:02Z",
    "version": 1,
    "uptime": "00:27:36",
    "numVCPUs": 4,
    "cpuUtilization": {
        "guest": 0,
        "irq": 0,
        "system": 0.3,
        "wait": 0,
        "idle": 99.3,
        "user": 0.3,
        "total": 0.9,
        "steal": 0,
        "nice": 0.3
    },
    "loadAverageMinute": {
        "one": 0.04,
        "five": 0.03,
        "fifteen": 0.04
    },
    "memory": {
        "writeback": 0,
        "hugePagesFree": 0,
        "hugePagesRsvd": 0,
        "hugePagesSurp": 0,
        "cached": 716380,
        "hugePagesSize": 2048,
        "free": 13573744,
        "hugePagesTotal": 0,
        "inactive": 2026324,
        "pageTables": 7744,
        "dirty": 848,
        "mapped": 107644,
        "active": 267504,
        "total": 16069100,
        "slab": 72004,
        "buffers": 140440
    },
    "tasks": {
        "sleeping": 111,
        "zombie": 0,
        "running": 0,
        "stopped": 0,
        "total": 111,
        "blocked": 0
    },
    "swap": {
        "cached": 0,
        "total": 16776188,
        "free": 16776188,
        "in": 0,
        "out": 0
    },
    "network": [
        {
            "interface": "eth0",
            "rx": 910,
            "tx": 12785
        }
    ],
    "diskIO": [
        {
            "writeKbPS": 16,
            "readIOsPS": 0,
            "await": 1,
            "readKbPS": 0,
            "rrqmPS": 0,
            "util": 0.8,
            "avgQueueLen": 0,
            "tps": 4,
            "readKb": 0,
            "device": "rdsdev",
            "writeKb": 16,
            "avgReqSz": 8,
            "wrqmPS": 0,
            "writeIOsPS": 4
        },
        {
            "writeKbPS": 4,
            "readIOsPS": 0,
            "await": 1,
            "readKbPS": 0,
            "rrqmPS": 0,
            "util": 0.4,
            "avgQueueLen": 0,
            "tps": 1,
            "readKb": 0,
            "device": "filesystem",
            "writeKb": 4,
            "avgReqSz": 8,
            "wrqmPS": 0,
            "writeIOsPS": 1
        }
    ],
    "physicalDeviceIO": [
        {
            "writeKbPS": 16,
            "readIOsPS": 0,
            "await": 1,
            "readKbPS": 0,
            "rrqmPS": 0,
            "util": 0.8,
            "avgQueueLen": 0,
            "tps": 3,
            "readKb": 0,
            "device": "nvme1n1",
            "writeKb": 16,
            "avgReqSz": 10.67,
            "wrqmPS": 1,
            "writeIOsPS": 3
        }
    ],
    "fileSys": [
        {
            "used": 372316,
            "name": "",
            "usedFiles": 251,
            "usedFilePercent": 0,
            "maxFiles": 13107200,
            "mountPoint": "/rdsdbdata",
            "total": 205270252,
            "usedPercent": 0.18
        },
        {
            "used": 2233064,
            "name": "",
            "usedFiles": 39420,
            "usedFilePercent": 6.02,
            "maxFiles": 655360,
            "mountPoint": "/",
            "total": 10230600,
            "usedPercent": 21.83
        }
    ]

ログは、ログストリームデータを消費できるその他のAWSサービスや、処理および可視化ツールを提供するサードパーティーツールに転送することができ、それぞれ、Amazon Kinesis Data Firehose や Amazon QuickSight といったものが挙げられます。

監視のためのOSプロセスリスト

DB インスタンスで実行されているプロセスの詳細を確認したい場合は、Amazon RDS コンソールの RDS インスタンスの [モニタリング] タブにある [OS プロセスリスト] を選択します。

プロセスリストビューに表示される拡張モニタリングメトリクスは、RDS 子プロセス、RDS プロセス、および OS プロセスに分類されます。

CloudWatch と拡張モニタリングの測定値には違いがあるかもしれません。詳細については、「CloudWatch と拡張モニタリングのメトリクスの相違点」を参照してください。

拡張モニタリングにより、ネットワーク、スワップ、ProcessListなどの新しいメトリクスにアクセスできます。拡張モニタリング専用のこれらのメトリクスは、トラブルシューティングを行っている間に、OS がどのように動作していたかをより深く理解するのに役立ちます。拡張モニタリングで利用できるメトリクスを確認するには、「拡張モニタリングの OS メトリクス」を参照してください。

Amazon RDS モニタリングツールに関する考慮事項

Amazon RDS は、データベースパフォーマンスのモニタリングとトラブルシューティングのため、拡張モニタリング、CloudWatch、Performance Insights の 3 つの主要なツールを提供します。これらのツールは、RDS に関する特定の問題のトラブルシューティングのため、それぞれ独自のユースケースがあります。

拡張モニタリングを使用すると、データベースエンジンが実行されている OS に関する非常に詳細なメトリクス、細かく分けられたメトリクス (CPUUtilization.nice、memory.free など)、および CloudWatch に送られたログを取得して、さらなる分析と統合が可能になります。

一方、CloudWatch は、RDS サービスによって公開されたデフォルトのメトリクスを 1 分単位で受け取り、インスタンスの動作を視覚的に確認するために幅広く使用されます。このツールには、グラフの重ね合わせ、軸の切り替え、数式計算、粒度の変更 (1 分、5 分、15 分)、CloudWatch 保持ポリシーで定義されている履歴データ (数か月にさかのぼる) の表示などの機能もあり、Amazon RDS でのリソース使用や顧客ワークロードの傾向を特定するのに非常に役立ちます。

拡張モニタリングと CloudWatch にはそれぞれ独自のメトリクスがあります。拡張モニタリングには、他のメトリクスに加えて物理デバイスのメトリクスがあります。一方、CloudWatch には、BurstBalance、DatabaseConnections など、使用パターンの特定に役立つ重要なメトリクスがあります。

Performance Insights では、データベースの負荷を評価して最適化できます。また、1 分未満のメトリクスも提供され、1 秒間のメトリクスは最大 2 年間保持されます。待機イベントや SQL クエリなど、複数のディメンションを使用して細かく分析できます。また、Performance Insightsでは、Amazon RDS の負荷を視覚化し、その原因となっているクエリの種類、クエリの発信元、原因となっているユーザーを特定するのに役立ちます。

クリーンアップ

追加コストが発生しないように、このデモンストレーションに使用したリソースはすべて削除してください。

RDS インスタンスを削除します。
ローカルホストからクライアントツールを削除します。
RDS インスタンスの拡張モニタリングに関連するログストリームを削除します。

RDSOSMetrics はデフォルトで 30 日間保持されることに注意してください。

まとめ

この記事では、Amazon RDS for MySQL のワークロードがスパイクするデモを使って、インスタンスのパフォーマンスをより包括的かつ正確に把握するために、拡張モニタリングの詳細なメトリクスを使用することの重要性を強調しました。

この投稿について質問やコメントがある場合は、コメントセクションに残してください。

著者について

Abdul Sarker は、AWS で 2 年間にわたってクラウドサポートエンジニアを務めています。AWS クラウドで優れたカスタマーエクスペリエンスを提供することに重点を置き、外部のお客様と協力して、Amazon RDS インフラストラクチャのトラブルシューティング、AWS DMS プロジェクトの支援、社内文書や記事の作成と改善など、さまざまなシナリオを処理しています。

Nirupam Datta は AWS のクラウドサポート DBA です。彼はAWSに約3年半在籍しています。データベースエンジニアリングとインフラストラクチャアーキテクチャで 11 年以上の経験を持つNirupamは、Amazon RDSのコアシステムと Amazon RDS for SQL Server の専門家でもあります。彼はお客様に技術支援を提供し、AWS クラウドへの移行、最適化、移行を支援しています。

翻訳はクラウドサポートエンジニアの立野が担当しました。原文はこちらです。

Amazon Web Services ブログ