GSP767

概要

Google Kubernetes Engine クラスタの基盤となるインフラストラクチャは、それぞれが Compute VM インスタンスであるノードで構成されます。このラボでは、クラスタのインフラストラクチャを最適化することで費用を抑え、アプリケーションのアーキテクチャをより効率的なものにする方法を説明します。

ワークロードの例に適切な構成のマシンタイプを選択することで、貴重なインフラストラクチャ リソースを最大限に活用する（そして、十分に活用されない事態を防ぐ）うえで役立つ戦略を学びます。使用するインフラストラクチャの種類だけでなく、インフラストラクチャの物理的な地理的位置も費用に影響します。この演習では、可用性の高いリージョン クラスタを管理するために費用対効果に優れた戦略を立てる方法を学習します。

目標

このラボでは、次の方法について学びます。

• Deployment のリソース使用状況を確認する
• Deployment をスケールアップする
• マシンタイプが最適化されたノードプールにワークロードを移行する
• クラスタで使用できるロケーション オプションについて学習する
• 異なるゾーンにある Pod 間でのフローログをモニタリングする
• 通信量の多い Pod を移動して、複数ゾーンにまたがるトラフィックの費用を最小限に抑える

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの説明をお読みください。ラボには時間制限があり、一時停止することはできません。タイマーは、Google Cloud のリソースを利用できる時間を示しており、[ラボを開始] をクリックするとスタートします。

このハンズオンラボでは、シミュレーションやデモ環境ではなく実際のクラウド環境を使って、ラボのアクティビティを行います。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モード（推奨）またはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生しないようにすることができます。

• ラボを完了するための時間（開始後は一時停止できません）

注: このラボでは、受講者アカウントのみを使用してください。別の Google Cloud アカウントを使用すると、そのアカウントに料金が発生する可能性があります。

ラボを開始して Google Cloud コンソールにログインする方法

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるダイアログでお支払い方法を選択してください。 左側の [ラボの詳細] ペインには、以下が表示されます。

   • [Google Cloud コンソールを開く] ボタン
   • 残り時間
   • このラボで使用する必要がある一時的な認証情報
   • このラボを行うために必要なその他の情報（ある場合）

2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します）。

   ラボでリソースがスピンアップし、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。

3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

   {{{user_0.username | "Username"}}}

   [ラボの詳細] ペインでもユーザー名を確認できます。

4. [次へ] をクリックします。

5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

   {{{user_0.password | "Password"}}}

   [ラボの詳細] ペインでもパスワードを確認できます。

6. [次へ] をクリックします。

   重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

7. その後次のように進みます。

   • 利用規約に同意してください。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

その後、このタブで Google Cloud コンソールが開きます。

注: Google Cloud のプロダクトやサービスにアクセスするには、ナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。

このラボでは、小規模なクラスタを作成して使用します。クラスタのプロビジョニングには、2～5 分程度かかります。

[ラボを開始] ボタンを押した後で、青い文字の「resources being provisioned」というメッセージと、読み込み中であることを意味する円アイコンが表示される場合は、クラスタがまだ作成中です。

この待ち時間の間に次の指示と説明を読み始めても構いませんが、リソースのプロビジョニングが完了するまではシェルコマンドを実行できません。

タスク 1. ノードのマシンタイプを理解する

全体の概要

マシンタイプとは、システムメモリ サイズ、仮想 CPU（vCPU）数、永続ディスクの制限など、仮想マシン（VM）インスタンスで使用できる仮想ハードウェア リソースのセットのことです。マシンタイプはさまざまなワークロード向けにファミリー単位でグループ化され、キュレートされます。

ノードプールのマシンタイプを選択する場合、一般的に、汎用マシンタイプ ファミリーがさまざまなワークロードで優れたコスト パフォーマンスを発揮します。汎用マシンタイプは、N シリーズと E2 シリーズで構成されます。

マシンタイプの違いがアプリにとって有益なこともあれば、そうでないこともあります。一般的に、E2 は N1 に近いパフォーマンスを持っていますが、費用を重視して最適化されています。通常は E2 マシンタイプを使用するだけでも、費用を抑えられます。

