AWS から新しい T2インスタンス が提供され、網元AMIも対応したので移行がてら、t1.micro と t2.midro の性能などを比較してみました。
なお、t2.micro インスタンスも AWS 無料枠の対象となっています。
目次
コストの比較
| モデル | 利用料金（1時間あたり） |
|---|---|
| 網元 t1.micro | $0.026 |
| 網元 t2.micro | $0.025 |
利用料金は東京リージョン（Asia Pacific (Tokyo)）でオンデマンドインスタンスの場合です。
t2.micro には EC2 利用料の他に Software 利用料 を含んでいますが、その上でも若干安くなっています。
なお、実際の請求にはこの他に EBS 利用料や転送量（リクエスト数）による利用料金などが加算されます。
月途中で切り替えたので、1ヶ月あたりの比較は t2.micro で1ヶ月運用して見ないと詳細は出ませんが、計算上は若干安くなってます。
気になる方は AWS の簡易見積ツールで計算することは出来ますが、実は金額以上に性能が良くなっています。
CPU、メモリ、ディスクの比較
| モデル | vCPU | メモリ（GiB） | ディスク |
|---|---|---|---|
| 網元 t1.micro | 1 | 0.613 | EBS Magnetic volumes |
| 網元 t2.micro | 1 | 1 | EBS General Purpose (SSD) volumes |
メモリが増えています。
ディスクについては t2.micro の場合デフォルトで SSD となります。
表側はNginxのリバースプロキシを使っていますので、あまり性能差を感じられないかもしれません。
しかし、キャッシュしていないダッシュボードを利用した時や CPU がバーストしたときに性能差が出ます。
バーストとCPUクレジット
t1.micro は AWS EC2 のいわゆる「お試し」なので、アクセス数や画像が多く転送量が多かったり、WordPress のプラグインの処理がたくさんあったりするとすぐ バースト します。
バーストしてもある程度は処理を継続してくれますが、その後は一定期間インスタンスの性能が低くなり結果「重い」「アクセスしづらい」となります。
T2ファミリーでもバーストはありますが、継続可能な時間が決まっていて、この時間 CPU クレジットで管理するようになりました。
| モデル | ベースライン性能 | 1時間あたりのCPUクレジット | CPUクレジットの最大値 |
|---|---|---|---|
| t2.micro | 10% | 6 | 144 |
| t2.small | 20% | 12 | 288 |
| t2.medium | 40% | 24 | 576 |
- CPUUtilization（利用量）がベースライン性能を下回れば、CPU クレジットはたまります。
- CPUUtilization（使用量）がベースライン性能を上回れば、CPU クレジットを消費してバーストします。
- 1CPU クレジットで1分間バーストできます。
- CPU クレジット使い切ると、性能は徐々にベースラインレベルに戻ります。この減速プロセスは15分にわたって行われます。
- 使わない CPU クレジットは最大24時間蓄積。
言葉で説明すると分かりづらいのですがこれらは CloudWatch で確認することが出来ます。
図は t2.micro を起動してから執筆時までの10日間の CPUUtilization と CPUクレジット の推移です。
グリーンが CPUUtilization （左軸）、ブルーがCPUクレジット（右軸）になります。
この期間、記事更新はなかったのですが、ベースラインの10%を超える時がたまにありました。
正確なログは見ていないのですが同じ時期に NetworkOut が増えている事を見ると何かしらのアクセスがあって Nginxのリバースプロキシでキャッシュされていない or 再生成してるのかなぁと推測します（NetworkOut があっても CPU にそれほど負荷がかかったいないときもある）。
2014.7.30 追記
1日（24時間）の様子を見てみました。
9時台と13時以降の2回、CPU が10%超えました。そして同時刻に NetworkIn、NetworkOut ともに増えています。
当然、バースとしているのでCPUクレジットもその時間帯で消費しています（14時台が顕著）。
合わせて Googleアナリティクスによる1日のページビューの推移です。
やはり、9時台と13時〜15時台とでアクセスが増えています。
おまけ：スケールアップの勘所
AWS の CloudWatch を使うことで、
- CPU性能が設定した閾値を○分以上超えている
- CPUクレジットが閾値以下になる
といったアラームを作成することができます。
これを駆使すればバースト時に CPU クレジットを消費し尽くす前にインスタンスのスケールアップを行うことも可能です。
もちろんアクセスなど負荷が下がってきたらスケールダウンすることも可能ですが、頻繁にバーストし、CPU クレジットが残らない状況であればインスタンスを1個上の性能に切り替えた方がよいでしょう。
既に網元t2についてはブログ記事が書かれていますので、そちらも合わせてご覧ください
移行方法は網元公式サイトに記載してあります。