T系インスタンスのバースト性能とCPU Creditについて

はじめに

AWS で EC2 インスタンスを利用する際、t2.micro のインスタンスはアカウント作成直後の無料利用枠に含まれていることもあり、T系インスタンス（t2、t3、t3a、t4g など）を利用する機会は多いはずです。これらのt系インスタンスの特徴として、CPU の利用効率が動的であり、「クレジット」という独自の仕組みによって管理されている点が挙げられます。このクレジットの消費量が少ない場合はあまり問題になりませんが、クレジットの消費が一定の基準を超えると、モードによってCPU の利用が制限されたり、余計なコストが発生したりすることがあります。

この記事では、T系インスタンスを利用するための基礎知識と、それらを効率的に使いこなすための方法について解説します。

T系インスタンスの特徴とモード

T系インスタンスには、CPU 利用率の「ベースライン」が設定されています。どのような状態であっても、このベースラインまでは性能を継続的に発揮できますが、これを超えて一時的にバースト性能を発揮することも可能です。インスタンスの紹介ページでは、バースト時の最大性能が記載されています。

たとえば、t3.medium インスタンスは 2 vCPU と 4 GB のメモリを持つインスタンスです。この 2 vCPU はバースト時の最大性能を示しており、ベースラインは 20% に設定されているため、0.4 vCPU 分の性能発揮が常時保証されます。

https://aws.amazon.com/jp/ec2/instance-types/t3/

このインスタンスを利用している中で、どの程度の CPU 利用率があったかに応じて、「クレジット」と呼ばれる値が増減します。このクレジットはインスタンスのバースト利用を制御するもので、CPU 利用率の平均がベースラインを下回っていればクレジットが蓄積され、ベースラインを上回るとクレジットを消費します。クレジットが 0 になったとき、インスタンスがどのように振る舞うかは設定されたモードによって異なります。 設定可能なモードは以下の２つです。

• スタンダードモード：CPU 利用率はベースラインの性能に制限されます。
• アンリミテッドモード：クレジットが 0 になっても引き続きバーストモードを利用できますが、条件を満たした時に追加課金が発生します。
  

T系インスタンスが登場した当初は、アンリミテッドモードは提供されておらず、インスタンス起動時にある程度のクレジットが自動的に付与されたり、停止・再開を行うとクレジットが失われたりする仕様が存在していました。しかし現在ではごく一部の条件を除いて、インスタンス起動時のクレジットは 0 から始まり、インスタンスを終了しない限り同じインスタンスのクレジットは保持される仕様となっています。

クレジットの蓄積・消費の計算方法

T系インスタンスには、CPUクレジットの増加（蓄積）と減少（消費）に関するルールがあります。これらのルールを同時に適用することで、特定の時間内にクレジットが増加するか減少するかが決まります。

増加ルール

各インスタンスタイプごとに、1時間あたりに増加するCPUクレジット数が決められています。例えば、t3.medium インスタンスの場合、1時間で24のクレジットが増加します。　この増加量は以下の式で計算できます。

1時間あたりの獲得クレジット数 = vCPU数 × ベースライン使用率 × 60分

t3.medium インスタンスは2つのvCPUを持ち、ベースライン使用率は20%（0.2）です。したがって、

2 vCPU × 0.2 × 60分 = 24クレジット

となります。

減少ルール

CPUクレジットは、CPUの使用状況に応じて消費されます。具体的には、1つのvCPUを100%で1分間使用すると、1クレジットが消費されます。

t3.medium インスタンスの場合、平均CPU使用率が20%であれば、1時間で24のクレジットを消費します。これは、2つのvCPUがそれぞれ20%の使用率で60分間動作するため、合計で2 × 20% × 60分 = 24クレジットを消費する計算になります。

クレジット上限・下限について

これらのルールに基づいてクレジットの増減が行われますが、蓄積可能なクレジットには上限があります。この上限は、インスタンスが24時間で獲得できる最大クレジット数に相当します。

