次の方法で共有

Azure Kubernetes Service (AKS) でのコストの最適化

  • [アーティクル]

コストの最適化とは、クラウド環境内の不要な費用を最小限に抑えながら、リソースの価値を最大化することです。 このプロセスには、コスト効率の高い構成オプションを特定し、ベスト プラクティスを実装することで、運用効率を向上させる方法が含まれます。 AKS 環境を最適化すると、パフォーマンス要件と信頼性要件を考慮しながら、コストを最小限に抑えることができます。

この記事では、次の内容について説明します。

  • 戦略的インフラストラクチャの選択。
  • 動的なライトサイジングと自動スケーリング。
  • Azure 割引を利用した大幅な節約の実現。
  • 包括的な監視と FinOps のプラクティス。

アプリケーション環境を準備する

SKU ファミリを評価する

デプロイの前に、アプリケーションのリソース要件を評価する必要があります。 小規模な開発ワークロードには、大規模な本番環境対応ワークロードとは異なるインフラストラクチャ ニーズがあります。 CPU、メモリ、ネットワークの容量構成の組み合わせは SKU のコスト効率に大きく影響しますが、次の仮想マシン (VM) の種類を検討してください。

SKU ファミリ 説明 ユース ケース
Azure スポット仮想マシン Azure Spot Virtual Machine ではスポット ノード プールが設定され、高可用性やサービス レベル アグリーメント (SLA) が保証されない単一の障害ドメインにデプロイされます。 スポット VM を使用すると、大幅な割引価格 (従量課金制の価格と比較して最大 90%) で未使用の Azure 容量を利用できます。 容量が Azure で再び必要になると、Azure インフラストラクチャはスポット ノードを削除します。 "開発環境とテスト環境、バッチ処理ジョブなどの中断を処理できるワークロード、柔軟な実行時間を持つワークロードに最適です。"
Ampere Altra Arm ベースのプロセッサ (Arm64) ARM64 VM は電力効率とコスト効率は高くなりますが、パフォーマンスが損なわれることはありません。 AKS での ARM64 ノード プールのサポートを使用すると、ARM64 Ubuntu エージェント ノードを作成でき、クラスター内で Intel と ARM のアーキテクチャ ノードを混在させることもできます。 これらの ARM VM は 動的でスケーラブルなワークロードを効率的に実行するように設計され、スケールアウト ワークロード用の同等の x86 ベースの VM よりも最大 50% 優れた価格パフォーマンスを実現できます。 "Web サーバーやアプリケーション サーバー、オープンソース データベース、クラウドネイティブ アプリケーション、ゲーム サーバーなどに最適です。"
GPU 最適化 SKU ワークロードの性質に応じて、コンピューティング、メモリ化、ストレージ、またはグラフィカル処理ユニット (GPU) を最適化した VM SKU の使用を検討してください。 GPU VM のサイズは、単一の GPU、複数の GPU、またはフラクショナル GPU で使用できる特別な VM です。 AKS 上の GPU 対応の Linux ノード プールは、グラフィックのレンダリング、大規模なモデル トレーニング、推論などのコンピューティング集中型ワークロードに最適です。

Note

コンピューティングのコストはリージョンによって異なります。 ワークロードを実行するためにより低コストなリージョンを選択する場合は、待機時間の潜在的な影響とデータ転送コストに注意してください。 VM SKU とその特性の詳細については、「Azure の仮想マシンのサイズ」を参照してください。

ストレージ オプションの確認

ストレージ オプションと関連するコストに関する考慮事項の詳細については、次の記事を参照してください。

クラスターのプリセット構成を使用する

