このチュートリアルでは、VPA の推奨事項と使用状況の指標を使用して、Google Kubernetes Engine（GKE）ワークロードのサイズを適正化する方法について説明します。
リソースサイズの適正化が重要な理由について
プロビジョニングが十分でない場合、アプリケーションの実行に必要なリソースのコンテナが枯渇して、それらの動作が遅くなり、信頼性が低下する可能性があります。プロビジョニングが過剰な場合、アプリケーションのパフォーマンスには影響しませんが、毎月の請求額が増加する可能性があります。
次の表に、CPU とメモリの過小プロビジョニングと過剰プロビジョニングとの関係を示します。
| リソース | プロビジョニングのステータス | リスク | 説明 |
|---|---|---|---|
| CPU | 過剰 | 費用 | 不要なリソースを予約することで、ワークロードの費用が増加します。 |
| 過少 | パフォーマンス | ワークロードが遅くなったり、応答しなくなったりする可能性があります。 | |
| 未設定 | 信頼性 | CPU が 0 にスロットリングされ、ワークロードが応答しなくなる可能性があります。 | |
| メモリ | 過剰 | 費用 | 不要なリソースを予約することで、ワークロードの費用が増加します。 |
| 過少 | 信頼性 | アプリケーションがメモリ不足（OOM）エラーで終了する可能性があります。 | |
| 未設定 | 信頼性 | kubelet が Pod を停止し、それらを失敗としてマークする可能性があります。 |
目標
このチュートリアルの学習内容は次のとおりです。
- サンプル アプリケーションをデプロイする。
- Monitoring から BigQuery に GKE 推奨事項の指標をエクスポートする。
- BigQuery と Looker Studio を使用して、複数のプロジェクトにまたがる GKE コンテナの推奨事項を表示する。
費用
このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。
始める前に
プロジェクトを設定する
Cloud Shell には、このチュートリアルに必要な Docker、kubectl、gcloud CLI、Terraform などのソフトウェアがプリインストールされています。Cloud Shell を使用しない場合は、gcloud CLI をインストールする必要があります。
- Google Cloud アカウントにログインします。Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
- Google Cloud CLI をインストールします。
-
gcloud CLI を初期化するには:
gcloud init
-
Google Cloud プロジェクトを作成または選択します。
-
Google Cloud プロジェクトを作成します。
gcloud projects create PROJECT_ID
PROJECT_IDは、作成する Google Cloud プロジェクトの名前に置き換えます。 -
作成した Google Cloud プロジェクトを選択します。
gcloud config set project PROJECT_ID
PROJECT_IDは、実際の Google Cloud プロジェクト名に置き換えます。
-
-
Resource Manager, Google Kubernetes Engine, Cloud Monitoring, BigQuery, Cloud Run, Cloud Build API を有効にします。
gcloud services enable cloudresourcemanager.googleapis.com
container.googleapis.com monitoring.googleapis.com bigquery.googleapis.com run.googleapis.com cloudbuild.googleapis.com cloudscheduler.googleapis.com artifactregistry.googleapis.com - Google Cloud CLI をインストールします。
-
gcloud CLI を初期化するには:
gcloud init
-
Google Cloud プロジェクトを作成または選択します。
-
Google Cloud プロジェクトを作成します。
gcloud projects create PROJECT_ID
PROJECT_IDは、作成する Google Cloud プロジェクトの名前に置き換えます。 -
作成した Google Cloud プロジェクトを選択します。
gcloud config set project PROJECT_ID
PROJECT_IDは、実際の Google Cloud プロジェクト名に置き換えます。
-
-
Resource Manager, Google Kubernetes Engine, Cloud Monitoring, BigQuery, Cloud Run, Cloud Build API を有効にします。
gcloud services enable cloudresourcemanager.googleapis.com
container.googleapis.com monitoring.googleapis.com bigquery.googleapis.com run.googleapis.com cloudbuild.googleapis.com cloudscheduler.googleapis.com artifactregistry.googleapis.com -
Google アカウントにロールを付与します。次の IAM ロールごとに次のコマンドを 1 回実行します。
roles/serviceusage.serviceUsageAdmin, roles/container.clusterAdmin, roles/iam.serviceAccountAdmin, roles/iam.securityAdmin, roles/container.admingcloud projects add-iam-policy-binding PROJECT_ID --member="user:EMAIL_ADDRESS" --role=ROLE
PROJECT_IDは、実際のプロジェクト ID に置き換えます。EMAIL_ADDRESSは実際のメールアドレスに置き換えます。ROLEは、個々のロールに置き換えます。
環境を設定する
環境の設定手順は次のとおりです。
環境変数を設定します。
export PROJECT_ID=PROJECT_ID export REGION=us-central1 export ZONE=us-central1-f export IMAGE=$REGION-docker.pkg.dev/$PROJECT_ID/main/vpa-recs-image:latestPROJECT_IDは、実際の Google Cloud プロジェクト ID に置き換えます。デフォルトの環境変数を設定します。
gcloud config set project $PROJECT_ID gcloud config set compute/region $REGION gcloud config set compute/zone $ZONEコード リポジトリのクローンを作成します。
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples作業ディレクトリを変更します。
cd kubernetes-engine-samples/cost-optimization/gke-vpa-recommendations
（省略可）サンプル アプリケーションを設定する
このセクションでは、サンプル アプリケーションをデプロイします。このセクションは省略可能です。既存のクラスタを使用するには、クラスタで Cloud Monitoring が構成されていることを確認します。
実際の環境をシミュレートするには、セットアップ スクリプトを使用して Online Boutique をデプロイします。
次の手順では、サンプル アプリケーションをインストールしてデフォルト構成を変更します。たとえば、一部のワークロードで HorizontalPodAutoscaler（HPA）を構成し、リソースのリクエストと制限を変更します。
設定スクリプトを実行します。
./scripts/setup.sh設定スクリプトは、次のことを行います。
- GKE クラスタを作成します。
- Online Boutique サンプル アプリケーションをデプロイします。
- Pod の CPU とメモリのリソース リクエストを更新します。
adserviceワークロードに HorizontalPodAutoscaler リソースを構成して、実際の環境をシミュレートします。
設定スクリプトが完了するまでに 10 分ほどかかることがあります。
サンプル アプリケーションの準備ができていることを確認します。
kubectl get deployment出力は次のようになります。
NAME READY UP-TO-DATE AVAILABLE AGE adservice 2/2 2 2 4m54s cartservice 1/1 1 1 4m55s checkoutservice 1/1 1 1 4m56s currencyservice 1/1 1 1 4m55s emailservice 1/1 1 1 4m56s frontend 1/1 1 1 4m55s loadgenerator 1/1 1 1 4m55s paymentservice 1/1 1 1 4m55s productcatalogservice 1/1 1 1 4m55s recommendationservice 1/1 1 1 4m56s redis-cart 1/1 1 1 4m54s shippingservice 1/1 1 1 4m54s
リポジトリを作成する
指標エクスポータ イメージを保存するリポジトリを作成します。
新しい Docker リポジトリを作成します。
gcloud artifacts repositories create main --repository-format=docker \ --location=$REGION \ --description="docker repository"Docker リポジトリの認証を設定します。
gcloud auth configure-docker $REGION-docker.pkg.dev次のコマンドを実行して、イメージをデプロイします。
gcloud builds submit metrics-exporter --region=$REGION --tag $IMAGE
アプリケーションをデプロイする
次のセクションでは、Terraform を使用して次のタスクを実行します。
- サービス アカウントを作成して、Google Cloud リソースの管理と操作に必要な権限を割り当てます。
- サービス アカウントにモニタリング閲覧者、BigQuery データ編集者、BigQuery データオーナー、BigQuery ジョブユーザー、Cloud Run 起動元のロールを付与します。
- Artifact Registry から Docker イメージを pull し、指定された構成でイメージを実行する Cloud Run ジョブをデプロイします。
- Cloud Run サービスを毎日トリガーする Cloud Scheduler ジョブを作成します。
- 指標データと推奨事項を保存する BigQuery のデータセット、テーブル、ビューを作成します。
Terraform を構成する
構成の環境変数を設定します。
export TF_VAR_BIGQUERY_DATASET=gke_metrics_dataset export TF_VAR_BIGQUERY_TABLE=gke_metrics export TF_VAR_RECOMMENDATION_WINDOW_SECONDS=1209600 export TF_VAR_RECOMMENDATION_DISTANCE=86400 export TF_VAR_LATEST_WINDOW_SECONDS=600 export TF_VAR_METRIC_WINDOW=259200 export TF_VAR_METRIC_DISTANCE=600このコマンドには次のものが含まれます。
TF_VAR_BIGQUERY_DATASETとTF_VAR_BIGQUERY_TABLE: GKE 指標データを保持します。TF_VAR_RECOMMENDATION_WINDOW_SECONDS: VPA 推奨事項の期間。デフォルトは 1,209,600 秒（14 日）です。TF_VAR_RECOMMENDATION_DISTANCE: VPA 推奨事項データポイントが返される間隔。デフォルトは 86,400 秒（1 日）です。TF_VAR_LATEST_WINDOW_SECONDS: 最近リクエストされたリソース値と上限を取得する期間。デフォルトは 600 秒（10 分）です。METRIC_WINDOW: GKE の使用状況と使用率の指標の期間を設定します。デフォルトは 259,200 秒（3 日）です。METRIC_DISTANCE: データポイントが返される間隔。デフォルトは 600 秒（10 分）です。
これらの値をワークロードのニーズに応じて調整します。たとえば、月に 1 回実行されるバッチ ワークロードの場合は、
TF_VAR_RECOMMENDATION_WINDOW_SECONDSとMETRIC_WINDOWを2592000秒（30 日）に更新します。
Terraform 構成をデプロイする
構成を初期化、検証、適用します。
terraform -chdir=terraform init terraform -chdir=terraform validate terraform -chdir=terraform apply -var project_id=$PROJECT_ID -var region=$REGION -var image=$IMAGEこのコマンドは、実行プランを提供し、変更を行う前に承認を求めます。プランを確認し、すべてが想定どおりになっている場合は、「
yes」と入力して続行します。apply コマンドが正常に完了すると、Terraform によってリソースが作成され、管理されます。
Cloud Scheduler ジョブを手動で実行します。
gcloud scheduler jobs run recommendation-schedule --location ${REGION}
デプロイを確認する
workload-recommendationsの詳細ページで [ログ] タブを選択します。Cloud Run コンソールで指標ログが処理されていることを確認します。
ログには、BigQuery に書き込まれている指標が示されます。出力例を以下に示します。
INFO - Building Row INFO - Successfully wrote 12 rows to BigQuery table [PROJECT_ID].gke_metric_dataset.gke_metrics. INFO - Run Completed出力が一致しない場合は、5 分待ってから
gcloud scheduler jobs run recommendation-schedule --location $REGIONコマンドを実行します。
BigQuery でコンテナの推奨事項を表示する
Google Cloud コンソールで [BigQuery] ページに移動します。
gke_metricsテーブルとcontainer_recommendationsビューにデータが表示されていることを確認します。ワークロードの数によっては、すべての指標を BigQuery に書き込むのに数分かかることがあります。クエリエディタで、
container_recommendationsビューのすべての行を選択します。SELECT * FROM `PROJECT_ID.gke_metrics_dataset.container_recommendations`このプログラムは、Cloud Monitoring から次の指標を抽出します。
ワークロードの詳細: プロジェクト ID、クラスタ名、コントローラ、コンテナ名。
CPU / メモリの使用率と使用量: ワークロードによって使用されている CPU とメモリの使用量と使用率。
リクエストされた量と上限: ワークロードに対してリクエストされた CPU とメモリの量、ワークロードで許可されている CPU とメモリの最大量。
CPU とメモリに関するワークロードの推奨事項: ワークロードが円滑に実行されるように、ワークロードに割り当てられる CPU とメモリの量に関する推奨事項（Deployment に対する VPA の推奨事項と Deployment 以外のオブジェクトに対する目標使用率に基づく）。
Looker Studio で推奨事項を可視化する
Looker Studio はセルフサービス型の無料のビジネス インテリジェンス プラットフォームで、データを可視化し、ダッシュボードやレポートを作成して利用することができます。Looker Studio を使用すると、データに接続し、可視化を行い、分析情報を他のユーザーと共有できます。
Looker Studio を使用して、BigQuery の container_recommendations ビューでデータを可視化します。
- ワークロードのサイズ適正化ダッシュボード テンプレートを開きます。
- [自分のデータを使用] をクリックします。
- プロジェクトを選択します。
- データセットの場合、[
gke_metric_dataset] を選択します。 - テーブルの場合、[
container_recommendations] を選択します。 - [追加] をクリックします。
- [レポートに追加] をクリックします。
Looker Studio テンプレートの詳細
Looker Studio テンプレートの詳細ページには、次の情報が表示されます。
- GKE ワークロードのサイズ適正化の概要: 次のようなクラスタの概要が提供されます。
- 信頼性とパフォーマンスの問題のリスクがあるベスト エフォートとバースト可能なワークロードの数。
- CPU とメモリのリソースを節約できる可能性。正の値は過剰プロビジョニングを示し、負の値は過少プロビジョニングであることを示します。
- ワークロードの推奨事項: ワークロードの CPU とメモリのリクエスト量と上限に関する推奨事項を提供します。
- リスクのある GKE ワークロード: 信頼性とパフォーマンスの問題が発生するリスクが特に高いワークロードが表示されます。
- 履歴 - ワークロードのサイズ適正化 - 現状:ワークロードのサイズ適正化とベスト エフォート型のワークロード数の削減の実装に関する履歴ビューを提供します。
リクエストされた CPU と上限に関するコンテナの推奨事項
リクエストされたワークロードの CPU と上限の値が等しい場合、QoS は保証済みとみなされ、CPU 推奨値は 14 日の期間内で最大値に設定されます。それ以外の場合は、14 日以内にリクエストされた CPU の推奨値の 95 パーセンタイルが使用されます。
CPU リクエストと上限の値が等しい場合、CPU 上限の推奨事項は、Deployment オブジェクトに対してのみ最大 CPU リクエストの VPA 推奨値に設定され、CPU 使用率は目標使用率の 70% に設定されます。ワークロードのリクエストと上限が同じでない場合は、既存の上限比率が使用されます。
リクエストされたメモリと上限に関するコンテナの推奨事項
メモリの推奨事項では、ワークロードの信頼性を確保するために、Deployment オブジェクトに対してのみ最大 VPA 推奨値を使用します。最大メモリ使用量には目標使用率の 80% が使用されます。目標使用率の値は、container_recommendation ビューのクエリで更新できます。
メモリは圧縮不可能なリソースのため、リクエストと上限に同じ量のメモリを使用することをおすすめします。メモリが枯渇した場合は、Pod を削除する必要があります。Pod の削除と環境の不安定化を回避するには、リクエストされたメモリをメモリ制限に設定する必要があります。
優先順位付けに関する推奨事項
各行には優先度の値が割り当てられ、推奨事項に基づいてすぐに対応が必要なワークロードが表示されます。CPU とメモリの単位は異なります。単位を正規化するために、事前定義された CPU とメモリの間の E2 マシンタイプのオンデマンド料金の比率が、メモリ単位を CPU 単位に変換する近似値として使用されます。
優先度は次の式で計算されます。
priority = (CPU requested - CPU recommendation) + ((memory requested -
memory recommendation) / (vCPUs on-demand pricing /memory on-demand pricing ))
Autopilot の場合、デプロイ構成でリクエストされるリソースの合計は、サポートされている最小値と最大値の範囲内にある必要があります。
複数のプロジェクトの VPA 推奨事項を表示する
複数のプロジェクトにわたる VPA コンテナの推奨値を表示するには、スコープ対象のプロジェクトとして新しいプロジェクトを使用します。
このプロジェクトを本番環境にデプロイするときに、分析するすべてのプロジェクトを新しいプロジェクトの指標スコープに追加します。
クリーンアップ
このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。
プロジェクトを削除する
課金を停止する最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。
Google Cloud プロジェクトを削除します。
gcloud projects delete PROJECT_ID
次のステップ
- GKE でコスト最適化 Kubernetes アプリケーションを実行するためのベスト プラクティスで、GKE の費用の最適化について学習する。
- Google Cloud アーキテクチャ フレームワーク: 費用の最適化で、Google Cloud ワークロードの費用を最適化するための設計に関する推奨事項とベスト プラクティスを確認する。
- オフピーク時に GKE クラスタをスケールダウンして費用を削減するで、需要の低い期間にクラスタの費用を最適化する方法を確認する。
- Monitoring を使用して費用を最適化するために GKE クラスタをモニタリングするで、GKE の費用の最適化について学習する。