GKE ワークロードのサイズ適正化 - 提案から対処まで

※この投稿は米国時間 2022 年 5 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

Kubernetes のワークロードのサイズを適正化する方法にあまり詳しくない方にとって、嬉しいニュースです。本日 Google は、この複雑なタスクをサポートするための、すぐに使える完全組み込み型の機能をリリースします。これにより、Google Kubernetes Engine（GKE）でアプリケーションを実行する際に、最適化の機会を発見して、ワークロード固有のリソース リクエストに関する提案を把握できるエンドツーエンドのワークフローをご利用いただけるようになります。最も重要なのは、こうした推奨事項に数秒で対応できることです。

このワークロード最適化ワークフローを使えば、リソース浪費の最大の要因となりがちな Kubernetes のリソース リクエストの量と上限を確認しながら、アプリケーションのサイズを適正化できます。リソース リクエストを正しく構成することは、アイドル状態のクラスタと、実際のリソース使用量に応じてダウンスケールされたクラスタとの違いを生み出します。

GKE の初心者ならば、サイズ適正化ツールが推奨するリソース リクエスト設定に従うことで時間と費用を節約できます。GKE ですでにワークロードを実行している場合は、既存するデプロイメントの最適化の機会を迅速に評価するためにこの機能を使うこともできます。

もう一歩進んで、ワークロードをさらに最適化するには、この新しいワークロード サイズ適正化機能を GKE Autopilot と組み合わせてください。GKE Autopilot の料金は、Pod リソース リクエストの量に基づいて決まります。GKE Autopilot を使用すると、Pod リソース リクエスト量の最適化（必要最低量を上回っていた場合）の結果が請求内容に直接反映されます。

また、実際の使用量の推移に基づいて、個々の対象ワークロードのリソース リクエストに関する推奨事項を提供する Cloud Monitoring 用の新しい指標も導入されます。

GKE によるシームレスなワークロードのサイズ適正化

この画面にはワークロードの実際の使用量が表示され、リソース リクエスト量が少ないために信頼性またはパフォーマンスに影響を及ぼすリスクを持つ、サイズ不足の可能性があるワークロードのシグナルを確認できます。

しかし、これらのアプリケーションのサイズを適切に適正化するというステップへ進めることは、特に規模が大きい場合には簡単ではありませんでした。この課題も、GKE の新しいサイズ適正化機能を使えば解決できます。

まず、最適化するワークロードを選びます。通常は、リソース リクエストの量および上限と、実際の使用量との差が大きいものが候補として適しています。GKE ワークロード コンソールの [費用の最適化] タブで、明るい緑色が多く表示されているワークロードがこれに該当します。

ワークロードを選んだら、ワークロードの詳細に移動して [アクション] => [スケール] => [リソース リクエストを編集] を選択し、詳細な最適化手順のガイドを確認します。

表示されるガイドの内容は、新しい「推奨されるレプリカあたりのリクエストコア数」と「推奨されるレプリカあたりのリクエスト バイト数」の指標（Cloud Monitoring で確認できるものと同じ指標）によって大きく変わります。これらの指標はいずれも実際のワークロード使用量に基づいています。対象の GKE デプロイメントごとにこのビューにアクセスでき、ご自身で何かを構成する必要はありません。

対象のデプロイメントに最適な値を確認したら、GKE コンソールでリソース リクエストの量と上限を直接編集できます。編集内容はワークロードに直接適用されます。

注: 提案内容はワークロードの実測使用パターンに基づいたもので、ご自身のアプリケーションに最適ではない可能性があります。また、それぞれのケースで特殊なケースや固有のニーズがある可能性もあります。総合的なチェックを行って、固有のワークロードに最適な値を把握することをおすすめします。

注: Java ワークロードによるメモリの使用状況は可視性が制限されているため、JVM ベースのワークロードではメモリに関する推奨事項はサポートされていません。

必要に応じてリソース リクエストの量と上限を GKE コンソール以外で設定する場合は、推奨される設定の YAML ファイルを生成してデプロイメントの構成に使用することもできます。

注: 水平 Pod 自動スケーリング（HPA）が有効になっているワークロードでは、HPA が構成されている指標と同じ指標の推奨値は提案されません。たとえば、ワークロードで CPU 向けの HPA が構成されている場合、メモリに関する提案のみが表示されます。

特定のワークロードの適格性および HPA などの他のスケーリング メカニズムとの互換性について詳しくは、機能に関するこちらのドキュメントをご確認ください。

GKE Autopilot とワークロードのサイズ適正化で効率性をレベルアップ

GKE Autopilot が GKE における重要な費用最適化メカニズムであることについては、これまでに何度もお伝えしてきました。GKE Autopilot は、ノードプールや VM 単位での最適化の必要性を排除するフルマネージドのインフラストラクチャ ツールです。そのため、稼働中の VM や、不要なリソースによる無駄、Day 2 運用の取り組みなどに関連するビンパッキング最適化の問題をなくすことができます。

GKE Autopilot では、リクエストしたリソースに対して課金されます。リソース リクエストの最適化が主な目的である、ワークロードのサイズ適正化と組み合わせることで、最適化の落とし穴になり得る 3 つの大きな問題のうち 2 つ（アプリのサイズ適正化とビンパッキング）に簡単に対処できるようになります。GKE Autopilot で対象ワークロードを実行してリソース リクエストを改善することで、すぐに直接的なプラスの影響が請求内容に現れてくるはずです。

GKE 最適化に役立つサイズ適正化指標などのリソース

新たな最適化の機会に注目している方や、GKE をもっと最適に実行するために使えるさまざまな機能をまとめて確認したい方は、コストが最適化された Kubernetes アプリケーションを GKE で実行するためのベスト プラクティスをご覧ください。GKE コスト最適化の YouTube シリーズや、オーバープロビジョニングを削減するための GKE のベスト プラクティスもおすすめです。

- GKE ソフトウェア エンジニア Karol Gołąb
- GKE プロダクト マネージャー Roman Arcea