Amazon RDS DB インスタンスでの書き込みレイテンシーの急増をトラブルシューティングする方法を教えてください。

簡単な説明

WriteLatency メトリクスは、各ディスク I/O 操作にかかる平均時間を定義します。書き込みレイテンシーは 1 桁ミリ秒を超えないようにするのがベストプラクティスです。

次のアクションを実行すると、DB インスタンスの書き込みレイテンシーが急増する可能性があります。

• シングル AZ データベースインスタンスの Amazon RDS バックアップを作成する。
• シングル AZ RDS DB インスタンスをマルチ AZ インスタンスに変更する。
• DB スナップショットから復元する。
• DB インスタンスのポイントインタイムリカバリ (PITR) を実行する。
• 新しいリードレプリカを作成する。

この急増は、1 秒あたりの入出力オペレーション (IOPS) や、データベースでの負荷が高いことによるスループットのボトルネックが原因である可能性もあります。

解決策

レイテンシーの急増のトラブルシューティング

DB インスタンスの書き込みレイテンシーが高い原因を特定するには、Amazon RDS の次の Amazon CloudWatch メトリクスを確認してください。

• WriteLatency
• WriteIOPS
• WriteThroughput
• DiskQueueDepth
• 汎用 SSD (gp2) ストレージ用 BurstBalance

次の値は、DB インスタンスに大きな負荷がかかっており、より多くのリソースが必要であることを示しています。

• レイテンシー値が高い。
• スループットと IOPS の値が最大クォータに達した。
• **DiskQueueDepth ** の値が高い。
• gp2 の場合、BurstBalance の値が低い。

IOPS またはスループットのボトルネックをトラブルシューティングするには、次のいずれかの操作を行います。

• gp2 ボリュームを含む DB インスタンスの場合は、DB インスタンスクラスとストレージサイズを確認します。詳細については、「Amazon EBS 最適化インスタンスタイプ」を参照してください。
• プロビジョンド IOPS (io1) ストレージを備えた DB インスタンスの場合は、DB インスタンスクラスと定義されているプロビジョンド IOPS を確認します。

CloudWatch メトリクスでリソースがスロットリングされていることが表示されない場合は、拡張モニタリングを使用して WriteIOSPS メトリクスを確認してください。

注: CloudWatch は 60 秒間隔でメトリクスを記録するため、すべての急増やドロップを記録するとは限りません。](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.Enabling.html#USER_Monitoring.OS.Enabling.Procedure)拡張モニタリングの Granularity プロパティ[を 1 秒間隔に設定できます。

前述のメトリクスでレイテンシーの原因が示されない場合は、NetworkReceiveThroughput および NetworkTransmitThroughput CloudWatch メトリクスでネットワークの問題がないか確認してください。

遅延読み込みを減らす

遅延読み込みは、PITR を実行したり、シングル AZ インスタンスをマルチ AZ インスタンスに変更したり、新しいリードレプリカを作成したりするときに発生する可能性があります。Amazon RDS がロードしなかったデータにアクセスしようとすると、DB インスタンスは要求されたデータを直ちに Amazon Simple Storage Service (Amazon S3) からダウンロードします。インスタンスは引き続きバックグラウンドで残りのデータをロードします。

迅速にアクセスする必要があるテーブルでの遅延読み込みを減らすには、SELECT\ * などのテーブル全体のスキャンを伴う操作を実行します。これにより、Amazon RDS はすべてのバックアップされたテーブルデータを Amazon S3 からダウンロードできます。

以下のいずれかのアクションを実行することでも、シングル AZ インスタンスをマルチ AZ インスタンスに変更した後の遅延読み込みを減らすことができます。

• インスタンスを変更したらすぐに手動フェイルオーバーを実行する。
• フルダンプを実行するか、必要なクエリのみを実行して、テーブルからすべてのデータをロードする。Amazon RDS for PostgreSQL インスタンスの場合は、pg_prewarm コマンドを実行できます。

高レイテンシーのベストプラクティスを実装する

DB インスタンスのレイテンシーが高い場合は、次のベストプラクティスを実装してください。

• クエリを実行するのに十分なリソースをデータベースに割り当てます。割り当てるリソースの数は、インスタンスタイプによって異なります。
• Performance Insights を使用してデータベースのワークロードを監視します。Performance Insights は、アプリケーションでレイテンシーが発生した場合に、データベースで実行されている基になる SQL クエリを特定するのに役立ちます。次に、データベースの負荷を評価して、今後のアクションを決定します。
• マイクロバーストを防ぐために、Amazon EBS ボリュームのサイズまたはタイプを変更します。詳細については、「EBS ボリュームでマイクロバーストが発生していないかを確認し、パフォーマンスへの影響を防ぐ方法を教えてください」を参照してください。
• クエリを調整してデータベースのパフォーマンスを最適化します。
• シングル AZ インスタンスをマルチ AZ インスタンスに変更する場合は、営業時間外に変更してください。
• Amazon RDS メトリクスの CloudWatch アラームを作成して、インスタンスがスロットルしないことを確認します。

重要: 2026 年 6 月 30 日に Performance Insights のサポートは終了します。2026 年 6 月 30 日までに、Database Insights の Advanced モードにアップグレードしてください。アップグレードしない場合、Performance Insights を使用する DB クラスターは、デフォルトで Database Insights の Standard モードを使用します。実行計画とオンデマンド分析は、Database Insights の Advanced モードでのみサポートされます。クラスターがデフォルト設定により Standard モードになった場合、コンソールでこれらの機能を使用できない可能性があります。Advanced モードの有効化については、「Amazon RDS で Database Insights の Advanced モードを有効にする」および「Amazon Aurora で Database Insights の Advanced モードを有効にする」を参照してください。

関連情報

Amazon RDS のベストプラクティス

Understanding burst vs. baseline performance with Amazon RDS and gp2 (Amazon RDS と gp2 のバーストパフォーマンスとベースラインパフォーマンスの比較)

Amazon RDS のマルチ AZ DB インスタンスデプロイ