Cloud Monitoring を使用して費用の最適化のための GKE クラスタをモニタリング

このチュートリアルでは、Google Kubernetes Engine(GKE)クラスタをモニタリングしてリソース使用率を最適化する方法について説明します。通常、このような種類の最適化は、アプリの安定性とパフォーマンスを損なうことなくリソース消費量を削減してコストを削減することが望ましいため、複雑なタスクです。このチュートリアルでは、GKE でのオーバープロビジョニングの最も一般的な原因に対して、ダッシュボードとアラート ポリシーを設定するプロセスについて説明します。このチュートリアルでは、アプリを確実に実行し費用に合わせて最適化し続けられるように、リソースの推奨事項も用意しています。

このチュートリアルは、デベロッパーやオペレーターを対象としています。彼らは、低コスト、高パフォーマンス、アプリの高い安定性を実現するために、GKE クラスタとアプリを最適化する必要があります。このチュートリアルは、ユーザーが DockerKubernetes、Kubernetes CronJob、GKE、Cloud Monitoring、Linux に精通していることを前提としています。

概要

一般に、費用の最適化は、費用の削減に重点を置く 1 回限りのプロセスだと誤解されています。しかし、ガートナーの定義によれば、費用の最適化とは、ビジネスの価値を最大化する必要もある継続的な規律を指します。このような規律を Kubernetes world にインスタンス化する場合は、他の視点も重要です。

4 つの異なる目標のバランスをとる: 費用の削減、パフォーマンス目標の達成、安定性の確保、業績の最大化。

この図に示すように、Kubernetes で費用を最適化するには、費用の削減、パフォーマンス目標の達成、安定性の確保、業績の最大化という 4 つの異なる目標のバランスをとる必要があります。つまり、費用の最適化の影響がよく理解されて熟慮されていなければ、ユーザー エクスペリエンスや業績を犠牲にしても費用削減は実現できません。

Google Cloud には、これらの目標のバランスをとるのに必要なツールが用意されています。ただし、ワークロード用に Kubernetes のようなクラウドベースのソリューションを採用するすべてのチームが、パフォーマンスや安定性の目標を達成できる専門知識を備えているわけではありません。多くの場合、そうしたチームの解決策は、ビジネスへの影響を軽減するために環境をオーバープロビジョニングすることになります。

オーバープロビジョニングを行うと、短期的な軽減策は講じられますが、費用は高くなります。Kubernetes は、慎重に、継続的な費用最適化プロセスの一部としてのみ使用してください。次の図は、このような費用最適化の取り組みを開始するチームで見られる上位 4 つの問題を表しています。

チームで見られる上位 4 つの問題: 文化、ビンパッキング、アプリのサイズ適正化、オフピーク時にスケールダウンしないこと。

  • 第 1 の問題は、文化です。パブリック クラウドを採用している多くのチームは、従量課金制の請求スタイルに慣れておらず、往々にして、アプリが実行されている環境(ここでは Kubernetes)を完全に理解しているわけではありません。最近注目されている FinOps 運動とは、このような文化を進化させることです。FinOps におけるベスト プラクティスの 1 つは、チームの費用とビジネスへの影響に関するリアルタイムの情報をそのチームに提供することです。こうした小さなことが、企業文化にかなり大きな影響を与え、よりバランスのとれた費用最適化の均衡化につながります。

  • 第 2 の問題は、ビンパッキングです。ビンパッキングとは、アプリを GKE ノードに圧縮する能力です。アプリをノードに効率的に圧縮するほど、節約額が大きくなります。

  • 第 3 の問題は、アプリのサイズ適正化です。サイズ適正化とは、クラスタにデプロイされているオブジェクトに対して適切なリソース リクエストとワークロードの自動スケーリング目標を構成する能力です。Pod に正確なリソースを設定する際の精度が高いほど、アプリはより確実に実行され、ほとんどの場合、クラスタで使わないスペースがより多くなります。

  • 最後の問題は、オフピーク時にクラスタをスケールダウンしないことです。理想的には、需要が低い期間(たとえば夜間)は、費用削減のために、実際の需要に合わせてクラスタがスケールダウンされるようにするべきです。ただし、場合によっては、クラスタ オートスケーラー(CA)をブロックするワークロードやクラスタ構成が原因で、想定どおりにスケールダウンしないこともあります。

