EBS ボリュームとパフォーマンス再入門

## EBS ボリュームタイプの選択
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-volume-types.html

### EBS ボリュームの種類

Amazon EBS では複数のボリュームタイプが提供されており、パフォーマンス特性と料金が異なります。

* 汎用 SSD (gp2, gp3): その名の通りほとんどのワークロードに適しています
* Provisioned IOPS SSD (io1, io2, io2Block Express): ミッションクリティカルで高い I/O 性能が求められるワークロードに適しています 

それぞれのボリュームタイプの最大性能が決まっており、このカタログ値も判断基準の一つです。
詳細は後述しますが、すべてのボリュームで常に最大パフォーマンスが得られるわけではないことに注意ください。

| ボリュームタイプ                       | gp2           | gp3          | io1           | io2           | io2 Block Express |
| -------------------------------------- | ------------- | ------------ | ------------- | ------------- | ----------------- |
| **ボリュームサイズ**                   | 1 GiB - 16TiB | 1GiB - 16TiB | 4 GiB～16 TiB | 4 GiB～16 TiB | 4 GiB～64 TiB     |
| **ボリュームあたりの最大IOPS**         | 16,000        | 16,000       | 64,000        | 64,000        | 256,000           |
| **ボリュームあたりの最大スループット** | 250 MiB/秒    | 1,000 MiB/秒 | 1,000 MiB/秒  | 1,000 MiB/秒  | 4,000 MiB/秒      |

※ io2 Block Express は R5b インスタンスで io2 ボリュームを使用した場合のみ、自動で有効化されます。

### 汎用 SSD (gp2, gp3) 選択時の考慮点 
#### gp2 の I/O クレジットおよびバーストパフォーマンスの考え方

gp2 の I/O 性能はボリュームの割当サイズにより変動します。ベースラインパフォーマンスは 1 GiB あたり 3 IOPS で、最小値は 100 IOPS、最大値は 16000 IOPS です。例えば 100 GiB のボリュームでは 300 IOPS がベースライン (最低保障) 性能となります。

1000 GiB 未満の汎用 (SSD) ボリュームでは、最大で 3000 IOPS までバースト可能です。gp2 ボリュームには I/O クレジットという概念があり、これを消費することで少ない割当のボリュームであっても、最大 30分間は 3000 IOPS のパフォーマンスを発揮することができます。I/O クレジットを消費した場合は時間とともに回復します。

バーストパフォーマンスに依存しているアプリケーションで I/O クレジットが枯渇した場合、稼働するアプリケーションに影響が発生する可能性がある点についてご注意ください。1000 GiB 未満のボリュームを使用している環境では I/O クレジットの残量を CloudWatch のメトリクス (BurstBalance) でモニタリングしておくことが重要です。

最大スループット性能もボリュームサイズに応じて変動します。

* 170 GiB 以下のボリューム: 128 MiB/秒
* 170 GiB 以上 334 GiB 以下のボリューム: I/Oクレジットを消費している間は 250 MiB/秒
* 334 GiB 以上のボリューム: 250 MIB/秒

#### gp3 ボリュームの概要

gp3 は最新世代の汎用 SSD ボリュームです。gp3 には I/O クレジットおよびバーストパフォーマンスの概念はありません。割当サイズによらず、ベースライン性能は 3,000 IOPS と 125 MiB/秒のスループットです。以下の追加料金を支払うことで IOPS とスループットをボリュームあたりの最大値までプロビジョニングできます。

東京リージョン 2021年10月 時点

+ 3,000 IOPS までは無料、3,000 を超えた分について 1 か月におけるプロビジョンド IOPS あたり 0.006USD
+ 125 MB/秒 までは無料、125 を超えた分について 1 か月におけるプロビジョンド MB/秒あたり 0.048USD