ただし、クラスタの場合、使用するリソースがアプリケーションのニーズに基づいて最適化されることが特に重要です。大幅にスケールする必要がある大規模なアプリケーションまたは Deployment の場合、ワークロードを多数の汎用マシンに分散するよりも、少数の最適化されたマシンにスタックする方が費用を抑えられることもあります。

この意思決定を行うには、アプリについて十分に理解する必要があります。アプリに固有の要件がある場合は、それに合わせてマシンタイプを構成できます。

次のセクションでは、デモアプリに注目し、そのアプリを適切な構成のマシンタイプを使用するノードプールに移行します。

タスク 2. Hello App にふさわしいマシンタイプを選ぶ

Hello デモクラスタの要件を調べる

ラボの開始時に 2 つの e2-medium（vCPU x 2、メモリ 4GB）ノードを使用して Hello デモクラスタが生成されました。このクラスタは、Hello App という簡単なウェブ アプリケーションのレプリカを 1 つデプロイします。これは Go で記述されたウェブサーバーで、すべてのリクエストに「Hello, World!」メッセージで応答します。

1. ラボでプロビジョニングが完了した後、Cloud コンソールのナビゲーション メニューをクリックしてから [Kubernetes Engine] をクリックします。

2. [Kubernetes クラスタ] ウィンドウで [hello-demo-cluster] を選択します。

3. 次のウィンドウで、[ノード] タブを選択します。

クラスタのノードの一覧が表示されます。

クラスタのリソースが GKE でどのように利用されているかを観察します。各ノードからリクエストされた CPU とメモリの量やノードにある割り当て可能な容量がわかります。

4. クラスタの最初のノードをクリックします。

[Pod] セクションを見てください。hello-server Pod が default Namespace にあることがわかります。hello-server Pod が表示されない場合は、前に戻ってクラスタの 2 番目のノードを選択します。

hello-server Pod が 400 mCPU をリクエストしていることがわかります。他にも少数の kube-system Pod が実行中であることが表示されます。これらは GKE のクラスタ サービス（モニタリングなど）を実行するために読み込まれた Pod です。

5. [戻る] ボタンを押して、前の [ノード] ページに戻ります。

Hello-App の 1 つのレプリカと基本的な kube-system サービスを実行するには 2 つの e2-medium ノードが必要なことがわかります。また、クラスタの CPU リソースの大半が使用されていますが、割り当て可能なメモリは約 3 分の 1 しか使用されていません。

このアプリのワークロードがまったく変動しない場合は、必要な CPU とメモリの使用量も正確にわかるため、それに合わせてカスタマイズしたマシンタイプを作成することも可能でしょう。マシンタイプをそのようにカスタマイズできると、クラスタ インフラストラクチャ全体で費用を抑えられます。

しかし実際には、GKE クラスタの実行するワークロードは複数あることが多く、ほとんどの場合スケールアップやスケールダウンが必要です。

Hello App にスケールアップが必要な場合、どうすればよいでしょうか。

Cloud Shell をアクティブにする

Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。

2. ウィンドウで次の操作を行います。

   • Cloud Shell 情報ウィンドウで操作を進めます。
   • Cloud Shell が認証情報を使用して Google Cloud API を呼び出すことを承認します。

接続した時点で認証が完了しており、プロジェクトに各自の Project_ID、 が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

3. （省略可）次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

4. [承認] をクリックします。

出力:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. （省略可）次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

Hello App をスケールアップする

1. クラスタの認証情報にアクセスします。

gcloud container clusters get-credentials hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}

2. Hello-Server をスケールアップします。

kubectl scale deployment hello-server --replicas=2

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。 Hello App をスケールアップする

3. コンソールで、左側の [Kubernetes Engine] メニューの [ワークロード] を選択します。

hello-server に「Does not have minimum availability」というエラー ステータスが表示されます。

