AWS T2 CPU クレジット残高と実際の CPU ワークロードの説明

AWS（アマゾンウェブサービス）が新製品をリリース 驚異的な速度で進化しているため、ユーザーがそれらのサービスのベストプラクティスやユースケースを把握することが困難になっています。IT チームにとっては、ビジネス運用の改善、コストの削減、IT パフォーマンスの最適化につながる AWS サービスのリリースを逃してしまうリスクがあります。

特にあまり利用されていないサービスについてもう一度考えてみましょう。AmazonのT2インスタンスタイプは新しいものではありませんが、詳しく知らない人にとっては複雑に思えるかもしれません。 アマゾンの言葉「T2 インスタンスは、CPU を頻繁にまたは継続的にフル活用することはないが、時折 CPU パフォーマンスをバーストする必要があるワークロード向けです。」ただし、この定義は曖昧に思えます。  

インスタンスが CPU を「頻繁」以上使用するとどうなるでしょうか? それは実際のパフォーマンスにどのように表れますか? 以下のように大きく異なる CloudWatch と OS の統計をどのように調整すればよいでしょうか?

これらの質問について詳しく調べてみましょう。

T2インスタンスでのCPUクレジットの仕組み

Amazon 説明して 「T2 インスタンスのベースライン パフォーマンスとバースト能力は、CPU クレジットによって制御されます。各 T2 インスタンスは継続的に CPU クレジットを受け取りますが、そのレートはインスタンスのサイズによって異なります。T2 インスタンスはアイドル状態のときに CPU クレジットを蓄積し、アクティブなときに使用します。CPU クレジットは、2 分間の CPU コア全体のパフォーマンスを提供します。」つまり、インスタンスには常に CPU クレジットが「供給」され、CPU がアクティブなときに消費します。消費率が供給率を超えると、CPUCreditBalance (CloudWatch で表示されるメトリック) が増加します。それ以外の場合は、減少します (または同じまま)。このダイナミクスにより、TXNUMX インスタンスは AWS のバースト可能なインスタンス ファミリーの一部となります。

もっとわかりやすく説明しましょう。T2.mediumを見てみましょう。 アマゾンは言う ベースライン割り当ては 40 つの vCPU の 24% で、100 時間あたり 24 クレジットを獲得します (各クレジットは 40 分間 2% で実行される XNUMX つの vCPU を表します。したがって、XNUMX 時間あたり XNUMX クレジットを獲得すると、インスタンスを XNUMX つの vCPU の XNUMX% のベースラインで実行できます)。この割り当ては、TXNUMX.medium インスタンスの XNUMX つのコアに分散されます。 

重要な点は、CPU クレジットは基本パフォーマンス レベルを維持するために使用されるということです。基本パフォーマンス レベルは、獲得したクレジットに加えて付与されるわけではありません。つまり、実質的には、デュアル コア T20.medium で 2% の CPU 負荷を維持できることになります (20 つのコアが 40% で結合され、XNUMX% のベースライン割り当てになります)。 

現実には、クレジットが完全になくなることもありますが、Amazon は 20% のベースライン作業を許可してくれるため、40% を少し超える金額を受け取ることになります。また、一時的にクレジット残高が残り、短期間ベースラインを超える金額を受け取ることができる場合もあります。

例えば、T2.mediumインスタンスが高負荷で稼働しており、クレジットをすべて使い果たしている場合、LogicMonitorから次のことがわかります。 CloudWatchモニタリング このインスタンスが常に21.7％で実行されているとAmazonが考えるグラフ：

このインスタンスは 0.43 分あたり 25.8 CPU クレジットを消費します (残高は常にゼロなので、割り当てられたクレジットはすべて消費されます)。したがって、実際にはこのインスタンスは理論上の 43 ではなく、60 時間あたり 24 使用クレジット (.XNUMX * XNUMX 分) を取得します。

