メニュー
Amazon Elastic Compute Cloud
Linux インスタンス用ユーザーガイド

I/O の特性とモニタリング

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

IOPS

IOPS とは、1 秒あたりの入出力操作数を表す測定単位です。操作は KiB 単位で測定され、そのボリュームタイプで単一 I/O としてカウントされる最大データ量は、基盤となるドライブのテクノロジーによって決まります。SSD ボリュームではサイズが小さい I/O やランダム I/O の処理が HDD ボリュームより効率良く行われるため、最大の 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 ボリュームを (io1 ボリュームを 3,000 IOPS でプロビジョニングするか、gp2 ボリュームを 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 レイテンシーの上昇の影響を受けるため、io1 および gp2 の SSD-Backed ボリュームが適しています。キュー長を小さく抑え、ボリュームで利用可能な限り高い IOPS を維持することにより、低いレイテンシーと高い IOPS を実現できます。ボリュームで利用可能な IOPS を超える IOPS を継続的に強制すると、I/O レイテンシーが上昇する可能性があります。

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

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

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

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

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

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

CloudWatch で I/O 特性を監視する

これらの I/O 特性は、各ボリュームの CloudWatch メトリクス を使用して監視できます。考慮する必要のある重要なメトリクスには、次のようなものがあります。

  • BurstBalance

  • VolumeReadBytes

  • VolumeWriteBytes

  • VolumeReadOps

  • VolumeWriteOps

  • VolumeQueueLength

BurstBalancegp2st1、および sc1 ボリュームのバーストバケットバランスを残りのバランスの割合として表示します。バーストバケットが減ると、ボリューム I/O クレジット (gp2 ボリューム用) またはボリュームスループットクレジット (st1 および sc1 ボリューム用) はベースラインにスロットリングされます。この理由でボリュームに制限が適用されているかどうかを確認するには、BurstBalance の値を調べてください。

st1 および sc1 の HDD-Backed ボリュームは、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 を使用して、レイテンシーを低く抑えることを検討してください。

Amazon EBS I/O の特性の詳細については、このトピックの「Amazon EBS: パフォーマンスを考慮した設計 re:Invent」プレゼンテーションを参照してください。