注: ラボ環境では、このエラーが表示されない場合があります。クラスタの Kubernetes のバージョンによっては、kube-system Pod がリクエストするリソースが小さくなっており、クラスタが新しいワークロードに対応できるためです。エラーが表示されなくても心配はいりません。このエラーが表示されなくてもこのラボは完了できます。

4. エラー メッセージをクリックしてステータスの詳細を取得します。エラーの原因が「Insufficient cpu」と表示されます。

これは予想どおりです。すでに説明したとおり、クラスタに CPU リソースの余裕がほとんどない状態で、hello-server の別のレプリカでさらに 400m をリクエストしました。

5. ノードプールを増やして新しいリクエストに対応します。

gcloud container clusters resize hello-demo-cluster --node-pool my-node-pool \ --num-nodes 3 --zone {{{project_0.default_zone | "ZONE"}}}

6. 続行するかどうかを確認するメッセージが表示されたら、「y」と入力して Enter キーを押します。

7. コンソールで、hello-server ワークロードのステータスが「OK」に変わるまで、[ワークロード] ページを更新します。

クラスタを確認する

ワークロードのスケールアップが正常に行われたら、クラスタの [ノード] タブに戻ります。

1. hello-demo-cluster をクリックします。

2. 次に、[ノード] タブをクリックします。

ノードプールが大きいほど処理の重いワークロードに対応できますが、インフラストラクチャ リソースの使用状況に注目してください。

GKE はクラスタのリソースを最大限に利用しますが、最適化の余地はまだあります。1 つのノードがメモリの大半を使用していますが、2 つのノードでは相当量のメモリが未使用です。

この時点でアプリのスケールアップを続けると、同じようなパターンが見え始めるでしょう。Kubernetes は hello-server Deployment の新しいレプリカごとにノードを見つけようとしますが、使用できるノードがない場合、CPU が約 600m の新しいノードを作成します。

ビンパッキング問題

ビンパッキング問題とは、体積や形状にばらつきがある品目を、数に限りのある、形状の定まった「ビン（容器）」、つまりコンテナに収めなくてはならないという問題です。要するに、ある品目をできる限り少ない数のビンにいかにして効率よく「パッキング」するかという課題です。

これは、実行するアプリケーションに合わせて Kubernetes クラスタを最適化するときに直面する課題と似ています。複数のアプリケーションがあり、リソースの要件（メモリ、CPU など）がそれぞれで異なると仮定します。これらのアプリケーションは、Kubernetes によって管理されるインフラストラクチャ リソース（おそらくはクラスタの費用の大半が費やされる部分）にできる限り効率的に収める必要があります。

Hello デモクラスタは効率よくビンパッキングされていません。このワークロードにもっと適切なマシンタイプを使用するよう Kubernetes で構成すると、費用効率が向上するでしょう。

注: 説明をわかりやすくするため、このラボでは 1 つのアプリケーションの最適化に専念します。実際には、要件の異なる多数のアプリケーションを Kubernetes クラスタで実行することになるでしょう。Kubernetes には、Kubernetes で利用可能なさまざまなマシンからアプリケーションのワークロードに最適なものを探す際に役立つツールが含まれています。複数の GKE ノードプールを使用して、1 つの Kubernetes クラスタで複数のマシンタイプを管理できます。

最適化されたノードプールに移行する

• より大きなマシンタイプを使用して新しいノードプールを作成します。

gcloud container node-pools create larger-pool \ --cluster=hello-demo-cluster \ --machine-type=e2-standard-2 \ --num-nodes=1 \ --zone={{{project_0.default_zone | "ZONE"}}}

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。 ノードプールを作成する

次の手順で Pod を新しいノードプールに移行できます。

1. 既存のノードプールを閉鎖する: これにより、既存のノードプール（node）内のノードがスケジュール不可に設定されます。スケジュール不可に設定されると、Kubernetes はこれらのノードに新しい Pod をスケジュールしなくなります。
2. 既存のノードプールをドレインする: これにより、既存のノードプール（node）のノードで実行されているワークロードが正常に強制排除されます。

• まず、元のノードプールを閉鎖します。

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=my-node-pool -o=name); do kubectl cordon "$node"; done