AWS RDS インスタンスも CPU クレジットを使用しますが、計算は少し異なり、インスタンスのサイズとクラス (汎用 vs メモリ最適化) によって異なります。T2 バースト モデルでは、T2 インスタンスを他のインスタンス タイプよりも低価格にできますが、それは効果的に管理した場合に限られます。

CPUクレジットバランスがパフォーマンスに与える影響

しかし、これはインスタンスのパフォーマンスにどのように影響するのでしょうか? Amazon は、インスタンスが CPU 使用率 21% で実行されていると考えています (CloudWatch によって報告)。オペレーティング システムはどのように考えているのでしょうか?

同じインスタンスのオペレーティングシステムのパフォーマンス統計を見ると、非常に異なる状況がわかります。



CloudWatch が示す値に反して、使用率は一定ではなく、ピークや持続的な負荷によって変動します。この 21 つをどう調和させればよいでしょうか。CloudWatch によると、システムは、オペレーティング システムあたり 12% で実行されているときに利用可能なノード リソースの 21% を使用し、オペレーティング システムあたり 80% で実行されているときに XNUMX% を使用します。何ですか。

少し違った考え方をすると役に立ちます。21% を「CPU クレジットによって課せられた現在の制約内で実行できる合計作業」と考えてください。これを 21 秒あたり 21 作業単位としましょう。オペレーティング システムはこの制約を認識していないため、1 作業単位で実行できる合計作業を実行するように OS に要求すると、59 秒で完了し、その後はアイドル状態になります。オペレーティング システムは、作業がもっとあればもっと多くの作業を実行できると考えます。そのため、1.6 秒間ビジー状態、次の XNUMX 秒間はアイドル状態、つまり XNUMX% ビジー状態であると報告します。 

しかし、これはコンピューターが最初の 98 秒間に 42% 以上の作業を実行できたことを意味するものではありません。コンピューターに 2 作業単位を実行するように要求すると、それを実行するのに XNUMX 秒かかります。そのため、OS にアイドル状態の CPU パワーがたくさんあるように見えても、タスクを完了するまでの待ち時間は XNUMX 倍になります。

これは簡単なベンチマークで確認できます。同じワークロードを持つ 2 つの同一の TXNUMX.medium インスタンスでは、同じ作業を完了するのにかかる時間が大きく異なります。CPU クレジットが十分にあるインスタンスでは、sysbench テストがはるかに速く完了します。

sysbench --test = cpu --cpu-max-prime = 2000 run

sysbench 0.4.12：マルチスレッドシステム評価ベンチマーク


スレッド数：1


CPUテストでチェックされた最大プライム数：2000

テスト実行の概要：

    合計時間：1.3148秒

    イベントの総数：10000

同一のインスタンスですが、CPUクレジットがゼロの場合、同じ作業を行うのにはるかに長い時間がかかります。

テスト実行の概要：

    合計時間：9.5517秒

    イベントの総数：10000

どちらのシステムも、OSレベルから50％のCPU負荷（100％で実行されているデュアルコアシステムのシングルコア）を報告しました。 しかし、それらは同一の「ハードウェア」であるにもかかわらず、同じ作業を行うのに非常に異なる時間を要しました。

つまり、CPU はクレジットを使い果たして基本割り当てを終えると「ビジー」になるが動作しなくなるということです。これは VMware 環境の「CPU 準備完了」カウンターに非常によく似ており、ゲスト OS に作業があるが CPU をスケジュールできないことを示します。CPU クレジットを使い果たした後、「アイドル」および「ビジー」CPU パフォーマンス メトリックは、プロセッサ キューに作業を追加できる能力を示しますが、作業をさらに実行できる能力は示しません。そして、もちろん、キューに多くの作業があると、レイテンシも増加します。

CPUクレジットの使用量の監視と管理

したがって、CPUクレジットに注意を払う必要があることは明らかです。 LogicMonitor—T2 インスタンスクレジットデータソースはこれを自動的に実行します。(これはすでにアカウント内にある場合もあれば、コアリポジトリからインポートできる場合もあります。) このデータソースは CPU クレジット残高と消費率をプロットするため、OS と CloudWatch の統計情報との関連でクレジットの動作を簡単に確認できます。

