Amazon EBS ボリュームで I/O 待機時間やキューが長くなり、遅延が急増する原因を知りたいです。

所要時間1分

Amazon Elastic Block Store (Amazon EBS) ボリュームにおいて、I/O 待機時間やキューが長くなり、遅延が急増しています。

解決策

I/O 操作の完了に遅延があると、Amazon EBS ボリュームでのキュー長および、I/O 待機時間が増加します。遅延が増加する一般的な理由を次に示します。

ボリュームがスループットまたは IOPS クォータに近づいている

スループットや IOPS クォータに近づいている場合、遅延が発生する可能性があります。スループットと IOPS クォータを決定するには、「Amazon EBS ボリュームの最大 IOPS とスループットを計算する方法を教えてください」を参照してください。次に、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの EBS ボリュームがスループットまたは IOPS のクォータに近づいているかどうかを確認します。

スループットまたは IOPS のクォータに頻繁に達する場合は、ボリュームのタイプまたはサイズをアプリケーションのニーズに合ったものに変更してください。使用するボリュームタイプを決定するには、テスト環境を使用して、ワークロードに対して EBS ボリュームをベンチマークするのがベストプラクティスです。

インスタンスのスループットまたは IOPS のクォータに達している

EBS 最適化 EC2 インスタンスでは、インスタンスにアタッチされているすべての EBS ボリュームで合計スループットと IOPS が最大になります。I/O 待機時間が長くなり、遅延が増加しても、ボリュームがスループットまたは IOPS クォータに達していない場合があります。このような場合は、ボリュームのスループットまたは IOPS がインスタンスのスループットまたは IOPS のクォータに達しているかどうかを確認してください。

たとえば、1 TiB の gp3 ボリュームにおいて、プロビジョニングされた IOPS が 16,000、スループットが 700 MiBPS で、t3.medium インスタンスに接続されているとします。t3.medium インスタンスは、接続されているすべてのボリュームにわたる合計で、260.57 MiBps のスループットと 11,800 IOPS という最大パフォーマンスを実現できます。インスタンスでは、24 時間中 30 分間のみこのパフォーマンスを実現します。その後のパフォーマンスは、接続されているすべてのボリューム合計で、43.43 MiBps のスループットと 2,000 IOPS というベースラインに抑えられます。1 つのボリュームでは最大 700 MiBps と 16,000 IOPS を管理できますが、インスタンスではこのパフォーマンスを実現できません。

アプリケーションのパフォーマンスニーズがインスタンスの能力を超えている場合は、インスタンスタイプをワークロードを管理できるものに変更してください。

ボリューム内でマイクロバーストが発生する

マイクロバーストは、ボリュームが収集期間よりも大幅に短い期間において、IOPS またはスループットをバーストしたときに発生します。Amazon CloudWatch では、マイクロバーストを確認できません。詳細については、「Amazon EBS ボリュームがマイクロバーストしているかどうかを判断する方法と、それを防ぐ方法を教えてください。」を参照してください。

スナップショットからボリュームを復元したが、ボリュームが初期化中である

スナップショットからボリュームを復元すると、そのボリュームではデータを初期化する必要があります。データの各ブロックに初めてアクセスするときに、ボリュームが Amazon Simple Storage (Amazon S3) からデータをダウンロードする必要があるため、遅延が増加する場合があります。

ボリュームの初期化を強制することで、遅延を最小限に抑えることができます。Amazon EBS 高速スナップショット復元を有効にして、ボリュームの作成時に完全に初期化することもできます。

ボリュームの基盤となるストレージサブシステムに問題がある

上記のトラブルシューティング手順をすべて試しても遅延が解消されない場合は、AWS サポートにお問い合わせください。