• 次に、プールをドレインします。

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=my-node-pool -o=name); do kubectl drain --force --ignore-daemonsets --delete-emptydir-data --grace-period=10 "$node"; done

この時点で、Pod が新しい larger-pool というノードプールで実行されていることが確認できます。

kubectl get pods -o=wide

3. Pod が移行されたので、古いノードプールを削除しても問題ありません。

gcloud container node-pools delete my-node-pool --cluster hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}

4. 続行するか確認のメッセージが表示されたら、「y」と入力して Enter キーを押します。

削除に 2 分ほどかかります。その間に次のセクションに目を通してください。

費用分析

この時点で、3 つの e2-medium マシンを必要とする同じワークロードを 1 つの e2-standard-2 マシンで実行しています。

そこで、E2 標準マシンタイプと E2 共有コア マシンタイプを使用する 1 時間あたりの費用に注目してみましょう。

標準:

共有コア:

3 つの e2-medium マシンの費用は 1 時間あたり約 $0.1 ですが、1 つの e2-standard-2 は 1 時間あたり約 $0.067 です。

1 時間あたり $0.04 の削減は小さいと感じるかもしれませんが、実行するアプリケーションのライフサイクルの間、これがずっと積み重なります。もっと規模が大きければ、さらに目に見える違いがあるでしょう。e2-standard-2 マシンはこのワークロードをより効率よくパッキングできるので、未使用の領域が減り、スケールアップの費用が増えるペースが下がります。

これは興味深い事実です。というのも、E2-medium は共有コア マシンタイプであり、リソースを大量に消費しない小規模なアプリケーションに優れた費用対効果を提供するためのものだからです。ところが、Hello-App の現在のワークロードについては、より大きなマシンタイプでノードプールを使用することが、結果としてより費用対効果に優れた戦略となります。

Cloud コンソールで、hello-demo クラスタの [ノード] タブがまだ表示されているはずです。このタブを更新し、larger-pool ノードの [リクエストされた CPU] と [割り当て可能な CPU] の各フィールドを確認します。

さらに最適化できる余地があることがわかります。この新しいノードは、別のノードをプロビジョニングしなくても、ワークロードの別のレプリカを含むことができます。またはこの場合でも、アプリケーションで必要とされる CPU とメモリの量に適合するカスタムサイズのマシンタイプを選択すると、さらにリソースの使用を抑えられる可能性があります。

リソースの価格はクラスタのロケーションによって異なることに留意する必要があります。このラボの次のセクションでは、最適なリージョンを選択し、リージョン クラスタを管理する方法を説明します。

クラスタに適したロケーションを選択する

リージョンとゾーンの概要

クラスタのノードに使用される Compute Engine リソースは、世界各地の複数のロケーションでホストされています。これらのロケーションはリージョンとゾーンからなります。リージョンとは、リソースをホストできる特定の地理的位置です。リージョンには 3 つ以上のゾーンがあります。

仮想マシン インスタンスやゾーン永続ディスクなど、ゾーンを有効範囲とするリソースはゾーンリソースと呼ばれます。静的外部 IP アドレスなど、それ以外のリソースはリージョン リソースです。リージョン リソースは、ゾーンに関係なく、そのリージョン内のどのリソースでも使用できますが、ゾーンリソースは同じゾーン内の他のリソースでのみ使用できます。

リージョンまたはゾーンを選択する場合、次のことに注意してください。

1. 障害対応 - アプリで使用するリソースが 1 つのゾーン内にのみ配置されている場合、そのゾーンが使用できなくなると、アプリも使用できなくなります。規模が大きく、需要の多いアプリであれば、障害に対応するため、リソースを複数のゾーンまたはリージョンに分散することをおすすめします。
2. ネットワーク レイテンシの短縮 - サービス提供地点に近いリージョンまたはゾーンを選択すると、ネットワーク レイテンシを軽減できます。たとえば、ほとんどの顧客が米国東海岸にいる場合は、このエリアに近いリージョンとゾーンをメインに選択します。

