cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。
先だってお伝えしたAmazon EBSのディスクオプションの追加ですが、追加された「General Purpose(SSD)：通称 gp2」の仕様について、これに採用されている「トークンバケット」というモデルについて理解するためにちょっと調べてみました。
携帯電話の7GB規制に似た仕様ですが、色々なルールがあるようです。
ディスクサイズごとにベースラインが違う
バースト時のIOPSは「3000」ですが、バーストするトークン（”I/O credit”）を使い果たした後にIOPSが「ベースラインパフォーマンス（確保しているディスクサイズ(GB) x 3(IOPS)）」になります。
バースト時間にも差がある
基本的なルールとして、ディスク確保時に540万I/Oクレジットのトークンが確保されており、3000IOPSでバーストさせ続けると、5,400,000(I/Oクレジット)/3,000(IOPS)/3/ディスクサイズという計算式でバーストクレジットを消費して行き、使い切ると「3 x ディスクサイズ分のIOPS」にフォールバックするという仕様になっています。
回復時間にも差がある
トークンを全て消費してしまった後の回復は「3 x ディスクサイズ(GB)」毎秒ごとに回復します。
ディスクサイズによっては回復までにだいぶ時間がかかってしまいますね。
(疑問1)I/Oをかけ続けてる間も、回復時間にカウントしてもらえるかどうか
結局ここがミソになってくると思います。仮説は2つあります。
仮説1：I/Oが発生している秒についてはトークンがもらえない
I/Oをかけ続けてる間は回復しないというパターン
仮説2：ベースパフォーマンスになっている秒数分、純粋にカウントされる
制限が発動した直後から上記「回復時間にも差がある」のグラフのとおり回復していくパターン
→2014.6.29 本件については以下のP.18を見れば分かる通り「IOPSがベースパフォーマンスを下回っている時間に貯金が行われる」が正解のようです。要は基本的には「仮説2」のとおり
(疑問2)回復したトークンは、どのタイミングで反映されるか
ユーザーとしては「3000IOPS分のトークン」が溜まった都度トークンバケットに反映されれば嬉しいですが、これにもいくつか仮説があるかなと思います。
仮説1：3000IOPS分のトークンが溜まるごとに反映される
これだと少し我慢すればまたしばらく使えるようになります。（動作としては回復しては使い、回復しては使い、とバタつくイメージ）
仮説2：定期的に溜まったトークンが反映される
30分とか1時間ごとに、溜まったトークンがあれば反映される（定期的にIOPSが3000に回復する）
仮説3：540万I/Oクレジット分が溜まってから反映される
これだとツラいけど、一気に満タンになる感じ。
→2014.6.29 本件については福島さんが観察日記を書いてくれてます。観察からの推察として、数百ms内においてIOPSがベースパフォーマンスに到達していなければトークンがバケットに付与されていく間隔ではないか、と。要は「仮説1」が正解ではないが最も近い
上記、疑問1、2については実際にベンチマークを取得してみて観察日記を書いてみようと思います。
元記事は、こちら
