IOPS ボリュームのキュー長とレイテンシー I/O サイズとボリュームのスループット制限 CloudWatch を使用して I/O 特性を監視する関連リソース

Amazon EBS I/O の特性およびモニタリング

ボリューム設定が同じであっても、特定の I/O 特性により EBS ボリュームのパフォーマンス動作が向上します。SSD-Backed ボリューム – 汎用 SSD (gp2 および gp3) とプロビジョンド IOPS SSD (io1 および io2) – I/O オペレーションがランダムでもシーケンシャルでも、安定したパフォーマンスが提供されます。HDD-Backed ボリューム – スループット最適化 HDD (st1) および Cold HDD (sc1) – サイズが大きくシーケンシャルな I/O の場合のみ、最適なパフォーマンスが提供されます。アプリケーションにおける SSD ボリュームおよび HDD ボリュームのパフォーマンスについて理解するには、ボリュームに対するデマンド、ボリュームに対して使用可能な IOPS の量、I/O 操作が完了するまでにかかる時間、およびボリュームのスループット制限の間のつながりについて知ることが重要です。

IOPS

IOPS とは、1 秒あたりの入出力操作数を表す測定単位です。操作は KiB 単位で計測され、基礎となるドライブテクノロジーが1 つの I/O としてカウントするデータの最大量を決定します。I/O サイズは、SSD ボリュームで 256 KiB、HDD ボリュームで 1,024 KiB に制限されます。これは、小さい I/O やランダム I/O の扱いにおいて、SSD ボリュームは HDD ボリュームに比べてはるかに効率的であるためです。

小さな I/O 操作が物理的に連続している場合、Amazon EBS ではできる限りこれらを最大の I/O サイズになるまで、単一の I/O 操作にマージして処理します。同様に、I/O 操作が最大 I/O サイズより大きい場合、Amazon EBS ではより小さな I/O 操作に分割して処理しようとします。例をいくつか、次の表に示します。

ボリュームタイプ	最大 I/O サイズ	アプリケーションからの I/O 操作	IOPS 数	コメント
SSD	256 KiB	1 x 1024 KiB I/O 操作	4 (1,024 ÷ 256 = 4)	Amazon EBS は、1,024 の I/O 操作を 4 つのより小さな 256 KiB の操作に分割します。
		8 x シーケンシャル 32 KiB I/O 操作	1 (8 x 32 = 256)	Amazon EBS は、8 つの連続した 32 KiB の I/O 操作を、1 つの 256 KiB の操作にマージします。
		8 つのランダムな 32 KiB の I/O 操作	8	Amazon EBS は、ランダムな I/O 操作を個別にカウントします。
HDD	1,024 KIB	1 x 1024 KiB I/O 操作	1	I/O 操作は、すでに最大 I/O サイズと等しくなっています。マージまたは分割されません。
		8 x シーケンシャル 128 KiB I/O 操作	1 (8 x 128 = 1,024)	Amazon EBS は、連続した 8 つの128 KiB I/O 操作を、1 つの 1,024 KiB の I/O 操作にマージします。
		8 つのランダムな 32 KiB の I/O 操作	8	Amazon EBS は、ランダムな I/O 操作を個別にカウントします。

このため、3,000 IOPS をサポートする SSD-Backed ボリュームを (Provisioned IOPS SSD ボリュームを 3,000 IOPS でプロビジョニングするか、汎用 SSD ボリュームを 1000 GiB にサイズ設定することによって) 作成し、十分な帯域幅を提供できる EBS 最適化インスタンスにアタッチした場合、1 秒あたり最大 3,000 件の I/O 操作分のデータを転送できます (スループットは I/O サイズで決まります)。

ボリュームのキュー長とレイテンシー

ボリュームのキュー長とは、デバイスに対する保留中の I/O リクエストの数です。レイテンシーとは、実際に I/O 操作にかかるエンドツーエンドのクライアント時間です。つまり、I/O を EBS に送信してから、読み取りまたは書き込みの I/O が完了したという確認を EBS から受信するまでの時間ということになります。ゲストオペレーティングシステムまたは EBS へのネットワークリンクでのボトルネックを回避するには、I/O サイズとレイテンシーに合わせて正しくキュー長を調整する必要があります。

