RDS・Auroraの監視：主要メトリクスとCPU使用率が高いときの調べ方

Amazon RDS や Aurora を使っていると、CloudWatch に数十のメトリクスが並んでいて、どれにアラームを付ければよいのか迷います。この記事では RDS と Aurora の監視で最初に押さえたいメトリクスとその読み方、CPU 使用率が高いときの調べ方、AWS CLI でそのまま使えるアラームの設定例を説明します。Performance Insights が 2026 年に提供を終え、CloudWatch Database Insights に移ったことも反映しています。

RDS・Aurora の監視に使う 4 つの仕組み

RDS と Aurora の監視には AWS の中で次の 4 つの仕組みを使います。役割が少しずつ違うので、最初に整理しておきます。

仕組み	分かること	粒度と保存	費用
CloudWatch メトリクス	CPU、メモリ、接続数、ストレージ、I/O、レプリカ遅延など	1 分ごと。1 分単位のデータは 15 日間参照できる	標準のメトリクスは無料、アラームは有料
CloudWatch Database Insights	DB の負荷 (DBLoad) と、その内訳 (待機イベント、SQL、ユーザー、ホスト)	Standard モードは詳細データを 7 日間無料で保存	Advanced モードは vCPU 時間に応じて課金
拡張モニタリング (Enhanced Monitoring)	OS から見た CPU の内訳、メモリ、プロセスごとの使用量	1、5、10、15、30、60 秒から選ぶ。CloudWatch Logs に既定 30 日保存	CloudWatch Logs の料金
RDS イベント通知	フェイルオーバー、再起動、ストレージ不足などの出来事	発生時に通知 (最大 5 分ほど遅れることがある)	Amazon SNS の料金

CloudWatch メトリクスは「いつ、どの程度おかしいか」を数字で示し、Database Insights は「何がその負荷を生んでいるか」を示します。拡張モニタリングは OS の中で何が CPU を使っているかを示し、イベント通知はフェイルオーバーのような出来事を知らせます。アラームは主に CloudWatch メトリクスに設定し、原因を調べるときに残りの 3 つを使う、という分担が分かりやすい構成です。

RDS で見るべき主要メトリクス

RDS for MySQL・PostgreSQL・MariaDB などで、まず見ておきたいメトリクスを挙げます。単位は CloudWatch に送られる単位で、RDS のコンソールでは MB など別の単位で表示されることがあります。

メトリクス	意味	単位	見方
`CPUUtilization`	CPU 使用率	%	高い状態が続くかを見る。瞬間的な 100% は珍しくない
`FreeableMemory`	使えるメモリの量 (`/proc/meminfo` の MemAvailable)	バイト	普段の水準から下がり続けていないか
`SwapUsage`	スワップの使用量	バイト	増え続けるならメモリが足りていない
`DatabaseConnections`	クライアントからのネットワーク接続の数	件	`max_connections` に対する割合で見る
`FreeStorageSpace`	空きストレージ	バイト	残量と、減る速さを見る
`ReadLatency` / `WriteLatency`	ディスク I/O 1 回あたりの平均時間	秒	普段より大きくなっていないか
`ReadIOPS` / `WriteIOPS`	1 秒あたりのディスク読み書き回数	回/秒	ストレージの上限に近づいていないか
`DiskQueueDepth`	ディスクへのアクセスを待っている I/O の数	件	増えているなら I/O が詰まっている
`ReplicaLag`	リードレプリカの遅れ	秒	リードレプリカがある場合
`BurstBalance`	gp2 ボリュームの I/O クレジットの残り	%	gp2 を使っている場合、0 に近づくと I/O が遅くなる
`CPUCreditBalance`	T クラスの CPU クレジットの残り	クレジット	db.t3、db.t4g などの場合

エンジンごとの値もあります。MySQL と MariaDB では BinLogDiskUsage (バイナリログが使うディスク) が、PostgreSQL では MaximumUsedTransactionIDs (トランザクション ID の消費)、OldestReplicationSlotLag (いちばん遅れているレプリケーションスロットの WAL の量)、TransactionLogsDiskUsage (WAL が使うディスク) が参考になります。PostgreSQL のレプリケーションスロットは、受け取り側が止まると WAL を消せずにディスクを埋めることがあるため、論理レプリケーションや DMS を使っている場合は特に見ておきたい値です。