環境の費用を効率的に最適化するためには、こうした問題に継続的に取り組む必要があります。実践的な事項に焦点を当てるため、このチュートリアルの残りの部分では、文化の問題は省略し、GKE クラスタでビンパッキングとアプリのサイズ適正化をモニタリングする Cloud Monitoring を使用する方法について説明します。需要の低い期間中のクラスタの費用最適化に関する詳細については、オフピーク時間中に GKE クラスタをスケールダウンして費用を削減するをご覧ください。

目標

  • GKE クラスタを作成する。
  • サンプルアプリをデプロイします。
  • 必要な指標を Cloud Monitoring にエクスポートするためのコンポーネントを設定します。
  • リソースの使用状況と推奨事項をモニタリングするためのダッシュボードを動的に生成します。
  • オーバープロビジョニングとアンダープロビジョニングのアラート ポリシーを動的に生成します。

料金

このチュートリアルでは、課金対象である次の Google Cloud コンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただけます。

始める前に

  1. Google Cloud Console で [プロジェクトの選択] ページに移動します。

    プロジェクト セレクタに移動

  2. Google Cloud プロジェクトを選択または作成します。

  3. Cloud プロジェクトに対して課金が有効になっていることを確認します。プロジェクトに対して課金が有効になっていることを確認する方法を学習する

このチュートリアルを終了した後、作成したリソースを削除すると、それ以上の請求は発生しません。詳しくは、クリーンアップをご覧ください。

環境の準備

  1. Cloud Console で Cloud Shell を開きます。このチュートリアル全体を通して、Cloud Shell でコマンドを実行します。

    Cloud Console の下部で Cloud Shell セッションによって、コマンドライン プロンプトが開かれて表示されます。Cloud Shell はシェル環境です。gcloud コマンドライン ツールを含め、Cloud SDK がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。

  2. Cloud Shell で、Cloud プロジェクト ID とメールアドレスを構成し、Compute Engine、GKE、Cloud Monitoring API を有効にします。

    PROJECT_ID=YOUR_PROJECT_ID
    ALERT_EMAIL=YOUR_EMAIL_ADDRESS
    CLUSTER=gke-cost-optimization-monitoring
    gcloud config set project $PROJECT_ID
    
    gcloud services enable \
        compute.googleapis.com \
        container.googleapis.com \
        monitoring.googleapis.com
    
    gcloud config set compute/region us-central1
    gcloud config set compute/zone us-central1-f
    

    以下を置き換えます。

    • YOUR_PROJECT_ID: このチュートリアルで使用しているプロジェクトの Cloud プロジェクト ID。
    • YOUR_EMAIL_ADDRESS: クラスタ内でオーバープロビジョニングとアンダープロビジョニングの機会が見つかった場合に通知されるメールアドレス。

    別のリージョンとゾーンを選択できます。

  3. gke-cost-optimization-monitoring GitHub リポジトリのクローンを作成します。

    git clone https://github.com/GoogleCloudPlatform/gke-cost-optimization-monitoring
    cd gke-cost-optimization-monitoring
    

    このリポジトリのコードは、次のフォルダにまとめられます。

    • ルート: CronJob でカスタム指標を Cloud Monitoring にエクスポートするために使用される main.go ファイルと Dockerfile ファイルが含まれます。
    • api/: Kubernetes オブジェクトと Monitoring オブジェクトを操作するための golang API が含まれます。
    • k8s/templates/: クラスタ内に CronJob オブジェクト、VPA オブジェクト、Horizontal Pod Autoscaler(HPA)オブジェクトを作成するために使用されるテンプレートが含まれます。
    • monitoring/dashboards/templates/: ビンパッキングとアプリのサイズ適正化のダッシュボードを動的に作成するために使用されるテンプレートが含まれます。
    • monitoring/policies/templates/: ビンパッキングのアラート ポリシーとアプリのサイズ適正化のアラート ポリシーを動的に作成するために使用されるテンプレートが含まれます。

