Amazon RDSのモニタリングとデータベース負荷分析

Amazon RDSの性能問題を調べるときは、「インスタンス全体がどれほど忙しいか」と「どの処理がデータベースを忙しくしているか」を分けて見ます。CPU使用率やストレージ空き容量のような標準メトリクスは、異常が起きた時間やリソースの種類をつかむのに役立ちます。OS上のプロセスやメモリの状態まで調べる場合は拡張モニタリング（Enhanced Monitoring）、SQLや待機イベントの影響を時間軸で分析する場合はPerformance Insightsと、その分析機能を提供するCloudWatch Database Insightsが候補になります。

観測する層が異なるため、これらは単純な代替関係ではありません。アプリケーションの応答が遅いとき、標準メトリクスで発生時刻とリソースをつかみ、Database Insightsで負荷の原因となるSQLや待機を絞り込み、必要なら拡張モニタリングでOSのCPUやメモリ、プロセスの状態を確認します。

監視する階層を選ぶ

手段	主に見える情報	適した問い
Amazon CloudWatchの標準RDSメトリクス	CPU使用率、接続数、読み書きIOPS、レイテンシー、空きストレージなど	いつ異常が始まり、どのリソース指標が変化したか
拡張モニタリング	OSレベルのCPU内訳、メモリ、ファイルシステム、プロセスなど	OS上でCPUやメモリを消費しているものは何か
Performance Insights / CloudWatch Database Insights	データベース負荷、SQL、待機イベントなど	どのSQLや待機要因がデータベース負荷に影響しているか

標準メトリクスは、データベースの全体的な状態を継続的に監視し、CloudWatchアラームで閾値超過を通知する用途に向きます。メトリクスは一定間隔の集計値なので、インスタンスの負荷が上がったことは分かっても、その時間に実行されていたSQLや、OS内部のどのプロセスが原因かまでは分からない場合があります。RDSのエンジンや設定によって利用できるメトリクスは異なるため、対象DBのCloudWatchメトリクス一覧を確認します。

拡張モニタリングは、RDS DBインスタンスを動かすOSの情報を収集します。CPU使用率の内訳、メモリやスワップの状況、プロセス単位の使用量など、標準メトリクスよりOSに近い情報を確認できます。収集間隔は秒単位で設定できますが、これはサブ秒の状態を測定する機能ではありません。データはCloudWatch Logsに送られ、保持期間やログの取り扱いを含めて運用します。利用にはモニタリングロールなどの権限設定が関係し、料金や対応エンジンも構成に応じて確認が必要です。

拡張モニタリングはOSの状態を示しますが、SQLを解析して遅いクエリを特定する機能ではありません。反対に、Performance InsightsやDatabase Insightsはデータベース負荷やクエリに着目するもので、OSのすべてのプロセス情報を置き換えるものではありません。例えばメモリ圧迫やOSプロセスのCPU消費が疑われるなら拡張モニタリング、特定のSQLが負荷を押し上げているか調べたいならDatabase Insightsを使います。

Performance InsightsとDatabase Insights

Performance Insightsは、データベースエンジンの性能データを収集し、DB負荷を時間軸で見ながらSQLや待機イベントなどの切り口で分析する機能です。データベース負荷は、アクティブなセッションがCPU上で実行中か、I/Oやロックなどの処理を待っているかを含めて捉えます。負荷の高い時間帯にどのSQLが目立つかを調べることで、インスタンスのCPU使用率だけを見ていると分からないボトルネックを探せます。

AWSはデータベース性能の可視化と診断をCloudWatch Database Insightsにまとめて提供しています。Performance Insightsで使われてきたデータベース負荷やSQL分析の考え方は、Database Insightsのダッシュボードでも活用されます。新しい監視構成では、RDSコンソールのPerformance Insights専用画面だけを前提にせず、CloudWatch Database Insightsの現在のモード、エンジン対応状況、保持条件を確認します。既存の設定やAPIを使う場合も、AWSの移行情報とサポート状況を確かめてください。

