なぜRDSの遅延原因が分からないのか？CloudWatchを超えてSQLを特定する実践的な監視術
Amazon RDSの運用中、突如としてパフォーマンスが悪化した経験はないでしょうか。CloudWatchでCPU使用率やI/Oの急増を捉えられても、「どのクエリが、何を原因として高負荷を招いているのか」という本質には届かず、結局のところインスタンス再起動やスペック増強で応急処置を施すパターンは珍しくありません。
RDS監視では、インフラ側のメトリクス（現象）と、データベース内部のクエリ動作（要因）との間に、標準ツールのみでは解消しづらい「可視化の隔たり」が生じています。
この記事では、ベテランDBエンジニアが障害発生時に必ず確認する主要メトリクスの関連性から、Performance Insightsを徹底活用したボトルネック究明法まで解説します。また、実行計画の時系列変化まで追跡する実践的な監視手法も紹介するので、ぜひ最後までご覧ください。
＼情シス向け！ “可観測性”で変わるデータベース運用についてはこちらの資料から／
目次[非表示]
RDS監視の標準メトリクスだけで原因特定が難しい理由
CloudWatchはAWS運用の基本ツールですが、データベース（DB）特有の深部で起きている事象を捉えるには、データ特性を正しく理解する必要があります。なぜ標準監視だけでは「原因不明」に陥りやすいのか、構造的な要因を深掘りします。
＼情シス向け！ “可観測性”で変わるデータベース運用についてはこちらの資料から／
リソース監視「CloudWatch」で見えるのは結果のみ
CloudWatchが提供するメトリクスは、CPU使用率やメモリ空き容量、ディスクI/Oといった「OS・ハードウェアリソースの消費結果」です。例えば、CPU使用率が100%に達している事象を確認できたとしましょう。しかし「特定の非効率なSQLによるフルスキャン」なのか、「同時実行数の急増によるロック競合」なのか、「統計情報の劣化による実行計画の変更」なのかは判別できません。
体温計で発熱していることを把握できても、原因がウイルス性なのか疲労なのかを特定するには精密検査が必要なのと同様に、CloudWatchはあくまで異常の「兆候」を知らせるためのツールであると認識すべきです。
1分間隔のサンプリングでは突発的なスパイクを見逃す
CloudWatchの標準モニタリングは、RDSでデフォルト1分間隔でデータをサンプリングします（高解像度カスタムメトリクスなら1秒単位も可能ですが、コストが増大します）。
しかし、DBトラブルの多くは数秒単位のバースト的なクエリ集中や、特定のトランザクションによる瞬間的なデッドロックから始まります。1分間の平均値としてデータが丸められてしまうと、グラフ上では緩やかな上昇にしか見えません。結果、現場のエンジニアが「体感としては重いのに、グラフ上では問題が見えない」という乖離（サイレント・パフォーマンス・ダウン）を引き起こす要因となります。
インフラ担当とDBAの視点の壁がトラブル解決を遅らせる
RDSの運用現場では、インフラ層を監視するSRE（Site Reliability Engineer）と、クエリやスキーマを管理するDBA（Database Administrator）の間で情報の分断が起きがちです。
インフラ担当の視点：「CPUやIOPSには余裕があるため、DBサーバー側に問題はない」と判断する
DBA/アプリ担当の視点：「アプリケーションのレスポンスが明らかに遅延しているため、DBのクエリに問題があるはずだ」と主張する
両者は、共通の指標（SQL実行レベルの相関データ）を持っていません。そのため、トラブル発生時の切り分けに多大な時間を要し、MTTR（平均修復時間）の長期化を招いています。
まず見るべき！トラブル時に直結する重要メトリクスと見方
トラブル発生時、闇雲に全てのグラフを見るのではなく、リソースの相関関係からボトルネックを迅速に絞り込む必要があります。
以下のメトリクス群を優先的に確認することで、問題の所在が「ストレージ」か「コンピューティング」か「アプリケーション」かを切り分けられるでしょう。
CPUUtilizationとRead/Write Latencyの相関関係
CPU使用率とディスクレイテンシの相関は、パフォーマンス分析の基本です。以下の表に基づき、現在のステータスを分類してください。
パターン | メトリクスの状態 | 推測される原因と対策 |
演算負荷型 | CPU高 / Latency低 |
|
I/Oボトルネック型 | CPU高 / Latency高 |
|
待機・ロック型 | CPU低 / Latency低 |
|
DatabaseConnectionsの急増が示す、待ち行列の正体
コネクション数の急増は、単純なアクセス増だけでなく「処理の滞留」を意味します。
セッションのスタック：特定の重いクエリが長時間排他ロックを保持する
後続クエリの待機：ロック解放を待つセッションが次々と増え、コネクション上限に達する
カスケード障害：DBの応答遅延がアプリ側のスレッドを消費し、システム全体がダウンする
メトリクスが急騰している際は、アクティブなセッションが何に「待たされているか（Wait Events）」を確認しましょう。
FreeableMemoryが減り続けるメモリプレッシャーの危険信号
FreeableMemoryは、OSレベルで自由に利用できるメモリ量を示します。減少した際のチェックポイントは、以下のとおりです。
SwapUsageの確認：メモリ不足によりスワップが発生していないか（1MBでも継続的なスワップがあれば致命的）
バッファキャッシュヒット率：メモリ不足により、ディスク読み取りが頻発していないか
一時ファイルの作成：ソート処理などがメモリに収まらず、WorkFilesをディスク上に作成していないか
SQLを特定するためのパフォーマンスインサイト活用術
AWSが提供する「Performance Insights（パフォーマンスインサイト）」は、RDS監視において「どのクエリが負荷の源か」を特定するために役立ちます。特に「DB負荷」という、独自の指標を読み解くことが重要です。
なお、Performance Insightsは2026年6月30日をもってサポートを終了し、CloudWatch Database Insightsに統合されます。Database Insightsでは、スタンダードモード（無料）で7日以上のデータ保持と実行計画機能が利用可能になり、アドバンストモード（有料）では15ヶ月のデータ保持が可能です。
「DB負荷（AAS）」を理解すればボトルネックが一目でわかる
パフォーマンスインサイトの核心指標であるAAS（Average Active Sessions：平均アクティブセッション）は「ある期間内に、平均して何個のセッションがアクティブ（実行中または待機中）であったか」を示す要素です。
例えば、AASが「5」であれば、常に5つのクエリが動いている状態を指します。もしRDSインスタンスの「最大CPU数（グラフ上の細い破線）」を超えている場合、物理的な処理能力を超えたリクエストが押し寄せており、ユーザー側では必ず待ち時間（遅延）が発生していることになります。
実行時間の長いSQL（Top SQL）を特定する手順
AASのグラフを確認した後、画面下部の「Top SQL」タブを利用して、具体的な原因クエリを特定します。
待機イベントの分類：グラフの色を確認する（例：青はCPU、薄茶色はIO、オレンジはLock）
SQLの絞り込み：負荷が高い順に並んだSQLリストから、特定の時間帯にAASを押し上げているクエリを選択する
統計情報の確認：そのSQLの実行回数、1回あたりの平均所要時間を確認し、アプリケーションの改修が必要か判断する
パフォーマンスインサイトでも解決できない「データの断絶」
非常に有用なツールである反面、専門的なチューニングには以下の限界が存在します。
短期間のデータ保持：無料枠では7日間しか保存されず、1ヶ月前のピーク時との比較ができない
実行計画の履歴不足：「どの実行計画（Execution Plan）で動いたか」の履歴がないため、統計情報の変化による突発的な劣化を後から追跡するのが困難
詳細なセッション情報：デッドロックの詳細なグラフや、特定のセッションが保持しているロックの詳細は追いきれない場合がある
RDSの詳細解析と可視化の最適解
エンタープライズ環境やマルチクラウド、あるいは大規模なRDS運用において、標準機能だけで対応するには限界があります。より高度な分析と、迅速な意思決定を可能にするための「可視化の最適解」を提案します。
複数インスタンスを一元管理できないCloudWatchの弱点
CloudWatchはインスタンスごとのモニタリングには優れていますが、大規模環境では「複数インスタンスの横断的な比較」が困難です。例えば、同一アプリケーションが利用する複数の読み取り専用レプリカのうち、1台だけが遅延している場合、個別のダッシュボードを行き来して比較するのは非効率です。
また、オンプレミスからAWSへの移行期間中など、異なるプラットフォームのDBを同一画面で比較分析する機能が標準では不足しています。
「どの実行計画が悪かったのか」を過去に遡って分析する方法
SQLのパフォーマンス劣化の主因は「実行計画の変動」です。分析には、以下の要件を満たす仕組みが必要です。
ヒストリカルな実行計画の保存：過去の正常時と現在の異常時の計画を比較する
統計情報の可視化：インデックスの断片化や、テーブルのデータ量推移とパフォーマンスの相関を見る
ビジュアル解説：テキスト形式の実行計画（EXPLAINの結果）をツリー形式で表示し、どのステップでコストがかかっているかを直感的に理解する
監視から解決へのスピードを最大化するフルスタック可視化
真の解決スピードを上げるためには、以下3つのレイヤーを「1クリック」で往来できるUIが必要です。
ダッシュボードレイヤー：インスタンス群の健康状態を俯瞰する
メトリクスレイヤー：CPU、メモリ、待機イベントの相関をミリ秒単位で掘り下げる
SQL/セッションレイヤー：実行計画、ロック待機ツリー、SQLテキストを特定する
参考情報：AWS公式：Amazon RDS 拡張モニタリングの使用
RDSの問題を解決するexemONEとは
AWS標準機能の「あと一歩」のニーズを満たし、DBAレベルの高度な分析を自動化するのが、システム統合運用管理ソリューションexemONEです。
「exemONE」の詳細は、以下から確認してください。
AWS標準機能では届かない「DB内部の詳細」を瞬時に可視化
exemONEは、RDSの標準メトリクスだけでは見えない「DB内部の振る舞い」を独自の方式で収集・可視化します。
ロックツリーの可視化：どのセッションがどのリソースをロックし、誰を待たせているかをグラフィカルに表示する
マイクロ分析：CloudWatchよりも細かい粒度でデータを保持し、瞬間的なスパイクも逃さずキャプチャする
複雑なSQLチューニングを支援する高度な分析機能
exemONEは、SQLチューニングに特化した強力な分析モジュールを搭載しています。
機能 | 概要 | メリット |
実行計画の自動追跡 | SQLごとの実行計画を履歴として保存 | 過去の良好な計画と比較し、原因を即座に特定できる |
アドバイザリ機能 | AI/ヒューリスティックによる最適化提案 | 専門知識がなくてもインデックスの改善案が得られる |
長時間保存 | 数ヶ月単位のパフォーマンスログを保持 | 月次バッチや季節性イベントの比較が可能 |
DBだけではない、インフラ、アプリケーションも含めた統合監視
exemONEは、RDS単体の監視に留まらず、サーバー（EC2/オンプレ）、コンテナ、クラウドサービス全体を統合管理できる点です。
アプリケーションのレスポンスタイムから、引き起こしているバックエンドの特定のSQLまでを、画面を切り替えることなく一気通貫で追跡（トレーサビリティ）できます。
結果インフラ担当者とDBAの「視点の壁」を破壊し、組織全体のトラブルシューティング能力を底上げします。
まとめ
Amazon RDSの遅延原因を特定できない最大の理由は「リソース消費の結果（CloudWatch）」と「実際のSQLの振る舞い」が紐付いていないことです。
標準メトリクスで異常の兆候を掴む
パフォーマンスインサイトで負荷の正体（待機イベント）を分類する
exemONEのような高度な分析ツールで実行計画やロックの真因を特定する
上記3ステップを確立することで、RDS運用は「勘」から「データに基づく確信」へと変わります。現状の監視体制で原因特定に1時間以上を要しているなら、ツールと手法の見直しが必要なサインです。
