概要
RDSインスタンスの監視において重要な8つの主要メトリクスについて学習した内容をまとめておく。これらのメトリクスを適切に監視することで、データベースのパフォーマンス問題を早期に発見し、適切な対策を講じることができる。
1. メモリ (FreeableMemory)
FreeableMemoryは、RDSインスタンスで現在利用可能なRAMの量をバイト単位で示すメトリクス。オペレーティングシステムがキャッシュやバッファとして使用していない、データベースプロセスが自由に利用できるメモリの量を表している。
このメトリクスが低下すると、データベースがディスクI/Oを頻繁に行う必要が生じ、パフォーマンスが大幅に低下する可能性がある。メモリ不足は特にOLTPワークロードにおいて致命的な影響を与える可能性があるため、継続的な監視が重要。
基準値と監視:
- Aurora: 総メモリの5%を下回らないように監視
- Aurora以外のエンジン: 総メモリの25%を下回らないように監視
- ワークロードによって最適な値は異なるため、運用開始後は実績値を参考に調整する
- SwapUsageメトリクスと合わせて監視することで、メモリ枯渇の状況をより正確に把握できる
2. DB接続 (DatabaseConnections)
DatabaseConnectionsは、RDSインスタンスへのアクティブなクライアント接続の総数を示す。このメトリクスはデータベースに同時に接続しているユーザーやアプリケーションの数を反映しており、接続プールの適切な設定やアプリケーションの接続管理の健全性を評価する際の重要な指標となる。
接続数が多すぎると、データベースの負荷が増大し、新しい接続が拒否される可能性がある。また、接続数の急激な増加は、アプリケーションのバグや設定ミス、さらには悪意のあるアクセスの兆候である場合もある。
基準値と監視:
- 現在の接続数が最大接続数の約80%を超えないように監視することが推奨される
- 最大接続数はインスタンスタイプやDBパラメータグループの設定によって決まる
- 接続数のトレンドを継続的に監視し、異常なスパイクや増加傾向がないかを確認する
- 接続プールの設定が適切かどうかも併せて検証する
3. CPU (CPUUtilization)
CPUUtilizationは、RDSインスタンスのCPU使用率をパーセンテージで示すメトリクス。データベースがクエリの実行、データ処理、バックグラウンドタスクなどにどれだけのCPUリソースを使用しているかを表している。
CPU使用率が高い状態が続くと、データベースの応答速度が低下し、全体的なパフォーマンスに重大な影響を与える。特に複雑なクエリや大量のデータ処理が必要なワークロードでは、CPU使用率の監視が不可欠。
基準値と監視:
- 一般的に、CPU使用率が80%を超える状態が継続する場合は対策が必要
- 一時的なスパイクは許容される場合があるが、持続的な高使用率は問題
- DBLoadやQueriesメトリクスと合わせて監視することで、CPU負荷の原因を特定しやすくなる
- 高使用率が続く場合は、インスタンスタイプの見直しやクエリの最適化を検討する
4. ストレージ (FreeStorageSpace)
FreeStorageSpaceは、RDSインスタンスで利用可能なストレージ容量をバイト単位で示す。データベースファイル、ログファイル、一時ファイルなどが格納されるディスク領域の空き容量を表している。
このメトリクスが枯渇すると、データベースは新しいデータを書き込めなくなり、最悪の場合サービスが停止する可能性がある。ストレージ容量の監視は、サービス継続性の観点から極めて重要。
基準値と監視:
- 利用可能なストレージが割り当てられたストレージの10%未満になった場合にアラートを設定
- オートスケーリングが有効な場合でも、コスト管理の観点から監視は重要
- predict_linear関数を使用して将来のストレージ枯渇を予測し、事前に対応を計画する
- ストレージの増加傾向を把握し、適切なタイミングでのスケールアップや不要データの削除を検討
5. リード/ライトレイテンシー (ReadLatency/WriteLatency)
ReadLatencyとWriteLatencyは、それぞれRDSインスタンスでのディスク読み込み操作と書き込み操作にかかる平均時間を秒単位で示すメトリクス。これらはデータベースのI/Oパフォーマンスを直接的に表しており、アプリケーションの応答時間に直結する重要な指標。
レイテンシーが高い場合、ディスクI/Oがボトルネックとなり、クエリの実行速度が著しく低下する。特にOLTPワークロードでは、低いレイテンシーが要求されるため、継続的な監視が不可欠。
基準値と監視:
- 読み書きのレイテンシーが250msを超える場合は、ディスクI/Oに問題がある可能性が高い
- アプリケーションの応答時間に直結するため、可能な限り低い値を維持することが重要
- ReadIOPS、WriteIOPS、DiskQueueDepthなどのメトリクスと合わせて監視し、根本原因を特定する
- レイテンシー増加の原因として、不適切なインデックスや大量のデータスキャンなども考慮する
6. ディスクキューの深さ (DiskQueueDepth)
DiskQueueDepthは、ディスクI/O操作がディスクにアクセスするのを待っている未処理のI/Oリクエストの数を示すメトリクス。この値が高い場合、ストレージシステムがI/Oリクエストを処理しきれていないことを示唆しており、ディスクI/Oのボトルネックが発生している可能性が高い。
このメトリクスは、ストレージのパフォーマンス限界やプロビジョンドIOPSの不足を早期に発見するための重要な指標となる。
基準値と監視:
- 一般的に、DiskQueueDepthは低い値（0-2程度）を維持することが望ましい
- 継続的に高い値を示す場合は、ストレージのパフォーマンスがワークロードに対して不足
- ReadIOPS、WriteIOPS、ReadLatency、WriteLatencyと合わせて監視することで、ボトルネックの詳細な分析が可能
- 高いDiskQueueDepthは、プロビジョンドIOPSの不足やインスタンスタイプのIOPS上限到達を示唆
7. 読み取り/書き込みIOPS (ReadIOPS/WriteIOPS)
ReadIOPSとWriteIOPSは、それぞれRDSインスタンスが1秒あたりに実行するディスク読み込み操作と書き込み操作の平均数を示すメトリクス。これらはデータベースのI/Oスループットを測定し、ワークロードがストレージのIOPS制限に近づいているかどうかを判断するのに役立つ。
IOPSの制限に達すると、I/O待機時間が増加し、データベースのパフォーマンスが大幅に低下する。特にランダムI/Oが多いワークロードでは、IOPS制限がボトルネックになりやすい。
基準値と監視:
- ワークロードによって最適なIOPSは大きく異なるが、プロビジョンドIOPSの上限に近づいている場合は要注意
- ストレージタイプの変更（gp2からgp3やio1/io2への変更）やインスタンスタイプのスケールアップを検討
- ReadIOPSやWriteIOPSが急増したり上限に張り付いている場合は、ディスクI/Oがボトルネック
- ReadLatency、WriteLatency、DiskQueueDepthと合わせて監視することで包括的な分析が可能
8. ネットワークスループット (NetworkReceiveThroughput/NetworkTransmitThroughput)
NetworkReceiveThroughputはRDSインスタンスへの受信ネットワークトラフィックを、NetworkTransmitThroughputは送信ネットワークトラフィックをバイト/秒で示すメトリクス。これらには顧客のデータベーストラフィックとAmazon RDSが監視データなどに使用するトラフィックの両方が含まれる。
ネットワーク帯域幅がボトルネックになると、アプリケーションからのデータベースアクセスが遅延し、全体的なパフォーマンスに影響を与える。特に大量のデータ転送が必要なアプリケーションでは重要な監視項目となる。
基準値と監視:
- ネットワークスループットの具体的な推奨基準値は、アプリケーションの要件とインスタンスタイプによって大きく異なる
- インスタンスタイプが提供するネットワーク帯域幅の上限に近づいていないかを継続的に確認
- 大量のデータ転送や多数のクライアント接続がある場合は特に注意深く監視
- ネットワーク帯域幅の上限に近づいている場合は、より高性能なインスタンスタイプへの移行を検討
まとめ
これらのメトリクスは相互に密接に関連しているため、単一のメトリクスだけでなく、複数のメトリクスを組み合わせて監視することが重要。例えば、CPU使用率が高い場合は、DatabaseConnectionsやDBLoadも併せて確認し、原因がクエリの非効率性にあるのか、接続数の増加にあるのかを判断する必要がある。
また、各メトリクスの最適な値はワークロードの性質によって大きく異なるため、運用開始後は実際の使用パターンを分析し、環境に適した監視基準を設定することが不可欠。定期的なパフォーマンス分析と継続的な最適化により、RDSインスタンスの健全性とパフォーマンスを維持していく。