Performance Insightsの従来の保持設定では、直近7日間が標準の保持期間で、有料の長期保持を選ぶと最大2年間のデータを保持できる設定がありました。ただし、この上限をDatabase Insightsのすべてのモードや現行のRDSエンジンに共通する値として扱ってはいけません。Database Insightsではモードにより保持期間、機能、料金が異なる場合があります。現在選択できる保持期間は、対象DBの設定とAWSのDatabase Insights料金情報で確認します。保存期間を長くすると過去の傾向比較には便利ですが、保管に伴う費用も評価します。

DB負荷と待機イベントから原因を絞る

Database Insightsでは、問題が起きた時間帯を選び、DB負荷の変化とSQLや待機イベントを関連付けて調べます。たとえば、動画配信サービスで新作の公開直後にカタログAPIの応答が遅くなった場合、該当時刻にDB負荷が上がったかを確認します。負荷の内訳で特定の検索SQLが大きな割合を占めているなら、そのSQLの実行回数や実行計画、インデックスを調べる手掛かりになります。

待機イベントは、データベースセッションが処理を進めずに何を待っていたかを表します。CPU待ちが目立つ場合は、同時実行数やCPUを多く使うクエリが関係している可能性があります。I/O関連の待機が多い場合は、読み込み・書き込みのパターンやストレージ性能、キャッシュ効率を確認します。ロックに関する待機が目立つなら、トランザクションの競合やロックを保持する時間を調べます。待機イベントは原因を確定するものではなく、次に調査する範囲を絞るための観測情報です。

時間軸を使うと、利用者やバッチ処理の増加とSQL負荷の変化を照らし合わせられます。高負荷が発生した期間を選び、負荷の寄与が大きいSQLと待機イベントを確認してから、クエリ単位の改善やインスタンス・ストレージの拡張を検討します。指標を見ずにDBインスタンスを大きくするだけでは、ロック競合や非効率なSQLといった原因が残ることがあります。

性能問題を段階的に調べる

1. 異常が起きた時間を特定する: CloudWatchメトリクスやアラームから、CPU使用率、接続数、I/O、空きストレージなどが変化した時刻を確認します。
2. データベース負荷を確認する: Database Insightsで同じ時間帯を表示し、DB負荷が上がったか、どのSQLや待機イベントの寄与が大きいかを確認します。
3. OS側の状態を確認する: SQL分析だけで説明できない場合やメモリ・プロセスの影響が疑われる場合は、拡張モニタリングでCPU内訳、メモリ、プロセス情報を確認します。
4. 原因に合わせて対処する: SQLやインデックスの見直し、トランザクション時間の短縮、接続数の調整、インスタンスやストレージの変更などを候補にします。
5. 変更後の効果を同じ指標で確かめる: 同様の負荷条件でDB負荷、待機イベント、レイテンシー、OSメトリクスを再確認します。

試験での見分け方

• OSレベルのCPU・メモリ・プロセス情報を詳しく見たい: 拡張モニタリングを使う。
• どのSQLがDB負荷を高めているか知りたい: Performance InsightsまたはCloudWatch Database Insightsで、時間帯ごとの負荷、SQL、待機イベントを調べる。
• アプリケーションの応答が遅く、問題の時間帯も分からない: まずCloudWatchの標準RDSメトリクスやアラームで、異常の時刻とリソース傾向を確認する。
• DB負荷の上昇と同じ時刻に特定SQLやI/O待ちが増えている: SQL、実行回数、実行計画、I/Oパターンを調査する。待機イベントだけで原因を断定しない。
• 拡張モニタリングでSQLのランキングを確認したい: 用途が異なる。SQLや待機イベントの分析にはDatabase Insightsを使う。
• Performance Insightsの保持期間は常に7日から最大2年と考える: 既定と従来の長期保持設定の目安であり、現行の保持期間や費用はDatabase Insightsのモードと対象エンジンで確認する。

AWS公式ドキュメント

• Amazon RDSの拡張モニタリング
• Amazon RDSのPerformance Insights
• Amazon CloudWatch Database Insights
• Amazon RDSのCloudWatchメトリクス
• Amazon CloudWatchの料金