Container Service for Kubernetes:コスト推定ポリシー

Introduction to cost estimation policies

単一リソースコスト推定

これはデフォルトのコスト見積もりポリシーです。 クラスターのリソース透かしに基づいてクラスターコストを計算する場合は、このポリシーを使用することを推奨します。

利用シナリオ

リソースウォーターマークは、全リソースに対する要求されたリソースの比率を指す。 ほとんどの場合、クラスタのリソース透かしは、最も要求されるリソースタイプに依存する。 したがって、単一リソースコスト推定ポリシーは、クラスタのCPUまたはメモリ透かしが他のものよりもはるかに高いシナリオに適しています。 これらのシナリオでは、クラスター内のほとんどのアプリケーションは1種類のリソースのみを使用します。

Javaアプリケーションなどのメモリ集約型アプリケーションは、クラスタから大量のメモリリソースを要求します。 この場合、メモリコストはCPUコストよりもはるかに高くなります。 メモリリソースの供給は、クラスター内のアプリケーションをスケジュールできるかどうかを決定します。 単一リソースコスト推定ポリシーは、前述のシナリオに適しています。 メモリ透かしが90% である場合、メモリコストはクラスタコストの90% を占める。 これは、メモリ透かしがメモリコスト比と完全に一致することを意味する。

制御ポリシー機能の動作

このポリシーは、ポッドのCPUまたはメモリコストを計算します。

ポッドのコストを計算する

このポリシーでは、次の式を使用してポッドのCPUまたはメモリのコストを計算します。

名前空間のコストの計算

名前空間は、1つ以上のフィールドを共有するポッドのグループです。 クラスター内の各ポッドのコスト比率を取得したら、名前空間内の各ポッドのコスト比率の合計に、クラスターの請求書のすべての支払い金額の合計を掛けることで、名前空間の料金を計算できます。

• 名前空間のコストは、次の式に基づいて計算されます。

  

• 名前空間のコスト比は、次の式に基づいて計算されます。

  

加重リソースコストの見積もり

利用シナリオ

クラスター内のアプリケーションが両方のタイプのリソースを使用する場合、またはクラスターのCPU透かしがメモリ透かしに近い場合は、加重リソースコスト推定ポリシーを使用することを推奨します。 CPUコストがメモリコストに近い場合は、CPUウォーターマークとメモリウォーターマークを比較することで、CPUコストとメモリコストを比較できます。

仕組み

加重リソースコスト推定ポリシーは、ポッドのCPU重量とメモリ重量に基づいてポッドのコストを計算します。 CPU重みおよびメモリ重みは、クラスタのCPU透かしおよびメモリ透かしによって決定される。

ポッドのコストを計算する

単一リソースコスト推定ポリシーとは異なり、重み付きリソースコスト推定ポリシーは、ポッドのCPU重みとメモリ重みに基づいてポッドのコストを計算します。 このポリシーでは、次の式を使用してポッドのコストを計算します。

CPU透かし、メモリ透かし、CPU重量、およびメモリ重量は、次の式に基づいて計算されます。

• CPU透かし:

  

• メモリ透かし:

  

• CPUの重量:

  

• メモリ重量:

  

例

次の例は、さまざまなシナリオで適切なコスト見積もりポリシーを選択する方法を示しています。

例1: クラスター内のほとんどのアプリケーションは1種類のリソースのみを使用します

次の図では、2つのメモリ集約型アプリケーションがクラスターにデプロイされています。 1つのアプリケーションは1 vCoreと2 GBのメモリを要求し、他のアプリケーションは1 vCoreと4 GBのメモリを要求します。 この場合、クラスタのメモリ透かしが90% され、CPU透かしが20% される。 クラスターの1日のコストが 200米ドル。