適切な VM SKU、リージョン、ノード数、およびその他の構成オプションを選択することが困難なことがあります。 Azure portal のクラスターのプリセット構成はコスト効率とパフォーマンスが高いさまざまなアプリケーション環境で推奨構成を提供するため、この最初の課題を解消するのに役立ちます。 開発/テストプリセットは、新しいワークロードの開発や既存のワークロードのテストに最適です。 運用エコノミープリセットは、ワークロードで中断を許容できる場合にコスト効率よく運用トラフィックを提供するために最適です。 重要でない機能は既定でオフになり、プリセット値はいつでも変更できます。

マルチテナントを検討する

AKS では、柔軟にマルチテナント クラスターを実行してリソースを分離できます。 信頼性の高いマルチテナントの場合、"論理分離" を使用してチームと部署の間でクラスターとインフラストラクチャを共有できます。 Kubernetes の名前空間では、ワークロードとリソースの論理的な分離境界を形成します。 インフラストラクチャを共有すると、クラスター内のリソース使用率とポッド密度を改善しながら、クラスター管理のオーバーヘッドを削減できます。 AKS のマルチテナントの詳細と、これが組織のニーズに適しているかどうかを判断するには、「マルチテナントに関する AKS の考慮事項」と「マルチテナント用のクラスターの設計」を参照してください。

警告

悪意のあるマルチテナントの場合、Kubernetes 環境は完全に安全というわけではありません。 共有インフラストラクチャ上のテナントを信頼できない場合は、テナントが他のサービスのセキュリティに影響を与えないように追加の計画が必要です。

"物理分離" の境界を検討してください。 このモデルでは、チームまたはワークロードは独自のクラスターに割り当てられます。 トレードオフとして、管理コストと金銭的な負担が増えます。

クラウドネイティブ アプリケーションを構築する

できるだけリーンなコンテナーを作成する

リーンなコンテナーとは、コンテナー化されたアプリケーションのサイズとリソースのフットプリントを最適化することを指します。 基本イメージとして最小限の条件を設定し、必要な依存関係のみが含まれるようにしてください。 不要なライブラリとパッケージを削除してください。 コンテナー イメージを小さくすると、デプロイ時間を短縮し、スケーリング操作の効率を高めることができます。 AKS で成果物ストリーミングを使用すると、Azure Container Registry (ACR) からコンテナー イメージをストリーミングできます。 最初のポッドの起動に必要なレイヤーのみを取得するため、大きなイメージの取得時間を数分から数秒に短縮できます。

リソース クォータを適用する

リソース クォータを利用すると、開発チームまたは開発プロジェクト全体でリソースの予約と制限ができます。 クォータは特定の名前空間で設定し、コンピューティング リソース、ストレージ リソース、およびオブジェクト数を設定できます。 リソース クォータを定義すると、個々の名前空間が割り当てられたリソースを超える数のリソースを使用できなくなります。 リソース クォータは、チームがインフラストラクチャを共有しているマルチテナント クラスターに役立ちます。

クラスターの開始と停止を使用する

小さな開発/テスト クラスターをそのままにしておくと、不必要なコストが発生する可能性があります。 クラスターの開始と停止機能を使用して、常に実行する必要のないクラスターをオフにすることができます。 この機能によりすべてのシステム ノード プールとユーザー ノード プールが停止するため、追加のコンピューティング料金を支払う必要がなくなります。 クラスターを再度起動すると、クラスターとオブジェクトの状態は維持されます。

容量予約を使用する

容量予約を使用すると、任意の期間で Azure リージョンまたは可用性ゾーンのコンピューティング容量を予約できます。 予約が削除されるまで、予約容量は即時に使用できます。 既存の容量予約グループをノード プールに関連付けると、ノード プールに割り当てられた容量が保証され、コンピューティング需要が高い期間にオンデマンド価格が急増する可能性を回避できます。

環境と支出を監視する

Microsoft Cost Management を使用して可視性を高める

