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の残クレジットを見る方法があると嬉しいです。

最後に

マネーフォワードでは、新しい事にチャレンジできるエンジニアを募集しています!
みなさまのご応募お待ちしております!

マネーフォワード採用サイト
https://recruit.moneyforward.com/

Wantedly
https://www.wantedly.com/companies/moneyforward

Pocket