DatabaseConnections は、DB 内部のセッションや、ネットワーク接続を失ったが片付いていないセッションを含まないため、DB の中で数えたセッション数より少なく出ることがあります。接続数の上限に関わる調査では、DB の中でも確認してください (SHOW GLOBAL STATUS LIKE 'Threads_connected'; や pg_stat_activity)。

Aurora で RDS と違うところ

Aurora は RDS と同じ AWS/RDS 名前空間にメトリクスを送りますが、ストレージの仕組みが違うため、見るメトリクスがいくつか変わります。

まず、空きストレージです。Aurora のデータはクラスターボリュームに入り、使った分だけ自動で大きくなります。そのため FreeStorageSpace で空きを見る、という RDS の考え方はそのまま使えません。クラスター全体の使用量は VolumeBytesUsed で見ます。Aurora MySQL では、ボリュームの上限に近づいていないかを AuroraVolumeBytesLeftTotal (残りの容量) で見るよう公式ドキュメントが勧めています。

一方、FreeLocalStorage は各インスタンスのローカルストレージの空きです。一時テーブルやソートの作業領域に使われ、容量はインスタンスクラスで決まります。大きな集計クエリで一時領域を使い切ることがあるので、こちらは監視の対象にします (Aurora Serverless には当てはまりません)。

次に、レプリカ遅延です。Aurora のリーダーの遅延は AuroraReplicaLag で、単位はミリ秒です。RDS の ReplicaLag は秒なので、同じ閾値を使い回さないよう注意してください。ライター側では AuroraReplicaLagMaximum で、いちばん遅れているリーダーの値を見られます。

Aurora では DB エンジンの中の値も CloudWatch に出ています。BufferCacheHitRatio (バッファキャッシュから返せた割合)、Deadlocks (1 秒あたりのデッドロック数)、CommitLatency (コミットにかかる平均時間、ミリ秒) は Aurora MySQL・Aurora PostgreSQL の両方で使えます。Aurora MySQL にはさらに DMLLatency、SelectLatency、BlockedTransactions などがあります。

最後に、アラームを付ける単位です。Aurora はフェイルオーバーでライターとリーダーが入れ替わるため、インスタンス ID ではなく、DBClusterIdentifier と Role (WRITER または READER) の組み合わせでアラームを設定するよう公式ドキュメントが勧めています。こうしておけば、どのインスタンスがライターになっても、ライターの CPU を見続けられます。

CPU 使用率が高いときの調べ方

「RDS の CPU 使用率が高い」というアラームが来たときに、どの順で調べるかをまとめます。

1. どのくらい続いているかを見る

CloudWatch で CPUUtilization のグラフを、期間 1 分・統計「最大」と、期間 5 分・統計「平均」の両方で見ます。数分の山が 1 回あるだけなら、バッチや集計の一時的な負荷であることが多く、急ぎの対処は要らない場合があります。高い状態が続いている、あるいは毎日同じ時刻に山が高くなり続けているなら、次に進みます。

T クラス (db.t3、db.t4g など) を使っている場合は、CPUCreditBalance も見てください。クレジットを使い切ると、スタンダードモードでは CPU がベースラインの性能に制限され、無制限 (Unlimited) モードでは超えた分が追加料金になります (CPUSurplusCreditsCharged で確認できます)。AWS は T クラスを開発・テストなど本番以外の用途に勧めています。

2. DB の負荷と vCPU 数を比べる

Database Insights の DB 負荷 (DBLoad) は、その時点で活動しているセッションの平均数です。CloudWatch には DBLoad、DBLoadCPU (CPU を使っているセッション)、DBLoadNonCPU (CPU 以外を待っているセッション)、DBLoadRelativeToNumVCPUs (DB 負荷を vCPU 数で割った値) も送られます。

1 つの vCPU で同時に動けるプロセスは 1 つです。DB 負荷が vCPU 数を上回ることが多く、主な待機が CPU であれば、CPU が足りていない状態です。反対に、CPU 使用率が高くても DB 負荷の大半が I/O やロックの待ちなら、CPU を増やしても解決しにくく、別の原因を探す必要があります。