GKE クラスタの作成

  1. Cloud Shell で、GKE クラスタを作成します。

    gcloud container clusters create $CLUSTER \
        --enable-ip-alias \
        --release-channel=stable \
        --machine-type=e2-standard-2 \
        --enable-autoscaling --min-nodes=1 --max-nodes=5 \
        --enable-vertical-pod-autoscaling
    

    この設定は本番環境構成ではありませんが、このチュートリアルには適しています。この設定では、VPA を有効にすることで、アプリのサイズ適正化の基盤を抽出します。

サンプルアプリのデプロイ

  1. Online Boutique アプリをデプロイします。

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/master/release/kubernetes-manifests.yaml
    

    Online Boutique アプリは、さまざまなコンピュータ言語で記述された多くのマイクロサービスで構成されるデモの小売ウェブストアです。

  2. より現実的な環境をシミュレートするには、Online Boutique Deployment の HPA を作成します。

    kubectl get deployments --field-selector='metadata.name!=adservice,metadata.name!=cartservice' -o go-template-file=k8s/templates/cpu-hpa.gtpl | kubectl apply -f -
    
    kubectl get deployments --field-selector='metadata.name==cartservice' -o go-template-file=k8s/templates/memory-hpa.gtpl | kubectl apply -f -
    

    ほとんどの Online Boutique Deployment に対しては CPU を対象とする HPA オブジェクト、cartservice Deployment に対してはメモリを対象とする HPA オブジェクトを作成し、adservice に対しては HPA 構成を作成しないことに留意してください。以降のセクションで示すように、この設定を使用すると、さまざまなダッシュボードを可視化して説明できます。

指標を Cloud Monitoring にエクスポートするためのコンポーネントを設定する

  1. カスタム指標エクスポータのコードをビルドして push します。

    docker build . -t gcr.io/$PROJECT_ID/metrics-exporter
    docker push gcr.io/$PROJECT_ID/metrics-exporter
    

    このコードは、クラスタ内の VPA オブジェクトと HPA オブジェクトに対するクエリを実行し、そのデータに基づくカスタム指標を Cloud Monitoring に送信する役割を担います。この実装により、VPA を対象とする推奨事項と HPA リソースを対象とする使用状況(パーセンテージ形式で定義した CPU とメモリ)がエクスポートされます。

  2. CronJob をデプロイして、1 分ごとにワークロード オートスケーラーの指標を Cloud Monitoring に送信します。

    sed "s/PROJECT_ID/$PROJECT_ID/g" k8s/templates/metrics-exporter.yaml > k8s/metrics-exporter.yaml
    kubectl create ns custom-metrics
    kubectl apply -f k8s/metrics-exporter.yaml
    

    このチュートリアルを(前の手順で作成したクラスタではなく)ユーザー独自のクラスタで実行し、Workload Identity が有効化されている場合は、指標を Cloud Monitoring にエクスポートすることを許可するために、必ず Workload Identity の使用の手順に沿って操作してください。

  3. クラスタ内のすべての Deployment、StatefulSet、DaemonSets オブジェクト用の VPA を作成します。

    rm k8s/vpas.yaml 2> /dev/null
    ALL_NAMESPACES=$(kubectl get namespaces -o jsonpath={.items[*].metadata.name})
    for NAMESPACE in $ALL_NAMESPACES
    do
        kubectl get deployments,statefulset,daemonset -n $NAMESPACE -o go-template-file=k8s/templates/vpa.gtpl >> k8s/vpas.yaml
    done
    kubectl apply -f k8s/vpas.yaml
    

    上記のスニペットでは、システム オブジェクトを含むすべての Namespace のすべてのオブジェクト用に Off モードで VPA が作成されます。このアプローチでは、クラスタレベルとノードプール レベルでの推奨事項のより正確なビューが提供されます。ただし、metrics-server Service の過負荷を避けるために、数百のアプリがデプロイされている大規模なクラスタでは、上記のスクリプトをそのまま実行することはおすすめしません。大規模なクラスタ シナリオの場合、上記のスクリプトを実行するのは、費用を最適化したい Namespace だけに限定することをおすすめします。このシナリオでは、クラスタレベルとノードプール レベルでの推奨事項は正確ではないため、無視するか削除してください。

