Amazon Relational Database Service (Amazon RDS) DB インスタンスがあります。Amazon RDS インスタンスの Amazon Elastic Block Store (Amazon EBS) ボリュームのレイテンシーをトラブルシューティングしたいと考えています。
解決方法
IOPS またはスループットのボトルネックによって引き起こされた Amazon RDS インスタンスのレイテンシーが発生する最も一般的な理由は次のとおりです。
- インスタンスレベルでの IOPS のボトルネック
- ボリュームレベルでの IOPS のボトルネック
- インスタンスレベルでのスループットのボトルネック
- ボリュームレベルでのスループットのボトルネック
- マイクロバースト
ユースケースに基づいて、以下のトラブルシューティング手順を実行します。
汎用 SSD を搭載した RDS インスタンス (gp2)
次のチェックを実行します。
- DB インスタンスクラスやストレージサイズなど、Amazon RDS インスタンスの設定情報を確認します。この情報は、IOPS とスループットの制限を追跡するのに役立ちます。IOPS またはスループットのボトルネックを引き起こす問題をトラブルシューティングする場合は、これらの値を把握しておく必要があります。
- Amazon CloudWatch のグラフを使用して、DiskQueueDepth、ReadLatency、および WriteLatency の値にスパイクがないかを確認します。通常の状況では、1000 IOPS ごとに 1 分あたり 1 つの DiskQueueDepth を使用することがベストプラクティスです。ReadLatency および WriteLatency は 10 ミリ秒未満になることが想定されます。スパイクに気付いた場合は、スパイクの時間を特定します。
- CloudWatch のグラフを使用して、ReadIOPS および WriteIOPS メトリクスを表示します。DiskQueueDepth、ReadLatency、および WriteLatency の値でスパイクが生じた期間中に、ボリュームレベルでの IOPS 制限の違反がないかを確認します。
- CloudWatch のグラフを使用して、BurstBalance の値で低下が見られないかを確認します。このチェックは、サイズが 1 TB 未満のボリュームにのみ適用されます。BurstBalance の値の低下は、スパイクの期間中に IOPS のボトルネックが発生していることを示唆するものです。
- CloudWatch のグラフを使用して、ReadThroughput および WriteThroughput のメトリクスを表示します。ReadThroughput および WriteThroughput の値でスパイクが生じた期間中に、ボリュームレベルでのスループット制限の違反がないかを確認します。
- EBS 最適化 RDS インスタンスクラスを使用している場合は、CloudWatch のグラフを使用して IOPS またはスループットのスロットリングがないかを確認します。バーストキャパシティを備えたインスタンスクラスの場合は、CloudWatch のグラフで EBSIOBalance% および EBSByteBalance% のメトリクスを表示します。EBSIOBalance% または EBSByteBalance% の常に低い値は、インスタンスレベルで IOPS またはスループットのボトルネックが発生していることを示唆しています。
IOPS、スループット、またはその両方のスロットリングは、IOPS またはスループットがストレージレベルのワークロードにとって不十分であることを示唆しています。この問題を修正するには、次の操作を実行します。
- データベースの負荷を増加させる SQL クエリを特定し、これらのクエリを最適化します。ワークロードが想定どおりであるか、SQL クエリをチューニングするためのスコープがない場合は、IOPS 容量を増やすためにストレージサイズを大きくする必要がある場合があります。
注: RDS インスタンスのストレージサイズを大きくした後に、サイズを小さくして前の値にすることはできません。
- ボリュームを汎用 (gp2) からプロビジョンド IOPS (io1) に切り替えることを検討してください。DB インスタンスがシングル AZ で、カスタムパラメータグループを使用している場合、gp2 と io1 を切り替えると、短時間のダウンタイムが発生する可能性があります。インスタンスがマルチ AZ の場合、ダウンタイムは発生しません。
- インスタンスレベルでの IOPS またはスループットのスロットリングに気付いた場合は、IOPS またはスループット容量を増やすためにインスタンスクラスをスケールアップする必要があります。
プロビジョンド IOPS を備えた RDS インスタンス (io1)
- DB インスタンスクラスや定義済みのプロビジョンド IOPS などの Amazon RDS インスタンスの設定情報を確認して、DB インスタンスクラスの IOPS 制限またはスループット制限を決定します。
- CloudWatch のグラフを使用して、DiskQueueDepth、ReadLatency、および WriteLatency の値にスパイクがないかを確認します。通常の状況では、1000 IOPS ごとに 1 分あたり 1 つの DiskQueueDepth を使用することがベストプラクティスです。ReadLatency または WriteLatency は 10 ミリ秒以内であることが想定されます。スパイクに気付いた場合は、スパイクの時間を特定します。
- CloudWatch のグラフを使用して、ReadIOPS および WriteIOPS メトリクスを表示します。DiskQueueDepth、ReadLatency、および WriteLatency の値でスパイクが生じた期間中に、IOPS 制限の違反がないかを確認します。
- CloudWatch のグラフを使用して、ReadThroughput および WriteThroughput のメトリクスを表示します。ReadThroughput および WriteThroughput の値でスパイクが生じた期間中に、スループット制限の違反がないかを確認します。
- EBS 最適化 RDS インスタンスクラスを使用している場合は、CloudWatch のグラフを使用して IOPS またはスループットのスロットリングがないかを確認します。バーストキャパシティを備えたインスタンスクラスの場合は、CloudWatch のグラフで EBSIOBalance% および EBSByteBalance% のメトリクスを表示します。EBSIOBalance% または EBSByteBalance% の常に低い値 (%) は、それぞれ、インスタンスレベルで IOPS またはスループットのボトルネックが発生していることを示唆しています。
IOPS またはスループットのスロットリングは、IOPS またはスループットがストレージレベルのワークロードにとって不十分であることを示唆しています。この問題を修正するには、次の操作を実行します。
- データベースの負荷を増加させる SQL クエリを特定し、これらのクエリを最適化します。ワークロードが想定どおりであるか、SQL クエリをチューニングするためのスコープがない場合は、プロビジョンされた IOPS を増やす必要がある場合があります。
- インスタンスレベルでの IOPS またはスループットのスロットリングに気付いた場合は、スループットまたは IOPS 容量を増やすためにインスタンスクラスをスケールアップする必要があります。
マイクロバースト
マイクロバーストは、EBS ボリュームが収集期間よりも大幅に短い期間で高い IOPS またはスループットを「バースト」したときに発生します。CloudWatch メトリクスは 60 秒間隔で収集されます。このボリュームは収集期間よりも短い期間で高い IOPS またはスループットをバーストするため、CloudWatch にはバーストが反映されません。Enhanced Monitoring を使用して、マイクロバーストがレイテンシーを引き起こしていないかを特定できます。1 秒の粒度で Enhanced Monitoring をオンにします。Read IO/s メトリクスと Write IO/s メトリクスを使用して、実際の IOPS 使用率を判断できます。Read Kb/s および Write Kb/s を使用して、1 秒あたりの実際のスループット使用率を判断できます。詳細については、Enhanced Monitoring メトリクスの説明を参照してください。
関連情報
Amazon RDS のメトリクス
Understanding burst vs. baseline performance with Amazon RDS and GP2
DB インスタンスクラスのハードウェア仕様
EBS ボリュームがマイクロバーストしているかどうかを判断する方法と、それを防ぐ方法を教えてください
Determining the IOPS needs for Oracle database on AWS