クラスタのベスト プラクティス

リージョンによる費用の差異はさまざまな要因に左右されます。たとえば、us-west2 リージョンのリソースは、us-central1 のリソースより高価になりがちです。

クラスタで使用するリージョンまたはゾーンを選択する場合は、アプリで実行される処理を確認します。レイテンシの影響を受けやすい本番環境では、ネットワークのレイテンシが短縮され、効率に優れるリージョンまたはゾーンにアプリを配置すると、パフォーマンスと費用の最適なバランスが得られるでしょう。

しかし、レイテンシの影響を受けにくい開発環境では、アプリを廉価なリージョンに配置することで費用を抑えられます。

注: VM とリージョン別の料金については、VM インスタンスの料金をご覧ください。

クラスタの可用性に対処する

GKE で使用できるクラスタのタイプには、ゾーン（シングルゾーンまたはマルチゾーン）とリージョンがあります。額面の料金では、シングルゾーンのクラスタが最も廉価です。しかし、アプリケーションに高い可用性を与えるには、クラスタのインフラストラクチャ リソースを複数のゾーンに分散するのが最適です。

多くのケースで、マルチゾーン クラスタまたはリージョン クラスタを使用してクラスタ内の可用性を優先させると、パフォーマンスと費用のバランスが最適なアーキテクチャになります。

注: マルチゾーン クラスタでは 1 つ以上のゾーンが追加で定義されますが、コントロール プレーンは 1 つのレプリカのみが単一のゾーンで動作しています。ワークロードはコントロール プレーンのゾーンが停止しているときも実行できますが、コントロール プレーンが使用可能になるまでクラスタの構成を変更することはできません。

リージョン クラスタには、特定の 1 リージョン内の複数ゾーンで動作する複数のコントロール プレーンのレプリカが含まれています。ノードも、コントロール プレーンのレプリカが動作する各ゾーンで実行されます。リージョン クラスタは最も多くのリソースを消費する代わりに最大の可用性を提供します。

詳細については、クラスタのタイプに関する記事をご覧ください。

タスク 3. リージョン クラスタを管理する

設定

複数のゾーンにまたがったクラスタのリソース管理は、やや複雑になります。注意を怠ると、Pod 間での不要なゾーン間通信によって余計な費用が積み重なる可能性があります。

このセクションでは、クラスタのネットワーク トラフィックを観察し、大量のトラフィックを相互に送っている通信量の多い 2 つの Pod を同じゾーンに移動します。

1. [Cloud Shell] タブで、新しいリージョン クラスタを作成します（このコマンドは完了までに数分かかります）。

gcloud container clusters create regional-demo --region={{{project_0.default_region | "REGION"}}} --num-nodes=1

Pod とノードでやり取りされるトラフィックを実際に確認するため、リージョン クラスタ内で 2 つの Pod を別々のノードに作成します。モニタリングできるトラフィックを生成するために、ping を使用して Pod 間でトラフィックを生成します。

2. 次のコマンドを実行して、最初の Pod のマニフェストを作成します。

cat << EOF > pod-1.yaml apiVersion: v1 kind: Pod metadata: name: pod-1 labels: security: demo spec: containers: - name: container-1 image: wbitt/network-multitool EOF

3. 次のコマンドを使用して、Kubernetes で最初の Pod を作成します。

kubectl apply -f pod-1.yaml

4. 続けて、以下のコマンドを実行して、2 番目の Pod のマニフェストを作成します。

cat << EOF > pod-2.yaml apiVersion: v1 kind: Pod metadata: name: pod-2 spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - demo topologyKey: "kubernetes.io/hostname" containers: - name: container-2 image: gcr.io/google-samples/node-hello:1.0 EOF

5. 2 番目の Pod を Kubernetes に作成します。

kubectl apply -f pod-2.yaml

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。 Pod の作成を確認する

作成した Pod は、node-hello コンテナを使用し、リクエストされたときに Hello Kubernetes メッセージを出力します。

