「費用的に一番やすいから」という理由のみで汎用型のT系インスタンスを使っていませんか？
Amazon EC2には、
- T系インスタンス（バースト可能な汎用インスタンス）
- M系インスタンス（汎用インスタンス）
- C系インスタンス（コンピューティング最適化インスタンス）
- R系インスタンス（メモリ最適化インスタンス）
など様々なインスタンスタイプがあります。インスタンスタイプを選ぶ際は、それぞれの特徴とシステム（サイト）の特徴を考え、マッチするものを選ぶことが重要です。
T系インスタンスは、特徴をしっかり理解していないとサービスに重大な影響をおよぼす可能性があります。
この記事では、T系インスタンスの特徴であるCPUクレジットを枯渇させ、その時なにが起きるのかを検証しました。T系インスタンスの特徴を知ることで、インスタンスタイプへの理解を深めてもらい、最適なインスタンスタイプの選択の手助けになれればと考えています。
T系インスタンスの特徴
T系インスタンスは、バースト可能な汎用インスタンスです。AWS公式には、次のように記載されています。
T3 インスタンスは、ベースラインレベルの CPU パフォーマンスを提供する次世代のバースト可能な汎用インスタンスタイプで、いつでも必要な時間だけ CPU 使用率をバーストさせる機能を備えています。T3 インスタンスはバランスの取れたコンピューティング、メモリ、およびネットワークのリソースを提供し、使用中に一時的なスパイクが生じる中程度の CPU 使用率を持つアプリケーション向けに設計されています。
T3 インスタンスは、ワークロードがベースラインしきい値未満で動作しているときに CPU クレジットを蓄積します。得られた CPU クレジットごとに、T3 インスタンスには、必要時に 1 分間、CPU コアのフルパフォーマンスでバーストする機会が提供されます。Unlimited モードでは、T3 インスタンスはいつでも必要なだけ長くバーストすることができます。
参考：https://aws.amazon.com/jp/ec2/instance-types/
簡単にまとめると、
- インスタンスタイプごとにベースライン（CPU使用率）が設定されている
- CPUクレジットを消費して、100%の使用率が提供される（バースト）
- ベースライン以下の使用率の時に、CPUクレジットが蓄積される
- CPUクレジットが枯渇すると、ベースラインで、CPU使用率に制限がかかる
というような内容です。このことから、常時ベースラインを超えるような使い方には向いていません。普段はベースライン以下、稀にベースラインを超えるくらいの負荷が上がるケースに適したインスタンスタイプとなっています。
このことを理解していないと、CPUクレジットが枯渇し、サービスに重大な影響を及ぼす可能性があります。
CPUクレジット枯渇の影響を確認する方法
枯渇するとどうなるのか？EC-CUBEとJMeterを使って確認していきます。
確認環境
以下の環境を構築します。
- インスタンス：t3.large
- OS：CentOS7
- システム：EC-CUBE4
負荷生成シナリオ内容
以下のシナリオを作成し、JMeterから負荷をかけます。
- トップページ表示
- ログイン画面表示
- ログイン実施
確認方法
システムの限界スループットの60%程度の負荷をかけていき、CPUクレジットの枯渇前後の状態を確認していきます。
具体的には次の手順で行いました。
1．限界スループットの確認
段階的に負荷を上げていき、スループットの推移を確認します。頭打ちとなった部分が限界スループットとなります。
限界スループットの60%程度のスループットになる負荷強度を確認しておきます。
今回は、下の表のようになったので、60%程度のスループットになる負荷強度は、スレッド数「10」とします。
限界スループットの確認
2．CPUクレジットの枯渇状況の確認
１で確認した、限界スループットの60%程度になる負荷強度でCPUクレジットを枯渇させていきます。
その際の次の様子を確認します。
- CPUクレジット残高
- CPU使用率
- WEBの平均応答速度
CPUクレジットを枯渇させてみた結果
スレッド数「10」で長時間負荷をかけてみた結果、次のようになりました。
CPUクレジット
CPUクレジットの推移
縦軸がCPUクレジットのカウント、横軸がUTC時間です。（以降はJST表記の時間ですすめます）上のグラフがCPUクレジット使用量、下のグラフがCPUクレジット残高となっています。プロット間隔は5分です。
CPUクレジット使用量は、負荷をかけている期間中は、5分間で約6.6消費され、枯渇してからは消費量が約3に減りました。
CPUクレジット残高は使用量分だけ下がりに減っており、10時10分（UTC表記：01:10)で0となり枯渇しました。
CPU使用率
CPU使用率の推移
一番上のグラフはCPUの使用率を表しており、縦軸がCPU使用率、横軸が時刻（JST）となっています。青線（USER）がユーザーが利用しているもので、赤線（Steal)が使用制限されているものとなります。プロット間隔は1秒です。
常時60%以上の使用率となっていましたが、10時14分に、ユーザーの使用率が30%に制限されていることがわかります。クレジット残高の推移とほぼ一致しています。
平均応答速度
平均応答速度の推移
全リクエストの平均応答速度の推移をグラフにしました。縦軸が平均応答速度で、横軸が時刻（JST）です。プロットは1分間隔としています。
10時14分までは、1秒以内の応答を返しています。CPUの制限がかかった10時14分以降は応答速度が3秒以上に悪化していることがわかります。
わかったこと
T系インスタンスでは、クレジット残高があるうちは、CPU使用率の制限がかかることはありませんでした。しかしながら、CPUクレジット残高が0になると、CPU使用率に制限がかかります。その影響で、WEBの応答速度遅延が発生しました。
もし本番サービスで発生したと考えてみると、3秒程度の応答遅延があるということは、ユーザーに大きなストレスを与えてしまいます。今回のケースでは3秒程度でしたが、負荷があがれば10秒以上の遅延に発展することも考えられます。
一番問題なのは、今回のようにCPUクレジットが枯渇し本来の応答速度よりも遅延しているにもかかわらず、ユーザーが大きな声を上げない程度の遅延で、それに気づかずユーザービリティを損ない続けてしまうケースかもしれません。
このような状況を防ぐためには、CPUクレジットの監視や応答速度監視などが重要になります。
まとめ
CPUのバースト可能なT系インスタンスは、CPUクレジットが枯渇するとCPUの使用率に制限がかかるインスタンスです。制限がかかると、応答速度遅延などシステムに悪い影響を及ぼします。
T系インスタンスを使う場合は、動作するシステムが、CPUクレジット残高が枯渇する可能性が少ない、または枯渇しても問題ない時に選択するようにしましょう。
また、問題が発生する前に対策が打てるように、CloudWatchを利用してCPUクレジット残高の監視をしておくとよいですね。
参考
AWS公式 Amazon EC2インスタンスタイプ：https://aws.amazon.com/jp/ec2/instance-types/
ちょっと待ってください!あなたが使うべきは本当にT系インスタンスですか!?：https://dev.classmethod.jp/articles/ec2-t-or-m/
今回利用したJMeterのシナリオ：https://ptune.jp/tech/introduction-to-jmeter-scenario-creation/
限界スループットの確認方法：https://ptune.jp/tech/how-to-check-the-maximum-throughput/