Amazon RDS DB インスタンスの書き込みレイテンシスパイクのトラブルシューティングを行うにはどうすればよいですか?

所要時間2分

Amazon Relational Database Service (Amazon RDS) DB インスタンスでの書き込みレイテンシの急上昇のトラブルシューティングを行いたい。

簡単な説明

Amazon CloudWatch メトリクス WriteLatency は、ディスク I/O 操作ごとにかかる平均時間を定義します。理想的には、書き込みレイテンシは 1 桁のミリ秒を超えてはなりません。

次の手順を実行すると、DB インスタンスの書き込みレイテンシが急上昇する可能性があります:

スパイクは、データベースの重いワークロードが原因で発生した IOPS またはスループットのボトルネックが原因である可能性もあります。

解決方法

レイテンシスパイクのトラブルシューティング

1. DB インスタンスで読み取りまたは書き込みのレイテンシが高くなる原因のトラブルシューティングを行うには、次の CloudWatch メトリクスを確認してください:

ReadLatency と WriteLatency
ReadIOPS と WriteIOPS
ReadThroughput と WriteThroughput
DiskQueueDepth
BurstBalance (gp2 ストレージ用)

次のうち 1 つ以上に気付いたとします:

レイテンシの値が高い。
スループットと IOPS の値が最大制限に達しました。
DiskQueueDepth の値は高いです。
BurstBalance の値は低いです (gp2の場合)。

これは、RDS インスタンスのワークロードが大きく、より多くのリソースが必要であることを意味します。詳細については、「Amazon RDS インスタンスの IOPS ボトルネックによって引き起こされる Amazon EBS ボリュームのレイテンシをトラブルシューティングするにはどうすればよいですか?」を参照してください。

IOPS またはスループットのボトルネックを引き起こす問題のトラブルシューティングを行うには、次の手順を実行します:

汎用SSD (gp2) を使用する RDS インスタンスの場合は、DB インスタンスクラスとストレージサイズを確認してください。

プロビジョンド IOPS (io1) を使用する RDS インスタンスの場合は、DB インスタンスクラスと定義済みのプロビジョンド IOPS を確認してください。

詳細については、「DB インスタンスクラス」と「Amazon EBS 最適化インスタンス」を参照してください。

2. CloudWatch メトリクスがリソーススロットリングを示さない場合は、拡張モニタリングを使用して読み取り IO/秒と書き込み IO/秒を確認します。

CloudWatch メトリクスは 60 秒間隔で記録されます。したがって、すべてのスパイクまたはドロップが記録されない場合があります。ただし、拡張監視の粒度を最大 1 秒に設定して、データをキャプチャできます。60 秒間隔内のリソース使用率の急上昇は、拡張モニタリングによってキャプチャできます。詳細については、「EBS ボリュームがマイクロバーストしているかどうかを確認するにはどうすればよいですか? また、これを防ぐにはどうすればよいですか?」を参照してください。

3. 上記のすべてのチェックで問題の原因が示されていない場合は、CloudWatch メトリクス NetworkReceiveThroughpu と NetworkReceiveThroughput をチェックして、ネットワークに問題がないことを確認します。

遅延読み込みの影響を軽減する

スナップショットから RDS データベースインスタンスを復元する場合、DB インスタンスはバックグラウンドでデータをロードし続けます。このプロセスは、遅延読み込みと呼ばれます。

遅延読み込みは、ポイントインタイムリストア、シングル AZ インスタンスからマルチ AZ インスタンスへの変換、新しいリードレプリカの作成など、スナップショットからのリストアを必要とするすべてのシナリオで発生する可能性があります。まだロードされていないデータにアクセスしようとすると、DB インスタンスはリクエストされたデータを Amazon Simple Storage Service (Amazon S3) からすぐにダウンロードします。その後、インスタンスはバックグラウンドで残りのデータをロードし続けます。詳細については、「Amazon EBS スナップショット」を参照してください。迅速なアクセスが必要なテーブルへの遅延読み込みの影響を軽減するために、SELECT* などの全表スキャンを含む操作を実行できます。これにより、RDS はバックアップされたすべてのテーブルデータを Amazon S3 からダウンロードできます。

ベストプラクティスに従う

DB インスタンスで高い書き込みレイテンシを処理する場合は、次のベストプラクティスと回避策に留意してください:

クエリを実行するのに十分なリソースがデータベースに割り当てられていることを確認してください。RDS では、割り当てられるリソースの量はインスタンスタイプによって異なります。
CloudWatch メトリクスも拡張モニタリングメトリクスもリソーススロットリングを示していない場合は、パフォーマンスインサイトを使用してデータベースのワークロードをモニタリングします。パフォーマンスインサイトを使用すると、アプリケーションで遅延が発生しているときに、データベースで実行されている基になる SQL クエリを特定できます。この情報を使用して、データベースの負荷を評価し、以降のアクションを決定できます。詳細については、「Amazon RDS でのパフォーマンスインサイトを使用した DB 負荷のモニタリング」を参照してください。
ユースケースに応じて Amazon EBS ボリュームのサイズまたはタイプを変更することにより、マイクロバーストを防止します。
データベースのパフォーマンスを最適化するには、クエリが適切に調整されていることを確認してください。
シングル AZ データベースインスタンスをマルチ AZ インスタンスに変換する場合は、営業時間外に変換することを検討してください。
マルチ AZ 変換後の遅延読み込みの影響を減らすには、次のいずれかを実行することを検討してください:

マルチ AZ インスタンスに変換した直後に手動フェイルオーバーを実行します。
フルダンプまたは必要なクエリのみを実行して、テーブルからすべてのデータをロードします。このプロセスは、データをロードし、すべてのブロックを S3 から新しいホストに強制的にプッシュするのに役立ちます。Amazon RDS for PostgreSQL インスタンスの場合、pg_prewarm コマンドを実行できます。

RDS インスタンスで書き込みレイテンシが急上昇する理由を特定するのに役立つ RDS キーメトリクスで Amazon CloudWatch アラームを設定できます。これらのメトリクスの例には、ReadIOPS、WriteIOPS、読み取りスループット、書き込みスループット、DiskQueueDepth、ReadLatency、WriteLatency などが含まれます。これらのアラームを使用して、インスタンスがスロットルしないことを確認できます。