作成した pod-2.yaml ファイルを調べると、podAntiAffinity がルールとして定義されていることがわかります。これにより、この Pod は pod-1 と同じノードにスケジュールされないように指定されます。pod-1 の security: demo ラベルに基づいて matchExpressions のロジックが適用されるためです。podAffinity は Pod が同じノードにスケジュールされるようにし、podAntiAffinity は Pod が同じノードにスケジュールされないようにします。

注: Kubernetes には Node Affinity のコンセプトもあり、アプリケーションを最適なマシンタイプで実行するのに利用できます。

今回のケースでは、ノード間のトラフィックを可視化するのに podAntiAffinity を使用しますが、podAntiAffinity と podAffinity を賢く使用すれば、リージョン クラスタのリソースをさらに効率よく利用できます。

6. 作成した Pod を表示します。

kubectl get pod pod-1 pod-2 --output wide

どちらの Pod も [Running] ステータスと内部 IP を返します。

出力例: NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-1 1/1 Running 0 4m40s 10.60.0.7 gke-regional-demo-default-pool-abb297f1-tz3b pod-2 1/1 Running 0 4m31s 10.60.2.3 gke-regional-demo-default-pool-28b6c708-qn7q

pod-2 の IP アドレスをメモしておきます。これは次のコマンドで使用します。

トラフィックをシミュレートする

1. pod-1 コンテナへのシェルを取得します。

kubectl exec -it pod-1 -- sh

2. シェルを使用して、リクエストを pod-2 に送信します。ここで [POD-2-IP] は、pod-2 のものとして表示された内部 IP アドレスに置き換えます。

ping [POD-2-IP]

pod-1 から pod-2 への ping で発生する平均レイテンシをメモしておきます。

フローログを確認する

pod-1 から pod-2 に ping を実行するときに、クラスタが作成された VPC のサブネットで、トラフィックを観察するためにフローログを有効にすることができます。

1. Cloud コンソールで、ナビゲーション メニューを開き、[ネットワーキング] セクションの [VPC ネットワーク] を選択します。

2. [default] ネットワークをクリックします。[サブネット] タブで、 リージョンの default サブネットを探してクリックします。

3. 画面の上部にある [編集] をクリックします。

4. [フローログ] で [オン] を選択します。

5. 次に、[保存] をクリックします。

6. 次に、[ログ エクスプローラでフローログを表示する] をクリックします。

ログのリストが表示され、いずれかのインスタンスで送信または受信があるたびに大量の情報が示されます。

ログが生成されない場合は、上記のスクリーンショットを参考にして、「vpc_flows」の前にある「/」を「%2F」に置き換えます。

このままでは少し読みづらいかもしれません。次に、このログを BigQuery テーブルに書き出して、関連情報をクエリできるようにします。

7. [操作] > [シンクの作成] をクリックします。

8. シンクに「FlowLogsSample」という名前を付けます。

9. [次へ] をクリックします。

シンクの宛先

• [シンクサービスの選択] で [BigQuery データセット] を選択します。
• [BigQuery データセット] で [新しい BigQuery データセットを作成する] を選択します。
• データセットに「us_flow_logs」という名前を付け、[データセットを作成] をクリックします。

これ以外はそのままで構いません。

1. [シンクを作成] をクリックします。

2. 新しく作成したデータセットを確認してみましょう。Cloud コンソールのナビゲーション メニューで、[分析] セクションの [BigQuery] をクリックします。

3. [完了] をクリックします。

4. プロジェクト名を選択してから us_flow_logs を選択し、新しく作成されたテーブルを表示します。テーブルが一切表示されていない場合は、作成されるまで画面を更新する必要があります。

5. us_flow_logs データセットの下で compute_googleapis_com_vpc_flows_xxx テーブルをクリックします。

6. [クエリ] > [新しいタブ] をクリックします。

7. BigQuery エディタで、SELECT と FROM の間に以下のコードを貼り付けます。

jsonPayload.src_instance.zone AS src_zone, jsonPayload.src_instance.vm_name AS src_vm, jsonPayload.dest_instance.zone AS dest_zone, jsonPayload.dest_instance.vm_name

