容量とIO数に掛かってくる。/100万IOリクエスト。容量あたりのコストは安いが、性能はぼちぼち。指定したIOPSの±10%を99.9%で保証。容量とIO数に掛かってくる。コストは高いが、安定したIOPSが出るので安心。IOPSまでバーストする。(ちょっと難しいルールあり。後述のSSDのルールを参照。容量のみに掛かってくる。Magneticより少々コストは高いが、ランダムアクセスでもバーストする&一定のIOを保つ。2種類を比較して、IOPSのみをベンチマーク対象。PIOPSは、指定したIOPS数が出る事が過去に実証済みですので、ベンチマーク外。fioで、シーケンシャル、ランダム、ミックス(Read70%)のパターンを施行しました。IOPSを保っており、シーケンシャルRead以外はMagneticより、高性能であると見て取れます。ランダムアクセスも安定しています。3064余談Magneticはもう少し性能が低いはずなので、fioのsizeを5G、ミックスの割合をRead50%に変えてみました。(ミックスは変える必要が無かった気がする。3064無事、Magneticが遅くなり、期待通りの結果になってくれました。SSDのルールについて(重要)と、これまでSSDの良さを紹介しましたが、以下のルールを理解した上で使う必要があります。ベースパフォーマンスという概念があり、EBSサイズに依存する。1GBあたり3IOPS。IOPSがベースパフォーマンスとなる。1EBSあたり、540万IOリクエストのクレジットが付与される。IOPSまでバースト可能。バーストは継続可能時間が決まっている。100GBに3000IOPSを掛け続けた場合、約33分間はバースト可能。クレジットを使い切ると、ベースパフォーマンスとなる。IO負荷がベースパフォーマンス以下になると、クレジットが貯金(回復)される。SSDのルールの詳細、計算式は以下を参考にして下さい。http://media.amazonwebservices.com/jp/summit2014/TA-02.pdfhttp://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSVolumeTypes.html所感OSのブート領域や瞬間的にIO負荷が高くなる特性のサーバにSSDは向いており、頻繁にIO負荷が発生するDBなどはPIOPSを使う感じが良いかと思います。検証時のfioコマンドのオプションを「-runtime=600」くらいにすれば、クレジット0状態を作ることが出来たかと思いますが、それはまた機会あれば。各EBSの残クレジットを見る方法があると嬉しいです。