翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
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 は、HDDボリュームよりもinput/output operations per second. The operations are measured in KiB, and the underlying drive technology determines the maximum amount of data that a volume type counts as a single I/O. I/O size is capped at 256 KiB for SSD volumes and 1,024 KiB for HDD volumes because SSD volumes handle small or random I/Oはるかに効率的に表される測定単位です。
小さな I/O オペレーションが物理的にシーケンシャルである場合、Amazon はそれらを最大 I/O サイズまで 1 回の I/O オペレーションにマージEBSしようとします。同様に、I/O オペレーションが最大 I/O サイズより大きい場合、Amazon はそれらをより小さな I/O オペレーションに分割EBSしようとします。例をいくつか、次の表に示します。
ボリュームタイプ | 最大 I/O サイズ | アプリケーションからの I/O 操作 | の数IOPS | メモ |
---|---|---|---|---|
SSD | 256 KiB | 1 x 1024 KiB I/O 操作 | 4 (1,024 ÷ 256 = 4) | Amazon は、1,024 の I/O オペレーションを 4 つの小さな 256 KiB オペレーションにEBS分割します。 |
8 x シーケンシャル 32 KiB I/O 操作 | 1 (8 x 32 = 256) | Amazon は、8 つのシーケンシャル 32 KiB I/O オペレーションを 1 つの 256 KiB オペレーションにEBSマージします。 | ||
8 つのランダムな 32 KiB の I/O 操作 | 8 | Amazon はランダム I/O オペレーションを個別にEBSカウントします。 | ||
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 は、8 つのシーケンシャル 128 KiB I/O オペレーションを 1 つの 1,024 KiB I/O オペレーションにEBSマージします。 | ||
8 つのランダムな 32 KiB の I/O 操作 | 8 | Amazon はランダム I/O オペレーションを個別にEBSカウントします。 |
したがって、3,000 をサポートする SSD-backed ボリュームを作成し IOPS (3,000 で io1
または io2
ボリュームをプロビジョニングするかIOPS、1,000 GiB のgp2
ボリュームのサイズを設定するか、gp3
ボリュームを使用するかのいずれか)、十分な帯域幅を提供できる EBS最適化インスタンスにアタッチすると、I/O サイズによって決定されるスループットで 1 秒あたり最大 3,000 I/O のデータを転送できます。
ボリューム のキュー長とレイテンシー
ボリュームのキュー長とは、デバイスに対する保留中の I/O リクエストの数です。レイテンシーとは、I/O オペレーションの真の end-to-endクライアント時間、つまり、I/O が に送信EBSされてから I/O の読み取りまたは書き込みが完了したEBSことの確認を受け取るまでの経過時間です。キューの長さは、ゲストオペレーティングシステムまたは へのネットワークリンクでボトルネックが発生しないように、I/O サイズとレイテンシーで正しくキャリブレーションする必要がありますEBS。
最適なキューの長さは、特定のアプリケーションの感度IOPSとレイテンシーに応じてワークロードごとに異なります。ワークロードがEBSボリュームで利用可能なパフォーマンスを最大限に活用するために十分な I/O リクエストを配信していない場合、ボリュームはプロビジョニングした IOPSまたは スループットを配信しない可能性があります。
トランザクション集約型アプリケーションは、I/O レイテンシーの増加に敏感であり、SSD-backed ボリュームに適しています。キューの長さを低くし、ボリュームIOPSで使用できる の数を多く維持することで、レイテンシーを抑えIOPSながら高い を維持できます。使用可能なボリュームよりも多くのボリュームIOPSに一貫して運転すると、I/O レイテンシーが増加する可能性があります。
スループットを多用するアプリケーションは、I/O レイテンシーの増加に対する感度が低く、HDD-backed ボリュームに適しています。シーケンシャル I/O を大規模に実行する場合、キュー長を長くすることで、HDD-backed ボリュームへの高スループットを維持できます。
I/O サイズとボリュームのスループット制限
SSD-backed ボリュームの場合、I/O サイズが非常に大きいと、ボリュームのスループット制限に達しているため、プロビジョニングしたIOPSよりも の数が少なくなる可能性があります。例えば、バーストクレジットが使用可能な 1,000 GiB 未満のgp2
ボリュームは 3,000 IOPSの制限があり、ボリュームスループット制限MiB/s. If you are using a 256 KiB I/O size, your volume reaches its throughput limit at 1000 IOPS (1000 x 256 KiB = 250 MiB). For smaller I/O sizes (such as 16 KiB), this same volume can sustain 3,000 IOPS because the throughput is well below 250 MiB/s. (These examples assume that your volume's I/Oは 250 でインスタンスのスループット制限に達していません)。各EBSボリュームタイプのスループット制限の詳細については、「」を参照してくださいAmazon EBSボリュームタイプ。
小規模な I/O オペレーションでは、インスタンス内から測定されたIOPS値が表示される higher-than-provisioned場合があります。これは、インスタンスオペレーティングシステムが小さな 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に最適化されたインスタンス (またはEBSボリュームGb/s network connectivity) for optimal performance. Another possible cause for not experiencing the expected IOPS is that you are not driving enough I/Oに 10 を含むインスタンス) を使用する必要があります。
を使用した I/O 特性のモニタリング CloudWatch
これらの I/O 特性は、各ボリュームのCloudWatch ボリュームメトリクスでモニタリングできます。
停止した I/O をモニタリングする
VolumeStalledIOCheck
はEBSボリュームのステータスをモニタリングして、ボリュームに障害が発生したかどうかを判断します。メトリクスは、EBSボリュームが I/O オペレーションを完了できるかどうかに基づいて、0
ステータス (合格) またはステータス 1
(失敗) を返すバイナリ値です。
VolumeStalledIOCheck
メトリクスが失敗した場合は、 が問題を解決 AWS するのを待つか、影響を受けるボリュームの置き換えや、ボリュームがアタッチされているインスタンスの停止と再起動などのアクションを実行できます。ほとんどの場合、このメトリクスが失敗すると、 EBSは数分以内にボリュームを自動的に診断して復旧します。の I/O 一時停止アクションを使用して AWS Fault Injection Service 、制御された実験を実行し、このメトリクスに基づいてアーキテクチャとモニタリングをテストして、ストレージ障害に対する回復性を向上させることができます。
ボリュームの I/O レイテンシーをモニタリングする
VolumeAvgReadLatency
および VolumeAvgWriteLatency
メトリクスをそれぞれ使用して、Amazon EBSボリュームの読み取りおよび書き込みオペレーションの平均レイテンシーをモニタリングできます。
I/O レイテンシーが要件よりも大きい場合は、アプリケーションがボリュームにプロビジョニングした数よりも多くの IOPSまたはスループットをドライブしようとしていないことを確認してください。次の式を使用して、特定の期間にボリュームに駆動される平均IOPSとスループットを計算し、それをボリュームのプロビジョニングされたスループットIOPSと比較します。
Sum(VolumeReadOps) + Sum(VolumeWriteOps)
Estimated average IOPS in ops/s = ----------------------------------------
Period - Sum(VolumeIdleTime)
(Sum(VolumeReadBytes) + Sum(VolumeWriteBytes)) / 1024
Estimated average throughput in KiB/s = -----------------------------------------------------
Period - Sum(VolumeIdleTime)
また、 メトリクスVolumeIOPSExceededCheck
と VolumeThroughputExceededCheck
メトリクスをモニタリングして、ワークロードが一貫してドライブを試みたかどうかIOPS、または特定の 1 分間にボリュームのプロビジョニングされたパフォーマンスよりも大きいスループットを実行しようとしたかどうかを判断することもできます。駆動がボリュームのプロビジョニングされたIOPSパフォーマンスをIOPS一貫して超える場合、VolumeIOPSExceededCheck
メトリクスは を返します1
。ドリブンスループットがボリュームのプロビジョニングされたスループットパフォーマンスを一貫して超える場合、VolumeThroughputExceededCheck
メトリクスは を返します1
。駆動型IOPSでスループットがボリュームのプロビジョニングされたパフォーマンス内にある場合、メトリクスは を返します0
。
アプリケーションがボリュームで提供できる数IOPSよりも多くの を必要とする場合は、次のいずれかの使用を検討する必要があります。
-
必要なレイテンシーを達成するIOPSのに十分な容量でプロビジョニングされた
gp3
io2
、、またはio1
ボリューム -
十分なベースラインIOPSパフォーマンスを提供するより大きな
gp2
ボリューム
HDD-backed st1
および sc1
ボリュームは、最大 I/O サイズ 1,024 KiB を利用するワークロードで最高のパフォーマンスを発揮するように設計されています。ボリュームの平均 I/O サイズを決定するには、 VolumeWriteBytes
で割りますVolumeWriteOps
。読み取り操作にも同じ計算を適用できます。平均 I/O サイズが 64 KiB を下回る場合は、st1
または sc1
のボリュームに送る I/O 操作のサイズを大きくすると、パフォーマンスが向上します。
、gp2
、st1
および sc1
ボリュームのバーストバケットバランスをモニタリングする
BurstBalance
は gp2
、st1
、および sc1
ボリュームのバーストバケットバランスを残りのバランスの割合として表示します。バーストバケットが減ると、ボリューム I/O (gp2
ボリューム用) またはボリュームスループット (st1
および sc1
ボリューム用) はベースラインにスロットリングされます。この理由でボリュームに制限が適用されているかどうかを確認するには、BurstBalance
の値を調べてください。使用可能な Amazon EBSメトリクスの完全なリストについては、Amazon の Amazon CloudWatch メトリクス EBS「」および「Nitro ベースのインスタンスの Amazon EBSメトリクス」を参照してください。
リアルタイムの I/O パフォーマンス統計をモニタリングする
Nitro ベースの Amazon EC2インスタンスにアタッチされている Amazon EBSボリュームの詳細なパフォーマンス統計にリアルタイムでアクセスできます。
これらの統計を組み合わせて、平均レイテンシーと を取得したりIOPS、I/O オペレーションが完了しているかどうかを確認したりできます。アプリケーションがEBSボリュームまたはアタッチされたインスタンスのプロビジョニングIOPSされた制限またはスループット制限を超えた合計時間を表示することもできます。これらの統計の経時的な増加を追跡することで、アプリケーションのパフォーマンスを最適化するためにプロビジョニングされた制限IOPSとスループット制限のどちらを増やす必要があるかを特定できます。詳細なパフォーマンス統計には、読み取りおよび書き込み I/O オペレーションのヒストグラムも含まれます。これにより、レイテンシーバンド内で完了した I/O オペレーションの合計数を追跡することで、I/O レイテンシーを分散できます。
詳細については、「Amazon EBS の詳細なパフォーマンス統計」を参照してください。
関連リソース
Amazon EBS I/O の特性の詳細については、re:Invent プレゼンテーション「Amazon EBS: パフォーマンスを考慮した設計