3. 負荷の大きい SQL を特定する

Database Insights の画面で、DB 負荷を SQL ごとに分けて表示し、上位の SQL を確認します。Advanced モードを有効にしていれば、クエリごとの統計やスロークエリの分析も使えます。

DB の中からも同じことを確かめられます。RDS for PostgreSQL では拡張機能 pg_stat_statements、RDS for MySQL では Performance Schema を使い、実行時間の合計が大きいクエリを探します。具体的な SQL は MySQL のスロークエリと PostgreSQL のスロークエリで説明しています。CPU を使うクエリの多くは、インデックスが効かずに大量の行を読んでいるものです。実行計画の読み方は MySQL の EXPLAIN と PostgreSQL の EXPLAIN を参照してください。

4. OS の中を拡張モニタリングで見る

CloudWatch の CPUUtilization はハイパーバイザー (仮想マシンを動かす層) から測った値で、拡張モニタリングは DB インスタンス上のエージェントが測った値です。拡張モニタリングでは CPU の内訳やプロセスごとの使用量が分かるため、DB エンジン以外のプロセスが CPU を使っていないかも確かめられます。

拡張モニタリングはインスタンスの変更で有効にでき、再起動は要りません。AWS CLI では次のように設定します。IAM ロールは事前に作成しておきます。

aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --monitoring-interval 60 \
  --monitoring-role-arn arn:aws:iam::123456789012:role/rds-monitoring-role

取得の間隔を短くするほど CloudWatch Logs に送るデータが増え、費用も増えます。普段は 60 秒にしておき、調査のときだけ短くする、という使い方もできます。

5. 対処を決める

原因が特定の SQL ならクエリやインデックスを直します。アクセスが増えてインスタンスの能力が足りないなら、インスタンスクラスを上げるか、読み取りをリードレプリカ (Aurora ならリーダー) に分けます。接続が急に増えて CPU を使っているなら、アプリの接続の使い方や RDS Proxy の利用を見直します。接続数の問題は Too many connections の記事も参照してください。

CloudWatch アラームの設定例

ここからは、aws cloudwatch put-metric-alarm でそのまま使えるアラームの例です。閾値は出発点としての例なので、自分の DB の普段の値を見て調整してください。閾値の考え方はアラートの閾値の決め方で詳しく説明しています。

CPU 使用率が高い状態が続く (RDS)

aws cloudwatch put-metric-alarm \
  --alarm-name mydb-cpu-high \
  --namespace AWS/RDS \
  --metric-name CPUUtilization \
  --dimensions Name=DBInstanceIdentifier,Value=mydb \
  --statistic Average \
  --period 300 \
  --evaluation-periods 3 \
  --datapoints-to-alarm 3 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:db-alerts \
  --ok-actions arn:aws:sns:ap-northeast-1:123456789012:db-alerts

5 分平均が 80% を超える状態が 3 回続いたら (15 分間) 通知します。--datapoints-to-alarm を --evaluation-periods より小さくすると「N 回のうち M 回」の判定になり、上下に揺れる値でも拾いやすくなります。--ok-actions を付けると、回復したときにも通知が届きます。

空きストレージが少ない (RDS)

aws cloudwatch put-metric-alarm \
  --alarm-name mydb-free-storage-low \
  --namespace AWS/RDS \
  --metric-name FreeStorageSpace \
  --dimensions Name=DBInstanceIdentifier,Value=mydb \
  --statistic Minimum \
  --period 300 \
  --evaluation-periods 1 \
  --threshold 10737418240 \
  --comparison-operator LessThanThreshold \
  --treat-missing-data breaching \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:db-alerts

単位はバイトなので、10 GiB は 10737418240 です。統計は「最小」にして、5 分の中でいちばん少なかった値で判定します。--treat-missing-data breaching は、データが届かないときも異常として扱う設定です。既定の missing のままだと、インスタンスが止まってデータが来ないときにアラームが反応しません。容量の割合ではなく残りの量で判定しているので、割り当てたストレージを増やしたら閾値も見直してください。

