コンテンツに移動
Containers & Kubernetes

GKE の費用最適化の可能性をコンソールで探る

2021年10月18日
https://storage.googleapis.com/gweb-cloudblog-publish/images/GCP_Kubernetes_A.max-2600x2600.jpg
Google Cloud Japan Team

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

お使いの Google Kubernetes Engine(GKE)クラスタ数が 1 つなのか 1,000 あるのか、それが GKE Standard クラスタなのか、Autopilot なのか、そのインフラストラクチャを 1 人で専有しているのか、大きなチームの一員として作業しているのかに関係なく、クラスタをハイ パフォーマンスで低コストなものに最適化する方法を知ることは、GKE を活用するうえで非常に重要です。

Google ではこれまでに、オーバー プロビジョニングを減らすための GKE のベスト プラクティスについてさまざまなドキュメントを作成し、費用最適化のための GKE クラスタのモニタリングに関するガイドを発行してきました。本日は、こうしたリソースに記載されている知見の一部を GKE インターフェースに直接反映させた機能である、GKE 費用最適化インサイトのプレビューをご紹介します。この機能は、GKE クラスタとワークロードの費用とパフォーマンスの間で適切なバランスを取るのに役立ちます。

このリリースにより、課金対象であるクラスタとワークロードによるコンピューティング リソースの利用効率を直接把握できるようになります。GKE クラスタページとワークロード ページの両方にある新しい費用最適化タブでは、各クラスタと各ワークロードが使用またはリクエストしている CPU とメモリの量を表示したりフィルタリングしたりして、詳細を確認できます。また、クラスタページでは割り当て可能なリソースの合計量、ワークロード ページでは特定のコンピューティング リソースに設定したリソース制限を確認できます。データの可視化により、割り当てまたはリクエストしているリソース量と、実際に使用している量が不釣り合いになっている領域を迅速に特定できます。この情報を利用すれば、パフォーマンスを維持しつつ、リソースの割り当て量またはリクエスト量を適正化して費用を管理できます。    

リソース使用率と GKE の費用について

Google ユーザーと緊密に連携する中で、GKE ワークロードを効率よく処理するうえで重要な点が 4 つあることがわかりました。FinOps に向けた組織文化の変革、適切なビンパッキング、アプリのサイズ適正化、需要ベースのダウンスケーリングです。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_Understanding_resource_utilization_and_G.max-1300x1300.jpg
  • 組織文化の変革 - パブリック クラウドを導入している多くのチームは、GKE のような従量課金制プラットフォームを扱ったことがないため、リソース割り当てとアプリのデプロイ プロセスが費用にどのように影響を与えるかをよく理解していません。新しい GKE 費用最適化インサイトは、チームが費用とパフォーマンスの間に存在するビジネス上のトレードオフを評価するうえで役立ちます。

  • ビンパッキング - アプリを GKE ノードに圧縮する能力です。アプリをノードに効率的に圧縮するほど、節約額が大きくなります。実際の使用量に基づいて適切な量のリソースを割り当ておよびリクエストするようにすることで、アプリをノードに効率的に圧縮できます。

  • アプリのサイズ適正化 - クラスタにデプロイされているオブジェクトに対して適切なリソース リクエストとワークロードの自動スケーリング目標を構成する能力です。Pod に設定するリソースの量が正確であるほど、アプリがより確実に実行されるようになります。またほとんどの場合、クラスタの空き容量が大きくなります。

  • 需要ベースのダウンスケーリング - 需要が低い期間(たとえば夜間)の費用を節約するため、需要に合わせてクラスタをスケールダウンできるようにする必要があります。ただし、場合によっては排除できないワークロードがあることや、クラスタの構成に誤りがあるためにダウンスケールできないことがあります。

この 4 つの考慮すべき事項の詳細については、オーバー プロビジョニングを減らすための GKE のベスト プラクティスをご覧ください。

GKE 費用最適化インサイトの使用

GKE 費用最適化インサイトを使用すると、このような考慮すべき事項の一部またはすべてに、GKE コンソールからより簡単かつ直接的に対処できます。

たとえば、クラスタページ ビューでは、リソース使用率の概要を完全に把握し、割り当て可能リソース、リクエストしたリソース、使用したリソース間の関係、さらには実際に使用した CPU およびメモリ時間を簡単に可視化できます。

使用およびリクエストした CPU とメモリの指標からは、アプリのサイズ適正化によりメリットを受けられる可能性のあるクラスタを知ることができます。リソースのリクエスト量と割り当て可能量を比較すると、ビンパッキングを改善する機会を特定できます。また、クラスタのビンパッキングが GKE Autopilot クラスタによりどの程度自動的に行われているのかを把握すれば、ご自身とチームがアプリのサイズ適正化に専念できるようにもなります。このようなメリットがあるため、Autopilot クラスタの導入は、非効率的なビンパッキングが行われているクラスタを費用最適化する最速の方法となっています。  

CPU とメモリの合計時間をクラスタごとに確認できるため、ビンパッキングまたはサイズ適正化に関する問題をよりよく理解できます。同時に、特定の期間別にデータをフィルタリングできるため、特定のユースケースに焦点を当てたり、異なる時間帯の情報を可視化したりすることができます。

https://storage.googleapis.com/gweb-cloudblog-publish/original_images/2_Using_GKE_cost_optimization_insights.gif

GKE 費用最適化インサイトは、クラスタだけでなくワークロードに対しても利用できます。  使用およびリクエストしたリソース量をワークロード別に確認できるため、リソースのリクエストまたは使用が非効率的なワークロードを特定して修正できます。クラスタレベル ビューの場合と同様、ワークロードレベル ビューでも CPU とメモリの使用率が集計され、最も負荷の高いワークロードを明確に把握できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_Using_GKE_cost_optimization_insights.max-1300x1300.jpg

要件とサポートされる指標

内部的には、GKE 費用最適化インサイトは Cloud Monitoring のシステム指標を使用します。そのため、クラスタでシステム指標の収集が有効化されている場合は、すぐに利用できる状態で結果を入手できます。

また、一般的によく知られている CPU や メモリの指標だけにとどまらず、GKE 費用最適化インサイトで使用されるすべての指標を理解しておくことも重要です。

次の表は、インサイトの指標集計の計算で使用される Kubernetes の指標の一覧です。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_Requirements_and_supported_metrics.max-1100x1100.jpg

絶対値をすぐに分析する必要がある場合は、省略可能な列を有効にして、チャート内部で使用されるすべての数値を表示できます。

最後の点として、GKE の UI で使用可能な時間選択ツールを使用すると、計算する時間帯を選択できます。使用率指標は指定した期間で平均化されますが、コアとメモリの合計時間は累計されます。費用最適化の指標の詳細については、こちらをご覧ください。

まとめ

このような分析情報が、ビンパッキングとアプリのサイズ適正化にどのように役立つかはすぐにおわかりいただけると思います。一方で、こうした情報は、費用を節約する文化の確立という別の課題に対処する際にも役立ちます。GKE リソースが可視化されると、ソリューションを自分自身で構築しなくても、チームがプロダクトの内部からこの重要な情報にアクセスできるようになります。分析情報は、GKE の従量課金制モデルと、未使用リソースがインフラストラクチャの費用に与える影響をより良く理解するのにも役立ちます。

今すぐ GKE コンソールで、新しい費用最適化インサイトをご確認ください。活用する準備が整っている場合は、費用を最適化した Kubernetes アプリケーションを GKE で実行するためのベスト プラクティスをご覧ください。

- GKE プロダクト マネージャー Roman Arcea

- シニア ソフトウェア エンジニア Michał Jasiński

投稿先