最適なキュー長は、アプリケーションがどの程度 IOPS およびレイテンシーの影響を受けるかによってワークロードごとに異なります。EBS ボリュームで利用可能なパフォーマンスをフル活用するための十分な I/O リクエストがワークロードから提供されないと、プロビジョニングどおりの IOPS またはスループットをボリュームで実現できないことがあります。

トランザクション量の多いアプリケーションは、I/O レイテンシーの上昇の影響を受けるため、SSD-Backed ボリュームが適しています。キュー長を小さく抑え、ボリュームで利用可能な限り高い IOPS を維持することにより、低いレイテンシーと高い IOPS を実現できます。ボリュームで利用可能な IOPS を超える IOPS を継続的に強制すると、I/O レイテンシーが上昇する可能性があります。

スループットが高いアプリケーションは I/O レイテンシーの上昇による影響を受けにくいため、HDD-Backed ボリュームが適しています。HDD-Backed ボリュームに対する高いスループットを維持するには、サイズの大きなシーケンシャル I/O を実行するときにキュー長を大きくします。

I/O サイズとボリュームのスループット制限

SSD-Backed ボリュームで I/O サイズが非常に大きい場合は、ボリュームのスループット制限に達することにより、IOPS 値がプロビジョニングした値よりも小さくなることがあります。例えば、利用可能なバーストクレジットを持つ 1,000 GiB 未満の gp2 ボリュームの IOPS 制限は 3,000 で、ボリュームスループット制限は 250 MiB/秒です。256 KiB の I/O サイズを使用している場合、ボリュームは 1000 IOPS (1000 x 256 KiB = 250 MiB) でスループット制限に達します。より小さい I/O サイズ (16 KiB など) では、スループットが 250 MiB/s を大幅に下回っているため、同じボリュームで 3,000 IOPS を維持できます。(これらの例では、ボリュームの I/O がインスタンスのスループット限界に達していないと想定しています)。各 EBS ボリュームタイプのスループット制限については、Amazon EBS ボリュームの種類を参照してください。

サイズの小さな I/O 操作では、インスタンス内で測定した IOPS がプロビジョニングの値より高くなることがあります。この状況は、インスタンスのオペレーティングシステムが、小さな I/O 操作を Amazon EBS に渡す前に、大きな操作にマージした場合に生じます。

ワークロードが HDD バックアップの st1 および sc1 ボリュームでシーケンシャル I/O を使用する場合、ワークロードで使用している I/O がシーケンシャルであれば、インスタンス内で測定した IOPS が予測値より高くなることがあります。この状況は、インスタンスのオペレーティングシステムが、シーケンシャル I/O をマージし、1,024 KiB サイズ単位でカウントすることによって生じます。ワークロードで小さな I/O またはランダム I/O を使用している場合は、スループットが予測値より低くなることがあります。これは、非シーケンシャルの各ランダム I/O をカウントして合計の IOPS カウントを求める過程で、予測より早くボリュームの IOPS 制限に達する場合があるためです。

EBS ボリュームタイプに関係なく、設定したはずの IOPS またはスループットを得られない場合は、EC2 インスタンスの帯域幅が制限要因になっていないか確認してください。最適なパフォーマンスを得るには、常に現行世代の EBS 最適化インスタンス (または、10 Gb/s のネットワーク接続を確保できるインスタンス) を使用してください。予想された IOPS が得られない別の原因として、EBS ボリュームに対して十分な I/O を提供していないことが考えられます。

CloudWatch を使用して I/O 特性を監視する

これらの I/O 特性は、各ボリュームの CloudWatch ボリュームメトリクスを使用してモニタリングできます。考慮すべき重要なメトリクスは次のとおりです。

