Money Forward Developers Blog

株式会社マネーフォワード公式開発者向けブログです。技術や開発手法、イベント登壇などを発信します。サービスに関するご質問は、各サービス窓口までご連絡ください。

20230215130734

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