ユーザー エクスペリエンスを損なうことなく Kubernetes の費用最適化に取り組む方法
Google Cloud Japan Team
※この投稿は米国時間 2023 年 10 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。
アプリケーションの成功は、アプリケーションが提供するユーザー エクスペリエンスにかかっています。ユーザー エクスペリエンスの向上が顧客満足度や長期的なエンゲージメントに直接結びついていることは周知の事実です。もちろん、費用最適化もアプリケーションの成功にとって重要です。Kubernetes 管理者とアプリケーション開発者は、費用最適化を図るために信頼性と費用のバランスを取ろうとします。しかし、Google による最新の State of Kubernetes Cost Optimization(Kubernetes の費用最適化の現状)レポートによると、費用最適化の取り組みで信頼性を軽視すると、ユーザー エクスペリエンスが損なわれる可能性があります。このレポートでは、費用最適化対策を考慮しながらユーザー エクスペリエンスを優先することが重要であると強調されています。
信頼性を考慮せずに費用最適化の取り組みを進めると、エンドユーザーのエクスペリエンスが損なわれる可能性があります
State of Kubernetes Cost Optimization report(Kubernetes の費用最適化の現状)
以前の投稿では、リソース リクエストの設定やワークロードの適正サイズなど、アプリケーションの最適化に必要な基本手順について説明しました。今回の投稿では、特に BestEffort または Burstable Quality of Service クラスの Pod を扱う際に、Kubernetes のスケジューリングがどのようにユーザー エクスペリエンスを損なう意思決定につながる可能性があるかを探っていきます。このブログ投稿を読めば、ユーザー エクスペリエンスに影響を与える主な要素と、それらの要素に優先順位を付ける方法についてより深く理解できるようになります。
多くのプラットフォーム管理者は、Kubernetes のスケジューリングを扱う際に費用を削減する方法を模索しています。不十分な情報に基づいて行動することと、ビンパッキング指標(十分に活用されていないノード)が原因でノードを積極的にスケールダウンすることの 2 つが典型的な行動として挙げられます。ただし、State of Kubernetes Cost Optimization レポートによると、多数の BestEffort Pod を持つクラスタでは通常、ビンパッキングが低くなります。この場合、クラスタをスケールダウンするという対応が適しているように思えます。ただし、そうすると BestEffort Pod がより頻繁に終了することになり、ユーザー エクスペリエンスに悪影響を与える可能性があります。
ユーザーの満足度がアプリケーションの成功の核心にあると認識することは極めて重要です。したがって、エンドユーザーのニーズを無視した費用最適化戦略は困難に直面する可能性が高く、すべての費用最適化の決定において信頼性を優先することが重要であるのは明らかです。
予測不可能な要素とそれがカスタマー エクスペリエンスに与える影響
BestEffort Pod と Burstable Pod は両方とも、リソース管理の柔軟性を提供します。ただし、特に BestEffort Pod と Burstable Pod が正しく構成されていない場合には、独自の課題が伴います。Kubernetes は、ノード プレッシャーにより Pod が突然終了した場合、その Pod に代わる新しい Pod を自動的に作成するため、それについてユーザーに明示的に警告しません。この動作は継続性を確保する一方で、根本的な問題を曖昧にする可能性があるため、プロアクティブなモニタリングが必要になります。
BestEffort Pod には次の特徴があります。
- 明示的なリソース リクエストと制限がないため、ノード内でノード プレッシャー プロセスが発生した場合に突然強制終了される可能性が最も高い。
- 予測不可能性により、ユーザー エクスペリエンスが損なわれる可能性がある。
一方、バースト可能な Pod の場合:
- 指定されたリクエストを超えて継続的に消費すると、突然強制終了されるリスクがある
- バースト可能な Pod による宣言されたリソース リクエストを頻繁に超過するため、リソース不足が発生し、ワークロード、特に BestEffort などのより低い QoS クラスのワークロードに悪影響を及ぼす可能性がある。
- 予測不可能性がユーザー エクスペリエンスを損なう可能性がある。
このため、必要最小限の信頼性レベルを持つワークロードのリソース リクエストを設定することが重要です。こちらをクリックすると、クラスタ内のリクエストを設定していないワークロードの数が表示されます。
スムーズなユーザー エクスペリエンスの実現に必要なリソースを見積もる
アプリケーションに必要なリソースを正確に見積もることは、特に最新のアプリケーションの動的な性質を考慮すると、困難な作業になる可能性があります。しかしながら、この推測にかかる労力を軽減するためのツールや機能があります。Google Kubernetes Engine(GKE)は、(ワークロードに VPA リソースをデプロイしていない場合でも)UI 内でワークロードに対する組み込みの垂直 Pod オートスケーラー(VPA)推奨事項を提供します。これを Cloud Monitoring と組み合わせることで、アプリケーションの実際のリソース使用状況に関する貴重な分析情報を得られます。さらに、より構造化されたアプローチを希望する場合は、ワークロードの適正化に関するブログ投稿で詳しく説明されているワークロードの推奨事項のエクスポートに関するガイドがあります。すべてのワークロードのリソース リクエストを確立して設定した後、使用パターンに基づいて必要なインスタンスの数を自動的に調整する水平 Pod オートスケーラーや、必要に応じてクラスタノードをスケールするクラスタ オートスケーラーなどのツールを使用して、環境をさらに調整してスケールできます。どちらのツールも、信頼性を優先しながらリソース割り当て管理を改善します。
モニタリングとアラートの設定は、高品質のエンドユーザー エクスペリエンスを維持するためのもう一つの重要な側面です。上述のリクエストされたリソースを使用してアプリケーションのパフォーマンス、リソース使用量、BestEffort ワークロード、バースト可能ワークロードを継続的に観察すると、貴重な分析情報が得られ、管理者は問題が拡大する前に積極的に対処できます。事前定義されたしきい値や異常なパターンに基づいて戦略的なアラートを設定することで、潜在的な問題が即座にチームに通知され、これを迅速に解決できます。GKE インタラクティブ ハンドブックは、クラッシュループしている Pod やスケジュール不能な Pod のモニタリングに役立つ事前構築されたビューを提供します。このプロアクティブなアプローチは、効果的なモニタリングとアラートの実践に基づいており、エンドユーザー エクスペリエンスの中断を完全に防止できない場合でも、最小限に抑えられます。基本的に、一貫したモニタリングとタイムリーなアラートは、ユーザーが期待するエクスペリエンスを保護するための最前線の防御策として機能します。
Kubernetes の費用最適化は、信頼性と費用のトレードオフであってはなりません。このブログ投稿で強調しているように、費用最適化の意思決定を行う際には、ユーザー エクスペリエンスを優先することが不可欠です。また、Kubernetes プラットフォーム管理者は、費用最適化を追求するために信頼性を軽視すべきではありません。適切なバランスを取るには、ワークロードのサイズを適切に設定し、適切に最適化されたリソース割り当てと信頼性機能を組み合わせて使用する必要があります。そうすることで、管理者は堅牢かつ持続可能な費用最適化策を確保し、長期的なエンゲージメントと成長を実現するユーザー エクスペリエンスを優先することができます。
クラスタをスケールダウンする前に、適切なリソース リクエストを設定することが重要であることに注意してください。また、State of Kubernetes Cost Optimization レポートをダウンロードして主な調査結果を必ずご確認ください。次回のブログ投稿をお楽しみに!
関連情報
- リソース リクエストの設定: Kubernetes の費用最適化への鍵
- 信頼性を最大化し、費用を最小化する: Kubernetes ワークロードのサイズ適正化
- ワークロードの大規模なサイズ適正化ソリューション ガイド
- シンプルな kube-requests-checker ツール
- 一連のサンプル ワークロードを使って GKE をセットアップするためのインタラクティブ チュートリアル
-ソリューション アーキテクト Ameenah Burhan