リソースの使用率と推奨事項をモニタリングするためのダッシュボードの設定

  1. Cloud Console で [Monitoring] ページに移動します。

    [モニタリング] に移動

  2. プロジェクトを作成する。

    1. [Add your project to a Workspace] ページで、Cloud プロジェクトを選択します。
    2. [Add] をクリックします。

    ワークスペースの作成には、数分かかることがあります。

  3. Cloud Shell で、費用の最適化に関するダッシュボードを動的に生成します。

    YOUR_NAMESPACES=$( echo $ALL_NAMESPACES| sed 's/[a-zA-Z0-9_.-]*-system//g; s/gke-[a-zA-Z0-9_.-]*//g; s/kube-public//g; s/kube-node-lease//g; s/custom-metrics//g')
    for NAMESPACE in $YOUR_NAMESPACES
    do
        GTPL_FILE='./monitoring/dashboards/templates/app-rightsizing.gtpl'
        OUTPUT_FILE="./monitoring/dashboards/app-rightsizing-$CLUSTER-$NAMESPACE.yaml"
    
        kubectl get deployments,statefulset,daemonset -n $NAMESPACE -o go-template-file=$GTPL_FILE > $OUTPUT_FILE
    
        sed -i.bkp "s/CLUSTER_TO_REPLACE/$CLUSTER/g" $OUTPUT_FILE
        sed -i.bkp "s/NAMESPACE_TO_REPLACE/$NAMESPACE/g" $OUTPUT_FILE
    
        replace=""
        i=0
        while : ; do
            if grep -q "Y_POS_TO_REPLACE_$i" $OUTPUT_FILE
            then
                ((yPos=12 + (4 * $i)))
                replace="s/Y_POS_TO_REPLACE_$i/$yPos/g; ${replace}"
                ((i=i+1))
            else
                break
            fi
        done
        eval "sed -i.bkp '$replace' $OUTPUT_FILE"
        rm "$OUTPUT_FILE.bkp"
    done
    
    sed "s/CLUSTER_TO_REPLACE/$CLUSTER/g" ./monitoring/dashboards/templates/binpacking.yaml > ./monitoring/dashboards/binpacking.yaml
    

    このスクリプトは、ビンパッキング ダッシュボードを作成するだけでなく、クラスタ内の各 Namespace(system Namespace を除く)用にアプリのサイズ適正化ダッシュボードも生成します。このチュートリアルでは、スクリプトによって default Namespace 用のダッシュボードが 1 つだけ生成されます。これは、Online Boutique 全体がこの Namespace にデプロイされるためです。しかし、独自の GKE クラスタで同じスクリプトを実行する場合は、Namespace ごとに 1 つのダッシュボードが生成されます。

  4. 生成したダッシュボードを Cloud Monitoring にインポートします。

    for filename in monitoring/dashboards/*.yaml; do
        echo "Creating dashboard policy based on file: $filename"
        gcloud monitoring dashboards create \
            --config-from-file=$filename
    done
    

    出力は次のようになります。

    Creating dashboard policy based on file: monitoring/dashboards/app-rightsizing-gke-cost-optimization-monitoring-default.yaml
    Created [9c1a6cb6-3424-44a8-b824-f2ec959f6588].
    Creating dashboard policy based on file: monitoring/dashboards/binpacking.yaml
    Created [97f6349d-4880-478d-9da8-ca3c8a433093].
    

アプリのサイズ適正化ダッシュボードの表示

  1. [モニタリング ダッシュボード] ページに移動します。

    [ダッシュボード] ページに移動

  2. [GKE - App Right-Sizing (gke-cost-optimization-monitoring):default] ダッシュボードをクリックします。

このセクションの残りの部分では、ダッシュボードに表示されるチャートを確認して解釈する方法について説明します。

インストールされたデモ環境には、シミュレートされた一定の負荷がかかっています。つまり、そのチャートには、時間の経過に伴う大きな変化はありません。ただし、独自のクラスタで同じチュートリアルを実行する場合、スケールアップとスケールダウンの動態、日と週で発生する負荷分散の違いを確認するには、数時間(理想的には 24 時間以上)待つ必要があります。

チャートの最初の行には Namespace のオーバープロビジョニング、2 行目にはオーバープロビジョニングされたアプリの上位 5 件、3 行目にはアンダープロビジョニングされたアプリの上位 5 件が示されています。

上のチャートに示すように、ダッシュボードの最初の 3 行には、集計された次の Namespace 情報がまとめられています。

  • 1 行目: CPU とメモリ: Namespace のオーバープロビジョニング。特定の Namespace でアプリを費用最適化する方法の簡単な概要を示します。
  • 2 行目: CPU とメモリ: オーバープロビジョニングされたアプリの上位 5 件。Namespace を改善する方法を探すときに最初に取り組むべきアプリがある場所を示します。
  • 3 行目: CPU とメモリ: アンダープロビジョニングされたアプリの上位 5 件2 行目と同様に、この行には特別な注意が必要なアプリが示されます。ただし、このシナリオでは、費用の削減ではなく、クラスタ内でアプリをスムーズに実行することを重視します。「利用できるデータがありません」というメッセージが表示される場合は、最適化案が見つからなかったことを意味します。

次のチャートは、CPU、メモリ、レプリカに関して、アプリごとにダッシュボードに表示される詳細情報を示しています。各行は、特定の Namespace にあるアプリを表します。この情報は、開発者が考えるアプリに必要なもの(requested_<cores|memory> 行)とアプリが実際に使用するもの(used_<cores|memory> 行)を比較することで、アプリのサイズ適正化に役立ちます。

アプリのサイズ適正化ダッシュボードには、CPU、メモリ、レプリカの詳細が表示されます。

以降のセクションには、上のチャートの 3 つの列について説明します。

1 列目: CPU(p / Pod)

ワークロードの構成内容に応じて、これらのチャートによりさまざまなヒントが表示され、アプリの適切なサイズを判断するのに役立ちます。

  • VPA CPU の推奨事項vpa_recommended_cores): このヒントは、アプリに HPA が構成されていない(ダッシュボードの CPU: adservice (p/Pod) チャート)場合、または HPA が CPU 以外の指標で構成されている場合(ダッシュボードの CPU: cartservice (p/Pod) チャート)に表示されます。こうしたヒントが表示された場合は、静的にヒントを適用するか、チャート履歴の確認が苦にならない場合は、Initial または Auto モードで VPA を有効にすることを強くおすすめします。

  • HPA CPU の目標使用率hpa_target_utilization): このヒントは、アプリが CPU 使用率(他のすべての CPU チャート)に基づく HPA で構成されている場合に表示されます。このシナリオでは、次のようにすることをおすすめします。

    • オーバープロビジョニングの場合: 常に実際の使用率(used_cores)が HPA 目標(hpa_target_utilization)を大幅に下回っている場合、HPA の minReplicas 値に指定された値で Deployment が動作しているということです。このシナリオで推奨されるアクションは、minReplicas 値を小さくすることです。
    • アンダープロビジョニングの場合: 常に実際の使用率(used_cores)が HPA 目標(hpa_target_utilization)を上回っている場合、HPA の maxReplicas 値に指定された値で Deployment は動作しています。この場合は、maxReplicas 値を増やすか、Pod を大きくするために要求されるリソースを増やすことをおすすめします。
    • スケールアップとスケールダウンを理解する: CPUReplicas のチャートを確認して、CPU に対する HPA が Pod のスケールアップとスケールダウンをトリガーするタイミングを把握してください。
    • HPA 目標使用率の微調整: お使いの環境に適用する前に、ベスト プラクティスを確認してください。
    • また、同じワークロードで CPU やメモリに VPA と HPA を混在させないようにすることも重要です。そのためには、MPA を使用します。

2 列目: メモリ(p / Pod)

CPU の列と同様、ワークロードの構成内容によっては、これらのチャートによって、アプリの適正サイズの決定に役立つさまざまなヒントが表示されます。

  • VPA メモリの推奨事項vpa_recommended_bytes): このヒントは、アプリケーションに HPA が構成されていない(ダッシュボードの Mem: adservice (p/Pod) チャート)場合、または HPA がメモリ以外の指標で構成されている(Men: emailservice (p/Pod) など)場合に表示されます。リソースの無駄や「Out Of Memory Kill」(OOMKill)イベントの発生を避けるために、こうした推奨事項の適用を検討するか、チャート履歴の確認が苦にならない場合は、Initial または Auto モードで VPA を有効にしてください。

  • HPA メモリの目標使用率hpa_target_utilization): このヒントは、アプリがメモリ使用率(ダッシュボードの Mem: cartservice (p/Pod) チャート)に基づく HPA で構成されている場合に表示されます。このシナリオでは、次のようにすることをおすすめします。

    • オーバープロビジョニングの場合: 常に実際の使用率(used_bytes)が HPA 目標(hpa_target_utilization)を大幅に下回っている場合、HPA の minReplicas 値に指定された値で Deployment が動作しています。このシナリオで推奨されるアクションは、minReplicas 値を小さくすることです。
    • アンダープロビジョニングの場合: 常に実際の使用率(used_bytes)が HPA 目標(hpa_target_utilization)を上回っている場合、HPA の maxReplicas 値に指定された値で Deployment が動作しています。この場合は、maxReplicas 値を増やすか、Pod を大きくするために要求されるリソースを増やすことをおすすめします。
    • スケールアップとスケールダウンを理解する: MemReplicas のチャートを確認して、メモリに対する HPA が Pod のスケールアップとスケールダウンをトリガーするタイミングを把握してください。
    • HPA 目標使用率の微調整: お使いの環境に適用する前に、ベスト プラクティスを確認してください。
    • また、同じワークロードで CPU やメモリに VPA と HPA を混在させないようにすることも重要です。そのためには、MPA を使用します。

3 列目: レプリカ

この列のチャートは、特定のアプリが持っている Pod の数を示しています。この情報は、HPA と一緒にデプロイされるワークロードの推奨リソースに対する使用リソースの変動を把握するのに役に立ちます。

ビンパッキング ダッシュボードの表示

  1. 再度、[モニタリング ダッシュボード] ページに移動します。

    ダッシュボードに移動する

  2. [GKE - Cluster Bin Packing (gke-cost-optimization-monitoring)] ダッシュボードをクリックします。

次のチャートに示すように、ビンパッキング ダッシュボードには、クラスタ(1 行目)とノードプール(2 行目)で集計された情報が表示されます。この情報は、クラスタとノードプール内の割り当て可能容量(allocable_<cores|memory> の行)と、開発者が考えるアプリに必要な容量(requested_<cores|memory> の行)を比較することにより、クラスタをビンパッキングするときに役に立ちます。

ビンパッキング ダッシュボードには、クラスタ(1 行目)とノードプール(2 行目)で集計された情報が表示されます。

これらのチャート上で実行できる有用な分析の一つとして、あるリソースタイプ(メモリなど)が不足していないか、別のリソースタイプ(CPU など)を浪費していないかを確認するという分析方法があります。このシナリオでは、スケジュールされた Pod をクラスタに収めるために利用できるメモリがないため、クラスタ オートスケーラーによってスケールアップがトリガーされます。別のよくあるケースは、Pod 密度、つまりノードあたりの Pod 数に関連があります。ノードプール: Pod 数のチャートでは、各ノードプール内の Pod の密度を確認でき、構成済みの情報(チャートには示されません)と比較できます。ノードプールの構成密度に達すると、利用可能な CPU とメモリが大量にある場合でも、CA によってスケジュールされた Pod に合わせて新しいノードが起動されます。

もう 1 つの重要な分析は、上記のダッシュボードで入手できませんが、オートスケーラーの最小構成と最大構成に関連があります。たとえば、HPA か CA のいずれかで最小数を越えた要求があるため、夜間にクラスタがスケールダウンしていない可能性があります。さらに、CA がノードプールに構成されたノードの最大数に達している可能性があるため、予定されたノードプールで CA によって Pod が起動されていない可能性があります。

ダッシュボードの制限事項

  • アプリのサイズ適正化ダッシュボードには、特定の Namespace にあるすべてのアプリに関する集計情報が表示されますが、固有のダッシュボードで使用できるウィジェットの数の制限により、名前順に最初の 8 つのアプリの CPU、メモリ、レプリカのみが表示されます。表示されているアプリが最重要ではないと判断できる場合は、必要に応じてダッシュボードを編集します。
  • ビンパッキング ダッシュボードには、クラスタとノードプールの集計データが表示されます。数多くのクラスタやノードプールを扱う場合は、チャートの作成に使用される Monitoring Query Language(MQL)に対してフィルタを実行できないため、可視化が制限されます。
  • ビンパッキング ダッシュボードでは、数百のアプリで大規模なクラスタをモニタリングする場合、読み込みに長い時間がかかります。この場合は、読み込まれるデータの量を減らすため、ダッシュボードを長期間フィルタしないことをおすすめします。

オーバー プロビジョニングとアンダー プロビジョニングのアラート ポリシーの設定

会社の財務部門から、最近クラウドの請求額が 2 倍になった理由について質問された場合、オーバー プロビジョニングの問題があると回答することは望ましくありません。このような状況を回避するため、計画した状態から環境が逸脱したときに、トリガーされるアラート ポリシーを作成することを強くおすすめします。

  1. Cloud Shell で、通知チャネルを作成します。

    gcloud beta monitoring channels create \
        --display-name="Cost Optimization team (Primary)" \
        --description="Primary contact method for the Cost Optimization effort"  \
        --type=email \
        --channel-labels=email_address=${ALERT_EMAIL}
    

    出力は次のようになります。

    Created notification channel [projects/your_project/notificationChannels/13166436832066782447].
    

    上記のコマンドでは、チュートリアルの手順を簡単にするため、タイプ email通知チャネルが作成されます。本番環境では、通知チャネルを smspagerduty に設定して、非同期の程度がより低い方法を使用することをおすすめします。

  2. NOTIFICATION_CHANNEL_ID プレースホルダに表示された値を含む変数を設定します。

    NOTIFICATION_CHANNEL_ID=$(gcloud beta monitoring channels list --filter='displayName="Cost Optimization team (Primary)"' | grep 'name:' | sed 's/name: //g')
    
  3. アラート ポリシーを動的に作成してデプロイします。

    for NAMESPACE in $YOUR_NAMESPACES
    do
        for templatefile in monitoring/policies/templates/rightsizing/*.yaml; do
            outputfile=monitoring/policies/$(basename $templatefile)
            sed "s/CLUSTER_TO_REPLACE/$CLUSTER/g;s/NAMESPACE_TO_REPLACE/$NAMESPACE/g" $templatefile > $outputfile
            echo "Creating alert policy based on file: $outputfile"
            gcloud alpha monitoring policies create \
                --policy-from-file=$outputfile \
                --notification-channels=$NOTIFICATION_CHANNEL_ID
        done
    done
    
    for templatefile in monitoring/policies/templates/binpacking/*.yaml; do
        outputfile=monitoring/policies/$(basename $templatefile)
        sed "s/CLUSTER_TO_REPLACE/$CLUSTER/g;s/NAMESPACE_TO_REPLACE/$NAMESPACE/g" $templatefile > $outputfile
        echo "Creating alert policy based on file: $outputfile"
        gcloud alpha monitoring policies create \
            --policy-from-file=$outputfile \
            --notification-channels=$NOTIFICATION_CHANNEL_ID
    done
    

    出力は次のようになります。

    Creating alert policy based on file: monitoring/policies/app-rightsizing-cpu-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/18091138402474167583].
    Creating alert policy based on file: monitoring/policies/app-rightsizing-cpu-underprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/8586234469403227589].
    Creating alert policy based on file: monitoring/policies/app-rightsizing-memory-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/9685822323903723723].
    Creating alert policy based on file: monitoring/policies/app-rightsizing-memory-underprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/15705075159352926212].
    Creating alert policy based on file: monitoring/policies/nodepools-binpacking-cpu-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/14555072091442814207].
    Creating alert policy based on file: monitoring/policies/nodepools-binpacking-memory-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/1442392910032052087].
    

    作成されたアラート ポリシーにはデフォルトで、1 日より長い期間、アプリが 80% を超え、かつ、ノードプールが 40% を超えてオーバープロビジョニングされた場合にアラートをトリガーする仕様が含まれています。このポリシーは、リソース使用率の要件に合わせて確実に微調整してください。

  4. [モニタリング アラート] ページに移動して、アラート ポリシーを確認してください。

    [アラート] ページに移動

  5. 作成したポリシーのいずれかをクリックして、アラート構成の詳細を確認または編集します。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにする手順は次のとおりです。

プロジェクトを削除する

課金を停止する最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。

  1. Cloud Console で [リソースの管理] ページに移動します。

    [リソースの管理] に移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