AWS GP2ボリュームのI/Oクレジットが何かを説明する
はじめに
本記事では AWS EBSのGP2ボリュームのバースト性能を考える上で必要なI/Oクレジットとは何かを説明します。
AWSの公式のEBSのページを見てもGP2ボリュームがどういう仕組みでどれくらいの時間バーストのリードライトに耐えられるのかがわからない、といった方向けの記事となります。
トークンバケット方式とは
一旦、I/Oクレジットが何かを説明する前に、「トークンバケット方式」について説明します。実はI/Oクレジットの考え方そのものがトークンバケット方式なのですが、その方式を知らないことにはI/Oクレジットの説明も難しいためです。
ここでは簡単なスライドでトークンバケット方式を説明します。
基本的なトークンバケットの考え方は以上となります。このトークンバケットにおいては
- バケット内にトークンのある限り、連続してアクションを実行し続けることが可能です。
- アクションを実行し続けた結果、トークンは枯渇しますので、この状態ではアクションが実行できなくなります。
- しかし、トークンは一定のスピードで常に補充が行われています。
- その結果、トークンが枯渇した後は、一定のスピードで補充されたトークンにより、一定のスピードでアクションを実行することが出来る状態になります
という動作となります。次はこちらの動作をEBS GP2ボリュームのI/Oクレジットに当てはめていきます。
I/Oクレジットの動作
今度はI/Oクレジットの動作のスライドを用意致しました。
通常のトークンバケットの方式と異なり、②’の動作が追加されていますが、基本的な考え方としては上記のトークンバケットの方式と同様となります。
- ベースラインIOPSとして定義されている 3[IOPS/GiB]があり、これがクレジットをバケットに補充するスピードになります。
- そのため、3[IOPS/GiB]を超えるリード・ライトアクセスがない限り、バケットの中のクレジット量にはほとんど影響がありません。
- 3[IOPS/GiB]を超えるリード・ライトアクセスが発生した場合、超えたアクセスに対してはバケット内に蓄積されていたクレジットが消費されていきます。
- バケットのサイズは5,400,000 IOPSと決まっています。このクレジットを消費しきるまでは、3000[IOPS/S]のリード・ライトアクセスを許容します。
- 3000[IOPS/S]のリード・ライトアクセスにてクレジットを消費しきった後は、ベースラインIOPSの3[IOPS/GiB]のスピードでのリード・ライトが行われます。
GP2ボリュームのサイズにより、3000[IOPS]でアクセス可能な時間が異なるのはボリュームサイズによりベースラインIOPSが異なる、つまりクレジットの補充量が異なるためです。
抜粋:
ボリュームサイズ (GiB) | ベースラインパフォーマンス (IOPS) | 持続的な 3,000 IOPS でのバースト期間 (秒数) | IO がない場合に空のクレジットバランスを満たすまでの秒数 |
1 | 100 | 1,802 | 54,000 |
100 | 300 | 2,000 | 18,000 |
例えば100GBのボリュームであれば、そのベースラインIOPSは300[IOPS]となります。x秒後にバケット内のクレジットが0になる方程式を計算してみると
5,400,000 + 300*x = 3000*x
x = 2,000
ということで、3000[IOPS/S]のバースト的なリード・ライトアクセスは最大で2,000秒まで、ということが計算できますし、空のクレジットバランス、バケットを満たすまでにかかる時間は
5,400,000 / 300 = 18,000
で18,000秒だということがわかります。これでI/Oクレジットの考え方の謎が解けたのではないでしょうか?
最後に注意点となりますが、GP2ボリュームのサイズが1,000GBを超えた場合、ベースラインIOPSが3,000を超えますので、上記のバースト的なリード・ライトアクセスの話は無関係となります。つまり、ベースラインIOPS以上のリード・ライトアクセスは出来ないことにご注意下さい。
最後に
本記事ではトークンバケット方式の説明を元に、AWS EBS GP2ボリュームのI/Oクレジットの考え方を説明致しました。ではまた。
ディスカッション
コメント一覧
まだ、コメントがありません