• 単一リソースコスト推定:

  • クラスターのメモリコストを計算すると、ポッドコストは USD 180 (USD 200 × 90%) 。 結果は、クラスタの総コストに近い。

  • クラスターのCPUコストを計算すると、ポッドコストは USD 40 (USD 200 × 20%) 。 大量のクラスタコストが割り当てられず、クラスタによって提供されるメモリの10% のみがポッドスケジューリングに使用可能である。

• 加重リソースコストの見積もり:

  メモリ重量は約80% であり、CPU重量は約20% である。 ポッドのコストは USD 152 (USD 180 × 80% + USD 40 × 20%) 。 USD 28は未割り当てです。 結果は、メモリコストを計算したときの結果よりも小さくなります。

結果は、単一リソースコスト推定ポリシーが使用される場合、メモリコストがクラスタコストの90% を占めることを示す。 したがって、単一リソースコスト推定ポリシーは、クラスタ内のほとんどのアプリケーションが1つのタイプのリソースのみを使用するシナリオに適しています。

例2: クラスタ内のアプリケーションが両方のタイプのリソースを使用する

次の図では、メモリ集約型アプリケーションとCPU集約型アプリケーションがクラスターにデプロイされています。 1つのアプリケーションは1 vCoreと4 GBのメモリを要求し、他のアプリケーションは4 vCoreと1 GBのメモリを要求します。 この場合、クラスタのCPU透かしが40% され、メモリ透かしが50% される。 クラスターの1日のコストが 200米ドル。

• 単一リソースコスト推定:

  • クラスターのメモリコストを計算すると、ポッドコストは USD 100 (USD 200 × 50%) 。

  • クラスターのCPUコストを計算すると、ポッドコストは USD 80 (USD 200 × 40%) 。

• 加重リソースコストの見積もり:

  メモリ重量は約56% であり、CPU重量は約44% である。 ポッドのコストは 91.2米ドル (100米ドル × 56% + 80米ドル × 44%) 。 USD 8.8は未割り当てです。 結果は、メモリコストを計算したときの結果よりも小さくなります。

結果は、単一リソース (メモリ) コスト推定ポリシーを使用することによって割り当てられるコストが、加重リソースコスト推定ポリシーを使用することによって割り当てられるコストよりも高いことを示す。 しかし、CPU要求がメモリ要求に近いため、CPU透かしはメモリ透かしに近い。 これは、クラスタのCPUコストがクラスタのメモリコストに近いことを示します。 したがって、重み付きリソースコスト推定ポリシーは、クラスタ内のアプリケーションが両方のタイプのリソースを使用するシナリオに適しています。

よくある質問

重み付きリソースコスト推定ポリシーを使用してクラスターのコストを割り当てる場合、未割り当てコストを削減するにはどうすればよいですか。

原因: 加重リソースコスト推定ポリシーを使用してクラスターのコストを割り当てると、特定のコストが割り当てられなくなる可能性があります。 これは、クラスタによって集中的に使用されるリソースの透かしが、他のリソースの透かしよりもはるかに高いためである。 集中的に使用されるリソースの透かしがボトルネックに達すると、他のタイプの空きリソースが存在する。 たとえば、クラスタのCPU透かしがクラスタのメモリ透かしよりもはるかに高い場合、アイドル状態のメモリリソースが存在します。 この場合、単一リソースコスト推定ポリシーを使用してクラスターのコストを割り当てると、アイドルリソースのコストも割り当てることができます。 加重リソースコスト推定ポリシーを使用してクラスターのコストを割り当てる場合、アイドルリソースのコストを割り当てることはできません。

解決策: ワークロードのリソース要求に基づいて適切なECS (Elastic Compute Service) インスタンスタイプを選択し、クラスターのCPU透かしがメモリ透かしに近いことを確認します。 または、単一リソースコスト推定ポリシーを使用して、クラスターのコストを割り当てることもできます。

関連ドキュメント

• HTTP APIリクエストを送信して、コストインサイトデータを取得し、そのデータをカスタム開発に使用できます。 詳細については、「APIを呼び出してコストデータを照会する概要」をご参照ください。