Microsoft Cost Management は、クラスター内外のコストに対するクラウドの予算作成、予測、可視性に役立つ幅広い機能セットを提供します。 支出の傾向を把握し、最適化の機会を特定し、アプリケーション開発者とプラットフォーム チームの間でアカウンタビリティを高めるには、適切な可視性が不可欠です。 AKS Cost Analysis アドオンを有効化すると、Azure コンピューティング、ネットワーク、ストレージのカテゴリ別に加え、Kubernetes コンストラクト別の詳細なクラスター コストの内訳を取得できます。

Azure Monitor

Container insights を使用してメトリック データを取り込む場合は、マネージド Prometheus に移行することをお勧めします。これにより、大幅なコスト削減を実現できます。 データ収集ルール (DCR) を使用して Container insights メトリックを無効化し、Azure Resource Manager、Azure CLI、Azure portal、Terraform を使用した構成をサポートするマネージド Prometheus アドオンをデプロイできます。

詳細については、「Azure Monitor のベスト プラクティス」と「Container Insights のコスト管理」に関するページを参照してください。

Log Analytics

コントロール プレーンのログについては、Log Analytics のコストを削減するために、不要なカテゴリを無効にするか、該当する場合は基本ログ API の使用を検討してください。 詳細については、「Azure Kubernetes Service (AKS) コントロール プレーン/リソース ログ」を参照してください。 データ プレーン ログ、またはアプリケーション ログの場合は、コスト最適化設定の調整を検討してください。

自動スケーリングを使用してワークロードを最適化する

ベースラインを確立する

自動スケーリング設定を構成する前に、Azure Load Testing を使用してアプリケーションのベースラインを確立できます。 ロード テストは、異なるトラフィック条件下でアプリケーションがどのように動作するかを理解し、パフォーマンスのボトルネックを特定するのに役立ちます。 ベースラインができたら、アプリケーションが予想される負荷を処理できるように自動スケーリング設定を構成できます。

アプリケーションの自動スケーリングを有効化する

ポッドの垂直自動スケーリング

実際の使用量よりも高い要求と制限により、ワークロードが過剰にプロビジョニングされ、リソースが無駄になることがあります。 これに対し、要求と制限が低すぎると、メモリ不足によるスロットリングとワークロードの問題が発生することがあります。 ポッドの垂直オートスケーラー (VPA) を使用すると、ポッドに必要な CPU リソースとメモリ リソースを微調整できます。 VPA は、手動設定や自動更新が可能なコンテナーの使用量の履歴に基づいて、CPU とメモリの要求と制限に推奨される値を提供します。 "リソースの需要が変動するアプリケーションに最適です。"

水平ポッドの自動スケーリング

ポッドの水平オートスケーラー (HPA) は、CPU やメモリの使用量などの観察したメトリックに基づいて、ポッド レプリカの数を動的にスケーリングします。 需要が高い期間には、HPA はスケールアウトすることで、ポッド レプリカを追加してワークロードを分散します。 需要が低い期間には、HPA はスケールインすることで、レプリカの数を減らしてリソースを節約します。 "リソースの需要が予測可能なアプリケーションに最適です。"

警告

同じ CPU メトリックやメモリ メトリックで VPA と HPA を使用しないでください。 この組合せでは、両方のオートスケーラーが同じメトリックを使用して需要の変化に対応しようとするため、競合が発生する可能性があります。 ただし、CPU やメモリに VPA を使用し、カスタム メトリックに HPA を使用すると、重複がなくなり、各オートスケーラーでワークロード スケーリングの別々の側面を対象にできます。

Kubernetes イベント ドリブン自動スケーリング

Kubernetes イベント ドリブン オートスケーラー (KEDA) アドオンを使用すると、アプリケーションの動作と連携するさまざまなイベント ドリブン メトリックに基づいてさらに柔軟にスケーリングできます。 たとえば、Web アプリケーションの場合、KEDA は受信 HTTP 要求トラフィックを監視し、ポッド レプリカの数を調整することで、アプリケーションの応答性を確保できます。 ジョブを処理する場合、KEDA はメッセージ キューの長さに基づいてアプリケーションをスケーリングできます。 すべての Azure スケーラーに対してマネージド サポートが提供されます。

