クラスタコストの最適化は、クラスタリソースを経済的かつ効率的に使用し、不要な費用を削減することを目的としています。このトピックでは、クラスタコストを最適化し、ワークロードの安定性と信頼性、クラスタの安定性と信頼性、およびクラスタの維持にかかる費用をバランスさせるためのベストプラクティスを紹介します。これらのベストプラクティスを読んだ後、低コストでクラスタを構成する方法、ワークロードとノードのスケーリング機能を使用する方法、およびクラスタコストをリアルタイムで監視する方法を学習します。
このトピックについて
このトピックは、Container Service for Kubernetes (ACK) クラスタの管理者を対象としています。このトピックでは、クラスタコスト削減に関する一般的な提案を提供します。このトピックの提案は特定の順序でソートされていません。ビジネス要件に基づいて提案を選択して適用できます。このトピックを読む前に、次の Kubernetes 用語について学習することをお勧めします。ポッドとコンテナのリソース、名前空間、自動スケーリング (ワークロードスケーリング と ノードスケーリング)、および スケジューリング。
ACK クラスタにデプロイされたアプリケーションの安定性を確保するために、「HA クラスタを作成するための推奨構成」および「推奨ワークロード構成」のトピックで提案されている構成を組み合わせることをお勧めします。
クラスタが ACK Pro マネージドクラスター で、500 を超えるノードまたは 10,000 を超えるポッドを含む場合、「大規模クラスタの使用に関する推奨事項」トピックのガイドに従うことをお勧めします。
このトピックは、FinOps システムとチームを構築し、FinOps 戦略目標を設定するのに役立ちます。FinOps は「Finance + DevOps」の略です。これは、企業のクラウド財務管理のための文化と実践の組み合わせです。 FinOps は、企業がクラウドリソースのコストを見積もり、クラウドリソースの使用を透過的にするのに役立ちます。 FinOps は、ビジネス開発とイノベーションを促進するために、コストを効率的に制御および最適化できます。詳細については、「コストスイート」をご参照ください。
低コストでクラスタを構成する
クラスタをデプロイする前に、クラスタにデプロイされるアプリケーションのリソース需要を評価し、適切なインスタンスタイプとクラスタの課金方法を選択して全体的なコストを削減します。
適切な ECS インスタンスタイプを選択する
ノードプールにインスタンスタイプを選択する場合、安定性と費用対効果を確保するために、パフォーマンス、価格、およびワークロードの要素を考慮する必要があります。ほとんどの場合、高仕様 (CPU およびメモリ仕様) の Elastic Compute Service (ECS) インスタンスタイプ、または特定のセクターに特化した ECS インスタンスタイプ (GPU インスタンスや異種インスタンスなど) は高価格で提供されます。
ビジネスシナリオに基づいてインスタンスタイプを選択する
ビジネスシナリオに基づいて、最も費用対効果の高いインスタンスタイプを選択します。たとえば、分散キャッシングシナリオでは、通常、メモリ負荷の高いアプリケーションが使用されます。他のインスタンスタイプと比較して、vCPU とメモリの比率が 1:8 のメモリ最適化インスタンスタイプは、CPU 使用率を効率的に向上させ、コストを削減できます。ディープラーニングのシナリオでは、ディープラーニングタスクには通常、大量の GPU リソースが必要であり、データの前処理と I/O 操作を実行するために CPU リソースも占有します。したがって、推奨される GPU と vCPU の比率は 1:8 から 1:12 です。 ECS インスタンスタイプの選択に関する推奨事項の詳細については、「ACK クラスタの ECS 仕様の選択に関する推奨事項」をご参照ください。
リソースのボトルネックとリソースの断片化を避けるために、本番環境では低仕様のインスタンスタイプ (2 vCPU、4 GB 以下のメモリを搭載したインスタンスタイプなど) を使用しないことをお勧めします。詳細については、「ACK クラスタの ECS 仕様の推奨事項」をご参照ください。
共有インスタンスファミリを使用する
個人の開発者である場合、または小規模または中規模の Web サイトアプリケーションを構築する場合、共有インスタンスファミリを使用することをお勧めします。エンタープライズレベルのインスタンスファミリと比較して、共有インスタンスファミリはパフォーマンスの変動を引き起こす可能性があります。したがって、共有インスタンスファミリの価格は低くなります。共有インスタンスファミリは、中小規模の Web サイト、Web アプリケーション、開発環境、軽量データベース、および軽量エンタープライズクラスアプリケーションに適しています。
共有インスタンスファミリの紹介とインスタンスタイプの選択方法の詳細については、「共有インスタンスファミリ」をご参照ください。
適切な課金方法を選択する
ビジネスの種類によって、リソースのライフサイクルに対する要件が異なります。コストを最適化するには、適切な課金方法を選択する必要があります。
サブスクリプション
サブスクリプション課金方法を使用すると、割引価格でリソースを継続的に使用できます。ビジネスに次の特性がある場合は、サブスクリプション課金方法を使用することをお勧めします。
予測可能なリソースライフサイクル。
変動のない安定したワークロード。
長期的なリソース需要。
たとえば、Web サービスまたはデータベースサービスを継続的に提供するには、サブスクリプション課金方法を使用することをお勧めします。
従量課金
従量課金は柔軟な課金方法であり、実際に使用したリソースに対して料金を支払うことができます。事前に大量のリソースを購入する必要はありません。従量課金リソースは、セルフマネージドデータセンターよりも費用対効果が高くなります。ビジネスに次の特性がある場合は、従量課金方法を使用することをお勧めします。
ワークロードが定期的に変動するか、トラフィックが時折急増します。リソース需要を予測することは困難です。
リソース需要が変動します。リソースを頻繁にデプロイおよびリリースする必要があります。
たとえば、テスト、ビジネス開発、または e コマースのプロモーションイベントのためにワークロードを一時的に拡張するには、従量課金方法を使用することをお勧めします。
プリエンプティブルインスタンス
プリエンプティブルインスタンスは、価格がリアルタイムの在庫に基づいて変化する従量課金インスタンスです。通常の従量課金インスタンスと比較して、プリエンプティブルインスタンスは総コストを 90% 削減するのに役立ちます。ただし、プリエンプティブルインスタンスは、期限切れになった後いつでも回収される可能性があります。したがって、プリエンプティブルインスタンスは、バッチ処理や機械学習ワークロード、ビッグデータ ETL (抽出、変換、書き出し) ジョブ (Apache Spark など)、キューに入れられたトランザクション処理アプリケーション、REST API を使用するアプリケーションなど、フォールトトレランス機能が強力なステートレスワークロードにのみ適しています。プリエンプティブルインスタンスは、長期的なビジネスや高い安定性を必要とするアプリケーションには適していません。詳細については、「プリエンプティブルインスタンスベースのノードプールのベストプラクティス」をご参照ください。
節約プランを使用する
長期的なビジネスに ECS インスタンスまたはエラスティックコンテナインスタンスを使用する必要がある場合は、節約プランを購入して大きな割引を受けることができます。節約プランを使用すると、1 年、3 年、または 5 年以内に特定の支払額をコミットすることで、割引された従量課金価格を利用できます。詳細については、「節約プランの概要」および「節約プランの購入と適用」をご参照ください。
クラスタに適したリージョンを選択する
ECS インスタンスの価格は、リージョンによって異なる場合があります。ほとんどの場合、クラスタがユーザーに近いリージョンにデプロイされている場合、ユーザーはネットワークレイテンシの短縮と転送速度の向上を実現できます。ビジネスが高いネットワークレイテンシを許容できる場合は、インスタンス価格が低いリージョンにクラスタをデプロイできます。さまざまなリージョンにおける ECS インスタンスの価格の詳細については、Elastic Compute Service をご参照ください。
使用する ACK マネージドクラスター
ACK マネージドクラスター のコントロールプレーンは、ACK によって作成およびホストされます。ワーカーノードを作成するだけで済みます。コントロールプレーン (マスターノード) を管理したり、そのリソース料金を支払う必要はありません。したがって、ACK マネージドクラスターは、ACK 専用クラスター と比較して費用対効果が高くなります。
大規模なビジネスを実行する場合、ビジネスに高い安定性またはセキュリティが必要な場合は、ACK Pro マネージドクラスター を使用することをお勧めします。ACK Pro マネージドクラスター は、補償条項を含む SLA の対象となり、強化された信頼性、セキュリティ、およびスケジューリング機能を提供します。詳細については、「クラスター」をご参照ください。
ワークロードのリソース割り当てを最適化する
適切なリソースリクエストと制限を構成する
リソースリクエストと制限を適切に構成する必要があります。リソースリクエストと制限が高すぎるとリソースが浪費され、リソースリクエストと制限が低すぎるとピーク時にクラスタの安定性が損なわれる可能性があります。ほとんどの場合、コンテナの履歴リソース使用率やアプリケーションのストレステスト結果などの統計を参照して、アプリケーションの安定性レベルとリソース使用率レベルを評価できます。これにより、コンテナの状態に基づいてリソース割り当てを調整できます。
リソースプロファイリングで提案されているリソース構成を使用することをお勧めします。リソースプロファイリングは、クラスタ内の履歴リソース使用データ分析して、推奨されるコンテナリソース仕様を生成します。リソースプロファイリングは、リソースリクエストと制限設定の複雑さを軽減するだけでなく、コンテナごとにリソース仕様を設定してリソース使用率を向上させることもできます。詳細については、「リソースプロファイリング」をご参照ください。
名前空間とリソースクォータを管理する
マルチテナントシナリオでは、さまざまなビジネスまたはチーム向けにさまざまな名前空間にアプリケーションをデプロイする必要がある場合があります。名前空間を作成してリソースを分離し、さまざまな名前空間にリソースクォータを設定して、各アプリケーションまたはチームが使用できるリソースの量を制限できます。名前空間の CPU、メモリ、ストレージ、およびポッドクォータを構成できます。詳細については、「名前空間とリソースクォータの管理」をご参照ください。
適切なスケーリング機能を使用する
ワークロードの変動が大きい場合は、ビジネス要件に基づいて自動スケーリングを構成することをお勧めします。自動スケーリングを使用すると、ピーク時にポッドを迅速にスケールアウトしてトラフィックの急増に対応し、オフピーク時にポッドをスケールインしてリソースコストを削減できます。ピーク需要に基づいてリソースを構成および支払うことなく、実際に使用したリソースに対してのみ料金を支払う必要があるため、クラスタコストが大幅に削減されます。
ワークロードスケーリング: このスケジューリングレイヤーソリューションは、ワークロードの変化に基づいてポッドの数またはポッドに割り当てられるリソースの量を動的に調整することにより、ポッドレベルで動作します。たとえば、HPA は、トラフィックの変化に基づいてアプリケーションポッドの数を自動的に調整し、現在のワークロードによって占有されるリソースの量をさらに調整できます。
コンピューティングリソースのスケーリング: このリソースレイヤーソリューションは、ノードスケーリング と仮想ノードスケーリングで構成されます。このソリューションを使用して、ポッドのスケジューリング結果とリソース使用量に基づいて、アプリケーションに割り当てられるリソースの量を増減できます。
ワークロードスケーリング
ソリューション | 説明 |
HPA は、CPU 使用率、メモリ使用率、またはカスタムメトリックに基づいてポッドを自動的にスケーリングします。 HPA は、ピーク時にポッドをスケールアウトしてトラフィックの急増に対応し、オフピーク時にポッドをスケールインしてリソースコストを削減できます。 HPA は、多数のサービスをデプロイし、変動の大きいワークロードのリソースを頻繁にスケーリングする必要があるシナリオに適しています。 アプリケーションの安定性を確保するために、HPA を構成する際には次の項目に注意することをお勧めします。
| |
CronHPA は、crontab のようなポリシーに基づいてリソースを定期的にスケーリングします。 CronHPA は、スケジュールされた時刻にタスクを実行したり、トラフィックの急増に対応したりする必要があるシナリオに適しています。 CronHPA を構成する際には、アプリケーションの安定性を確保するために次の項目に注意することをお勧めします。
| |
VPA は、ポッドの履歴リソース使用データに基づいて推奨される CPU およびメモリ仕様を生成し、リソース需要を満たすようにリソース構成を調整します。 VPA は、安定したリソース供給を必要とするステートフルアプリケーションに適しています。 VPA を構成する際には、アプリケーションの安定性を確保するために次の項目に注意することをお勧めします。
| |
AHPA は、アプリケーションの履歴リソース統計を分析することにより、スケーリングサイクルを自動的に識別し、必要なリソース容量を推定し、ポッドを動的にスケールアウトして、トラフィックの急増が発生する前にリソースがプロビジョニングされるようにします。さらに、AHPA は、オフピーク時にポッドを迅速にスケールインできます。 AHPA を構成する際には、アプリケーションの安定性を確保するために次の項目に注意することをお勧めします。
| |
KEDA は、Kafka、MySQL、PostgreSQL、RabbitMQ、MongoDB などのイベントソースからイベントを定期的に消費し、それに応じてリソースをスケーリングします。 KEDA は、ビデオ/オーディオのオフライン トランスコード中、イベント駆動型ジョブ、およびデータストリーミングに適しています。 KEDA を構成する際には、アプリケーションの安定性を確保するために次の項目に注意することをお勧めします。
|
ノードスケーリング
ワークロードスケーリング 機能を使用する場合は、ノードリソースの不足が原因でポッドのスケジューリングエラーが発生した場合に備えて、ノードスケーリング を有効にすることをお勧めします。ノード自動スケーリング と ノードインスタントスケーリング のどちらを選択するかについては、「スケーリングソリューション: ノード自動スケーリングとノードインスタントスケーリング」をご参照ください。
ソリューション | 説明 |
現在の Container Service for Kubernetes (ACK) クラスタ内のリソースがポッドのスケジューリングを満たすことができない場合、ノード自動スケーリング を使用してノードを自動的にスケーリングできます。ノード自動スケーリング 機能は、スケーリング要件が限られているシナリオに適用されます。これには、自動スケーリングが有効になっているノードプールが 20 未満のクラスタ、またはノードプールあたりのノードが 100 未満のクラスタが含まれます。ノード自動スケーリングは、安定したトラフィックパターン、定期的または予測可能なリソース需要、および単一バッチスケーリングがビジネス要件を満たす操作に最適です。 ノード自動スケーリング を構成する際には、アプリケーションの安定性を確保するために次の項目に注意することをお勧めします。
| |
ノード自動スケーリング と比較して、ノードインスタントスケーリング を使用すると、クラスタを大規模に、またはより速いペースでスケーリングできます。この機能により、開発者の技術スキル要件が軽減され、リソーススケーリング効率が向上し、手動 O&M 作業の必要性が軽減されます。 ノードインスタントスケーリング には一定の制限があります。詳細については、「ノードインスタントスケーリングの制限」をご参照ください。 | |
ACK クラスタを使用する場合、短期間で多数のポッドを起動する必要がある場合があります。ポッド用に ECS インスタンスを作成することを選択した場合、作成プロセスに時間がかかる場合があります。 ECS インスタンスを予約することを選択した場合、インスタンスはポッドの作成前とポッドの終了後にアイドル状態になり、リソースが浪費されます。 ACK 仮想ノードを作成して、ポッドをエラスティックコンテナインスタンスにすばやくスケジュールできます。このようにして、ECS インスタンスを購入または管理する必要はありません。詳細については、「仮想ノードスケジューリングとソリューション比較の紹介」および「ポッドをエラスティックコンテナインスタンスにスケジュールする」をご参照ください。 |
ポッドスケジューリングを最適化する
動的リソースオーバーコミットメント
QoS クラスが Guaranteed および Burstable のポッドがクラスタ内に共存している場合は、動的リソースオーバーコミットメントを構成して、割り当てられているが使用されていないリソースを使用できます。
ACK クラスタのアップストリームサービスとダウンストリームサービスのワークロード変動を処理するために、アプリケーション管理者は通常、Guaranteed または Burstable ポッドごとにリソースバッファを構成する必要があります。その結果、使用されるリソースの量は、リクエストされたリソースの量よりもはるかに少なくなります。割り当てられているが使用されていないリソースを使用するには、動的リソースオーバーコミットメントを構成してリソース使用率を向上させることができます。
動的リソースオーバーコミットメントを使用すると、リソース冗長率を定義して、冗長率を超えるリソースを動的にオーバーコミットできます。ノードで動的にオーバーコミットできるリソースの量は、実際のリソース使用量に基づいて変化します。ポッドをノードにスケジュールするときに、Best Effort (BE) ポッドを優先できます。詳細については、「動的リソースオーバーコミットメントを有効にする」をご参照ください。
たとえば、コロケーションシナリオでは、Latency Sensitive (LS) ポッドとリソース負荷の高い BE ポッドをクラスタ内またはノード上にデプロイする必要があります。 LS ポッドの QoS 要件を満たすために、BE ポッドのリソースオーバーコミットメントを構成して、きめ細かい CPU およびメモリ管理を行うことをお勧めします。これにより、全体的なリソース使用率が向上します。詳細については、「はじめに」をご参照ください。
GPU 共有
GPU コストの最適化のために 1 つの GPU で複数コンテナを実行するには、GPU 共有を使用できます。
単一 GPU 共有と複数 GPU 共有が利用可能です。単一 GPU 共有モードでは、各ポッドが 1 つの GPU をリクエストし、GPU リソースの一部を占有します。このモードは、モデル推論シナリオに適しています。複数 GPU 共有モードでは、各ポッドが複数の GPU をリクエストします。各 GPU から同じ量のリソースが割り当てられます。このモードは、分散モデルの開発とトレーニングに適しています。 GPU 共有と分離ポリシーを構成することもできます。たとえば、複数のポッドが優先的に 1 つの GPU を使用するか、複数の GPU にポッドを分散するように構成できます。詳細については、「GPU 共有」をご参照ください。
リソースとコストの監視を設定する
コストインサイト機能を使用して、部門またはアプリケーションのコストを監視する
IT 支出管理者は通常、クラスタリソースの使用状況と、さまざまなディメンションからのリソースコストの変化の傾向を把握する必要があります。これにより、リソースコストを削減し、リソース使用率を向上させることができます。 ACK クラスタによって提供されるコストインサイト機能を使用して、指定されたコストガバナンスサイクル内のクラスタ、部門、またはアプリケーションのコストとリソース使用量を表示できます。詳細については、「コストインサイト」をご参照ください。
ポッドは、ACK クラスタの最小デプロイ可能単位です。ポッドコストは、クラスタコストの計算における重要な要素です。ポッドによって、リソース仕様、スケジューリングポリシー、およびライフサイクルが異なる場合があります。したがって、ポッドのコストを見積もることは複雑です。コストインサイト機能は、コストデータモデル を使用して各ポッドのコストとコスト比率を見積もり、総コストをさまざまな業務部門に割り当てます。また、多次元コストダッシュボードを使用して、履歴リソース使用量とコストの詳細の傾向を分析し、予期しないコストの原因を特定することもできます。
アイドルリソースを定期的にスキャンする
ACK クラスタ内のアイドルリソース (CPU、メモリ、ストレージ、ネットワークリソースなど) を定期的にスキャンして解放し、リソースコストを削減できます。
また、コストインサイト機能を有効にして、ポッド内のアイドルリソースを表示し、原因を特定してから、リソース割り当てポリシーを最適化することもできます。詳細については、「課金方法とポッドの使用状況」をご参照ください。
ACK クラスタは、ECS インスタンス、Elastic Block Storage (EBS) リソース、Classic Load Balancer (CLB) インスタンス、およびエラスティック IP アドレス (EIP) などのクラスタ関連のアイドルリソースを特定するのに役立つ機能も提供します。詳細については、「アイドルリソースの最適化」をご参照ください。