Amazon Elastic Block Store (EBS) General Purpose (SSD) volumes (gp2) の バースト特性

先週リリースされた EBS gp2 タイプですが、これまでのスタンダードタイプよりバースト性能が改善されています。 バーストの仕様についてはマニュアルや公式ブログにかなり詳しく記載されていますが、実際に動作確認を行ってみました。

まずはおさらい

この前の記事にも記載しましたがEBS gp2 のバースト仕様を簡単におさらいしておきます。

• バースト時の最大出力は 3000 IOPS
• バーストの制御方法は、Token Bucket 方式
• Token は容量1GBあたり毎秒3個づつ補給される。
• Token 一個は 1 I/Oに相当
• Token はEBS 1 個あたり最大 5,400,000 個 保存できる。
• EBS作成時は、5,400,000 個 Token が補充される。

今回のテスト環境

今回使用した環境は、m3.xlarge を使用しました。OS側の影響を少なくするために少し大きめのインスタンスを利用しています。I/O 処理する分と、dd が動作する分と、sar と ssh が動く分でCPU 4つぐらいあれば大丈夫かな? という程度の考え方です。

EBS は gp2 タイプ 100 GB 確保して、ブートディスクとは別にインスタンスにアタッチしました。

単純に IOPS がでればいいので、以下のコマンドラインで負荷をかけました。

while true ; do dd if=/dev/zero of=/dev/xvdb bs=4k ; done 

以前はIOPSでの課金があったので、ベンチマークを実施するときはお財布を気にしながらでしたが、EBS gp2 タイプでは従量課金がなくなったので安心して負荷をかけることができます。

プレウォームを実施

EBSは特性上、プレウォームを実施すると全体の特性が良くなります。

今回もプレウォームを実施しました。

実施結果

cloudwatch の VolumeWriteOps の結果です。
CloudWatch では、EBS の IO 数を 5 分間隔で取得できます。
5分間のIO数合計が出力されます。

左から一つ目の山がプレウォーム時のものです。プレウォーム時で5分間に 約 600,000 IO 出ています。60s × 5 = 300 s で割ると、 2,000 IOPS ぐらいです。プレウォームしないと、3,000 IOPS は出ません。 

二つ目の山が、プレウォーム後少しおいて再度負荷をかけた時のものです。大体 800,000 IO 出てますので、およそ 2,666 IOPS です。 3,000 ぴったりにはなっていないですが、大体いい値ではないでしょうか。

その後は大体 300 IOPS で安定しています。

バーストしている時間はプレウォームの期間も含めておよそ30分強でした。これも仕様と大きく離れていません。

復活するか

その後2時間ほど負荷を停止して token がたまるのを待って見ました。満タンになるのに5時間ほどかかってしまうので、2時間ほどでどれだけ復活するか見てみました。

最後の山が復活した時のものです。たしかに停止するとバーストは復活します。ただためている時間が短いので、10分程度しか持ちませんでした。

Token はいつ補充されるのか

Token がどのタイミングで補充されるかはマニュアルに明確な記載がありません。ここからは完全な推測です。

上のグラフは sar で取得した await の出力をEXCEL でグラフにしたものです。

OS 側で取得したのでかなりばらつきが大きくなっています。

間隔は1秒間隔で取得しています。最初の塊がプレウォーム時のもので大体 70-80 ms で推移しています。これは実ブロックの割り当て処理のオーバーヘッドでしょう。

その後暫く休憩して次にバースト時のものです。大体 50-80 ms ぐらいです。

最後に値が大きくなっているのはバースト終了後のもので、大体 480 ms ぐらいです。

バースト時とバースト終了時の差分が大体 400ms ぐらいです。

この差分は、Token が補充されるまでの時間だと予測できます。

おそらく1秒間に3個補充されるのではなく、300数十ms に1個補充されているのではないでしょうか。

それで1秒あたり3個補充されていることになるかと思います。

まとめ

EBS gp2 タイプのバースト特性はおおよそ以下の通りだと思います。

• token がある限り IO を払いだす。
• 3000 IOPS が、おおよその性能上限
• バースト時は結構ばらつきが大そう
• token は、300 数十 ms 毎に補充される 

おまけ

私は個人的には実はIOPSはあんまり気にしていません。

IOが不足しているかどうかの判断は VolumeQueueLength を参考にしています。

もし IO が要求に追い付いていないならば、キューの値が増加して減らなくなります。

もしキューにIOが無いならば、そもそもIO要求が来ていないことになります。

またキューがたまっている状態では IOPS は最高値になっているはずで、それ以上にIOが必要なっていることを示すだけで、余りサイジングの参考になりません。長期的にみて増加傾向ならばその傾向からある程度、サイジングの参考にはなると思います。