レプリカ遅延が大きい (Aurora、リーダーのロール単位)

aws cloudwatch put-metric-alarm \
  --alarm-name mycluster-reader-lag \
  --namespace AWS/RDS \
  --metric-name AuroraReplicaLag \
  --dimensions Name=DBClusterIdentifier,Value=mycluster Name=Role,Value=READER \
  --statistic Maximum \
  --period 60 \
  --evaluation-periods 5 \
  --datapoints-to-alarm 5 \
  --threshold 1000 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:db-alerts

AuroraReplicaLag はミリ秒なので、1000 は 1 秒です。Role=READER で集約しているため、リーダーが入れ替わってもアラームを作り直す必要はありません。ライターの CPU を見るなら、同じ形で --metric-name CPUUtilization と Name=Role,Value=WRITER を指定します。

ほかに用意しておきたいアラーム

上の 3 つに加えて、次のメトリクスにもアラームを付けておくと安心です。

FreeableMemory: 普段の水準から大きく下がった状態が続く
DatabaseConnections: max_connections の一定割合を超える
DiskQueueDepth または ReadLatency / WriteLatency: 普段より明らかに大きい状態が続く
FreeLocalStorage (Aurora): 一時領域の空きが少ない
MaximumUsedTransactionIDs (PostgreSQL): トランザクション ID の消費が増え続けている

メモリやレイテンシのように普段の水準が DB ごとに違う値は、固定の閾値が決めにくいものです。CloudWatch には過去の値から予想の幅を作る異常検出 (anomaly detection) のアラームもあり、--comparison-operator に GreaterThanUpperThreshold などを指定して使います。

フェイルオーバーや再起動、メンテナンスの通知は、メトリクスのアラームではなく RDS のイベント通知 (イベントサブスクリプション) で受け取ります。カテゴリを選んで SNS トピックに送る設定にしておくと、「CPU が下がったのはフェイルオーバーがあったから」のように、メトリクスの変化の理由が分かります。

監視を設定するときの注意点

アラームを作るときに引っかかりやすい点をまとめます。

1 つめは統計の選び方です。CPU やレイテンシは「平均」だと短い山がならされて見えにくくなり、「最大」だと一瞬の山でも反応します。通知したいのが「続いている状態」なら平均、「一度でも起きたら困る状態」なら最大か最小を選びます。

2 つめはデータが届かないときの扱いです。--treat-missing-data の既定は missing で、データがない期間はアラームの判定から外れます。空きストレージのように「値が来ないこと自体が異常」なものは breaching、夜間に値が出ないことがあるものは notBreaching か ignore を選びます。なお、Database Insights の DBLoad などは、DB に負荷がないときは CloudWatch に送られません。

3 つめは通知の数です。インスタンスごと・メトリクスごとにアラームを作ると、1 つの障害で何通も通知が届きます。ロール単位で集約する、関連するアラームを CloudWatch の複合アラーム (composite alarm) でまとめる、といった工夫で通知を減らせます。通知が多すぎる問題についてはアラート疲れの記事で扱っています。

4 つめは CloudWatch のメトリクスだけでは分からないことがある点です。CPU もメモリも正常なのに、アプリの不具合で注文が保存されていない、決済がすべて失敗している、という異常は、DB に入っているデータを数えないと気づけません。DB の中で見るべき項目はデータベース監視とはで、ツールの選び方はデータベース監視ツールの選び方で説明しています。

この監視を続けるには

CloudWatch のアラームを設定したら、通知が来たときに誰がどこを見るかを決めておきます。最初の数週間は、届いたアラームが本当に対応の必要なものだったかを記録し、閾値や統計を見直していくと、通知の質が上がります。

CloudWatch で見えないデータの中身については、AI に任せる方法もあります。Scandock は Amazon RDS に対応した、AI がデータベースを監視するサービスです。接続文字列を登録すると、AI がテーブルの構成と実データを読み、注文数や決済の成否、バッチ・ジョブの滞留のような数字も含めて何を監視するかを決めます。異常と判断すると、読み取り専用のクエリで関連するデータを調べ、原因・影響・根拠・対処案をつけて Slack やメールなどに通知します。