翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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 操作が完了するまでにかかる時間、およびボリュームのスループット制限の間のつながりについて知ることが重要です。
**Topics**
+ [IOPS](#ebs-io-iops)
+ [ボリューム のキュー長とレイテンシー](#ebs-io-volume-queue)
+ [I/O サイズとボリュームのスループット制限](#ebs-io-size-throughput-limits)
+ [CloudWatch を使用して I/O 特性を監視する](#ebs-io-metrics)
+ [リアルタイムの I/O パフォーマンス統計をモニタリングする](#monitor-io-nvme)
+ [関連リソース](#ebs-io-resources)
## 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 操作に分割して処理しようとします。例をいくつか、次の表に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-io-characteristics.html)
このため、3,000 IOPS をサポートする SSD-Backed ボリュームを (`io1` または `io2` ボリュームを 3,000 IOPS でプロビジョニングするか、`gp2` ボリュームを 1,000 GiB にサイズ設定するか、`gp3` ボリュームを使用することによって) 作成し、十分な帯域幅を提供できる 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 レイテンシーが上昇する可能性があります。最大限の整合性を確保するには、ボリュームは 1 分間で 1,000 のプロビジョンド IOPS ごとに 1 の平均キュー深度 (最も近い整数に四捨五入) を維持する必要があります。例えば、3,000 IOPS でプロビジョニングされたボリュームの場合、平均キュー深度は 3 である必要があります。
スループットが高いアプリケーションは 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 ボリュームの種類](ebs-volume-types.md)を参照してください。
サイズの小さな 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 ボリュームメトリクス](using_cloudwatch_ebs.md#ebs-volume-metrics)を使用してモニタリングできます。
**停止した I/O をモニタリングする**
`VolumeStalledIOCheck` は、EBS ボリュームのステータスをモニタリングして、ボリュームに障害が発生した時期を判断します。メトリクスは、EBS ボリュームが I/O 操作を完了できるかどうかに基づいて `0` (合格) または `1` (失敗) ステータスを返すバイナリ値です。
`VolumeStalledIOCheck` メトリクスが失敗した場合、 が問題を解決 AWS するのを待つか、影響を受けるボリュームの置き換えや、ボリュームがアタッチされているインスタンスの停止と再起動などのアクションを実行できます。ほとんどの場合、このメトリクスが失敗すると、EBS は数分以内にボリュームを自動的に診断して復元します。で [I/O の一時停止](ebs-fis.md)アクションを使用すると AWS Fault Injection Service 、制御された実験を実行して、このメトリクスに基づいてアーキテクチャとモニタリングをテストし、ストレージ障害に対する耐障害性を向上させることができます。
**ボリュームの I/O レイテンシーをモニタリングする**
`VolumeAvgReadLatency` および `VolumeAvgWriteLatency` メトリクスをそれぞれ使用して、Amazon EBS ボリュームの読み取りおよび書き込み操作の平均レイテンシーをモニタリングできます。の [Latency Injection](ebs-fis-latency-injection.md) アクションを使用すると AWS Fault Injection Service 、制御された実験を実行して、このメトリクスに基づいてアーキテクチャとモニタリングをテストし、ストレージのパフォーマンス低下に対する耐障害性を向上させることができます。
I/O レイテンシーが必要な値よりも高い場合、ボリュームに対してプロビジョニングした IOPS またはスループット以上の処理をアプリケーションが実行しようとしていないことを確認します。`VolumeAvgIOPS` および `VolumeAvgThroughput` メトリクスを使用して、1 分間にボリュームに駆動される平均 IOPS とスループットをモニタリングし、それをボリュームのプロビジョンド IOPS とスループットと比較できます。ボリュームが 1 分間に操作を駆動しない場合、メトリクスでは `0` の値が報告されます。高 IOPS またはスループットのバーストが 1 分よりも短い間隔で発生した場合、ボリュームにマイクロバーストが発生しますが、平均 IOPS およびスループットメトリクスでは、ボリュームのプロビジョンド IOPS またはスループット制限よりも低いパフォーマンスが駆動されていると報告される可能性があります。ボリュームで特定の 1 分間にパフォーマンスのバーストが発生しているかどうかを確認するには、`VolumeIOPSExceededCheck` および `VolumeThroughputExceededCheck` メトリクスを使用します。これらのメトリクスをモニタリングして、ワークロードが一貫して特定の 1 分間にボリュームのプロビジョニングされたパフォーマンスよりも大きい IOPS またはスループットを駆動しようとしたかを判断できます。1 分間の任意の秒において駆動された IOPS が一貫してボリュームのプロビジョンド IOPS のパフォーマンスを超える場合、`VolumeIOPSExceededCheck` メトリクスは `1` を返します。1 分以内の任意の秒において駆動されたスループットが一貫してボリュームのプロビジョニングされたスループットパフォーマンスを超える場合、`VolumeThroughputExceededCheck` メトリクスは `1` を返します。駆動された IOPS とスループットがボリュームのプロビジョニングされたパフォーマンス内に留まっている場合、メトリクスは `0` を返します。
ボリュームが提供できるよりも多くの 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 操作のサイズを大きくすると、パフォーマンスが向上します。
**`gp2`、`st1`、および `sc1` ボリュームのバーストバケットバランスをモニタリングする**
`BurstBalance` は `gp2`、`st1`、および `sc1` ボリュームのバーストバケットバランスを残りのバランスの割合として表示します。バーストバケットが減ると、ボリューム I/O (`gp2` ボリューム用) またはボリュームスループット (`st1` および `sc1` ボリューム用) はベースラインにスロットリングされます。この理由でボリュームに制限が適用されているかどうかを確認するには、`BurstBalance` の値を調べてください。利用可能な Amazon EBS メトリクスの完全なリストについては、[Amazon EBS の Amazon CloudWatch メトリクス](using_cloudwatch_ebs.md) および「[Nitro ベースのインスタンスの Amazon EBS メトリクス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ebs-metrics-nitro)」を参照してください。
## リアルタイムの I/O パフォーマンス統計をモニタリングする
Nitro ベースの Amazon EC2 インスタンスにアタッチされている Amazon EBS ボリュームの詳細なパフォーマンス統計にリアルタイムでアクセスできます。
これらの統計を組み合わせて、平均レイテンシーと IOPS を導き出したり、I/O 操作が完了中かどうかを確認したりすることができます。また、アプリケーションが EBS ボリュームまたはアタッチされたインスタンスのプロビジョンド IOPS またはスループット制限を超えた合計時間を表示することもできます。これらの統計の増加を経時的に追跡することで、アプリケーションのパフォーマンスを最適化するためにプロビジョンド IOPS またはスループット制限を増やす必要があるかどうかを判断できます。詳細なパフォーマンス統計には、読み取りおよび書き込み I/O 操作のヒストグラムも含まれています。これにより、レイテンシーバンド内で完了した I/O 操作の合計数を追跡することで、I/O レイテンシーの分布を確認できます。
詳細については、「[Amazon EBS の詳細なパフォーマンス統計](nvme-detailed-performance-stats.md)」を参照してください。
## 関連リソース
Amazon EBS の I/O 特性の詳細については、re:Invent プレゼンテーション[Amazon EBS: パフォーマンスを考慮した設計](https://www.youtube.com/watch?v=2wKgha8CZ_w)を参照してください。