需要に基づくダウンスケーリングのエリートレベルのパフォーマンス: ワークロード自動スケーリングの威力
Google Cloud Japan Team
※この投稿は米国時間 2023 年 10 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。
ワークロードを 4 分の 1 にスケールダウンできることは、確かに魅力的です。State of Kubernetes Cost Optimization（Kubernetes の費用最適化の現状）レポートによると、エリート パフォーマーはパフォーマンス レベルの低い同業者の 4 倍のスケールダウンが可能であることが判明しています。この優位性は、エリート パフォーマーが他のどのグループよりも既存の自動スケーリング機能を活用していることによるものです。
エリート パフォーマー グループは、需要に基づくダウンスケーリングはワークロードの自動スケーリング機能に大きく依存するため、リソースの適切な構成、モニタリング、意思決定が必要であることを理解しています。レポートによると、エリート パフォーマーは低パフォーマーと比較して、クラスタ自動スケーリング（CA）を 1.4 倍、水平 Pod 自動スケーリング（HPA）を 2.3 倍、垂直 Pod 自動スケーリング（VPA）を 18 倍活用しています。
ただし、これらのいずれかを有効にするだけでは不十分です。CA だけでは、オフピーク時にクラスタをスケールダウンできません。クラスタを自動スケーリングするには、HPA と VPA を備えたワークロード自動スケーリングを適切に構成する必要があります。このブログ記事では、ワークロード自動スケーリングの重要性の概要と、開発者やプラットフォーム管理者がそのメリットを活用するための大まかな手順をご説明します。
ステップ 1: CPU とメモリのリソース リクエストと上限を設定する
信頼性を確保し、スケールできるようワークロードを最適化するには、リソース リクエストと上限を設定することが重要です。このことは、ブログ投稿リソース リクエストの設定: Kubernetes の費用最適化への鍵でも強調されています。
リソースを適切に割り当てるには、リソース リクエストと上限の決め方を再検討します。リクエストには、アプリケーションが機能できる必要最小限の量ではなく、ワークロードで通常必要とされる量を反映させる必要があります。逆に、上限はスケーリング イベント中にワークロードを維持するために必要なリソースと見なします。
リソース リクエストが不足しているワークロードを特定するには、リスクのある GKE ワークロードのダッシュボードを参照します。HPA と CA でクラスタに弾力性をもたらすために必要となるため、リソース リクエストを設定することが重要です。
ステップ 2: 使用状況を確認するモニタリングを設定する
リソース リクエストと上限を決定したら、次のステップではワークロードの指標を観察するためのモニタリング ダッシュボードを設定します。Google Kubernetes Engine（GKE）の UI は、クラスタと個々のワークロードのオブザーバビリティ チャートを提供します。さらに、Cloud Monitoring では、ステップ 3 でご説明する VPA オブジェクトをデプロイしなくても、使用状況の指標と組み込みの VPA 推奨値を確認できます。事前定義されたダッシュボードを使用する場合でも独自にカスタマイズする場合でも、Cloud Monitoring では包括的なダッシュボードとアラートを作成できます。
ステップ 3: 推奨値と使用状況の指標を使用してワークロードのサイズを適正化する
ダウンスケールを効率的に行うには、クラスタのサイズを適正化する必要があります。先ほど設定したモニタリング ダッシュボードを利用することで、最適なリソース リクエストの値を正確に決定し、ワークロードの最大効率を確保することができます。ワークロードのサイズ適正化について詳しくは、以前の記事信頼性を最大化し、費用を最小化する: Kubernetes ワークロードのサイズ適正化をご覧ください。
ステップ 4: HPA と VPA のどちらの Pod 自動スケーリングを使うかを決める
ワークロードのスケーリング戦略を選択するには、まずそれぞれの目的を理解することが大切です。HPA は、Pod のパフォーマンスに合わせてレプリカ数を最適化する場合に適しています。一方、VPA は、リソースの使用率を最適化する場合に効果的です。HPA はピーク時でも需要に対処できるよう十分な量のリソースを確保しますが、VPA は貴重なリソースをオーバープロビジョニングしないようにしてアプリケーションを実行できるようにします。
HPA と VPA の両方を混在させることは可能ですが、一般的なガイドラインでは避けるべきとされています。このような組み合わせは不安定なスケーリング動作を誘発し、アプリケーションのダウンタイムとパフォーマンスと信頼性の関係が複雑になる恐れがあります。
ステップ 5: クラスタ オートスケーラーを有効にする
非ピーク時にスケールダウンできるワークロードが多ければ多いほど、CA でより巧みにノードを削除できます。
自動スケーリング プロファイルでは、使用率の最適化とリソースの可用性の確保のバランスを取りながら、ノードを削除するタイミングを決定します。使用率の低いノードを削除するとクラスタの効率性は高まりますが、リソースが再割り当てされるまで次のワークロードを一時停止しなければならない場合が生じる可能性があります。
この意思決定プロセスに適した自動スケーリング プロファイルを選択できます。利用可能なプロファイルは以下のとおりです。
- バランス重視: これはデフォルトのプロファイルで、キーノードを各ゾーンに分散させたい場合に適したオプションです。
- 使用率の最適化: このプロファイルは、余剰リソースを減らす代わりに使用率を最大化させようとします。これを選択すると、クラスタ オートスケーラーがより積極的に機能し、より速いペースでより多くのノードを削除します。
CA を使用した費用対効果の分析情報について詳しくは、コストが最適化された Kubernetes アプリケーションを GKE で実行するためのベスト プラクティスをご覧ください。
ステップ 6: GKE Autopilot を検討する
需要に基づくダウンスケーリングを効率的に管理することが目的の場合は、ワークロードを GKE Autopilot に移行することをご検討ください。Autopilot は、クラスタ インフラストラクチャ、コントロール プレーン、ノードの管理を処理することで、運用を容易にします。GKE Standard と GKE Autopilot のどちらを選択しても、リソース リクエストの設定から始まるステップ 1～4 は行う必要があります。ただし、Autopilot を使用するとお客様に代わってノードプールを管理するため、ステップ 5 を省略してプロセスを簡素化できます。
まとめ
この記事では、需要に基づく効率的なダウンスケーリングを促進する、ワークロード自動スケーリングの価値についてご紹介しました。リソース リクエストの設定からクラスタ オートスケーラーの有効化まで、最適なリソース配分を保証するためにさまざまな対策を講じることができます。この記事でご紹介した手順は、アプリケーション開発者、予算管理者、プラットフォーム管理者がワークロード スケーリングの最大化、費用削減、パフォーマンスの強化を行うための基盤となります。
クラスタをスケールダウンしようとする前に、適切なリソース リクエストを設定してユーザー エクスペリエンスを損なわないようにすることが重要であることにご注意ください。
State of Kubernetes Optimization（Kubernetes の費用最適化の現状）レポートをダウンロードして、主な調査結果をご確認ください。次回のブログ投稿をお楽しみに！
また、「State of Kubernetes Cost Optimization（Kubernetes の費用最適化の現状）」の主な調査結果を踏まえた他のブログ記事や本ブログ記事で言及した他のリソースもぜひご覧ください。
- リソース リクエストの設定: Kubernetes の費用最適化への鍵
- 信頼性を最大化し、費用を最小化する: Kubernetes ワークロードのサイズ適正化
- コストが最適化された Kubernetes アプリケーションを GKE で実行するためのベスト プラクティス
- ワークロードの大規模なサイズ適正化ソリューション ガイド
- シンプルな kube-requests-checker ツール
- 一連のサンプル ワークロードを使って GKE をセットアップするためのインタラクティブ チュートリアル
ー ソリューション アーキテクト Ameenah Burhan
