T3インスタンスのCPUクレジットを理解する：バースト性能と突然の速度低下の原因

本番環境でT3インスタンスを運用していると、ある時点から突然レスポンスタイムが悪化し、CPUが張り付いたように動かなくなる現象に遭遇することがある。アプリケーションのバグを疑い、メモリリークを調査し、それでも原因が見つからない。実はその原因がCPUクレジットの枯渇だったというケースは、T3インスタンスを使い始めたエンジニアが最初にはまる落とし穴の一つだ。

TL;DR：T3インスタンスのCPUクレジット早見表

項目内容
CPUクレジットとはベースライン未満のCPU使用時に蓄積し、バースト時に消費するトークン
クレジット枯渇時の挙動CPUパフォーマンスがベースラインに制限される（Standardモード）
Unlimitedモードクレジット枯渇後も性能を維持するが、余剰クレジット分が課金される
診断の起点CloudWatchのCPUCreditBalanceメトリクスを確認する
主なリスクUnlimitedモードでの予期しない追加料金

T3インスタンスのCPUクレジット機構：仕組みから理解する

T3インスタンスはバースト可能なパフォーマンスインスタンスファミリーに属する。「バースト可能」とは、常時高いCPU性能を保証するのではなく、ベースラインCPU使用率を定義し、それを下回る期間にクレジットを蓄積し、高負荷時にそのクレジットを消費して一時的に高い性能を発揮できる仕組みを指す。

各T3インスタンスタイプにはベースラインCPU使用率が定められており、例えばt3.microであれば10%、t3.smallであれば20%といった値が設定されている（正確な値はAWS公式ドキュメントを参照）。インスタンスがベースラインを下回るCPU使用率で稼働している間、1時間あたり一定数のCPUクレジットが自動的に付与される。逆にベースラインを超えてCPUを使用すると、クレジットが消費される。

CPUクレジットは銀行口座の残高に似ている。低負荷期間に少しずつ貯金し、高負荷時に引き出す。残高がゼロになれば、それ以上の引き出しはできない。

クレジットには上限（最大蓄積量）があり、インスタンスタイプによって異なる。上限に達したクレジットはそれ以上蓄積されない。また、T3インスタンスは起動時にある程度のクレジットを持った状態でスタートする。