gp3 はチューニングの自由度が高く、I/O クレジットのような複雑な概念がありません。1 GB あたりの利用料金も gp3 のほうが 20% 安価です。また割当容量が少ないボリュームの場合は、gp2 と比較して高いベースライン性能の恩恵を受けることができます。


### Provisioned IOPS SSD (io1, io2, io2 Block Express) 選択時の考慮点

主にデータベースサーバーのようなミッションクリティカルで高い I/O 性能が求められるワークロードに向けに用意されているボリュームタイプです。ボリューム毎に 100～64,000 (io1/io2) または 256,000 (io2 Block Express) まで任意の IOPS 値を指定することができます。

1GB あたりのストレージ料金のほか、割り当てる IOPS 値によって追加料金が発生します。IOPS 値はむやみに高い値を設定すると高額な請求になりますのでご注意ください。

東京リージョン 2021年10月時点

* io1
  * 1 か月におけるプロビジョンド IOPS あたり 0.074USD
* io2, io2 Block Express
  * 1 か月におけるプロビジョンド IOPS (最大 32,000 IOPS まで) あたり 0.074USD
  * 1 か月におけるプロビジョンド IOPS (最大 32,001～64,000 IOPS) あたり 0.052USD
  * 1 か月におけるプロビジョンド IOPS (64,000 IOPS 超) あたり 0.036USD

#### io2 ボリュームの概要

io2 は最新世代の Provisioned IOPS SSD ボリュームです。GB あたりの料金は io1 ボリュームと同じですが、以下の3点が異なります。

* プロビジョンド IOPS 料金
  * 32,001～64,000 IOPS の割当料金は io1 より io2 のほうが割安に設定されている

* データの耐久性が約100倍
  * io1 の 年間故障率 0.1%～0.2%
  * io2 の 年間故障率 0.001%
* 容量あたりに割当可能な IOPS 値が10倍
  * io1 の 1GiB あたりの最大割当 IOPS: 50
  * io2 の 1GiB あたりの最大割当 IOPOS:500


#### io2 Block Express の概要

io2 Block Express は io2 ボリュームより低レイテンシー、高い IOPS、スループット、大容量を得ることができるボリュームタイプです。io2 ボリュームはすべての EC2 インスタンスタイプで使用できますが、**io2 Block Express は R5b インスタンスでのみ利用できます。** R5b インスタンスに接続された io2 ボリュームが自動的に io2 Block Express ボリュームとして認識、実行されます。

## EC2 インスタンスタイプによる上限
EC2 のインスタンスタイプごとに Amazon EBS 専用の帯域幅が定められており、これにより IOPS、スループットの上限が決まります。つまり gp3 や io2 ボリュームで高い性能を確保していたとしても、インスタンスタイプごとの上限がボトルネックとなり、意図した性能を確保できないケースがあります。

また Nitro ハイパーバイザーかつ、2xlarge までのインスタンスタイプは EBS 専用帯域幅がバースト特性を持ちます。例えば m5.large というインスタンスタイプの場合は以下のような制限となります。

* 最大 IOPS: 18,750
* ベースライン IOPS: 3600
* 最大スループット: 593.75 MB/s
* ベースラインスループット: 81.25 MB/s 

最大 IOPS/ベースライン は 「24 時間につき少なくとも 30 分間維持することができる」性能です。30分以上パフォーマンスを維持する必要があるワークロードではベースラインの IOPS/スループットに基づいてインスタンスタイプを選択する必要があります。インスタンスタイプごとの上限値については以下のドキュメントを参照してください。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-optimized.html

## CloudWatch によるパフォーマンスモニタリング
各ボリュームのパフォーマンスは CloudWatch ボリュームメトリクスを使用してモニタリングできます。観測の結果、ストレージ性能がボトルネックになっていることがわかれば、IOPS の追加などの対応方針を検討できます。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using_cloudwatch_ebs.html#ebs-volume-metrics

### IOPS の確認方法

