[レポート][TA-06]Amazon EBS パフォーマンスベンチマーク 2015 #AWSSummit
AWS Summit Tokyo 2015のTA-06: Tech Deep Dive by Amazon:「Amazon EBS パフォーマンスベンチマーク 2015」のレポートです。
スピーカーはAmazon Data Services Japanの小林 正人氏。
レポート
EBSおさらい
EBSの容量は1GB単位で。最大16TB。 同一のAZからのみ利用可能。異なるAZで使いたい場合はスナップショットをとって任意のAZに復元する。 EC2に複数のEBSをつけることはできるがひとつのEBSを複数のEC2につけることはできない。 ボリューム内のデータはAZ内で複数のHWにレプリケートされているため、冗長化を考える必要はない。 EBSはEC2のHypervisorと通信するためセキュリティグループをすべて閉じても通信できる。
ボリュームタイプは「汎用SSD(デフォルト)」「プロビジョンドIOPS(PIOPS)」「Magnetic」の3種類。スナップショットを経由することでボリュームタイプを変えることができる。
汎用SSD
1GBあたり3IOPSを確保。 1000GB以下では一時的に3000IOPSまでバーストすることができる。 最大10000IOPS。つまり3333GBまでは容量を増やしていくことでパフォーマンスを上げていくことができる。
バーストの継続時間は「I/Oクレジット」と呼ばれる数値によってきまる。バースト中はI/Oクレジットを消費し、I/Oクレジットが空になるとバーストは終了する。ベースのパフォーマンス(容量 x 3のIOPS)以下のI/O負荷の時にI/Oクレジットが貯金されていく。補充時間や補充上限は容量によって違う。大きい容量のほうが早く上限まで貯まり、消費時間も長い。
スループットは容量に応じて変わっていく。
170GB以下では128MB/sで一定。そこから容量によって増大していき214GB以上は160MB/sで一定となる。
Provisioned IOPS
1年間のうち99.9%の時間について、指定したIOPS値の±10%の範囲の性能を発揮する。 100IOPSから20000IOPSの間で指定可能。容量の30倍が上限となる。つまり667GB以上を確保していると20000IOPSまでの指定が可能となる。スループットは1280IOPS以上で最大320MB/s。IOPSの指定値に伴い1IOPSあたり256kb/sの割合でスループットが上がっていき、1280GBからは一定となる。
Magnetic
平均100IOPS。最大数百IOPSへバーストできる場合がある、というふわっとした仕様。I/Oリクエスト回数による課金があるので見積もり時には注意。
EBSのパフォーマンスを律速する要素
EBSのパフォーマンスは
- EC2インスタンス側のスループット
- EBS自体のI/O処理性能
- EBSボリュームのスループット上限
の3つの要素で律速されるので、どこの部分がボトルネックになっているのかを把握することが重要。
EC2インスタンス側のスループット
- EBS-Optimizedを有効にすることでEBSとの帯域を独立して確保する
- インスタンスタイプが大きいほど帯域が広くなる
EBS自体のI/O処理性能
EBS側のIOPSをCloudWatchのVolume Read/Write Opsで確認する。IOPSが使用しているEBSボリュームタイプの上限であればボリュームタイプの変更(Magnetic -> PIOPS等)や設定変更(SSD:容量を増やすとIOPS値が増える / PIOPS:IOPS値を増やす)することでで使用できるIOPS値が増える。
EBSボリューム側のスループット
EBSのスループットをCloudWatchのVolume Read/Write Bytesで確認する。スループットが使用しているEBSボリュームタイプの上限であればボリュームタイプの変更(Magnetic -> SSD等)や設定変更(PIOPS:平均ブロックサイズから計算)することでで使用できるスループットが増える。
Pre-Warming
- EBSの初回アクセスはIOPSが5〜50%低下する
- Pre-Warmingを実行することで回避できる。
- 特にベンチマークをする際には事前にやっておくこと
RAID構成
- 単体のEBSのIOPSやスループットで期待する数値が出ない場合はRAID0を組むと組んだ数だけのスループット、IOPSの倍化が期待できる。
- 元々EBSは冗長化されているのでRAIDにて冗長化構成を組む必要はない
ベンチマーク環境
- インスタンスタイプ:c3.8large
- OS:Amazon Linux 2015.03
- File System:xfs
- EBS:Pre-Warming済
- ベンチマークツール:fio 2.1.5
8kbブロック ランダム読み込み
8kbランダムはほぼ仕様通り。スループットにはまだ余力がある。
16kbブロック ランダム読み込み
シングルボリュームはほぼ仕様通り。4000と3000はスループットに余力があるが10000,20000では上限に近い。
4MBブロック ランダム読み込み
巨大なファイルを読み書きするユースケースとして4MBブロックをベンチマークしてみる。 汎用SSDは上限に達している。これ以上性能はでない。大きなブロックでアクセスをする場合は大きくても小さくても上限値に当たるので、やりとりするファイルが大きい場合はIOPSを上げすぎても意味が無いかもしれない。
8kbブロック ランダム読み書き
読みと書きでは性能に大きな違いはない。
4MBブロック ランダム読み書き
RAID構成を組むことによってシングルボリュームでは実現できないIOPS、スループットを実現できる。
インスタンスストアの利用
- インスタンスストアの実体は物理ホストのローカルディスクなのでスループットはEC2インスタンスのEBSスループットに依存しない
- STOPでデータが消える(REBOOTでは消えない)
- 計算用の一時的な利用で使うのがいい
インスタンスストア ランダム読み込み
インスタンスストア ランダム読み書き
EBS暗号化
- EBSはKMSを使用して暗号化ができる
- ハードウェアを使用して暗号化処理を行うためパフォーマンスにはほぼ影響しない
ケース別ベスト構成
小さいデータのアクセスが多い場合
- ブロックサイズが小さいためスループットがボトルネックになることは少ない
- よってIOPSを重視する。
- SSDであれば容量を必要以上に取ることでIOPS値を上げることも有用
- RAID0を組むことで倍化させる
大きいデータのアクセスが多い場合
- シーケンシャルアクセスを行う場合はIOPSよりもスループットを重視。
- EC2インスタンス側のスループットがボトルネックになることが多い
- インスタンスタイプを大きくすることでスループットを確保する
- 逆にIOPSを抑えることでコストを削減することが可能。
低コストにまとめる場合
- magnetic一択
- magneticは最大容量が1TBなので、足りない場合はRAIDを組む
極めて高いI/O性能が必要な場合
- インスタンスストアを利用して高速処理を行う
- 永続化が必要な場合はEBSに保存する
まとめ
いかがでしたでしょうか。ベンチマークというデータを元にEBSのパフォーマンスを分析、理解することはAWSを知る上で大変重要です。 なんかパフォーマンスが出ない、という時は是非この記事を見返して下さい。