翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EBS ボリュームパフォーマンス
Amazon EBS のパフォーマンスは、I/O 特性やインスタンスとボリュームの設定などを含むいくつかの要因に左右されます。Amazon EBS 製品および Amazon EC2 製品の詳細ページに記載されているガイダンスに従うと、通常は良好なパフォーマンスを実現することができます。ただし、ピークパフォーマンスを実現するには、多少のチューニングを行う必要な場合があります。最適な設定を決定するには、ベンチマーキングに加えて、実際のワークロードからの情報でパフォーマンスをチューニングすることをお勧めします。EBS ボリュームの基本操作について理解したら、必要とする I/O パフォーマンスと、Amazon EBS パフォーマンスを向上させるオプションを確認し、そのパフォーマンス要件に対応できるようにすることをお勧めします。
AWS EBS ボリュームタイプのパフォーマンスの更新は、既存のボリュームにすぐには反映されない場合があります。古いボリュームで完全なパフォーマンスを確認するためには、最初に `ModifyVolume` アクションの実行が必要になる場合があります。詳細については、「[Elastic Volumes オペレーションを使用して Amazon EBS ボリュームを変更する](ebs-modify-volume.md)」を参照してください。
**Topics**
+ [Amazon EBS パフォーマンスのヒント](#tips)
+ [Amazon EBS 最適化](ebs-optimization.md)
+ [Amazon EBS ボリュームの初期化](initalize-volume.md)
+ [設定可能なインスタンス帯域幅の重み付け](instance-bandwidth-configuration.md)
+ [Amazon EBS I/O の特性およびモニタリング](ebs-io-characteristics.md)
+ [Amazon EBS および RAID の構成](raid-config.md)
+ [Amazon EBS ボリュームのベンチマーク](benchmark_procedures.md)
## Amazon EBS パフォーマンスのヒント
ここに示すヒントは、さまざまなユーザーシナリオで、EBS ボリュームから最適なパフォーマンスを得るためのベストプラクティスを表しています。
### EBS 最適化インスタンスを使用する
EBS 最適化スループットがサポートされていないインスタンスでは、インスタンスと EBS ボリュームの間のトラフィックが、ネットワークトラフィックと競合する場合があります。EBS 最適化インスタンスでは、これら 2 種類のトラフィックを分離した状態が維持されます。EBS 最適化インスタンスの設定によっては、追加コストが発生する場合 (C3、R3、M3 など) と、追加コストなしで常に EBS 最適化状態になる場合 (M4、C4、C5､D2 など) があります。詳細については、「[Amazon EBS 最適化](ebs-optimization.md)」を参照してください。
### インスタンス帯域幅を設定する
サポートされているインスタンスタイプでは、`ebs-1` の帯域幅の重み付けを使用して、Amazon EBS の帯域幅を 25% 増やすようにインスタンス帯域幅の重み付けを設定できます。この機能を使用して EBS と VPC ネットワーク間のインスタンスのネットワークリソース割り当てを最適化することで、I/O 集約型ワークロードの EBS パフォーマンスを改善できる可能性があります。詳細については、「[設定可能なインスタンス帯域幅の重み付け](instance-bandwidth-configuration.md)」を参照してください。
### パフォーマンスの計算方法を理解する
EBS ボリュームのパフォーマンスを測定する場合、関連する測定単位と、パフォーマンスの計算方法を理解することが重要です。詳細については、[Amazon EBS I/O の特性およびモニタリング](ebs-io-characteristics.md)を参照してください。
### ワークロードを理解する
EBS ボリュームの最大パフォーマンス、I/O 操作の数およびサイズ、各アクションが完了するまでの所要時間は、互いに関連しています。これらの各要因 (パフォーマンス、I/O、レイテンシー) は相互に影響を与えます。また、アプリケーションが異なると、影響を受ける要因もさまざまに異なります。詳細については、「[Amazon EBS ボリュームのベンチマーク](benchmark_procedures.md)」を参照してください。
### スナップショットからボリュームを初期化する際のパフォーマンス低下に注意する
スナップショットから作成された新しい EBS ボリュームの各データブロックに初めてアクセスするときには、レイテンシーが著しく増加します。このパフォーマンスヒットは、以下のいずれかの方法で回避できます。
+ 各ブロックへのアクセスが、ボリュームの本番環境への移行前に起こるようにする。このプロセスは、*初期化*と呼ばれます (以前は事前ウォーミングと呼ばれていました)。詳細については、[作成後にボリュームを手動で初期化する](initalize-volume.md#ebs-initialize)を参照してください。
+ スナップショットの高速スナップショット復元を有効化して、スナップショットから作成される EBS ボリュームが作成時に完全に初期化され、各ボリュームのあらゆるプロビジョンドパフォーマンスが即座に発揮されるようにします。詳細については、[Amazon EBS 高速スナップショット復元](ebs-fast-snapshot-restore.md)を参照してください。
### HDD パフォーマンスが低下する要因
スループット最適化 HDD (`st1`) または Cold HDD (`sc1`) ボリュームのスナップショットを作成すると、スナップショットの進行中はボリュームのベースライン値までパフォーマンスが低下する可能性があります。この動作は、これらのボリュームタイプに固有です。パフォーマンスが制限される他の要因としては、インスタンスでのサポート範囲を超えるスループットの強要、スナップショットから作成したボリュームの初期化中のパフォーマンス低下、ボリュームに対する大量の小さなランダム I/O などがあります。HDD ボリュームのスループットを計算する方法については、[Amazon EBS ボリュームの種類](ebs-volume-types.md)を参照してください。
アプリケーションから送られる I/O リクエスト数が十分でない場合も、パフォーマンスに影響します。これは、ボリュームのキュー長や I/O サイズを確認することで監視できます。このキュー長とは、アプリケーションからボリュームへの I/O リクエストのうち処理待ちのものの数です。最大限の安定性を確保するために、HDD-Backed ボリュームで 1 MiB のシーケンシャル I/O を実行する際には、キュー長 (整数に四捨五入) を 4 以上に保つ必要があります。安定したパフォーマンスの確保については、[Amazon EBS I/O の特性およびモニタリング](ebs-io-characteristics.md)を参照してください。
### `st1` および `sc1` (Linux インスタンスインスタンスのみ) で高いスループットの読み取りが多いワークロードに先読みを増やす
一部のワークロードでは読み取りが多く、オペレーティングシステムのページキャッシュを通じて (例えば、ファイルシステムから) ブロックデバイスへのアクセスが行われます。この場合、最大スループットを実現するには、先読みを 1 MiB に設定することをお勧めします。これは HDD ボリュームにのみ適用されるブロックデバイス単位の設定です。
ブロックデバイスに対する現在の先読み値を調べるには、次のコマンドを使用します。
```
$ sudo blockdev --report /dev/{{}}
```
ブロックデバイス情報は次の形式で返されます。
```
RO RA SSZ BSZ StartSec Size Device
rw 256 512 4096 4096 8587820544 /dev/
```
表示されているデバイスについては、先読み値として 256 (デフォルト値) が報告されています。この数値にセクターサイズ (512 バイト) を乗算すると、先読みバッファのサイズ (この場合は 128 KiB) を得ることができます。バッファ値を 1 MiBに設定するには、次のコマンドを使用します。
```
$ sudo blockdev --setra 2048 /dev/{{}}
```
最初のコマンドをもう一度実行して、先読み設定が 2,048 になったことを確認します。
この設定は、ワークロードがサイズの大きなシーケンシャル I/O で構成される場合にのみ使用してください。ワークロードの内容として、サイズの小さなランダム I/O がほとんどであれば、この設定を使用すると逆にパフォーマンスが低下します。一般的に、サイズの小さい I/O やランダム I/O が大部分を占めるワークロードの場合は、`st1` や `sc1` ボリュームではなく、汎用 SSD (`gp2` および `gp3`) ボリュームの使用を検討してください。
### 最新の Linux カーネルを使用する (Linux インスタンスのみ)
間接記述子がサポートされている最新の Linux カーネルを使用します。Linux カーネル 3.8 以降には、すべてこのサポートがあり、現行世代の EC2 インスタンスも同様です。平均 I/O サイズが 44 KiB 前後であれば、間接記述子がサポートされていないインスタンスやカーネルを使用している可能性があります。Amazon CloudWatch のメトリクスから平均 I/O サイズを得る方法については、[Amazon EBS I/O の特性およびモニタリング](ebs-io-characteristics.md)を参照してください。
`st1` または `sc1` ボリュームで最大スループットを達成するには、256 の値を、`xen_blkfront.max` パラメータ (Linux カーネルバージョン 4.6 未満の場合)または `xen_blkfront.max_indirect_segments` パラメータ (Linux カーネルバージョン 4.6 以降の場合) に適用することを推奨します。適切なパラメータは、OS の起動コマンドラインで設定できます。
例えば、Amazon Linux AMI では、`/boot/grub/menu.lst` に記述されている GRUB 設定で kernel 行の末尾に追加できます。
```
kernel /boot/vmlinuz-4.4.5-15.26.amzn1.x86_64 root=LABEL=/ console=ttyS0 xen_blkfront.max=256
```
後のカーネルの場合、コマンドは次のようになります。
```
kernel /boot/vmlinuz-4.9.20-11.31.amzn1.x86_64 root=LABEL=/ console=tty1 console=ttyS0 xen_blkfront.max_indirect_segments=256
```
この設定を有効にするには、インスタンスを再起動する必要があります。
詳細については、「[準仮想化 AMI 向けの GRUB の設定](https://docs.aws.amazon.com/linux/al2/ug/UserProvidedKernels.html#configuringGRUB)」を参照してください。他の Linux ディストリビューションでは (特に GRUB ブートローダーが使用されていない場合)、カーネル パラメータの調整に別のアプローチが必要になることがあります。
EBS I/O の特性の詳細については、このトピックの[Amazon EBS: パフォーマンスを考慮した設計](https://www.youtube.com/watch?v=2wKgha8CZ_w)プレゼンテーションを参照してください。
### RAID 0 を使用してインスタンスのリソース使用率を最大化する
一部のインスタンスタイプでは、単一の EBS ボリュームをプロビジョニングする場合よりも I/O スループットを増やすことができます。複数のボリュームを RAID 0 設定で結合し、これらのインスタンス用の利用可能な帯域幅を使用できます。詳細については、「[Amazon EBS および RAID の構成](raid-config.md)」を参照してください。
### Amazon EBS ボリュームのパフォーマンスをモニタリングする
Amazon CloudWatch、ステータスチェック、EBS の詳細なパフォーマンス統計を使用して、Amazon EBS ボリュームのパフォーマンスをモニタリングおよび分析できます。詳細については、「[Amazon EBS の Amazon CloudWatch メトリクス](using_cloudwatch_ebs.md)」および「[Amazon EBS の詳細なパフォーマンス統計](nvme-detailed-performance-stats.md)」を参照してください。