VolumeStalledIOCheck
BurstBalance
VolumeReadBytes | VolumeWriteBytes
VolumeReadOps | VolumeWriteOps
VolumeQueueLength

VolumeStalledIOCheck は、EBS ボリュームのステータスをモニタリングして、ボリュームに障害が発生した時期を判断します。メトリクスは、EBS ボリュームが I/O 操作を完了できるかどうかに基づいて 0 (合格) または 1 (失敗) ステータスを返すバイナリ値です。このチェックでは、Amazon EBS インフラストラクチャに関する次のような根本的な問題が検出されます。

EBS ボリュームの基盤となるストレージサブシステムのハードウェアまたはソフトウェアの問題
EC2 インスタンスからの EBS ボリュームの到達可能性に影響する、物理ホスト上のハードウェアの問題
インスタンスと EBS ボリューム間の接続に関する問題

VolumeStalledIOCheck メトリクスが失敗した場合は、AWS が問題を解決するまで待つか、影響を受けたボリュームの置き換えやボリュームがアタッチされているインスタンスの停止および再起動などのアクションを実行することができます。ほとんどの場合、このメトリクスが失敗すると、EBS は数分以内にボリュームを自動的に診断して復元します。AWS Fault Injection Service の [I/O の一時停止] アクションを使用してコントロールされた実験を実行し、このメトリクスに基づいてアーキテクチャやモニタリングをテストし、ストレージ障害に対する回復力を向上させることができます。

Amazon EBS ストレージ I/O レイテンシーは、VolumeReadOps、VolumeWriteOps、VolumeTotalReadTime、および VolumeTotalWriteTime を使用して測定できます。次の式を使用すると、ボリュームの平均 I/O レイテンシーをモニタリングできます。


Average I/O latency in ms/op = (VolumeTotalReadTime + VolumeTotalWriteTime) / (VolumeReadOps + VolumeWriteOps)

I/O レイテンシーが必要な値よりも大きい場合、駆動される IOPS をチェックして、アプリケーションがプロビジョニングした IOPS 以上の処理を実行しようとしていないことを確認します。ボリューム上の IOPS の平均駆動回数をモニタリングするには、次の式を使用します。


Estimated average IOPS in ops/s = (Sum(VolumeReadOps) + Sum(VolumeWriteOps)) / (Period - Sum(VolumeIdleTime))

ボリュームが提供できるよりも多くの IOPS がアプリケーションに必要な場合は、次のいずれかの使用を検討する必要があります。

必要なレイテンシーを実現するのに十分な IOPS がプロビジョニングされている、gp3、io2、または io1 ボリューム
十分なベースライン IOPS パフォーマンスを実現するより大容量の gp2 ボリューム

st1 および sc1 の HDD-Back ボリュームは、1,024 KiB の最大 I/O サイズを活用するワークロードに最適な設定になっています。ボリュームの平均 I/O サイズを求めるには、VolumeWriteBytes を VolumeWriteOps で除算します。読み取り操作にも同じ計算を適用できます。平均 I/O サイズが 64 KiB を下回る場合は、st1 または sc1 のボリュームに送る I/O 操作のサイズを大きくすると、パフォーマンスが向上します。

注記

平均 I/O サイズが 44 KiB 前後であれば、間接記述子がサポートされていないインスタンスやカーネルを使用している可能性があります。Linux カーネル 3.8 以降には、すべてこのサポートがあり、現行世代のインスタンスも同様です。

BurstBalance は gp2、st1、および sc1 ボリュームのバーストバケットバランスを残りのバランスの割合として表示します。バーストバケットが減ると、ボリューム I/O (gp2 ボリューム用) またはボリュームスループット (st1 および sc1 ボリューム用) はベースラインにスロットリングされます。この理由でボリュームに制限が適用されているかどうかを確認するには、BurstBalance の値を調べてください。利用可能な Amazon EBS メトリクスの完全なリストについては、Amazon EBS のAmazon CloudWatch メトリックスおよび「Nitro ベースのインスタンスの Amazon EBS メトリクス」を参照してください。