- エンジニアリングマネージャー
- Webエンジニア
- カスタマーサポート
- 他60件の職種
- 開発
-
ビジネス
- エンジニアリングマネージャー
- プロダクトマネージャー
- プロダクトマネージャー
- サステナビリティ
- 広報
- カルチャー推進・浸透
- 知財戦略立案・推進・発明発掘
- リスクマネジメント統括本部
- AML/CFTコンプライアンス
- AML・金融犯罪対策Ops
- 金融コンプライアンス
- ビジネス採用担当
- 経営企画(予実・IR)
- HRBP
- 法務
- 債権管理/MFK
- 法人営業
- インサイドセールス
- フィールドセールス
- インサイドセールス SDR
- インサイドセールス企画
- オンラインセールス
- SaaS営業、MFBC
- インサイドセールス MFBC
- セールス MFBC
- マーケティングリサーチャー
- マーケター
- データマーケター
- BtoBマーケティングリーダー
- CRMスペシャリスト
- イベントマーケター
- その他
マネーフォワードエンジニアブログをご覧のみなさま、こんにちは。
今回は、アプリ周りの話ではなく、インフラ周りの話をさせて頂こうと思います。
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/