VolumeReadOps と VolumeWriteOps の合計値から計算します。EBS は 1 分間ごとに CloudWatch へメトリクスを送るため、データの期間 1 分に変更し、その値を 60(秒) で割ることで IOPS を算出できます。

CloudWatch は数式を扱うことができる機能があるため、算出した IOPS の値をグラフにプロットできます。以下の例の場合、IOPS が 450 前後を記録していることがわかります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125105/abc2b918-9162-fab4-ca9a-ce8351005e64.png)


### スループットの確認方法

VolumeReadBytes と VolumeWriteBytes の合計値から計算します。データの期間を 1 分とし、60 で割るところは IOPS と同じですが、スループットは転送されたバイト総量から求める必要があるため、統計を合計に変更する必要があります。

CloudWatch の数式でプロットすると以下のようになります。この例の場合、15 MB/s 前後のスループットを記録していることがわかります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125105/067afbdd-e5fe-9ca4-5603-db6e355d8871.png)


### Compute Optimizer

CloudWatch 以外の確認方法としては AWS Compute Optimizer を使用できます。Compute Optimzer は EC2 や Auto Scaling Group のメトリクスと設定データを機械学習で分析して、推奨されるインスタンスタイプをレコメンドするサービスです。EBS ボリューム性能のレコメンデーションもサポートしています。I/O やスループットの過不足や、ボリュームタイプを変更した際のコスト、パフォーマンスへの影響を等を確認できます。

https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-ebs-recommendations.html


## ストライピング (RAID 0) による性能向上
### ストライピング とは

ストライピング (RAID 0) とは複数のボリュームをまとめて1つのボリュームのように管理する RAID の技術です。複数ボリュームに並行してデータを記録することで読み書きを高速化します。EBS でも複数のボリュームをまとめてストライピングすることで、より高いパフォーマンスのファイルシステムを実現できます。

ストライピングを使用した場合、IOPS と スループットの性能は単純に加算されていきます。例えば容量 100GB で 4000 の IOPS を割り当てた 2 つの gp3 ボリュームでストライピングを組んだ場合、8000 の IOPS を備えた 200 GB のボリュームとして扱うことができます。

AWS の機能として提供されているものではないため、各 OS レベルで ソフトウェア RAID を構成する必要があります。詳細な手順は AWS のドキュメントを参考にしてください。

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/raid-config.html

https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/raid-config.html

### ストライピング利用時の注意点

#### 既存のボリュームは変更できない
新規のボリュームを使用してフォーマットする必要があります。運用環境の場合はデータを移行するなどの考慮が必要です。

#### RAID 5/6 は使用しない
Amazon EBS のデータは AZ 内の複数のサーバーに複製されるため、データの耐久性を目的に RAID 5 または 6 を採用する必要はありません。パフォーマンスへの影響があるため、むしろ非推奨とされています。

#### バックアップ取得のタイミング
ストライピングは複数ボリュームに並行してデータを記録するため、データ整合性の観点からバックアップは同時に取得する必要があります。具体的には Data Lifecycle Manager でマルチボリュームスナップショットを取得するか、AWS Backup を使用してください。

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html#dlm-considerations

https://aws.amazon.com/jp/about-aws/whats-new/2021/06/aws-backup-supports-crash-consistent-backup-amazon-ebs-volumes-attached-to-amazon-ec2-instance/


## インスタンスストアの活用

インスタンスストアは、EC2 インスタンスが稼働するホストに直接アタッチされた揮発性のストレージです。インスタンスの停止や終了でインスタンスストア上のデータは失われますが、NW 腰EBS よりも高い IOPS/スループットを発揮できます。バッチ処理などで一時データ書き込み場所が必要なケースではインスタンスストアを利用することで追加コストなしで処理時間が改善される可能性があります。

インスタンスストアは特定の M5ad, R6gd のように追加機能として **d** がつくインスタンスタイプまたは、ストレージ最適化インスタンス の I3 など特定のインスタンスタイプでのみ利用できます。

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html