EC2 (t系インスタンス)のCPUクレジットについて試してみた

はじめに

EC2のT系インスタンスを利用する際、「CPUクレジット」というワードを聞いたことないでしょうか？

T系インスタンでは、ベースラインというCPU使用率が、インスタンスタイプ毎に定義されています。

例えばt3.largeであれば、vCPUあたり30％です。

このベースライン超えてCPUを利用したい場合に利用するのが、「CPUクレジット」です。

CPUクレジットを簡単に説明すると、T系インスタンがCPUリソースを効率的に使用できるようにする仕組みです。CPU使用率がベースラインを下回る場合は、クレジットを蓄積し、ベースラインを上回る場合は、蓄積したクレジットを消費して、ベースラインを超えるCPU使用率で利用できます。

そして、クレジットが0になると、ベースラインまでの制限が掛かるか、追加料金を払って性能を維持することもできます。

というのが、ざっくりした説明ですが、よく分からないですよね。

僕自身も、CPUクレジットについて調べた時に、こういう説明を色々読んだんですが、いまいち理解できなかったので、自分で試してみることにしました。

CPUクレジットの仕様(t3.large)

基本的なCPUクレジットに対する考え方は、T系インスタンスで共通です。(後述のように、t2とt3で若干の違いがあります。)

今回は、t3.largeを例にして、調べてみたところ、以下のことがわかりました。

■t3.largeインスタンスの仕様

• CPU数：2vCPU
• ベースラインパフォーマンス：30％(1コアあたり60%)

■CPUクレジットの獲得量の計算

• 1時間あたりの獲得クレジット数：ベースライン使用率(%)×vCPU 数(個)×60(分)
• t3.large : 30% * 2(vCPU) * 60 = 36(クレジット)/時　⇒0.6(クレジット)/分
• CPUクレジットの最大値は24時間で獲得できる最大値
• t3.large : 36(クレジット) * 24 = 864(クレジット)

■CPUクレジットの消費量の計算 

• vCPU時間の単位
• 1CPUクレジット = 1vCPU * 100% x 1分
• 2CPUクレジット = 2vCPU * 100% x 1分

■CPUクレジットのトータル消費量の計算

• 獲得クレジット – 消費クレジット

■インスタンス起動時のCPUクレジット仕様

• t2系はインタンス停止時にクレジットが消滅する
• t2系はインスタンス起動時に起動クレジットが30付与される
• t3系はインスタンス停止時から7日間クレジットが維持される
• t3系はインスタンス起動時の起動クレジットが付与されない

■参考文献

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html

とまぁ、なんかわかるような、、、わからないような、、、

ということで、実際に検証してみました。

検証内容

以下の条件を設定して、実際に試してみることにしました。

• t3.largeインスタンスの2CPUに対してstressコマンドなどで100%の負荷をかけ続ける
• CPUクレジットが枯渇するまでの時間を予測する
• 負荷テスト開始時のCPUクレジットは約190とする

予想結果

先程の仕様に照らし合わせて、以下の結果を予想します。

• 1分あたり2クレジットを消費する
• 1分あたり0.6クレジットを獲得する
• 1分あたり1.4クレジット(2 - 0.6=1.4)が消費される
• 190クレジットを消費するには約136分かかる⇒190 / 1.4 ≒ 136(分)
  ※実際には常時CPU使用率が100%ではないため、理論値よりも時間がかかると推測する
• CPUクレジット枯渇後はインスタンスのトータルCPU使用率が30%に落ちる
  ※クレジットが0になると、パフォーマンスに制限がかかるはず

検証結果

検証結果ですが、概ね想定通りでしたが、一部想定外もありました。

以下検証結果です。

• タイムライン
  •  開始時刻：13:04
  • クレジット残高(0)予想時刻：15:20
  • クレジット残高(0)時刻　　：15:25
  • クレジット枯渇までの時間：141分 (1.35クレジット消費/分)
• 概ね予測通りの時間(誤差5分)でCPUクレジットが枯渇した
• CPUクレジット枯渇後に、CPU使用率が約30％になることを予想したが、予想と異なり約100%の使用率が継続した
  • T系インスタンスにはCPUクレジットモードとしてStandardとUnlimitedがあり、デフォルトではUnlimitedが設定されていることが判明
  • UnlimitedモードではCPUクレジット枯渇後、追加料金を加算することで無制限にクレジットを消費できる (t3.largeの場合、1CPUクレジットあたり$0.05)
• インスタンスのCPUクレジット設定をUnlimitedからStandardに変更すると、クレジット残高0の状態では予想通り約30%の使用率となった

となりました。

CPUクレジットが0になるところまでは、概ね予想結果通りの動きをしましたが、クレジットが枯渇するとベースラインに制限されるはずが、なぜかクレジット0でも、CPU使用率100%を維持できるというものでした。

たしかに、これまでT系インスタンスを利用した際に、CPUクレジットが0になるのは何度かみたことがあったのですが、特に制限が掛かっている印象がなく、それが余計にCPUクレジットの謎になっていたのも事実です。

CPUクレジットに2つのモード(StandardとUnlimited)があり、デフォルトがUnlimitedだというのを、この検証を通じて初めて知りました。

というか、これを知らず、気が付いたらとんでもない追加料金を支払っているなんて方も、多いのではないでしょうか？

参考までに、検証時のCPU使用率はこんな感じでした。

また、CloudWatch上の、CPUクレジット残高の推移はこんな感じでした。

クレジットモードの変更は、AWSコンソールから可能です。
E2インスタンスを選択して、アクション⇒インスタンスの設定⇒クレジット仕様の変更から変更可能です。

まとめ

以上のように、CPUクレジットについて、実際に試してながら仕様を確認してみました。

• T系インスタンスにはインスタンスタイプ毎に、ベースラインと呼ばれるCPU使用率が設定されている(t3.largeであればvCPUあたり30％)
• ベースラインを超えるパフォーマンスを使用するには、CPUクレジットを消費する必要がある
• CPUクレジットは、ベースラインを下回る低負荷時に蓄積されいく
• ベースラインを上回るCPUを使用するとCPUクレジットが消費される
• CPUクレジットが0になると、ベースラインをMAXにCPU使用率を制限される(Standardモード)か、追加料金を支払うことで引き続きベースラインを超えて利用できる(Unlimitedモード)
  ※デフォルトはUnlimitedモードなので、注意！

T系インスタンスのCPUクレジット仕様は、EC2の他にもRDSや、その他サービスでもありますが、今度は別のサービスでも試してみようと思います。