インフラストラクチャの自動スケーリングを有効化する

クラスターの自動スケール

アプリケーションの需要に対応するために、クラスター オートスケーラーはリソースの制約のためにスケジュールできないポッドを監視し、それに応じてノード プール内のノード数をスケーリングします。 ノードに稼働中のポッドがない場合、クラスター オートスケーラーはノードの数をスケールダウンします。 クラスター オートスケーラーのプロファイル設定は、クラスター内のすべてのオートスケーラー対応ノード プールに適用されます。 詳細については、「クラスター オートスケーラーのベスト プラクティスと考慮事項」を参照してください。

ノードの自動プロビジョニング

複雑なワークロードでは、CPU とメモリの要件に対応するために、VM サイズ構成が異なる複数のノード プールが必要になることがあります。 複数のノード プール構成を正確に選択して管理すると、複雑さと運用上のオーバーヘッドが増えます。 ノードの自動プロビジョニング (NAP) は SKU の選択プロセスを簡素化し、保留中のポッド リソース要件に基づいてワークロードを最も効率的でコスト効果の高い方法で実行するための最適な VM 構成を決定します。

Note

スケーリングの追加のベスト プラクティスの詳細については、「Azure Kubernetes Service (AKS) の中小規模模のワークロードのパフォーマンスとスケーリング」と「Azure Kubernetes Service (AKS) の大規模なワークロードのパフォーマンスとスケーリングのベスト プラクティス」に関するページを参照してください。

Azure 割引を使用して節約する

Azure の予約

ワークロードが予測可能で、長期間存在する場合、リソース コストをさらに削減するために Azure 予約の購入を検討してください。 Azure 予約は 1 年間または 3 年間の期間で利用でき、コンピューティングの従量課金制の価格と比較して最大 72% の割引が適用されます。 予約は一致するリソースに自動的に適用されます。 "同じ SKU とリージョンで長期間稼働することが決定しているワークロードに最適です。"

Azure 節約プラン

一定した支出があるものの、SKU とリージョンで異なるリソースを使用するため、Azure 予約の利用が適していない場合は、Azure 節約プランの購入を検討してください。 Azure 予約と同様に、Azure 節約プランは 1 年または 3 年の期間で利用でき、特典スコープに含まれるすべてのリソースに自動的に適用されます。 SKU またはリージョンに関係なく、コンピューティング リソースに定額の 1 時間ごとの料金を支払うこと確約します。 "さまざまなリソースやさまざまなデータセンター リージョンを利用するワークロードに最適です。"

Azure ハイブリッド特典

Azure Kubernetes Service (AKS) 向けの Azure ハイブリッド特典を使用すると、追加コストなしでオンプレミス ライセンスの価値を最大化できます。 有効なソフトウェア アシュアランス (SA) または対象となるサブスクリプションを含む対象となるオンプレミス ライセンスを使用すると、低コストで Azure 上の Windows VM を取得できます。

FinOps を採用してコスト削減文化を構築する

財務業務 (FinOps) とは、財務上のアカウンタビリティにクラウドの管理と最適化を組み合わせた領域を指します。 これは、財務チーム、業務チーム、エンジニアリング チームの間の連携を促進することで、クラウド コストを把握して制御することに重点を置いています。 FinOps Foundation には、次のようないくつかの注目すべきプロジェクトがあります。

  • FinOps フレームワーク: FinOps を実践および実装する方法の運用モデルです。
  • FOCUS 仕様: すべての主要なクラウド プロバイダーのサービスにおけるクラウドの使用状況、コスト、課金データに関する技術仕様とオープン標準です。

次のステップ

コストの最適化は継続的で反復的な作業です。 詳細については、次の推奨事項とアーキテクチャのガイダンスを参照してください。