この記事では、スケーリング、インフラストラクチャのサイズ設定、GPU 使用率、マルチテナント、Azure割引全体で、Azure Kubernetes Service (AKS)の使用量とコストを最適化する実用的な方法について説明します。
ほとんどの運用ワークロードでは、AKS Automatic が推奨される開始点です。これは、運用環境対応の既定値を適用し、コア操作を自動化し、オーバープロビジョニングを減らすのに役立ちます。 より深いプラットフォームのカスタマイズが必要な場合、AKS Standard は適切な選択肢です。
この記事には、次の内容が含まれます。
最適化ベースラインを選択する
まず、コストと運用モデルに一致する AKS クラスター モードを選択します。
| シナリオ | 推奨されるクラスター モード | なぜでしょうか |
|---|---|---|
| 運用上のオーバーヘッドが少ない強力なコスト効率が必要なほとんどの運用ワークロード | AKS Automatic | 事前構成済みの運用対応の既定値、管理された操作、効率的なリソース割り当てにより、プラットフォームのチューニングに費やす無駄と時間を削減できます。 |
| 広範なカスタム クラスター構成、特殊なアドオン、または厳密なプラットフォーム制御を必要とするワークロード | AKS Standard | クラスターの構成と運用モデルを完全に制御します。 |
| Kubernetes 運用成熟度の初期段階にあり、迅速で予測可能なデリバリーに重点を置くチーム | AKS Automatic | チームがアプリケーションに集中できるように、プラットフォーム管理の複雑さを軽減します。 |
| 確立されたプラットフォーム エンジニアリング プロセスと特定のアーキテクチャ標準を持つチーム | AKS Standard | 高度なカスタマイズとカスタムの運用パターンをサポートします。 |
詳細については、Azure Kubernetes Service (AKS) Automatic とは?を参照してください。
AKS の自動コスト最適化の利点
AKS Automatic は、自動化によってコンピューティングの無駄を最小限に抑え、Kubernetes を実行する場合の運用オーバーヘッドを削減する 2 つの方法でコストを削減します。 次の表は、直接コストに影響を与える機能と、それらが AKS Standard とどのように比較されるかをまとめたものです。
事前構成済み 機能は常に有効になっており、変更することはできません。 既定 の機能はユーザーに合わせて構成されますが、調整できます。 オプション 機能は構成に使用でき、既定では有効になっていません。
| 特徴 | AKS Automatic | AKS Standard | コストの影響 |
|---|---|---|---|
| ノードの自動プロビジョニング (NAP) | 事前設定済み | オプション | 保留中のポッド用に適切なサイズのノードを自動的にプロビジョニングし、アイドル容量とオーバープロビジョニング容量を削減します。 |
| 水平ポッド オートスケーラー (HPA) | 事前設定済み | オプション | 手動による介入なしで需要に合わせてポッドをスケーリングし、トラフィックの少ないリソースの無駄を防ぎます。 |
| Kubernetes イベント ドリブン オートスケーラー (KEDA) | 事前設定済み | オプション | イベントドリブン スケーリングにより、処理を待機しているアイドル状態のレプリカが不要になります。 |
| 垂直ポッド オートスケーラー (VPA) | 事前設定済み | オプション | ポッド リソースの要求と制限は、時間の経過に伴う実際の使用量に基づいて自動的に適切なサイズに設定されます。 |
| ポッド ビンパッキング効率 | 事前設定済み | 手動チューニング | ポッドは、ノードの使用率を最大化するために効率的にビンパックされ、必要なノード数の合計を減らします。 |
| Managed Prometheus + Container Insights | デフォルト | オプション | 監視設定を必要とせずに、1 日目からすぐにコストを可視化できます。 |
| クラスターとノードの OS の自動アップグレード | 事前構成済み | 手動または省略可能 | アップグレード関連のエンジニアリングオーバーヘッドを排除し、パッチが適用されていないノードからのコストのかかるセキュリティ インシデントのリスクを軽減します。 |
| ノードの自動修復 | 事前設定済み | 事前構成済み | 手動による介入なしで、異常なノードからのダウンタイム コストを削減します。 |
| フル マネージド ノード リソース グループ | 事前設定済み | オプションのロックダウン | 予期しないコストが発生する可能性がある、偶発的または未承認のリソース変更を防ぎます。 |
| API サーバー稼働率 SLA（99.95%） | 含まれる | 有料 (Standard レベルのアップグレード) | 財政的にバックアップされたアップタイム保証を得るための追加コストはありません。 |
| ポッドの準備 SLA (5 分以内に 99.9%) | 含まれる | 該当なし | カスタムの信頼性投資なしで予測可能なスケーリング動作。 |
Note
HPA、KEDA、VPA などのスケーリング ツールは AKS Automatic で事前に構成されているため、チームはこれらの機能自体を構成する場合のセットアップ、テスト、およびメンテナンスコストは発生しません。 AKS Standard では、これらの各機能には手動構成と継続的なチューニングが必要です。
自動スケーリング
水平ポッドの自動スケーリング
水平ポッド オートスケーラー (HPA) は、リソースの需要を監視し、需要に合わせてポッドの数をスケーリングするようにワークロード リソースを自動的に更新します。 負荷の増加に対する応答は、より多くのポッドをデプロイするためです。 負荷が減少し、ポッドの数が構成されている最小値を超える場合、自動スケーラーはワークロード リソースにスケールダウンを指示します。
Metrics API は 60 秒ごとに kubelet からデータを取得し、HPA は既定で必要な変更がないか 15 秒ごとに Metrics API をチェックします。 これは、HPA が 60 秒ごとに更新されることを意味します。 デプロイ用に HPA を構成する場合は、実行できるレプリカの最小数と最大数、およびスケーリングするタイミングを決定するために HPA が使用するメトリックを定義します。
Tip
AKS Automatic では、HPA は事前に構成されており、追加のセットアップなしで使用できます。 AKS Standard では、各ワークロードで HPA を手動で構成します。
詳細については、「AKS での ポッドの水平自動スケーリング と 自動スケーリング」を参照してください。
Kubernetes イベント駆動型自動スケーリング
Kubernetes イベントドリブン オートスケーラー (KEDA) は、イベントドリブン自動スケールをワークロードに適用します。 KEDA は HPA と連携し、上書きや重複なしで機能を拡張できます。
Tip
AKS Automatic では、KEDA はクラスターで事前に構成され、有効になっています。 AKS Standard では、KEDA アドオンを手動でインストールして構成します。
AKS 用の KEDA アドオンを使用して、アプリケーションをスケーリングし、 Azure KEDA スケーラーの豊富なカタログを活用できます。 詳細については、「 KEDA アドオンを使用したアプリケーションの自動スケーリング 」および 「AKS 用 KEDA アドオンのインストール」を参照してください。
ポッドの垂直自動スケーリング
Vertical Pod Autoscaler (VPA) は、過去の使用状況に基づいて、ワークロードあたりのコンテナーに対するリソース要求と制限を自動的に設定します。 VPA は、ポッドの CPU とメモリを解放して、AKS クラスターを効果的に使用できるようにします。 時間の経過と同時に、VPA はリソースの使用に関する推奨事項を提供します。
Tip
AKS Automatic では、VPA はクラスターで事前に構成され、有効になっています。 AKS Standard では、VPA を手動で有効にして構成します。
詳細については、「 Azure Kubernetes Service (AKS) での垂直ポッドの自動スケーリング」および「Azure Kubernetes Service (AKS)での垂直ポッド オートスケーラー (VPA) の使用」を参照してください。
クラスターの適切なサイズ設定
クラスターのサイズを適切に設定する
コストとパフォーマンスを最適化するためにクラスターのサイズを適切に設定します。 アプリケーションのニーズに合わせてノードを追加または削除して、クラスターのサイズを手動で変更します。 また、クラスターを自動スケーリングして、需要の変化に応じてノードの数を自動的に調整することもできます。
Tip
AKS Automatic では、Managed Prometheus と Container Insights が既定で有効になるため、1 日目からリソース使用率をすぐに把握できます。 AKS Standard では、可観測性を個別に設定します。 早い段階で可視化できれば、過剰プロビジョニングの兆候が継続的な無駄として積み重なる前に対処できます。
詳細については、「 Azure Kubernetes Service (AKS) クラスターのサイズ変更」を参照してください。
クラスターの自動スケール
クラスター オートスケーラーを使用すると、リソースの使用状況と制約に基づいてノード プールを自動的にスケーリングできます。 たとえば、保留中のポッドをスケジュールするようにスケールアップしたり、スケールダウンして未使用ノードのコストを削減したりします。 クラスター オートスケーラー プロファイルは、クラスター オートスケーラーの動作を制御するために微調整できるパラメーターのセットです。
詳細については、「 Azure Kubernetes Service (AKS) でのクラスター自動スケールの概要」および「Azure Kubernetes Service (AKS)でのクラスター オートスケーラーの使用」を参照してください。
ノードの自動プロビジョニング
Karpenter に基づくノード自動プロビジョニング (NAP) では、保留中のポッド用に適切なサイズのインフラストラクチャがプロビジョニングされ、ビンパッキングの効率が向上します。
- AKS 自動では、ノードの自動プロビジョニングはマネージド エクスペリエンスの一部です。
- AKS Standard では、カスタム クラスター モデルでこの機能が必要な場合は、ノードの自動プロビジョニングを使用できます。
詳細については、「Azure Kubernetes Service (AKS)でのノードの自動プロビジョニング」を参照してください。
GPU の最適化
GPU のパーティション分割と共有
GPU パーティション分割は、複数のワークロード間で GPU を分割または共有することで、過小使用に対処するのに役立ちます。 以降のセクションでは、AKS で GPU をパーティション分割および共有するさまざまな方法について説明します。
タイム スライシング
NVIDIA GPU オペレーターは、Kubernetes クラスター内の GPU のタイム スライスを有効にします。 タイム スライスを使用すると、システム管理者は GPU のレプリカのセットを定義できます。各 レプリカ は、管理者がワークロードを実行するポッドに個別に配布できます。 クラスター全体の既定のタイム スライス構成とノード固有の構成を適用できます。
詳細については、「 Kubernetes のタイム スライス GPU」を参照してください。
マルチプロセス サービス (MPS)
1 つのプロセスで、GPU で使用可能なすべてのメモリとコンピューティング帯域幅の容量が使用されない場合があります。 マルチプロセス サービス (MPS) を使用すると、ワークロード間でメモリとコンピューティング リソースを論理的にパーティション分割できます。 また、異なるプロセスからのカーネル操作と memcopy 操作を GPU 上で重複させることもできます。 MPS は、GPU 使用率の向上と実行時間の短縮に役立ちます。
詳細については、「 マルチプロセス サービス (MPS)」を参照してください。
マルチインスタンス GPU (MIG)
マルチインスタンス GPU (MIG) を 使用すると、NVIDIA Ampere 以降のアーキテクチャに基づいて GPU を CUDA アプリケーション用の個別のセキュリティで保護された GPU インスタンスにパーティション分割できます。
詳細については、「MIG を 使用した GPU オペレーター」 および 「Azure Kubernetes Service (AKS) でのマルチインスタンス GPU ノード プールの作成」を参照してください。
マルチテナンシー
マルチテナントとは、テナント、チーム、およびビジネス ユニット間でのインフラストラクチャの共有を指します。 次の表は、AKS でマルチテナントを実装するさまざまな方法の概要を示しています。
| マルチテナントの種類 | マルチテナント レベル | クラスター ポッドの密度 | コストの割り当て | 理想的なユース ケース | 潜在的なリスク |
|---|---|---|---|---|---|
| 専用クラスター | ハード マルチテナント | 下 | 最も簡単 | 完全なセキュリティ分離境界と簡単なコスト割り当て | • クラスターが大規模に拡散すると、管理オーバーヘッドコストが増加する • ポッド密度が低く、リソースが過剰にプロビジョニングされている |
| 専用ノード プール | ソフト マルチテナント | 中程度 | 中程度 | 中程度のポッド密度 | • テナント間の信頼が必要 • ネットワーク ポリシー、クォータ管理、ロールベースのアクセス制御 (RBAC) などの追加のクラスター構成が必要です。 |
| 専用名前空間 | ソフト マルチテナント | より高い | より難しい | リソース使用率を最大化するためのインフラストラクチャの共有 | • 既定では、敵対的な環境では安全ではありません • ネットワーク ポリシー、クォータ管理、ロールベースのアクセス制御 (RBAC) などの追加のクラスター構成が必要です。 |
専用クラスター
専用クラスター マルチテナントでは、クラスターは 1 つのワークロードまたはチーム専用です。
次の表は、専用クラスターの使用の長所と短所の概要を示しています。
| 利点 | デメリット |
|---|---|
| •より簡単な分離方法 •簡単なコストの割り当てとチャージバック • テナントが互いを信頼しない場合に適しています (多くの場合、セキュリティとリソース共有の観点から)。 |
• 高い管理と財務オーバーヘッド • 一般的にポッド密度が低く、過剰に割り当てられたリソース |
専用ノード プール
専用ノード プールマルチテナントでは、クラスターは多くのテナントによって共有されます。
次の表は、専用ノード プールの使用の長所と短所を示しています。
| 利点 | デメリット |
|---|---|
| • 中程度のポッド密度 • 一部の共有インフラストラクチャ • 1 つのテナント専用のノード プールに Azure タグを適用する (タグはノードに伝達され、アップグレードによって保持されます) |
• テナント間の信頼が必要 • ネットワーク ポリシー、クォータ管理、ロールベースのアクセス制御 (RBAC) などの追加のクラスター構成が必要です。 |
専用の名前空間
専用名前空間マルチテナントでは、クラスターは多くのテナントによって共有され、名前空間は分離境界として機能します。
次の表は、専用名前空間を使用することの長所と短所の概要を示しています。
| 利点 | デメリット |
|---|---|
| • ポッド密度の向上 •最高のビン詰め • リソース使用率を最大化するためのインフラストラクチャの共有 |
• 既定では、敵対的な環境では安全ではありません • すべてのテナントを信頼できない場合は、追加のセキュリティ対策が必要です |
Azure の割引
さらに 1 ステップ節約するには、Azure の割引プラン、予約インスタンス、Azure ハイブリッド特典などの Azure 割引を利用します。
| Azure 割引の種類 | 詳細情報 |
|---|---|
| Azure の節約プラン | •1-3年の前払いコミットメント • 従量課金制と比較して最大 65% を節約 • 柔軟で、SKU ファミリやリージョンの制限なし • さまざまな SKU やリージョンのリソースと一貫したコストを伴うワークロードに最適 |
| 予約インスタンス | •1-3年の前払いコミットメント •従量課金制と比較して72% まで節約 • 特定の SKU ファミリとリージョンに制限 • 継続的に実行される安定したワークロードに最適 (予期しない SKU やリージョンの変更なし) |
| Azure ハイブリッドの利点 | • オンプレミスの Windows Server および SQL Server ライセンスを Azure に持ち込む • アクティブなソフトウェア アシュアランス (SA) または対象となるサブスクリプションを持つ対象のオンプレミス ライセンスを使用する |
関連するコンテンツ
AKS コストと AKS 自動の詳細については、次の記事を参照してください。