8. [実行] をクリックします。

先ほどのフローログが、source zone、source vm、destination zone、destination vm でフィルタされて表示されます。

regional-demo クラスタ内の 2 つのゾーン間で呼び出しが生成されている行を探します。

注: 実際のログの数値は、このサンプルの画像に示されているものと完全には一致しません。

フローログを観察すると、異なるゾーン間で頻繁にトラフィックが発生することがわかります。

次に、Pod を同じゾーンに移動し、効果を観察してみましょう。

通信量の多い Pod を移動して、複数ゾーンにまたがるトラフィックの費用を最小限に抑える

1. Cloud Shell に戻り、Ctrl+C キーを押して ping コマンドをキャンセルします。

2. exit コマンドを入力して pod-1 のシェルを終了します。

exit

3. 次のコマンドを実行して、pod-2 のマニフェストを編集します。

sed -i 's/podAntiAffinity/podAffinity/g' pod-2.yaml

podAntiAffinity ルールを podAffinity ルールに変更しますが、ロジックは変更しません。これで pod-2 は、pod-1 と同じノードにスケジュールされます。

4. 実行中の pod-2 を削除します。

kubectl delete pod pod-2

5. pod-2 が削除されたら、新しく編集したマニフェストを使用して再作成します。

kubectl create -f pod-2.yaml

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。 トラフィックをシミュレートする

6. 作成した Pod を表示し、どちらもステータスが「Running」であることを確認します。

kubectl get pod pod-1 pod-2 --output wide

出力を見ると、Pod-1 と Pod-2 が同じノードで実行されていることがわかります。

pod-2 の IP アドレスをメモしておきます。これは次のコマンドで使用します。

7. pod-1 コンテナへのシェルを取得します。

kubectl exec -it pod-1 -- sh

8. シェルを使用して、リクエストを pod-2 に送信します。ここで [POD-2-IP] は、先ほどのコマンドで取得した pod-2 の内部 IP に置き換えます。

ping [POD-2-IP]

2 つの Pod でやり取りされる ping の平均時間が、かなり短くなったことがわかるでしょう。

この時点で、フローログの BigQuery データセットに戻り、最新のログをチェックして、望ましくないゾーン間通信がなくなったことを確認できます。

費用分析

Google Cloud 内の VM 間外向きトラフィックの料金に注目します。

Pod が別々のゾーンから互いに ping を実行すると、1 GB あたり $0.01 の料金が課されます。少額だと思うかもしれませんが、複数のサービスがゾーン間で頻繁に呼び出しを行う大規模なクラスタであれば、たちまち費用がかさみます。

Pod を同じゾーンに移動したので、ping の実行に料金が発生しなくなりました。

お疲れさまでした

ここでは、GKE クラスタの一部である仮想マシンの費用を最適化する方法について学習しました。まず、より適切なマシンタイプのノードプールにワークロードを移行し、次に、異なるリージョンの長所と短所について理解したうえで、最後に、リージョン クラスタ内の通信の多い Pod を通信先の Pod と同じゾーンに配置しました。

このラボでは、GKE VM 向けの費用対効果に優れたツールと戦略を紹介しましたが、仮想マシンを最適化するには、まずアプリケーションとそのニーズを理解する必要があります。実行するワークロードの種類を知り、アプリケーションのニーズを見積もると、GKE クラスタの基盤となる仮想マシンに最適なロケーションとマシンタイプはどれかの判断が変わってきます。

クラスタのインフラストラクチャを効率的に利用することは、費用の最適化に大いに役立ちます。

次のステップと詳細情報

• マシンタイプに関するドキュメント
• コストが最適化された Kubernetes アプリケーションを GKE で実行するためのベスト プラクティス: 適切なマシンタイプを選択する
• コストが最適化された Kubernetes アプリケーションを GKE で実行するためのベスト プラクティス: 適切なリージョンを選択する

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2025 年 5 月 14 日

ラボの最終テスト日: 2025 年 5 月 14 日

Copyright 2025 Google LLC. All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。