graph TD A["インスタンス起動
初期クレジット付与"] --> B{"CPU使用率 vs ベースライン"} B -->|"使用率 < ベースライン"| C["CPUクレジット蓄積
残高が増加"] B -->|"使用率 > ベースライン"| D["CPUクレジット消費
残高が減少"] C --> E{"残高が上限に達した?"} E -->|"Yes"| F["蓄積停止
上限でキャップ"] E -->|"No"| B D --> G{"残高 > 0 ?"} G -->|"Yes（Standardモード）"| H["バースト継続"] G -->|"No（Standardモード）"| I["CPUをベースラインに制限
速度低下発生"] G -->|"No（Unlimitedモード）"| J["バースト継続
余剰クレジット課金発生"] H --> B F --> B
  1. クレジット蓄積フェーズ：CPU使用率がベースラインを下回っている間、クレジットが継続的に付与される。
  2. バーストフェーズ：CPU使用率がベースラインを超えると、超過分に対してクレジットが消費される。
  3. クレジット枯渇（Standardモード）：残高がゼロになると、CPUパフォーマンスはベースラインに制限される。これが突然の速度低下の正体だ。
  4. Unlimitedモード：クレジットが枯渇しても性能を維持するが、ベースラインを超えた使用分は余剰クレジットとして後払いで課金される。

StandardモードとUnlimitedモードの違い

T3インスタンスはデフォルトでUnlimitedモードで起動する。これはT2インスタンスのデフォルト（Standardモード）とは異なる点に注意が必要だ。

モードクレジット枯渇後の挙動追加料金T3デフォルト
StandardCPUがベースラインに制限されるなしいいえ
UnlimitedCPUパフォーマンスを維持する余剰クレジット分が課金されるはい

Unlimitedモードは便利に見えるが、継続的な高負荷ワークロードをT3インスタンスで動かすと、余剰クレジット課金が積み重なり、より上位のインスタンスタイプを使うよりもコストが高くなることがある。これは実際の運用でよく見落とされるコスト最適化の盲点だ。

CPUクレジット枯渇の診断：3ステップ

「なぜサーバーが遅くなったのか」を調査する際、最初に確認すべきはCPUCreditBalanceメトリクスだ。アプリケーションログやメモリ使用率を先に見てしまうと、原因特定に時間がかかる。

ステップ1：CPUCreditBalanceでクレジット残高の推移を確認する

速度低下が発生した時刻と、CPUCreditBalanceがゼロに近づいた時刻が一致するかどうかを確認する。これが一致すれば、クレジット枯渇が原因である可能性が高い。

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

ステップ2：CPUCreditUsageでクレジット消費速度を確認する

残高の低下速度だけでなく、どの時間帯にクレジットが急速に消費されたかを把握することで、負荷のパターンが見えてくる。バッチ処理の実行時刻やデプロイのタイミングと照合すると原因が絞り込みやすい。

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditUsage \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 300 \
  --statistics Sum \
  --region us-east-1

ステップ3：CPUSurplusCreditsChargedメトリクスで余剰課金を確認する

Unlimitedモードで運用している場合、クレジット枯渇後の高負荷継続によって余剰クレジットが発生し課金される。このメトリクスが継続的に増加しているなら、インスタンスタイプの見直しを検討すべきシグナルだ。

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUSurplusCreditsCharged \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 3600 \
  --statistics Sum \
  --region us-east-1
graph LR A["速度低下を検知"] --> B["Step1: CPUCreditBalance確認
残高がゼロに近いか？"] B -->|"Yes"| C["Step2: CPUCreditUsage確認
急消費の時間帯を特定"] B -->|"No"| Z["別の原因を調査
（メモリ・DB・ネットワーク）"] C --> D["Step3: CPUSurplusCreditsCharged確認
Unlimitedモードの余剰課金を検出"] D --> E{"CPUSurplusCreditsCharged
が継続増加?"} E -->|"Yes"| F["インスタンスタイプ
アップグレードを検討"] E -->|"No"| G["Standardモード切替
またはアラーム設定"]
  1. CPUCreditBalance確認：速度低下発生時刻とクレジット残高ゼロのタイミングが一致するか検証する。
  2. CPUCreditUsage確認：クレジットが急速に消費された時間帯を特定し、負荷イベントと照合する。
  3. CPUSurplusCreditsCharged確認：Unlimitedモードでの余剰課金発生を検出し、コスト影響を評価する。

実際の障害パターン：誤診から正しい原因特定へ

あるケースでは、夜間バッチ処理の完了後から翌朝にかけてAPIレスポンスタイムが急激に悪化するという問題が発生した。アプリケーションチームはまずデータベースのスロークエリを疑い、次にメモリリークを調査した。どちらも問題なし。

実際の原因は、夜間バッチがCPUクレジットをほぼ全て消費していたことだった。翌朝の業務開始時にはクレジット残高がほぼゼロの状態で、通常のAPIリクエストを処理しようとしてもCPUがベースラインに制限されたまま動けない状態になっていた。

CloudWatchでCPUCreditBalanceの24時間グラフを表示した瞬間、バッチ開始時刻から残高が急落し、バッチ終了時点でほぼゼロになっているパターンが一目で確認できた。アプリケーションログには何も記録されていない。CPUが制限されているだけで、エラーは発生していないからだ。

これがCPUクレジット枯渇の厄介な点で、アプリケーション層には一切エラーが出ない。ただ遅くなるだけだ。

対処方法：状況に応じた選択肢

選択肢A：Standardモードに切り替えてコストを予測可能にする

継続的な高負荷ではなく、予算の上限を優先したい場合はStandardモードへの変更を検討する。クレジット枯渇後はパフォーマンスが制限されるが、予期しない課金は発生しない。

aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications InstanceId=i-1234567890abcdef0,CpuCredits=standard \
  --region us-east-1

選択肢B：インスタンスタイプをアップグレードする

CPUSurplusCreditsChargedが継続的に発生しているなら、T3インスタンスのバースト前提の設計がワークロードに合っていない。m5やc5といった固定パフォーマンスインスタンスへの移行を検討する。余剰クレジット課金が積み重なるよりも、適切なインスタンスタイプを選ぶ方がトータルコストで有利になることが多い。

選択肢C：CloudWatchアラームでクレジット残高を監視する

問題が発生する前に検知するために、CPUCreditBalanceに対してアラームを設定する。残高が一定値を下回った段階で通知を受け取ることで、枯渇前に対処できる。

aws cloudwatch put-metric-alarm \
  --alarm-name t3-cpu-credit-low \
  --alarm-description 'T3 CPU Credit Balance is low' \
  --metric-name CPUCreditBalance \
  --namespace AWS/EC2 \
  --statistic Average \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --period 300 \
  --evaluation-periods 3 \
  --threshold 20 \
  --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:ops-alert \
  --region us-east-1

T3インスタンスのCPUクレジット監視：まとめと次のステップ

T3インスタンスのCPUクレジット機構を理解することは、バースト性能インスタンスを正しく運用するための基礎だ。突然の速度低下の原因がCPUクレジット枯渇であることを素早く診断できるかどうかは、CloudWatchメトリクスを日常的に監視しているかどうかにかかっている。

用語集

用語説明
CPUクレジットT3などのバースト可能インスタンスがベースラインCPU使用率を下回って稼働した時間に応じて蓄積されるトークン。バースト時に消費される。
ベースラインCPU使用率各T3インスタンスタイプに定義された標準的なCPU使用率の上限。これを超えるとクレジットが消費される。
Standardモードクレジット枯渇後にCPUパフォーマンスをベースラインに制限するモード。追加課金なし。
Unlimitedモードクレジット枯渇後も性能を維持するモード。超過分は余剰クレジットとして課金される。T3のデフォルト。
CPUSurplusCreditsChargedUnlimitedモードでクレジット残高がゼロの状態でバーストした際に課金される余剰クレジット量を示すCloudWatchメトリクス。

コメント

コメントを投稿

このブログの人気の投稿

SQS Visibility Timeoutの完全解説：メッセージ二重処理の原因と対策

SQSキューから取得したメッセージが複数のコンシューマーに重複処理される——この問題はVisibility Timeoutの設定ミスが原因であることがほとんどだ。処理時間がタイムアウト値を超えた瞬間、SQSはそのメッセージを「未処理」と判断して再度可視化し、別のワーカーが同じメッセージを拾ってしまう。 TL;DR：Visibility Timeoutとは何か 項目 内容 定義 コンシューマーがメッセージを受信してから、他のコンシューマーに見えなくなる時間 デフォルト値 30秒 設定範囲 0秒〜43,200秒（12時間） 二重処理の原因 処理時間がVisibility Timeoutを超えるとメッセージが再可視化される 対策 処理時間に余裕を持たせた値を設定、または処理中に延長APIを呼ぶ 削除タイミング 処理完了後に明示的に DeleteMessage を呼ぶ必要がある Visibility Timeoutの仕組みを理解する SQSはメッセージを受信した時点でそのメッセージを一時的に「不可視」にする。これはキューからメッセージを削除するわけではなく、他のコンシューマーから見えなくするだけだ。コンシューマーが処理を完了して DeleteMessage を呼べばメッセージは消える。しかしVisibility Timeoutが切れる前に削除されなければ、メッセージはキューに戻り、再度取得可能になる。 この設計は意図的なものだ。コンシューマーがクラッシュしたり応答しなくなった場合に、メッセージが失われないようにするためのフェイルセーフとして機能している。問題は、正常に動作しているコンシューマーの処理時間がタイムアウトを超えたときに、同じフェイルセーフが誤発動することだ。 sequenceDiagram participant CA as コンシューマーA participant SQS as SQS キュー participant CB as コンシューマーB CA->>SQS: ReceiveMessage SQS...
続きを読む

EC2 SSH接続タイムアウトの原因と修正方法 — セキュリティグループのインバウンドルール完全ガイド

新しいEC2インスタンスを起動してSSH接続を試みたとき、 ssh: connect to host xx.xx.xx.xx port 22: Connection timed out というエラーで止まった経験は多くのエンジニアにある。アプリケーションのエラーではなく、パケットがインスタンスに届いていないことを示すタイムアウトだ。原因の大半はセキュリティグループのインバウンドルール設定にあるが、それだけで解決しないケースも存在する。 TL;DR — EC2 SSHタイムアウトの主な原因と対処 原因レイヤー 確認項目 修正方向 セキュリティグループ ポート22のインバウンドルールが存在するか TCP 22をソースIPに対して許可 ネットワークACL サブネットレベルでポート22がブロックされていないか インバウンド/アウトバウンド両方のルールを確認 パブリックIPアドレス インスタンスにパブリックIPが割り当てられているか ElasticIPの関連付けまたはパブリックIP自動割り当ての有効化 インターネットゲートウェイ VPCにIGWがアタッチされているか IGWを作成してVPCにアタッチ ルートテーブル サブネットのルートテーブルに0.0.0.0/0 → IGWのルートがあるか デフォルトルートをIGWに向ける EC2 SSH接続の仕組み — パケットが届くまでの経路 SSHタイムアウトを正確に診断するには、クライアントのパケットがEC2インスタンスに到達するまでに通過するレイヤーを理解する必要がある。セキュリティグループだけを見て終わりにすると、別のレイヤーでブロックされているケースを見逃す。 graph LR Client["クライアント ローカルマシン"] -->|"TCP SYN port 22"| IGW["インターネット ゲートウェイ (IGW)"] IGW --> RT["ルートテーブル 0.0.0.0/0 → IGW"] RT --> ...
続きを読む

S3パブリックアクセス拒否の原因と解決策：バケットレベルの「Block Public Access」が優先される仕組み

S3に画像をアップロードしてオブジェクトACLを「public-read」に設定したのに、URLにアクセスすると「Access Denied」が返ってくる。オブジェクト単体の設定は正しいはずなのに、なぜ拒否されるのか——この問題の原因はほぼ確実に、バケットレベルの「Block Public Access」設定にある。オブジェクトACLより上位のレイヤーが存在することを知らないと、何度設定を変えても解決しない。 TL;DR：S3パブリックアクセス拒否の原因まとめ 確認レイヤー 設定項目 影響範囲 アカウントレベル S3 Block Public Access（アカウント全体） 全バケットに適用 バケットレベル S3 Block Public Access（バケット個別） そのバケット内の全オブジェクト バケットポリシー Principal: * を許可するポリシーの有無 ポリシーで指定したリソース オブジェクトACL public-read ACL 個別オブジェクト 結論： オブジェクトACLを「public-read」にしても、バケットまたはアカウントレベルの「Block Public Access」が有効な場合、そのACLは無効化される。上位レイヤーの設定が下位を上書きする構造になっている。 S3パブリックアクセス制御の仕組み：なぜオブジェクトACLだけでは不十分か S3のアクセス制御は複数のレイヤーが重なって機能する。オブジェクトACLはその中で最も下位のレイヤーに位置する。AWSは2018年以降、誤ったパブリック公開によるデータ漏洩を防ぐため「Block Public Access」という上位の制御機構を導入した。この設定が有効な場合、オブジェクトACLやバケットポリシーで「public」を許可しようとしても、Block Public Accessがそれを遮断する。 Block Public Accessには4つの独立した設定項目がある。それぞれが異なるシナリオをカバーしており、全部オフにしないとパブリックアクセスが通らないケースもある。 graph TD A[...
続きを読む