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 としてカウントするデータの最大量を決定します。SSD ボリュームは HDD ボリュームよりもはるかに効率的に小規模またはランダム I/O を処理するため、I/O サイズは SSD ボリュームで 256 KiB、HDD ボリュームで 1,024 KiB に制限されています。
小さな I/O 操作が物理的に連続している場合、Amazon EBS ではできる限りこれらを最大サイズになるまで単一の I/O 操作にマージして処理します。たとえば、SSD ボリュームでは、1 つの 1,024 KiB の I/O 操作は 4 つのオペレーション (1,024÷256=4) としてカウントされ、それぞれが 32 KiB の連続する 8 つの I/O オペレーションは、1 つのオペレーション (8×32=256) としてカウントされます。ただし、32 KiB の 8 つの連続しない I/O オペレーションは、個別に 8 つのオペレーションとしてカウントされます。この場合、32 KiB 未満の各 I/O オペレーションは 1 つのオペレーションとしてカウントされます。
同様に、HDD-Backed ボリュームの場合、1,024 KiB の単一 I/O 操作も、8 つの連続する 128 KiB の操作も、1 つの操作としてカウントされます。ただし、128 KiB のランダム I/O 操作 8 つは、8 つの操作としてカウントされます。
このため、3,000 IOPS をサポートする SSD-Backed ボリュームを (プロビジョンド 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 値がプロビジョニングした値よりも小さくなることがあります。例えば、利用可能なバーストクレジットを持つ
1000 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 のネットワーク接続を確保できるインスタンス) を使用してください。詳細については、「Amazon EBS 最適化インスタンス」を参照してください。予想された IOPS が得られない別の原因として、EBS ボリュームに対して十分な I/O を提供していないことが考えられます。
CloudWatch を使用して I/O 特性を監視する
これらの I/O 特性は、各ボリュームの CloudWatch ボリュームメトリクスを使用してモニタリングできます。考慮すべき重要なメトリクスは次のとおりです。
-
BurstBalance -
VolumeReadBytes -
VolumeWriteBytes -
VolumeReadOps -
VolumeWriteOps -
VolumeQueueLength
BurstBalance は gp2、st1、および sc1 ボリュームのバーストバケットバランスを残りのバランスの割合として表示します。バーストバケットが減ると、ボリューム I/O (gp2 ボリューム用) またはボリュームスループット (st1 および sc1 ボリューム用) はベースラインにスロットリングされます。この理由でボリュームに制限が適用されているかどうかを確認するには、BurstBalance の値を調べてください。使用可能な Amazon EBS メトリクスの完全なリストについては、Amazon EBS のメトリクス と Nitro ベースのインスタンスの Amazon EBS メトリクス をご参照ください。
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 以降には、すべてこのサポートがあり、現行世代のインスタンスも同様です。
I/O レイテンシーが必要な値よりも高い場合、VolumeQueueLength をチェックして、アプリケーションがプロビジョニングした IOPS 以上の処理を実行しようとしていないことを確認します。ボリュームが提供できる以上の IOPS を必要とするアプリケーションの場合は、より高いレベルのベースパフォーマンスを実現するサイズの
gp2 ボリュームを使用するか、より多くの IOPS をプロビジョニングできる io1 または io2 ボリュームを使用して、レイテンシーを低く抑えることを検討してください。
関連リソース
Amazon EBS の I/O 特性の詳細については、re:Invent プレゼンテーション「Amazon EBS: パフォーマンスを考慮した設計
