T 系 EC2 インスタンスのクレジットが回復しないので困った話 [DeNA インフラ SRE]

はじめに

こんにちは、IT 本部 IT 基盤部第一グループの横田です。私の所属する IT 基盤部では、組織横断的に複数のサービスのインフラ運用を行っており、インフラの安定的な稼働やコスト削減に取り組んでいます。今回は、DeNA TechCon2023 LIGHTNING TALKS ¹ でも発表させていただいた AWS の EC2 インスタンスにおけるコストコントロールで困った事例をご紹介します。

T 系 EC2 インスタンスとは

AWS の EC2 インスタンスには、高い CPU 使用率が持続しない用途において安い料金で利用できる特徴があるバーストパフォーマンスインスタンスと呼ばれる仕組みがあります。バーストパフォーマンスインスタンスは、マシンスペックを表すインスタンスタイプが T から始まるため、この記事ではバーストパフォーマンスインスタンスのことを T 系 EC2 インスタンスと呼ぶことにします。

T 系 EC2 インスタンスには、インスタンスタイプごとに CPU 使用率のベースラインが定められています。また、CPU 使用率のベースラインを超えて利用可能な CPU リソースの量を表す CPU クレジットという概念があります。起動時間に応じて CPU クレジットを獲得し、CPU 使用率のベースラインを超えた場合に CPU クレジットを消費する仕組みになっており、CPU クレジットが枯渇すると利用可能な CPU 使用率がベースラインに制限されます。

例えば、開発環境の EC2 インスタンスは、起動したまま CPU リソースを使用しない時間が長いため、他のインスタンスタイプと比べて料金が安い T 系 EC2 インスタンスを利用することでコスト削減をしています。

以下、T 系 EC2 インスタンスに分類されるインスタンスタイプである t3.large を以下の条件で利用する場合の動作を説明します。²

ベースライン CPU 使用率：30 %
獲得する CPU クレジット：36 クレジット／時間
Unlimited モード

何に困ったか

事の発端は、とある理由で EC2 インスタンスの CPU 使用率が 30 % のベースラインを超え続け、CPU クレジット残高が 0 になっていたことでした。

以下のグラフの青い線は CPU 使用率（CPUUtilization）、赤い線は 30 % のベースライン CPU 使用率を表しています。

CPU使用率とベースライン

また、以下のグラフの青い線は CPU クレジット残高（CPUCreditBalance）、黄色い線は CPU クレジットの使用量（CPUCreditUsage）を表しています。

CPUクレジット残高と使用量

CPU 使用率が高くなっていた問題を解決し、CPU 使用率はベースラインを下回りましたが、数十分経っても 1 時間に 36 クレジット獲得するはずの CPU クレジット残高が回復していないことに気がつきました。この時点では、CPU クレジット残高が回復しない理由が分からなかったため、別の原因があるのではないかと考えて調査を進めていました。

理由が分からないままでいると、CPU 使用率がベースラインを下回ってから約 1 時間 30 分後に以下のグラフの青い線が表している CPU クレジット残高が回復し始めました。

CPUクレジット残高の回復

何が起こっていたか

このとき何が起こっていたかというと、CPUSurplusCreditBalance と呼ばれる、残高を超えて使いすぎた CPU クレジットが蓄積していました。以下のグラフを見ると、約 1 時間 30 分経った頃に CPUSurplusCreditBalance が 0 になっていることが分かります。

CPUSurplusCreditBalance

AWS の公式ドキュメント ³ には、CPU クレジット残高が以下の式に従って 5 分おきに調整されると記載されています。

$$\mathrm{Adjusted\ balance} = [\mathrm{prior\ CPUCreditBalance}-\mathrm{prior\ CPUSurplusCreditBalance}]$$ $$+[\mathrm{Credits\ earned\ per\ hour}\times\frac{5}{60}-\mathrm{CPUCreditUsage}]$$

この式では、蓄積していた CPU クレジット残高から CPUSurplusCreditBalance を差し引き、5 分ごとに獲得する CPU クレジットと使用量の差を足した値と表現されています。つまり、CPUSurplusCreditBalance が負のクレジット残高として作用することが分かります。

これを元に、1 時間 30 分で獲得する CPU クレジットを計算すると、

$$\frac{36\times90}{60}=54\mathrm{\ [Credits]}$$

となります。上記の図の赤い丸が表す CPU 使用率がベースラインを下回った時点での CPUSurplusCreditBalance が約 52 クレジットであったことから、この計算とおおよそ一致することが確認できます。

対策

このような状況における対策として、以下の 2 つが挙げられます。

Unlimited モードではなく、Standard モードで T 系 EC2 インスタンスを起動することで CPU クレジットを使い切った場合に CPU 使用率が制限されるようにすること
CPU 使用率がベースラインを長時間超えると予想される場合は、スペックアップを検討すること

また、注意点として、CPUSurplusCreditBalance が蓄積された状態で T 系 EC2 インスタンスを停止すると追加で料金がかかります。これを回避するには、CPU 使用率がベースラインを下回った状態を保ち、CPU クレジットが回復するまで待つ必要があります。

おわりに

今回は、T 系 EC2 インスタンスにおいて CPU クレジットが回復せず困った事例をご紹介しました。結論として、残高を超えて使いすぎた CPU クレジットである CPUSurplusCreditBalance が蓄積していたことで、CPU クレジット残高が回復するのに時間がかかっていました。

本事例のように EC2 インスタンスの細かい仕様や仕組みを理解することで、コストコントロール可能な状態にすることができると考えています。同様の問題に直面した際に、ご参考になれば幸いです。