Amazon RDS インスタンスの IOPS のボトルネックによって引き起こされた Amazon EBS ボリュームのレイテンシーをトラブルシューティングするにはどうすればよいですか?

解決方法

IOPS またはスループットのボトルネックによって引き起こされた Amazon RDS インスタンスのレイテンシーが発生する最も一般的な理由は次のとおりです。

• インスタンスレベルでの IOPS のボトルネック
• ボリュームレベルでの IOPS のボトルネック
• インスタンスレベルでのスループットのボトルネック
• ボリュームレベルでのスループットのボトルネック
• マイクロバースト

ユースケースに基づいて、以下のトラブルシューティング手順を実行します。

汎用 SSD を搭載した RDS インスタンス (gp2)

次のチェックを実行します。

1. DB インスタンスクラスやストレージサイズなど、Amazon RDS インスタンスの設定情報を確認します。この情報は、IOPS とスループットの制限を追跡するのに役立ちます。IOPS またはスループットのボトルネックを引き起こす問題をトラブルシューティングする場合は、これらの値を把握しておく必要があります。
2. Amazon CloudWatch のグラフを使用して、DiskQueueDepth、ReadLatency、および WriteLatency の値にスパイクがないかを確認します。通常の状況では、1000 IOPS ごとに 1 分あたり 1 つの DiskQueueDepth を使用することがベストプラクティスです。ReadLatency および WriteLatency は 10 ミリ秒未満になることが想定されます。スパイクに気付いた場合は、スパイクの時間を特定します。
3. CloudWatch のグラフを使用して、ReadIOPS および WriteIOPS メトリクスを表示します。DiskQueueDepth、ReadLatency、および WriteLatency の値でスパイクが生じた期間中に、ボリュームレベルでの IOPS 制限の違反がないかを確認します。
4. CloudWatch のグラフを使用して、BurstBalance の値で低下が見られないかを確認します。このチェックは、サイズが 1 TB 未満のボリュームにのみ適用されます。BurstBalance の値の低下は、スパイクの期間中に IOPS のボトルネックが発生していることを示唆するものです。
5. CloudWatch のグラフを使用して、ReadThroughput および WriteThroughput のメトリクスを表示します。ReadThroughput および WriteThroughput の値でスパイクが生じた期間中に、ボリュームレベルでのスループット制限の違反がないかを確認します。
6. 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)

1. DB インスタンスクラスや定義済みのプロビジョンド IOPS などの Amazon RDS インスタンスの設定情報を確認して、DB インスタンスクラスの IOPS 制限またはスループット制限を決定します。
2. CloudWatch のグラフを使用して、DiskQueueDepth、ReadLatency、および WriteLatency の値にスパイクがないかを確認します。通常の状況では、1000 IOPS ごとに 1 分あたり 1 つの DiskQueueDepth を使用することがベストプラクティスです。ReadLatency または WriteLatency は 10 ミリ秒以内であることが想定されます。スパイクに気付いた場合は、スパイクの時間を特定します。
3. CloudWatch のグラフを使用して、ReadIOPS および WriteIOPS メトリクスを表示します。DiskQueueDepth、ReadLatency、および WriteLatency の値でスパイクが生じた期間中に、IOPS 制限の違反がないかを確認します。
4. CloudWatch のグラフを使用して、ReadThroughput および WriteThroughput のメトリクスを表示します。ReadThroughput および WriteThroughput の値でスパイクが生じた期間中に、スループット制限の違反がないかを確認します。
5. 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