t2 は昼間や深夜などアクセスが少ない時間帯にCPUクレジットがたまり、夕方などのアクセスが多い時間帯にCPUクレジットを消費してCPUを使うことができるので、Web/Appサーバとして良さそうだということで、テスト運用してみました。
ところが、CPUのベースラインについて勘違いしていたため混乱したので、ここに記録として残しておきます。
T2
Amazon EC2 には T2 タイプのインスタンスというものがあります。
T2 インスタンスはベースラインレベルの CPU パフォーマンスを提供しながら、そのベースラインレベルを超えてバーストする機能を備えています。
CPUクレジット
| タイプ | 1 時間あたりに受け取る CPU クレジット | ベースラインパフォーマンス（CPU 使用率） |
|---|---|---|
| t2.micro | 6 | 10% |
| t2.small | 12 | 20% |
| t2.medium | 24 | 40% |
ベースラインのCPUを使っていない場合、クレジットが溜まっていきます。CPUの使用量がベースラインを超えた場合は、クレジットを消費しますが、クレジットがある限りはCPUを使い続けることができます。
t2.medium
t2.micro、t2.small は分かりやすいのですが、t2.medium はコアが2つなので、注意が必要です。
Linuxの CPU Usage だと、1コア100% で、2コアだと 200% が上限になっています。この換算でいうところの 40% がベースラインです。
ところが CloudWatch ではCPUコアの合計を 100% として表示されます。
Linux: 40% / 200%
CloudWatch: 20% / 100%
というようになります。
なので、CloudWatch で数値を見ていて 20% になると、ベースラインの 40% に達している状態となっています。
まだ 20% だから余裕がある……と思っていると、CPUクレジットを消費していってしまう状態となりました。
感想
Web/Appは波があるとはいえ、そこそこのアクセスは継続してあるので、うちの場合では t2 よりは c3 のほうがコストパフォーマンスは良いということで、いまは c3 を使っています。
定期的な重いバッチ処理を動かすサーバなど、短時間だけCPUを必要とするようなサーバでは t2 がよさそうだと思いました。