EBS Magnetic vs SSDのベンチマーク

マネーフォワードエンジニアブログをご覧のみなさま、こんにちは。
今回は、アプリ周りの話ではなく、インフラ周りの話をさせて頂こうと思います。

AWSを触り始めて、ざっくり早3年。
AWSは、いい意味で機能追加が多くてついていくのが大変です。

そんな中で、今更ながらですが、2014/06/17に発表された SSDベースのEBSについて軽く調査＆ベンチマークを取ってみました。

SSDだから速いけど高いんでしょ？とか、俺は今までどおりのEBSで良いんだ！って方が割りと、多いかも知れません。

しかしながら、NWアーキテクチャがVPCへ、EC2が第3世代へと主流になった経緯からEBSもSSDが主流になるのでは無いでしょうか。
（プルダウンの一番上に出てくるし）

おさらい EBSは3種類ある

Magnetic (ハードディスク /従来のEBS)

性能：ベストエフォート。シーケンシャルアクセスはバーストし易く数千IOPS、ランダムアクセスは、おおよそ200 IOPSが目安。コスト：容量とIO数に掛かってくる。 $0.08 /GB/月、$0.08 /100万IOリクエスト。ManagementConsole/API/CLI上では、standard　と表示。容量あたりのコストは安いが、性能はぼちぼち。

PIOPS (SSDベース)

性能：指定したIOPSの±10%を99.9%で保証。コスト：容量とIO数に掛かってくる。 $0.142 /GB/月、$ 0.074 /IOPS/月ManagementConsole/API/CLI上では、io1　と表示。コストは高いが、安定したIOPSが出るので安心。

SSD (SSDベース)

性能：高性能バースト。1EBSあたり、3000 IOPSまでバーストする。
(ちょっと難しいルールあり。後述のSSDのルールを参照。)コスト： 容量のみに掛かってくる。 $0.12 /GB/月ManagementConsole/API/CLI上では、gp2　と表示。Magneticより少々コストは高いが、ランダムアクセスでもバーストする&一定のIOを保つ。

Magnetic vs SSD のベンチマーク

検証環境

Tokyoリージョン
m3.xlrage (4vCPU/15GB)
EBSサイズ 100GB

検証内容

EBSタイプ Magnetic と SSD　の2種類を比較して、IOPSのみをベンチマーク対象。
PIOPSは、指定したIOPS数が出る事が過去に実証済みですので、ベンチマーク外。
fioで、シーケンシャル、ランダム、ミックス(Read70%)のパターンを施行しました。

実行コマンド

fio -rw=read -bs=16k -size=1G -numjobs=4 -runtime=60 -direct=1 -invalidate=1 -ioengine=libaio -group_reporting -name=seq_read
fio -rw=write -bs=16k -size=1G -numjobs=4 -runtime=60 -direct=1 -invalidate=1 -ioengine=libaio -group_reporting -name=seq_write
fio -rw=randread -bs=16k -size=1G -numjobs=4 -runtime=60 -direct=1 -invalidate=1 -ioengine=libaio -group_reporting -name=randread
fio -rw=randwrite -bs=16k -size=1G -numjobs=4 -runtime=60 -direct=1 -invalidate=1 -ioengine=libaio -group_reporting -name=randwrite
fio -rw=randrw -rwmixread=70 -bs=16k -size=1G -numjobs=4 -runtime=60 -direct=1 -invalidate=1 -ioengine=libaio -group_reporting -name=randmix

結果

SSDは概ね、3000 IOPSを保っており、シーケンシャルRead以外はMagneticより、高性能であると見て取れます。ランダムアクセスも安定しています。（割りとMagneticも頑張っている・・・）

| EBS | Seq Read | Seq Write | Rand Read | Rand Write | Radn RW |
| Magnetic | 3694 | 1969 | 2849 | 1907 | 2198 |
| SSD | 3064 | 2894 | 3064 | 2681 | 3064 |

余談

Magneticはもう少し性能が低いはずなので、fioのsizeを5G、ミックスの割合をRead50%に変えてみました。(ミックスは変える必要が無かった気がする。。)

fio -rw=randrw -bs=16k -size=5G -numjobs=4 -runtime=60 -direct=1 -invalidate=1 -ioengine=libaio -group_reporting -name=randmix

| EBS | Rand RW |
| Magnetic | 416 |
| SSD | 3064 |

無事、Magneticが遅くなり、期待通りの結果になってくれました。

SSDのルールについて(重要)

と、これまでSSDの良さを紹介しましたが、以下のルールを理解した上で使う必要があります。

ベースパフォーマンスという概念があり、EBSサイズに依存する。1GBあたり3IOPS。
(例) 100GBの場合、300 IOPSがベースパフォーマンスとなる。1EBSあたり、540万IOリクエストのクレジットが付与される。クレジットが0になるまでは、最大3000 IOPSまでバースト可能。バーストは継続可能時間が決まっている。
(例) 100GBに3000IOPSを掛け続けた場合、約33分間はバースト可能。クレジットを使い切ると、ベースパフォーマンスとなる。
(例) 100GBのEBSが3000IOPSでバーストし続ける→ 33分後にクレジット0 →
300 IOPSになる。IO負荷がベースパフォーマンス以下になると、クレジットが貯金(回復)される。

SSDのルールの詳細、計算式は以下を参考にして下さい。
http://media.amazonwebservices.com/jp/summit2014/TA-02.pdf
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

所感

OSのブート領域や瞬間的にIO負荷が高くなる特性のサーバにSSDは向いており、頻繁にIO負荷が発生するDBなどはPIOPSを使う感じが良いかと思います。
検証時のfioコマンドのオプションを「-runtime=600」くらいにすれば、クレジット0状態を作ることが出来たかと思いますが、それはまた機会あれば。。
各EBSの残クレジットを見る方法があると嬉しいです。