Container Service for Kubernetes (ACK) クラスター上で実行される Pod はクラウドリソースを共有します。単一の Pod が複数のリソースを消費することもあれば、単一のリソースが複数の Pod にサービスを提供することもあります。部門やアプリケーションごとにクラスターのコストを割り当てるには、各 Pod のコストを計算する必要があります。
ACK コスト管理スイートでは、リソースウォーターマーク（リソース使用率）に基づいた 2 種類のコスト推定ポリシーを提供しています。各ポリシーは、個々の Pod や名前空間に帰属するクラスター全体のコストシェアを算出します。
コスト推定ポリシーの選択
|
ポリシー |
コストの割り当て基準 |
推奨される状況 |
|
単一リソースコスト推定 |
CPU または メモリのいずれか一方 |
いずれかのリソースが支配的である場合。たとえば、CPU ウォーターマークがメモリウォーターマークよりもはるかに高い場合、またはほとんどのアプリケーションがメモリ集約型である場合。 |
|
加重リソースコスト推定 |
CPU および メモリ。それぞれの使用率に基づいて重み付け |
CPU とメモリの使用率が近い場合、またはアプリケーションが両方のリソースタイプを消費する場合。 |
単一リソースコスト推定
コスト管理スイートのデフォルトポリシーです。このポリシーは、CPU またはメモリのいずれか一方のリソースディメンションに基づいて Pod のコストを計算します。
適用シナリオ
リソースウォーターマークとは、リクエストされたリソース量と割り当て可能なリソース総量の比率です。多くのクラスターでは、ある特定のリソースタイプがスケジューリングの判断を左右します。一方のリソースのウォーターマークが他方よりもはるかに高い場合、そのリソースがクラスターのコストを支配していることになります。
例：Java ワークロードなどのメモリ集約型アプリケーションは大量のメモリをリクエストします。メモリウォーターマークが 90% に達した場合、Pod をスケジュールできるかどうかはメモリ供給量によって決まります。このとき、メモリコストはクラスター全体のコストの 90% を占めることになります。単一リソースコスト推定ポリシーは、このような関係を正確に捉えます。
Pod コストの計算
このポリシーでは、以下の数式を用いて Pod の CPU またはメモリコストを計算します。
名前空間コストの計算
名前空間は、共通フィールドを持つ関連する Pod をグループ化します。名前空間のコストは、その名前空間内のすべての Pod のコスト比率の合計に、クラスター請求書の支払総額を掛けた値となります。
名前空間コストの数式：
名前空間コスト比率の数式：
加重リソースコスト推定
CPU とメモリの両方を用いて Pod のコストを計算し、クラスターレベルの使用率に基づいて重み付けを行います。これにより、ワークロードが両方のリソースタイプを消費する場合に、よりバランスの取れたコスト配分が可能になります。
適用シナリオ
以下の条件に該当する場合は、加重リソースコスト推定ポリシーを使用してください。
-
クラスターの CPU ウォーターマークとメモリウォーターマークが互いに近い値である場合。
-
クラスター内のアプリケーションは、CPU およびメモリリソースを消費します。
CPU コストとメモリコストが近い値である場合、それぞれのウォーターマークを比較することで、コスト配分における重み付けの妥当な根拠が得られます。
Pod コストの計算
加重リソースコスト推定ポリシーでは、Pod の CPU 重みとメモリ重みに基づいて Pod のコストを計算します。これらの重みは、クラスターレベルの CPU ウォーターマークおよびメモリウォーターマークから導出されます。
Pod コストの数式：
ウォーターマークおよび重みの数式
CPU ウォーターマーク、メモリウォーターマーク、CPU 重み、メモリ重みは、以下のように計算されます。
-
CPU ウォーターマーク（CPU 使用率）：
-
メモリウォーターマーク（メモリ使用率）：
-
CPU 重み：
-
メモリ重み：
ポリシー結果の比較
例 1：単一のリソースタイプが支配的
設定：クラスター内でメモリ集約型アプリケーションが 2 つ実行されています。
| アプリケーション | リクエスト vCore 数 | リクエストメモリ量 |
|---|---|---|
| App A | 1 vCore | 2 GB |
| App B | 1 vCore | 4 GB |
-
メモリウォーターマーク：90%
-
CPU ウォーターマーク：20%
-
クラスターの日次コスト：USD 200
単一リソースコスト推定の結果：
| リソースディメンション | Pod コスト | 計算式 | 未割り当てコスト |
|---|---|---|---|
| メモリ | USD 180 | USD 200 × 90% | USD 20 |
| CPU | USD 40 | USD 200 × 20% | USD 160 |
メモリに基づいてコストを割り当てると、クラスター全体コストの 90% をカバーできます。一方、CPU に基づいて割り当てると、80% が未割り当てとなりますが、これはクラスターのメモリのうちスケジューリングに利用可能な容量がわずか 10% しかないという事実と矛盾します。
加重リソースコスト推定の結果：
-
メモリ重み：約 80%
-
CPU 重み：約 20%
-
Pod コスト：USD 152（USD 180 × 80% + USD 40 × 20%）
-
未割り当てコスト：USD 48
結果：単一リソースコスト推定ポリシー（メモリ使用）では、USD 200 のうち USD 180 が割り当てられ、実際のリソース消費量に非常に近い結果が得られます。一方、加重ポリシーでは USD 152 しか割り当てられず、USD 48 が未割り当てとなります。単一のリソースが支配的なクラスターでは、単一リソースポリシーの方がより正確な結果をもたらします。
例 2：両方のリソースタイプが消費される
設定：クラスター内でメモリ集約型アプリケーションと CPU 集約型アプリケーションがそれぞれ 1 つずつ実行されています。
| アプリケーション | リクエスト vCore 数 | リクエストメモリ量 |
|---|---|---|
| App A | 1 vCore | 4 GB |
| App B | 4 vCores | 1 GB |
-
CPU ウォーターマーク：40%
-
メモリウォーターマーク：50%
-
クラスターの日次コスト：USD 200
単一リソースコスト推定の結果：
| リソースディメンション | Pod コスト | 計算式 |
|---|---|---|
| メモリ | USD 100 | USD 200 × 50% |
| CPU | USD 80 | USD 200 × 40% |
加重リソースコスト推定の結果：
-
メモリ重み：約 56%
-
CPU 重み：約 44%
-
Pod コスト：USD 91.2（USD 100 × 56% + USD 80 × 44%）
-
未割り当てコスト：USD 8.8
結果：CPU とメモリのウォーターマークが近い値（40% と 50%）であることから、CPU コストとメモリコストがほぼ同等であることがわかります。加重ポリシーでは両方のディメンションを考慮し、未割り当てコストを USD 8.8 に抑えています。一方、単一リソースによる割り当てでは、USD 100 または USD 120 が未割り当てとなります。混合ワークロードを実行するクラスターでは、加重リソースポリシーの方がよりバランスの取れた結果をもたらします。
加重ポリシーによる未割り当てコストの削減
原因：一方のリソースのウォーターマークが他方よりもはるかに高い場合、未割り当てコストが発生します。支配的なリソースがボトルネックに達した一方で、もう一方のリソースはアイドル状態になります。たとえば、CPU ウォーターマークがメモリウォーターマークよりもはるかに高い場合、メモリリソースがアイドル状態になります。単一リソースコスト推定ポリシーでは、これらのアイドルリソースのコストを割り当てることができますが、加重ポリシーではそれができません。
解決策：ご利用のワークロードのリソースプロファイルに合った Elastic Compute Service (ECS) インスタンスタイプを選択してください。CPU ウォーターマークとメモリウォーターマークが互いに近い値になるように調整します。あるいは、単一リソースコスト推定ポリシーに切り替えてください。
コストデータ API
-
HTTP API リクエストを送信して、カスタム開発用のコストインサイトデータを取得します。詳細については、「コストデータのクエリ API 呼び出しの概要」をご参照ください。