例えば、t3.medium インスタンスの場合、

24クレジット/時間 × 24時間 = 576クレジット

が上限となります。

この上限に達すると、それ以上クレジットは蓄積されません。

一方、クレジットの下限は０です。 ただし、アンリミテッドモードであれば CPUSurplusCreditBalance という項目でクレジットの前借を行った状態となります。 この項目は24時間で取得できるクレジット（t3.medium の場合は576クレジット）が上限となります。 この上限を超えるような CPU 利用が行われた場合、CPU の追加課金が発生するようになっています。 言い換えると、クレジットが0に到達しても、前借の上限に到達しなければ追加課金は発生しないことになります。

より正確に追加課金が発生する条件は「クレジットの前借分が24時間で獲得できる最大クレジット数を超えている場合」もしくは「インスタンスを停止、もしくは終了」した時、あるいはアンリミテッドモードを中断した時です。  詳細は AWS のドキュメントをご確認ください。

T系インスタンスを利用するケースと注意点

恒常的にインスタンスの性能を発揮できるインスタンスタイプ（M系、C系、R系など）も存在していますが、これらのタイプの新しいものでは medium 以下のサイズが提供されていません。 そのため、小規模なサーバーを利用する場合は、T系インスタンスを選択することが一般的です。​

T系インスタンスを利用する際は、基本的に アンリミテッドモード での運用を推奨します。​スタンダードモードで運用中にクレジットを使い切ると、通常、負荷の高い処理が実行中にクレジットが枯渇し、急激な性能低下が発生します。​その結果、実行中の処理が完了せず、タスクが滞留し、システムがハングしたような挙動を示すことがあります。​アンリミテッドモードを利用することで、このような問題を回避できます。​

ただし、CPU利用率が常にベースラインを上回る場合、アンリミテッドモードでT系インスタンスを使用すると、他のインスタンスタイプよりも費用が高くなる可能性があります。​具体例として、同じ2 vCPU / 8 GBのインスタンスである t3.large と m5.large を比較してみます。​ 

AWSの公式ドキュメントでは、バージニアリージョンのLinuxインスタンスにおいて、t3.largeのCPU利用率が42.5%以上の場合、m5.largeを利用する方がコスト効率が良いと示されています。​ただし、東京リージョンでは単価が異なるため、同様の計算を行う際には、東京リージョンの最新の料金を参照して比較検討する必要があります。

さらに、T系インスタンスは最大ネットワーク帯域（パフォーマンス）が他のインスタンスと比べて低いという仕様があります。​インスタンスはデータの受け入れや、EBSなどのディスクへの書き込み時にもネットワーク帯域の制約を受けるため、大量のデータの送受信や読み書きを行う場合、性能面でT系以外のインスタンスを選択する方が適切な場合があります。

まとめ

T系インスタンスの利用が適切と考えられるケースは以下の通りです：​

• 小規模なサーバーを起動する場合：​特に、medium以下のサイズのサーバーが必要な場合、事実上の選択肢がT系インスタンスしかありません。 ​ただし、この時に追加課金が発生しないような使い方になっているかは注意する必要があります。
• 平均的なCPU利用率が低いアプリケーションを運用する場合：​例えば、平日日中のみアクセスが集中するウェブサーバーなど、状況によって利用率の差が激しいながら、全体的なCPU使用率が低〜中程度のケースでの利用に適しています。 ​
• 取り扱うデータ量が大量でない場合：​T系インスタンスは、ネットワーク帯域幅やディスクI/O性能が他のインスタンスタイプに比べて制限されているため、大量のデータ処理が必要な場合には注意が必要です。 ​

本記事では、T系インスタンスの特性と、利用時に重要となるCPUクレジットの仕組みについて説明しました。​これらの知識を活用し、T系インスタンスの選択が適切であるかを自信を持って判断できるようになれば幸いです。