Amazon CloudWatch Database Insights によるデータベースのモニタリング
はじめに
Amazon CloudWatch Database Insights は、Amazon RDS および Aurora データベース向けの統合モニタリングソリューションです。データベースメトリクス、クエリ分析、ログ、イベント、アプリケーションテレメトリを CloudWatch コンソール内の単一のエクスペリエンスに統合し、データベース層で何が起きているかを把握するために複数のツールを切り替える必要をなくします。
この記事では 、Database Insights が提供する機能、2 つの動作モードの選択方法、データベースを効果的に監視するための実践的なガイダンス、および採用前に把握しておくべき制限事項について説明します。
Database Insights とは何ですか？
Database Insights は Amazon RDS Performance Insights を基盤として構築され、フリート全体のモニタリング、ログの相関分析、ロック分析、実行プランのキャプチャ、アプリケーションレベルの統合によって機能を拡張しています。これは、スタンドアロンの Performance Insights コンソールエクスペリエンス（まもなくサポート終了）の後継となるものです。
コアコンセプトは DB Load です。これは、任意の時点におけるデータベースのアクティブセッションの平均数を表します。DB Load がインスタンスの vCPU 数を超えると、データベースは過負荷状態になります。Database Insights はこのメトリクスを可視化し、複数のディメンション（SQL、待機イベント、ユーザー、ホスト、アプリケーション）でスライスすることで、パフォーマンス問題の根本原因を迅速に特定できます。
スタンダードモード vs. アドバンストモード
Database Insights は 2 つの階層で動作します。Standard モードはデフォルトで有効になっており、追加コストはかかりません。Advanced モードでは、15 か月の保持期間を設定した Performance Insights を有効にする必要があり、vCPU 時間（プロビジョニング済み）または ACU 時間（サーバーレス/リミットレス）に基づいて料金が発生します。
| 機能 | スタンダード | アドバンスト |
|---|---|---|
| ディメンション別の DB Load 主要要因の分析 | ✔ | ✔ |
| メトリクスのクエリ、グラフ化、アラーム（7 日間保持） | ✔ | ✔ |
| 機密性の高いディメンションに対するきめ細かい IAM アクセス制御 | ✔ | ✔ |
| フリート全体のモニタリングビュー | ✘ | ✔ |
| OS プロセス分析（Enhanced Monitoring） | ✘ | ✔ |
| SQL ロック分析（15 か月間保持） | ✘ | ✔ (Aurora PG) |
| SQL 実行プラン分析（15 か月間保持） | ✘ | ✔ (Aurora PG、Oracle、SQL Server) |
| クエリごとの統計の可視化 | ✘ | ✔ |
| スロー SQL クエリ分析 | ✘ | ✔ |
| Application Signals 統合（サービスの呼び出し） | ✘ | ✔ |
| 統合テレメトリダッシュボード（メトリクス、ログ、イベント） | ✘ | ✔ |
| Performance Insights カウンターメトリクスの自動インポート | ✘ | ✔ |
| CloudWatch 内の RDS イベント | ✘ | ✔ |
| オンデマンドパフォーマンス分析レポート | ✘ | ✔ |
| クロスアカウント・クロスリージョンモニタリング | ✘ | ✔ |
データ保持期間:
- スタンダード: Performance Insights データの保持期間は 7 日間です。
- アドバンスト: Database Insights が収集するすべてのメトリクスの保持期間は 15 か月間です。
主要機能の説明
フリートヘルスダッシュボード
Fleet Health Dashboard は、すべての RDS および Aurora インスタンスをクロスアカウント・クロスリージョンで 1 つ の画面に俯瞰的に表示します。ハニカムビジュアライゼーションは、vCPU キャパシティに対する DB 負荷に基づいて、インスタンスをヘルス状態（High、Warning、Ok、Idle）ごとに分類します。タグ（environment、service、team）でフィルタリングしたり、カスタムフリートビューを保存したりすることができます。Top-10 チャートでは、最も負荷の高いインスタンス、そのトップクエリ、およびトップ待機イベントを一目で確認できます。
数百のデータベースを管理する責任があり、どれに注意が必要かを素早く特定する必要がある場合に、ここから始めます。
DB 負荷分析 (調査ワークベンチ)
インスタンスダッシュボードの「DB Load Analysis」タブは、トラブルシューティングの大部分の時間を費やす場所です。5W に答えます。
- WHAT — SQL でスライスして、どのクエリが負荷を生成しているかを確認します。
- WHO — ユーザーまたはアプリケーションでスライスして、責任者を特定します。
- WHERE — ホストでスライスして、ソースマシンを見つけます。
- WHEN — タイムラインには、問題がいつ開始および停止したかが正確に表示されます。
- WHY — 調査結果を関連付けてアクションを実行します。
Top SQL テーブルは、負荷への貢献度によってクエリをランク付けし、calls/sec、平 均レイテンシ、検査された行数、およびプラン数を表示します。
ロック分析
Aurora PostgreSQL および RDS for PostgreSQL で利用可能です。Database Insights はロックスナップショットを 15 秒ごとにキャプチャし、ロックツリーとして可視化します。親ノードはブロッキングセッション、子ノードはウェイターを表します。ブロッキング SQL、継続時間、および影響を受けるダウンストリームセッションの数を確認できます。DB Load チャートの「Sliced by: Blocking SQL」オプションは、どのステートメントが時間の経過とともにロック競合を引き起こしているかを示します。
実行プラン分析
Aurora PostgreSQL (v14.10+、v15.5+)、RDS for Oracle、および RDS for SQL Server で利用可能です。Top SQL テーブルの Plans Count 列には、各クエリに存在する個別の実行プランの数が表示されます。プランを並べて比較することで、プランの変更がパフォーマンスの低下を引き起こした時点を特定できます。プラン数が多い場合は、オプティマイザーの不安定性を示しています。
データベーステレメトリ
以下の内容を含む統合タブ：
- メトリクス — CloudWatch、OS、エンジンカウンターメトリクスのカスタマイズ可能なダッシュボード。
- ログ — CloudWatch Logs にエクスポートされたデータベースログ（インラインで表示可能）。
- OS プロセス — Enhanced Monitoring によるプロセスごとの CPU/メモリ情報。
- スロー SQL クエリ — パターン別にグループ化され、頻度順にランク付けされたスロークエリ。
- イベント — RDS の運用イベント（フェイルオーバー、メンテナンス、設定変更）。
サービスの呼び出し (CloudWatch Application Signals 統合)
このアプリケーションパフォーマンスモニタリング統合は、どのアップストリームマイクロサービスがデータベースを呼び出しているかを、可用性、レイテンシ、エラーレート、リクエストボリュームとともに表示します。これにより、「データベースが遅い」と「この特定のサービスと関数が原因である」というギャップを埋めることができます。
オンデマンドパフォーマンス分析
任意の時間ウィンドウを選択し、Database Load チャートから「Analyze Performance」を選択することで、ML を活用した自動分析をトリガーできます。Database Insights は機械学習モデルを活用して、選択した期間をデータベースの通常のベースライン動作と比較し、SQL ステートメント、待機イベント、ホスト、ユーザーなどの複数のディメンションにわたってスキャンを行い、異常と根本原因（例：「CPU から I/O への待機イベントのシフトにより DB 負荷が 4 倍に増加」）を明らかにします。各レポートには優先順位付けされた調査結果と具体的な修復ガイダンスが含まれており、診断にかかる平均時間を数時間から数分に短縮します。レポートは 15 か月のメトリクス履歴とともに保持されるため、インシデント後のレビュー時に簡単に取得できます。
制限事項
Database Insights を採用する前に、以下の制約事項を確認してください。
エンジンと機能の可用性
- ロック分析は、Aurora PostgreSQL および RDS for PostgreSQL でのみ使用できます。
- 実行プラン分析は、Aurora PostgreSQL (v14.10+/v15.5+)、RDS for Oracle、および RDS for SQL Server でのみ使用 できます。
- Advanced モードのすべての機能がすべての AWS リージョンで利用できるわけではありません。
- Aurora PostgreSQL Limitless Database のサポートは存在しますが、機能セットが縮小されています（シャードグループレベルでのロック分析または実行プラン分析はありません）。
データと設定の要件
- スロー SQL 分析では、CloudWatch Logs へのデータベースログのエクスポートを有効にし、適切な DB パラメータを設定する必要があります(例：
log_min_duration_statementPostgreSQL の場合、slow_query_logMySQL の場合)。 - OS プロセスデータでは、Enhanced Monitoring を有効にする必要があります（追加コストが発生します）。
- 実行プラン (Aurora PostgreSQL) では、
aurora_compute_plan_idに設定されたパラメーターon。実際のプラン（推定値との比較）には、さらに次のものが必要です。aurora_stat_plans.with_analyze. - Calling Services では、アプリケーションに CloudWatch Application Signals のインストルメンテーションが必要です。
pg_stat_statementsAurora PostgreSQL 10 以降ではデフォルトでロードされますが、SQL テキストは次の箇所で切り捨てられます。track_activity_query_size(デフォルト 1,024 バイト)。長いクエリは不完全に表示される場合があります。
運用上の制限事項
- ロック分析スナップショットは 15 秒ごとに取得されます。非常に短命なロックはキャプチャされない場合があります。
- Fleet Health Dashboard では、保存されたフリートビューに Advanced モードが必要です。
- クロスアカウントモニタリングには、モニタリングアカウントとソースアカウントの両方で CloudWatch Observability Access Manager (OAM) のセットアップが必要です。
- パフォーマンス分析レポートは、開始時刻が保持期間外になると削除されます。
- Database Telemetry タブのダッシュボードカスタマイズは、アカウントごと、リージョンごと、エンジンタイプごとに適用されます。インスタンスごとではありません。
コストに関する考慮事項
- Advanced モードは、vCPU 時間（プロビジョニング済み）または ACU 時間（サーバーレス/リミットレス）ごとに料金が発生します。大規模なフリートでは、コストが大きくなる場合があります。
- Enhanced Monitoring には別途料金が発生します。
- ログエクスポートを有効にすると、CloudWatch Logs のインジェストおよびストレージコストが適用されます。
- クラスター内の個々のインスタンスに対して Advanced モードを有効にする方法はなく、DB クラスター 全体に適用されます。
ベストプラクティス
スタンダードから始め、戦略的にアップグレードする
Standard モードは無料で、7 日間の保持期間による DB 負荷分析を提供します。15 か月の保持期間、フリートビュー、ロック分析、または実行プランのキャプチャが必要な本番環境の重要なデータベースでは、Advanced モードを有効にしてください。すべての開発/テストインスタンスに Advanced モードが必要なわけではありません。
インスタンスに一貫したタグを付ける
Database Insights のフリートビューはタグでフィルタリングします。一貫したタグ付け戦略を採用してください(例： environment, service, team) これにより、「支払いサービスのすべての本番データベース」のような意 味のあるフリートビューを作成できます。
ログエクスポートを早期に有効化する
低速 SQL 分析とデータベーステレメトリのログセクションは、CloudWatch Logs へのログエクスポートを有効にしている場合にのみ機能します。これは遡及的に行うのではなく、インスタンス作成時に設定してください。エクスポートを有効にする前の過去の低速クエリを分析することはできません。
DB 負荷のアラームを設定する
CloudWatch アラームを作成します。 DBLoad インスタンスの vCPU 数に対するメトリクスの相対値です。vCPU 数を超える持続的な DB 負荷は、セッションがキューに入っていることを意味します。顧客が気づく前にアラートを設定してください。
Who/What/Where/When フレームワークを使用する
パフォーマンスの問 題を調査する際は、「Sliced by」ドロップダウンを体系的に確認します。
- SQL — 問題のあるクエリを特定します。
- Application または User — 実行しているユーザーを特定します。
- Host — 発生元のホストを特定します。
- Timeline — 問題が発生した時期を特定します。
この体系的なアプローチにより、無駄な方向に迷い込むことを防ぐことができます。
Aurora PostgreSQL の実行プランキャプチャを有効にする
設定 aurora_compute_plan_id = on クラスターパラメーターグループで設定します。プランの回帰は、突然のパフォーマンス低下の最も一般的な原因の 1 つであり、プランキャプチャなしでは手探り状態になります。オーバーヘッドは最小限です。
オンデマンド分析をインシデント後のレビューに使用する
パフォーマンスインシデン トが発生した後は、影響を受けた時間帯のパフォーマンス分析レポートを生成してください。このレポートは、COE やポストモーテムに添付できる自動化されたサマリーを提供し、15 か月間保持されます。
マルチアカウントアーキテクチャにおけるクロスアカウントモニタリングの活用
組織が異なるサービスや環境に対して別々の AWS アカウントを使用している場合は、OAM を使用して CloudWatch クロスアカウントオブザーバビリティを設定してください。これにより、中央モニタリングアカウントがすべてのアカウントとリージョンにわたって Fleet Health Dashboard を確認できるようになります。これは、共有データベースインフラストラクチャを管理するプラットフォームチームにとって不可欠です。
SQL テキストへのアクセスを制限する
IAM ポリシーを使用して、SQL テキストディメンションへのアクセスを制限してください。データベースクエリには機密データ（顧客 ID、WHERE 句内のメールアドレスなど）が含まれる場合があります。完全な SQL 可視性は DBA のみに付与し、他のロールは集計メトリクスのみにアクセスを制限してください。
規範的ガイダンス: 今日すべきこと
はじめての方へ：
- Standard モードがアクティブであることを確認します — デフォルトで有効になっているはずです。CloudWatch → Insights → Database Insights に移動し、インスタンスが表示されていることを確認します。
- 本番データベースの CloudWatch Logs へのログエクスポートを有効にします。
- 以下の項目に対して CloudWatch Alarms を設定します。
CPUUtilization,DatabaseConnections、およびDBLoad. - インスタンスに環境、サービス、チームのタグをタグ付けします。
本番ワークロードを実行している場合
- 本番クラスターで Advanced モードを有効にする — 15 か月の保持期間とフリートビューは、本番環境のコストに見合う価値があります。
- OS レベルの可視性のために Enhanced Monitoring を有効にする。
- 設定
aurora_compute_plan_id = on(Aurora PostgreSQL) 実行プラン取得用。 - フリートヘルスビューを作成し、本番タグでフィルタリングします。
- アプリケーションをインストルメントして、CloudWatch Application Signals で Calling Services ビューを有効にします。
大規模なフリートを管理している場合：
- OAM を使用してクロスアカウントのクロスリージョンモニタリングを設定します。
OAM の仕組み：
- モニタリングアカウント — チームがダッシュボードを閲覧する中央アカウントです。他のアカウントからのデータを受け入れる「シンク」をここで作成します。
- ソースアカウント — 実際にデータベースを実行するアカウントです。各ソースアカウントからモニタリングアカウントのシンクへ「リンク」を作成し、CloudWatch データの読み取り権限を付与します。
リンクされると、モニタリ ングアカウントはすべてのソースアカウントのメトリクス、ログ、トレースをローカルであるかのように確認できます。これには、リンクされたすべてのアカウントとリージョンにわたるインスタンスを単一のビューで表示する Database Insights Fleet Health Dashboard も含まれます。 2. チーム、サービス、または環境ごとにセグメント化された複数のフリートビューを作成します。 3. トリアージワークフローを確立します: Fleet Health → ホットインスタンスの特定 → DB Load Analysis → 誰が/何を/どこで/いつ → アクションを実行。 4. 最もトラフィックの多いインスタンスに対して定期的なオンデマンド分析を実行し、インシデントになる前に遅いリグレッションを検出します。
まとめ
CloudWatch Database Insights は、これまで複数のツール（Performance Insights、CloudWatch Metrics、CloudWatch Logs、RDS コンソール）を必要としていた作業を、単一のガイド付きエクスペリエンスに統合します。Standard モードでは、コストなしで即座に可視性を確保できます。Advanced モードでは、本格的な本番環境モニタリングに必要な深度が追加されます。フリートビュー、ロックツリー、実行プラン、スロークエリ分析、15 か月間の保持期間などが含まれます。
考え方の重要な転換は、事後対応型（「データベースが遅い、SSH で接続して pg_stat_activity に対してクエリを実行しよう」）から事前対応型（「フリート全体の健全性を確認し、任意のインスタンスに ドリルダウンして、単一のコンソールから 2 分以内に誰が/何を/どこで/いつを把握できる」）への移行です。Database Insights は、カスタムツールやサードパーティのソリューションを必要とせずに、そのワークフローを実現します。