Container Service for Kubernetes:ACK クラスターのコスト管理

ワークロードプロファイルに応じたインスタンスタイプのマッチング

以下の表では、一般的なワークロードプロファイルと、それぞれに推奨されるインスタンスタイプおよび課金方法をまとめています。

本番環境では、2 vCPU および 4 GB メモリ以下のインスタンスタイプを避けてください。これにより、リソースボトルネックおよび断片化を防止できます。詳細については、「ACK クラスター向け ECS 仕様の推奨事項」をご参照ください。

インスタンスタイプ選定の一般的なガイドラインについては、「ACK クラスター向け ECS 仕様の選定に関する推奨事項」をご参照ください。

プリエンプティブルインスタンスの活用

プリエンプティブルインスタンスは、リアルタイムの在庫状況に基づいて価格設定される従量課金インスタンスです。通常の従量課金インスタンスと比較して、総コストを最大 90 % 削減できます。

プリエンプティブルインスタンスは有効期限切れ後に再割り当てされる可能性があります。そのため、以下のようなステートレスかつ障害耐性のあるワークロードでのみ使用してください。

• バッチ処理および機械学習

• ビッグデータ ETL ジョブ（例：Apache Spark）

• キューイングされたトランザクション処理

• REST API を利用するアプリケーション

詳細については、「プリエンプティブルインスタンスベースのノードプールのベストプラクティス」をご参照ください。

共有インスタンスファミリーの活用

共有インスタンスファミリーは、個人開発者および中小規模の Web サイト、Web アプリケーション、開発環境、軽量データベース、軽量のエンタープライズクラスアプリケーションに適しています。CPU リソースが共有されるため、高負荷時にパフォーマンスが変動する可能性があります。詳細については、「共有インスタンスファミリー」をご参照ください。

節約プランの活用

長期間実行される ECS インスタンスまたはエラスティックコンテナインスタンスには、節約プランを購入することで、割引付きの従量課金価格を適用できます。節約プランは、1 年、3 年、または 5 年のコミットメントが必要です。「節約プランの概要」および「節約プランの購入および適用」をご参照ください。

リージョンの選択

ECS インスタンスの料金はリージョンによって異なります。ワークロードがより高いネットワーク遅延を許容できる場合、コストの低いリージョンにデプロイすることで費用を削減できます。リージョン別の料金については、「Elastic Compute Service」をご参照ください。

ACK マネージドクラスターの活用

ACK マネージドクラスターでは、コントロールプレーン（マスターノード）が Alibaba Cloud 上でホストされます。ユーザーはワーカーノードのみをプロビジョニングし、コントロールプレーンのリソース料金は発生しません。このため、マネージドクラスターは専用クラスターよりもコスト効率が優れています。

高い安定性およびセキュリティを必要とする大規模ワークロードには、ACK Pro マネージドクラスターをご利用ください。ACK Pro マネージドクラスターは、補償条項付きの SLA が適用され、信頼性、セキュリティ、およびスケジューリング能力が強化されています。「ACK Pro マネージドクラスターの概要」をご参照ください。

リソースリクエストおよび制限の構成

リソースリクエストおよび制限を正確に設定してください。過大なリクエストは容量を無駄にし、過小なリクエストはピーク時の不安定性を招くリスクがあります。これらの値を調整する際には、過去のコンテナ利用率データおよび負荷試験結果を活用してください。

リソースプロファイリングを活用すると、過去の使用データから推奨されるコンテナリソース仕様を生成できます。リソースプロファイリングにより、リソース設定のチューニングが簡素化され、全体的な利用率が向上します。「リソースプロファイリング」をご参照ください。

アプリケーションの進化に伴い、リソースリクエストおよび制限を継続的に見直してください。デプロイ時に正確であった設定が、時間の経過とともに陳腐化する可能性があります。

名前空間およびリソースクォータの管理

マルチテナントクラスターでは、異なるチームやワークロード間でリソースを分離するために名前空間を活用し、各名前空間ごとにリソースクォータを設定して消費量を制限してください。設定可能なクォータの種類には、CPU、メモリ、ストレージ、および Pod 数が含まれます。「名前空間およびリソースクォータの管理」をご参照ください。

ワークロードスケーリング

ノードスケーリング

ワークロードスケーリングに加えてノードスケーリングを有効化することで、クラスターのノードリソースが不足した際の Pod スケジューリング失敗を防止できます。ノードオートスケーリングとノードインスタントスケーリングのどちらを選択すべきかについては、「スケーリングソリューション：ノードオートスケーリングとノードインスタントスケーリング」をご参照ください。

動的リソースの過剰割り当て

Guaranteed および Burstable の Pod がクラスターを共有する場合、アプリケーション管理者は通常、ワークロードの変動を吸収するために各 Pod にリソースバッファーを構成します。これにより、リクエストされたリソースと実際のリソース使用量の間にギャップが生じます。動的リソースの過剰割り当てにより、この未使用容量を Best Effort（BE）Pod に再割り当てできます。

リソース冗長率を構成することで、どの程度のバッファーを保持するかを定義できます。冗長率を超えるリソースは、BE Pod に対して動的に利用可能になります。各ノードで過剰割り当て可能な量は、実際の使用状況に基づきリアルタイムで調整されます。ノードへの Pod スケジューリング時に、Best Effort（BE）Pod を優先させることも可能です。

Latency Sensitive（LS）Pod とリソース集約型の BE Pod が同一ノード上で共存するコロケーションシナリオでは、BE Pod のリソース過剰割り当てを構成することで、細かい粒度での CPU およびメモリ管理を実現できます。「動的リソースの過剰割り当ての有効化」および「はじめに」をご参照ください。

GPU 共有

単一の GPU 上で複数のコンテナを実行することで、GPU コストを削減できます。

利用可能なモードは以下の 2 種類です。

• 単一 GPU 共有：各 Pod が 1 つの GPU をリクエストし、そのリソースの一部を占有します。モデル推論シナリオに適しています。

• 複数 GPU 共有：各 Pod が複数の GPU をリクエストし、各 GPU から均等なリソース量を割り当てます。分散モデル開発およびトレーニングに適しています。

GPU 共有および分離ポリシーを構成できます。例えば、複数の Pod を 1 つの GPU にパッキングする、または GPU 間で分散させるなどです。「GPU 共有」をご参照ください。

Cost Insights の活用

Cost Insights を使用すると、指定されたコストガバナンスサイクル内におけるクラスター、部門、またはアプリケーションのリソース使用量およびコストを確認できます。この機能では、コストデータモデル を用いて、ACK における最小デプロイ単位である Pod のコストを推定し、総コストを業務部門に割り当てます。多次元ダッシュボードにより、過去の使用傾向を分析し、予期しない課金の原因を特定できます。「Cost Insights」をご参照ください。

アイドルリソースのスキャン

CPU、メモリ、ストレージ、ネットワークリソースなどのアイドルリソースを定期的にスキャンし、未使用の容量に対する課金を回避するために解放してください。

Cost Insights を使用してアイドル Pod を特定し、それに応じてリソース割り当てポリシーを調整してください。「課金方法および Pod の使用状況」をご参照ください。

ACK は、Elastic Compute Service (ECS) インスタンス、Elastic Block Storage (EBS) ボリューム、クラシックロードバランサー (CLB) インスタンス、EIP などのアイドル状態のクラスター関連リソースを検出するためのツールも提供しています。 詳細については、「アイドルリソースの最適化」をご参照ください。