このデータソースは、インスタンスの CPU クレジットが不足したときにも警告を発するため、CPU 使用率の急上昇が Amazon による調整によるものか、実際のワークロードの増加によるものかがわかります。

バースト可能なインスタンスとは何ですか?

バースタブルインスタンスは、 AmazonEC2インスタンス さまざまな CPU 使用パターンを持つワークロード向けに設計されています。ベースライン レベルのパフォーマンスと、ワークロードでより多くの CPU リソースが必要になったときにそのレベルを超えてバーストする機能が備わっています。

バースト可能な AWS EC2 インスタンスにはそれぞれ、いくつかの基本特性があります。

• ベースラインパフォーマンス: 基本CPUパフォーマンスレベル。これはCPUコアの容量全体に対する割合です。
• CPUクレジット: ベースラインレベルを超えるパフォーマンスを管理するために使用されるクレジット。CPU 使用率がベースラインを下回った場合に付与されます。
• クレジット残高: 基準レベルを下回ったために受け取った未使用のクレジット

この機能により、バースト可能なインスタンスは、トラフィック負荷が予測できないアプリケーションに最適です。バースト可能なインスタンスが使用される一般的なユースケースには、次のようなものがあります。

• トラフィックパターンが変化するWebサーバー
• リクエストによるCPU負荷の高い操作が時々発生する小規模データベース
• 開発およびテスト環境
• マイクロサービスとコンテナ化されたアプリケーション

T2 はバースト可能なインスタンスを可能にする唯一の製品ではありません。次の製品ファミリーにも含まれています。

• T3
• T3a
• T4g

T3 インスタンスとは何ですか?

T3インスタンス は、Amazon の AWS T ファミリーのバースト可能なインスタンスの次世代です。T3 はパフォーマンスが向上し、コストも抑えられるため、AWS の使用を開始する場合や現在のインスタンスをアップグレードする場合に最適です。

T3 は T2 に比べて多くの利点があります。

• より優れたパフォーマンスと価格: Amazon T30インスタンスと比較して、価格性能比が2%向上します
• ナイトロシステム: Amazon Nitroシステム上に構築され、より優れたネットワークとストレージ機能を提供します
• 無制限モード: デフォルトで「無制限」モードで実行し、追加料金でベースラインを無制限に超えてバーストする
• 複数のプロセッサ: T3とT3aでは、IntelとAMDのプロセッサラインのサポートが得られます

全体的に、Amazon の T3 ラインナップは、パフォーマンスとコストの面で T2 よりも大きな利点があります。選択肢を検討して、組織に適しているかどうかを判断してください。

T2 インスタンスのパフォーマンスを最適化するためのベスト プラクティス

では、CPU クレジットが不足しているという警告が表示されたらどうしますか? 問題になるでしょうか? まあ、ほとんどのことと同様に、それは状況によります。インスタンスがレイテンシに敏感なアプリケーションに使用されている場合、これは絶対に問題になります。CPU 容量が減り、タスクがキューに入れられ、アイドル状態の CPU があることで未使用の容量がなくなるからです。一部のアプリケーションでは、これで問題ありません。一部のアプリケーションでは、エンドユーザーのエクスペリエンスが損なわれます。そのため、 監視システム CloudWatch データ、OS レベルのデータ、アプリケーションのパフォーマンスなど、システムのあらゆる側面を監視できることが重要です。

もう 2 つ注意点があります。T2 インスタンスは、メモリ XNUMX GB あたりの最も安価なインスタンス タイプです。メモリが必要で、ベースライン CPU パフォーマンスを処理できる場合は、常にすべての CPU クレジットを消費するとしても、TXNUMX インスタンスを実行するのが妥当な選択です。

CPU クレジットを使い果たした場合の実際の影響について、これが役に立つ説明であったことを願っています。