GSP662

概要

Google Cloud 内にウェブサイトをデプロイする方法はたくさんあります。各ソリューションで提供される機能や制御レベルはそれぞれ異なります。Compute Engine では、ウェブサイトの実行に使用するインフラストラクチャを細かく制御できますが、Google Kubernetes Engine（GKE）や App Engine などのソリューションより運用管理に手間がかかります。Compute Engine を使用すると、仮想マシン、ロードバランサといったインフラストラクチャの側面を細かく制御できます。

このラボでは、サンプルのアプリケーションとして「Fancy Store」という名前の e コマース ウェブサイトをデプロイする方法と、Compute Engine でウェブサイトのデプロイとスケーリングを簡単に実行できることを確認します。

学習内容

このラボでは、次のタスクの実行方法について学びます。

• Compute Engine インスタンスを作成する
• ソース インスタンスからインスタンス テンプレートを作成する
• マネージド インスタンス グループを作成する
• マネージド インスタンス グループのヘルスチェックを作成してテストする
• HTTP(S) ロードバランサを作成する
• ロードバランサのヘルスチェックを作成する
• キャッシュにコンテンツ配信ネットワーク（CDN）を使用する

このラボが完了するまでに、マネージド インスタンス グループ内に複数のインスタンスを作成し、ウェブサイトの自動修復、ロード バランシング、自動スケーリング、ローリング アップデートを行えるようになります。

設定と要件

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

こちらの説明をお読みください。ラボには時間制限があり、一時停止することはできません。タイマーは、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 のプロダクトやサービスにアクセスするには、ナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。

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 の概要ガイドをご覧ください。

リージョンとゾーンを設定する

一部の Compute Engine リソースは、リージョン内やゾーン内に存在します。リージョンとは、リソースを実行できる特定の地理的なロケーションです。1 つのリージョンには 1 つ以上のゾーンがあります。

Cloud Shell で次の gcloud コマンドを実行して、ラボのデフォルトのリージョンとゾーンを設定します。

gcloud config set compute/zone "{{{project_0.default_zone|ZONE}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.default_region|REGION}}}" export REGION=$(gcloud config get compute/region)

タスク 1. Compute Engine API を有効にする

• 以下のコマンドを実行して、Compute Engine API を有効にします。

gcloud services enable compute.googleapis.com

タスク 2. Cloud Storage バケットを作成する

Cloud Storage バケットに、ビルド済みのコードと起動スクリプトを格納します。

• Cloud Shell で次のコマンドを実行して、新しい Cloud Storage バケットを作成します。

gcloud storage buckets create gs://fancy-store-{{{project_0.project_id | Project ID}}}

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Cloud Storage バケットを作成する

タスク 3. ソース リポジトリのクローンを作成する

このラボでは、monolith-to-microservices リポジトリに基づく既存の「Fancy Store」e コマース ウェブサイトをウェブサイトのベースとして使用します。

このタスクでは、Compute Engine へのデプロイに集中するために、ソースコードのクローンを作成します。このラボで後ほどコードを少し更新して、Compute Engine での更新が簡単であることを確認します。

1. 以下のコマンドを実行して、ソースコードのクローンを作成し、monolith-to-microservices ディレクトリに移動します。

git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices

2. ここでコードの初めてのビルドを実行し、アプリケーションをローカルで実行できるようにします。

./setup.sh

このスクリプトの実行が完了するまでに数分かかります。

3. 完了したら、以下のコマンドを使用して、対応している NodeJS バージョンを Cloud Shell が実行していることを確認します。

nvm install --lts

4. 次に、アプリケーションをテストするために以下のコマンドを実行し、microservices ディレクトリに移動して、ウェブサーバーを起動します。

cd microservices npm start

次の出力が表示されます。

出力:

Products microservice listening on port 8082! Frontend microservice listening on port 8080! Orders microservice listening on port 8081!

5. 「ウェブでプレビュー」アイコンをクリックし、[ポート 8080 でプレビュー] を選択してアプリケーションをプレビューします。

新しいウィンドウが開き、Fancy Store のフロントエンドが表示されます。

注: [プレビュー] オプション内にフロントエンドが表示されます。ただし、Products 関数と Orders 関数は、これらのサービスがまだ公開されていないため動作しません。

6. ウェブサイトを確認したら、このウィンドウを閉じ、ターミナル ウィンドウで Ctrl+C キーを押してウェブサーバー プロセスを停止します。

タスク 4. Compute Engine インスタンスを作成する

Compute Engine インスタンスのデプロイを開始します。

以降のセクションでは、次の操作を行います。

1. 起動スクリプトを作成してインスタンスを構成する。
2. ソースコードのクローンを作成して、Cloud Storage にアップロードする。
3. Compute Engine インスタンスをデプロイしてバックエンドのマイクロサービスをホストする。
4. バックエンドのマイクロサービス インスタンスを使用するようにフロントエンドのコードを再構成する。
5. Compute Engine インスタンスをデプロイして、フロントエンドのマイクロサービスをホストする。
6. 通信を許可するようにネットワークを構成する。

起動スクリプトを作成する

起動スクリプトを使用して、インスタンスが起動するたびに実行する処理をインスタンスに指示します。このようにしてインスタンスを自動的に構成します。

1. Cloud Shell ターミナルで以下のコマンドを実行して、startup-script.sh というファイルを作成します。

touch ~/monolith-to-microservices/startup-script.sh

2. Cloud Shell ツールバーの [エディタを開く] をクリックして、コードエディタを開きます。

3. monolith-to-microservices フォルダに移動します。

4. startup-script.sh ファイルに次のコードを追加します。その後、コードの一部を編集します。

#!/bin/bash # ロギングモニタをインストールする。モニタは syslog に # 送信されたログを自動的にモニタリングする curl -s "https://storage.googleapis.com/signals-agents/logging/google-fluentd-install.sh" | bash service google-fluentd restart & # apt から依存関係をインストールする apt-get update apt-get install -yq ca-certificates git build-essential supervisor psmisc # nodejs をインストールする apt-get install -y nodejs npm # Google Cloud Storage バケットからアプリケーションのソースコードを取得する mkdir /fancy-store gcloud storage cp -r gs://fancy-store-[DEVSHELL_PROJECT_ID]/monolith-to-microservices/microservices/* /fancy-store/ # アプリケーションの依存関係をインストールする cd /fancy-store/ npm install # nodeapp ユーザーを作成する。アプリケーションはこのユーザーとして実行する useradd -m -d /home/nodeapp nodeapp chown -R nodeapp:nodeapp /fancy-store # ノード アプリケーションを実行するように supervisor を構成する cat >/etc/supervisor/conf.d/node-app.conf << EOF [program:nodeapp] directory=/fancy-store command=npm start autostart=true autorestart=true user=nodeapp environment=HOME="/home/nodeapp",USER="nodeapp",NODE_ENV="production" stdout_logfile=syslog stderr_logfile=syslog EOF supervisorctl reread supervisorctl update

5. [DEVSHELL_PROJECT_ID] をプロジェクト ID（{{{project_0.project_id | Project ID}}}）に置き換えます。
6. ファイル > 保存 をクリックするか、Ctrl+S キーを押して startup-script.sh ファイルを保存します（まだ閉じないでください）。

7. [Save] をクリックするか、Ctrl+S キーを押して startup-script.sh ファイルを保存しますが、まだ閉じないでください。

8. Cloud Shell コードエディタの右下で、[End of Line Sequence]（改行シーケンス）が [CRLF] ではなく [LF] に設定されていることを確認します。



• [CRLF] に設定されている場合は、[CRLF] をクリックしてからプルダウンで [LF] を選択します。
• すでに [LF] に設定されている場合は、そのままにします。

Cloud Shell ターミナルに戻り、以下のコマンドを実行して startup-script.sh ファイルをバケットにコピーします。

gcloud storage cp ~/monolith-to-microservices/startup-script.sh gs://fancy-store-{{{project_0.project_id | Project ID}}}

これで、https://storage.googleapis.com/[BUCKET_NAME]/startup-script.sh から起動スクリプトにアクセスできるようになります。

[BUCKET_NAME] は Cloud Storage バケットの名前に置き換えます。起動スクリプトは、デフォルトで、承認されたユーザーとサービス アカウントのみが閲覧できます。ウェブブラウザからアクセスすることはできません。Compute Engine インスタンスは、サービス アカウントを使用して自動的に起動スクリプトにアクセスできるようになります。

起動スクリプトは次のタスクを実行します。

• Logging エージェントをインストールします。このエージェントは syslog から自動的にログを収集します。
• Node.js と Supervisor をインストールします。Supervisor はアプリをデーモンとして実行します。
• Cloud Storage バケットからアプリケーションのソースコードのクローンを作成し、依存関係をインストールします。
• アプリケーションを実行するように Supervisor を構成します。アプリケーションが予期せずに終了した場合や、管理者やプロセスにより停止した場合、Supervisor はアプリケーションを確実に再起動します。また、アプリの stdout と stderr を syslog に送信し、Logging エージェントが収集できるようにします。

Cloud Storage バケットにコードをコピーする

インスタンスを起動すると、インスタンスは Cloud Storage バケットからコードを pull するため、ユーザーはコードの .env ファイルに構成変数を保存できます。

注: 他の場所から環境変数を pull するようにコーディングすることもできます。ただし、今回はデモであるため、簡単な方法で構成します。本番環境では、通常コードの外部に環境変数を保存するようにします。
• 以下のコマンドを実行して、クローニングしたコードをバケットにコピーします。
cd ~ rm -rf monolith-to-microservices/*/node_modules gcloud storage cp -r monolith-to-microservices gs://fancy-store-{{{project_0.project_id | Project ID}}}/ 注: できるだけ速く効率的にコピーするために、依存関係のディレクトリである node_modules は削除されます。これらはインスタンスの起動時にインスタンス上に再作成されます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Cloud Storage バケットに起動スクリプトとコードをコピーする

バックエンド インスタンスをデプロイする

デプロイする最初のインスタンスはバックエンド インスタンスです。バックエンド インスタンスには、Orders と Products のマイクロサービスを配置します。

注: 本番環境では、各マイクロサービスを別々のインスタンスおよびインスタンス グループに分けて、個別にスケーリングできるようにします。今回はデモであるため、両方のバックエンド マイクロサービス（Orders と Products）を同じインスタンスおよびインスタンス グループに配置します。
• 以下のコマンドを実行して、起動スクリプトを使用するように構成された e2-standard-2 インスタンスを作成します。バックエンド インスタンスであることを示すためにインスタンスに backend のタグを付け、後で専用のファイアウォール ルールを適用できるようにします。
gcloud compute instances create backend \ --zone={{{project_0.default_zone | zone}}} \ --machine-type=e2-standard-2 \ --tags=backend \ --image-family={{{project_0.startup_script.debian_image_id_short | Debian image name}}} \ --image-project=debian-cloud \ --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-{{{project_0.project_id | Project ID}}}/startup-script.sh

バックエンドへの接続を構成する

アプリケーションのフロントエンドをデプロイする前に、先ほどデプロイしたバックエンドを参照するように構成を更新する必要があります。

1. 以下のコマンドでバックエンドの外部 IP アドレスを取得し、バックエンド インスタンスの EXTERNAL_IP（外部 IP）の値を確認します。
gcloud compute instances list

出力例:

NAME: backend ZONE: {{{project_0.default_zone | zone}}} MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: INTERNAL_IP: 10.142.0.2 EXTERNAL_IP: 35.237.245.193 STATUS: RUNNING

2. バックエンドの外部 IP をコピーします。

3. Cloud Shell エクスプローラで [monolith-to-microservices] > [react-app] に移動します。

4. コードエディタで [View] > [Toggle Hidden Files] を選択し、.env ファイルを表示します。

次のステップでは、バックエンドの外部 IP を参照するよう .env ファイルを編集します。[BACKEND_ADDRESS] は、直前に実行した gcloud コマンドで確認したバックエンド インスタンスの外部 IP アドレスです。

5. .env ファイルで、localhost を [BACKEND_ADDRESS] に置き換えます。
REACT_APP_ORDERS_URL=http://[BACKEND_ADDRESS]:8081/api/orders REACT_APP_PRODUCTS_URL=http://[BACKEND_ADDRESS]:8082/api/products

6. ファイルを保存します。

7. Cloud Shell で、以下のコマンドを実行して react-app を再ビルドします。これにより、フロントエンドのコードが次のように更新されます。

cd ~/monolith-to-microservices/react-app npm install && npm run-script build
8. 以下のコマンドを実行して、アプリケーション コードを Cloud Storage バケットにコピーします。
cd ~ rm -rf monolith-to-microservices/*/node_modules gcloud storage cp -r monolith-to-microservices gs://fancy-store-{{{project_0.project_id | Project ID}}}/

フロントエンド インスタンスをデプロイする

コードの構成が完了し、フロントエンド インスタンスをデプロイする準備が整いました。

• 前回と同じような以下のコマンドを実行してフロントエンド インスタンスをデプロイします。ファイアウォールで使用するために、このインスタンスには frontend のタグを付けます。
gcloud compute instances create frontend \ --zone={{{project_0.default_zone | zone}}} \ --machine-type=e2-standard-2 \ --tags=frontend \ --image-family={{{project_0.startup_script.debian_image_id_short | Debian image name}}} \ --image-project=debian-cloud \ --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-{{{project_0.project_id | Project ID}}}/startup-script.sh 注: コードは、デフォルトですべてのマイクロサービスを起動するように作られています。ここではシンプルにするために、フロントエンドとバックエンドの両方のインスタンスでデプロイ コマンドと起動スクリプトを使用するので、両方のインスタンスですべてのマイクロサービスが実行されます。本番環境では、各コンポーネントで必要なマイクロサービスだけを実行するようにします。

ネットワークを構成する

1. 以下のコマンドを実行して、フロントエンドではポート 8080 へのアクセス、バックエンドではポート 8081、8082 へのアクセスを許可するように、ファイアウォール ルールを作成します。次のファイアウォール コマンドでは、アプリケーションのインスタンス作成時に割り当てたタグを使用します。
gcloud compute firewall-rules create fw-fe \ --allow tcp:8080 \ --target-tags=frontend gcloud compute firewall-rules create fw-be \ --allow tcp:8081-8082 \ --target-tags=backend

これでウェブサイトが完全に機能するようになりました。

2. frontend の外部 IP にアクセスするには、そのアドレスを知っておく必要があります。以下のコマンドを実行して frontend インスタンスの EXTERNAL_IP（外部 IP）を確認します。
gcloud compute instances list

出力例:

NAME: backend ZONE: us-central1-f MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: INTERNAL_IP: 10.128.0.2 EXTERNAL_IP: 34.27.178.79 STATUS: RUNNING NAME: frontend ZONE: us-central1-f MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: INTERNAL_IP: 10.128.0.3 EXTERNAL_IP: 34.172.241.242 STATUS: RUNNING

インスタンスが起動して構成されるまで数分かかることがあります。

3. 3 分待ってからブラウザの新しいタブを開き、URL に http://[FRONTEND_ADDRESS]:8080 と入力してウェブサイトにアクセスします。[FRONTEND_ADDRESS] は、先ほど確認した frontend インスタンスの EXTERNAL_IP（外部 IP）に置き換えます。

4. [Products] と [Orders] ページにアクセスし、動作することを確認します。



[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 インスタンスをデプロイしてネットワークを構成する

タスク 5. マネージド インスタンス グループを作成する

アプリケーションのスケーリングを可能にするために、マネージド インスタンス グループを作成します。また、frontend インスタンスと backend インスタンスをインスタンス テンプレートとして使用します。

マネージド インスタンス グループ（MIG）には、単一のゾーンで単一のエンティティとして管理可能な同一のインスタンスが複数含まれます。マネージド インスタンス グループは、インスタンスの可用性をプロアクティブに維持する（ステータスを RUNNING（実行中）の状態に保つ）ことで、アプリケーションの高可用性を維持します。自動修復、ロード バランシング、自動スケーリング、ローリング アップデートを行えるよう、フロントエンドとバックエンドの両方のインスタンスでマネージド インスタンス グループを使用します。

ソース インスタンスからインスタンス テンプレートを作成する

マネージド インスタンス グループを作成するには、まず最初にグループのベースとなるインスタンス テンプレートを作成する必要があります。インスタンス テンプレートを使用することで、新しい VM インスタンスを作成する際に使用するマシンタイプ、ブートディスク イメージまたはコンテナ イメージ、ネットワーク、その他のインスタンス プロパティを定義できます。また、マネージド インスタンス グループに含めるインスタンスや、独立したインスタンスを作成することもできます。

インスタンス テンプレートを作成するには、作成済みの既存のインスタンスを使用します。

1. まず、以下のコマンドを実行して両方のインスタンスを停止します。
gcloud compute instances stop frontend --zone={{{project_0.default_zone | zone}}} gcloud compute instances stop backend --zone={{{project_0.default_zone | zone}}}
2. 次に、以下のコマンドを使用して、各ソース インスタンスからインスタンス テンプレートを作成します。
gcloud compute instance-templates create fancy-fe \ --source-instance-zone={{{project_0.default_zone | zone}}} \ --source-instance=frontend gcloud compute instance-templates create fancy-be \ --source-instance-zone={{{project_0.default_zone | zone}}} \ --source-instance=backend
3. 以下のコマンドを実行して、インスタンス テンプレートが作成されたことを確認します。
gcloud compute instance-templates list

出力例:

NAME: fancy-be MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: CREATION_TIMESTAMP: 2023-07-25T14:52:21.933-07:00 NAME: fancy-fe MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: CREATION_TIMESTAMP: 2023-07-25T14:52:15.442-07:00
4. インスタンス テンプレートを作成したら、以下のコマンドを実行して backend VM を削除し、リソース容量を節約します。
gcloud compute instances delete backend --zone={{{project_0.default_zone | zone}}}
5. プロンプトが表示されたら、「y」と入力します。

通常は frontend VM も削除できますが、このラボでは後ほどこれを使用してインスタンス テンプレートを更新します。

マネージド インスタンス グループを作成する

1. 次に、以下のコマンドを実行して、フロントエンド用とバックエンド用の 2 つのマネージド インスタンス グループを作成します。
gcloud compute instance-groups managed create fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}} \ --base-instance-name fancy-fe \ --size 2 \ --template fancy-fe gcloud compute instance-groups managed create fancy-be-mig \ --zone={{{project_0.default_zone | zone}}} \ --base-instance-name fancy-be \ --size 2 \ --template fancy-be

これらのマネージド インスタンス グループではインスタンス テンプレートを使用して、各グループ内で 2 つのインスタンスが起動するように構成します。インタンスには、base-instance-name で指定した文字列の後にランダムな文字が複数付いた名前が自動で付けられます。

2. 以下のコマンドを使用し、アプリケーションにおいて、frontend マイクロサービスをポート 8080 で、backend マイクロサービスを orders に対してはポート 8081、products に対してはポート 8082 でそれぞれ実行します。
gcloud compute instance-groups set-named-ports fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}} \ --named-ports frontend:8080 gcloud compute instance-groups set-named-ports fancy-be-mig \ --zone={{{project_0.default_zone | zone}}} \ --named-ports orders:8081,products:8082

これらは標準のポートではないため、ポートを識別するために名前付きポートを指定します。名前付きポートは Key-Value ペアのメタデータで、サービス名とサービスを実行するポートを表します。名前付きポートをインスタンス グループに割り当てることで、そのインスタンス グループに含まれるすべてのインスタンスでサービスを利用できます。この情報は、後で構成する HTTP ロード バランシング サービスで使用されます。

自動修復を構成する

アプリケーションの可用性を高め、そのレスポンスを検証するために、マネージド インスタンス グループ用の自動修復ポリシーを構成します。

自動修復ポリシーは、アプリケーション ベースのヘルスチェックを使用して、アプリケーションのレスポンスが期待どおりであることを検証します。デフォルトの動作ではインスタンスのステータスが RUNNING（実行中）かどうかを検証するだけですが、アプリケーションのレスポンスを確認することでより正確に状態を知ることができます。

注: ロード バランシングと自動修復には、別々のヘルスチェックを使用します。ロード バランシングのヘルスチェックとは、インスタンスがユーザー トラフィックを受信しているかどうかの確認です。そのため、より積極的な実施が可能で、またそのように実施すべきです。そして、必要に応じてトラフィックをリダイレクトすることができるように、レスポンスのないインスタンスをすばやく把握します。 対照的に、自動修復のヘルスチェックでは、障害が発生しているインスタンスが Compute Engine によってプロアクティブに置き換えられるので、このヘルスチェックはロード バランシングのヘルスチェックより慎重に実施しなければなりません。
1. 以下のコマンドを実行して、3 回連続して Unhealthy（異常）ステータスが返った場合は修復を行うよう、フロントエンドとバックエンドの両方に対しヘルスチェックを作成します。
gcloud compute health-checks create http fancy-fe-hc \ --port 8080 \ --check-interval 30s \ --healthy-threshold 1 \ --timeout 10s \ --unhealthy-threshold 3 gcloud compute health-checks create http fancy-be-hc \ --port 8081 \ --request-path=/api/orders \ --check-interval 30s \ --healthy-threshold 1 \ --timeout 10s \ --unhealthy-threshold 3
2. 以下のコマンドを実行し、ヘルスチェックのプローブがポート 8080、8081 のマイクロサービスに接続できるようにファイアウォール ルールを作成します。
gcloud compute firewall-rules create allow-health-check \ --allow tcp:8080-8081 \ --source-ranges 130.211.0.0/22,35.191.0.0/16 \ --network default
3. 以下のコマンドを使用して、ヘルスチェックを各サービスに適用します。
gcloud compute instance-groups managed update fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}} \ --health-check fancy-fe-hc \ --initial-delay 300 gcloud compute instance-groups managed update fancy-be-mig \ --zone={{{project_0.default_zone | zone}}} \ --health-check fancy-be-hc \ --initial-delay 300 注: 自動修復でグループ内のインスタンスのモニタリングが開始するまで、15 分ほどかかることがあります。
4. そのため、ラボを続けながら、自動修復でモニタリングが開始するのを待ちます。ラボの最後に障害をシミュレーションして自動修復をテストします。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 マネージド インスタンス グループを作成する

タスク 6. ロードバランサを作成する

マネージド インスタンス グループを補完するには、HTTP(S) ロードバランサを使用してフロントエンドとバックエンドのマイクロサービスにトラフィックを配信し、マッピングを使用してパスルールに基づいて適切なバックエンド サービスにトラフィックを送信します。これにより、ロードバランスされた単一の IP ですべてのサービスが公開されます。

Google Cloud でのロード バランシング オプションの詳細については、Cloud Load Balancing の概要をご覧ください。

HTTP(S) ロードバランサを作成する

Google Cloud ではさまざまな種類のロードバランサを提供しています。このラボでは、トラフィックに HTTP(S) ロードバランサを使用します。HTTP ロードバランサの構成は次のとおりです。

• 受信したリクエストを転送ルールによってターゲットの HTTP プロキシに転送します。
• ターゲット HTTP プロキシは各リクエストを URL マップと照合し、各リクエストに適したバックエンド サービスを判断します。
• バックエンド サービスは、バックエンドの処理能力、ゾーン、インスタンスの健全性に基づき、適切なバックエンドに各リクエストを転送します。HTTP ヘルスチェックを使用して各バックエンド インスタンスの健全性を検証します。バックエンド サービスが HTTPS または HTTP/2 のヘルスチェックを使用するように構成されている場合、リクエストは、バックエンド インスタンスへの転送時に暗号化されます。
• ロードバランサとインスタンス間のセッションでは、HTTP、HTTPS、HTTP/2 プロトコルを使用できます。HTTPS または HTTP/2 を使用する場合、バックエンド サービスの各インスタンスには SSL 証明書が必要です。
注: このデモでは、SSL 証明書に関する複雑な手順を避けてシンプルに説明するために、HTTPS ではなく HTTP を使用します。本番環境では、できるだけ HTTPS を使用して暗号化することをおすすめします。
1. 以下のコマンドを実行して、各サービスのトラフィックに対応可能なインスタンスを判断するために使用するヘルスチェックを作成します。
gcloud compute health-checks create http fancy-fe-frontend-hc \ --request-path=/ \ --port=8080 gcloud compute health-checks create http fancy-be-orders-hc \ --request-path=/api/orders \ --port=8081 gcloud compute health-checks create http fancy-be-products-hc \ --request-path=/api/products \ --port=8082 注: これらは、ロードバランサ用のヘルスチェックであり、ロードバランサからのトラフィック転送のみを処理します。これにより、マネージド インスタンス グループがインスタンスを再作成することはありません。
2. 以下のコマンドを実行して、ロードバランスされたトラフィックの送信先となるバックエンド サービスを作成します。バックエンド サービスでは、先ほど作成したヘルスチェックと名前付きポートを使用します。
gcloud compute backend-services create fancy-fe-frontend \ --health-checks=fancy-fe-frontend-hc \ --port-name=frontend \ --global gcloud compute backend-services create fancy-be-orders \ --health-checks=fancy-be-orders-hc \ --port-name=orders \ --global gcloud compute backend-services create fancy-be-products \ --health-checks=fancy-be-products-hc \ --port-name=products \ --global
3. 以下のコマンドを実行して、ロードバランサのバックエンド サービスを追加します。
gcloud compute backend-services add-backend fancy-fe-frontend \ --instance-group-zone={{{project_0.default_zone | zone}}} \ --instance-group fancy-fe-mig \ --global gcloud compute backend-services add-backend fancy-be-orders \ --instance-group-zone={{{project_0.default_zone | zone}}} \ --instance-group fancy-be-mig \ --global gcloud compute backend-services add-backend fancy-be-products \ --instance-group-zone={{{project_0.default_zone | zone}}} \ --instance-group fancy-be-mig \ --global
4. 以下のコマンドを実行して、どの URL をどのバックエンド サービスに転送するかを定義する URL マップを作成します。
gcloud compute url-maps create fancy-map \ --default-service fancy-fe-frontend
5. 以下のコマンドを実行して、/api/orders と /api/products のパスをそれぞれのサービスに転送するパスマッチャーを作成します。
gcloud compute url-maps add-path-matcher fancy-map \ --default-service fancy-fe-frontend \ --path-matcher-name orders \ --path-rules "/api/orders=fancy-be-orders,/api/products=fancy-be-products"
6. 以下のコマンドを実行して、URL マップに関連付けるプロキシを作成します。
gcloud compute target-http-proxies create fancy-proxy \ --url-map fancy-map
7. 以下のコマンドを実行して、パブリック IP アドレスとポートをプロキシに関連付けるグローバル転送ルールを作成します。
gcloud compute forwarding-rules create fancy-http-rule \ --global \ --target-http-proxy fancy-proxy \ --ports 80

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 HTTP(S) ロードバランサを作成する

構成を更新する

新しい静的 IP アドレスを取得したので、frontend のコードを更新します。このコードではこれまで、backend インスタンスを参照するエフェメラル アドレスを指定していましたが、その代わりに新しい IP アドレスを指定します。

1. Cloud Shell で以下のコマンドを実行して、構成を含む .env ファイルが保存されている react-app フォルダに移動します。
cd ~/monolith-to-microservices/react-app/
2. 以下のコマンドを実行して、ロードバランサの IP アドレスを見つけます。
gcloud compute forwarding-rules list --global

出力例:

NAME: fancy-http-rule REGION: IP_ADDRESS: 34.111.203.235 IP_PROTOCOL: TCP TARGET: fancy-proxy
3. Cloud Shell エディタに戻って .env ファイルを再編集し、ロードバランサのパブリック IP を参照するようにします。[LB_IP] は先ほど確認したバックエンド インスタンスの外部 IP アドレスに置き換えます。
REACT_APP_ORDERS_URL=http://[LB_IP]/api/orders REACT_APP_PRODUCTS_URL=http://[LB_IP]/api/products 注: ロードバランサが転送を処理するように構成されているため、新しいアドレスにポート番号は不要です。

4. ファイルを保存します。

5. 以下のコマンドを実行して react-app を再ビルドします。再ビルドすると、フロントエンドのコードが更新されます。

cd ~/monolith-to-microservices/react-app npm install && npm run-script build
6. 以下のコマンドを実行して、アプリケーション コードをバケットにコピーします。
cd ~ rm -rf monolith-to-microservices/*/node_modules gcloud storage cp -r monolith-to-microservices gs://fancy-store-{{{project_0.project_id | Project ID}}}/

フロントエンド インスタンスを更新する

コードと構成を更新したので、マネージド インスタンス グループに含まれるフロントエンド インスタンスが新しいコードを pull するようにします。

• インスタンスは起動時にコードを pull するので、以下のコマンドを実行してローリング リスタートを指示します。
gcloud compute instance-groups managed rolling-action replace fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}} \ --max-unavailable 100% 注: このローリング置換の例では、--max-unavailable パラメータですべてのマシンを即座に置換するように指定しています。このパラメータを指定しない場合、このコマンドは 1 つのインスタンスをそのままの状態で残して他のインスタンスをリスタートすることで可用性を確保します。ここではテストとして、速く処理するためにすべてを即座に置換するように指定します。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 フロントエンド インスタンスを更新する

ウェブサイトをテストする

1. rolling-action replace コマンドを発行してから、インスタンスが処理されるまで 3 分間待ちます。その後、マネージド インスタンス グループのステータスを確認します。以下のコマンドを実行して、サービスのステータスが HEALTHY（正常）であることを確認します。
watch -n 2 gcloud compute backend-services get-health fancy-fe-frontend --global
2. 2 つのサービスが HEALTHY（正常）と表示されるまで待ちます。

出力例:

backend: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instanceGroups/fancy-fe-mig status: healthStatus: - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-x151 ipAddress: 10.128.0.7 port: 8080 - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-cgrt ipAddress: 10.128.0.11 port: 8080 kind: compute#backendServiceGroupHealth 注: 1 つのインスタンスで問題が発生し、ステータスが UNHEALTHY になっている場合は、自動的に修復されるので、修復されるまで待ちます。

しばらく待ち、どちらのインスタンスも HEALTHY（正常）にならない場合は、フロントエンド インスタンスの設定に問題があり、ポート 8080 でアクセスできない状態になっています。ポート 8080 で直接インスタンスにアクセスして確認します。
3. 両方のインスタンスがリスト上に HEALTHY（正常）と表示されたら、Ctrl+C キーを押して watch コマンドを終了します。
注: アプリケーションには http://[LB_IP] でアクセスできます。[LB_IP] はロードバランサに指定した IP アドレスで、以下のコマンドで確認できます。

gcloud compute forwarding-rules list --global

アプリケーションは、このラボで後ほど確認します。

タスク 7. Compute Engine をスケーリングする

ここまで、2 つのマネージド インスタンス グループと、各グループに 2 つのインスタンスを作成しました。この構成は負荷に関係のない静的な構成ですが、十分に機能します。次に、使用率に応じた自動スケーリング ポリシーを作成し、各マネージド インスタンス グループを自動的にスケーリングします。

使用率に応じて自動的にサイズを変更する

• 自動スケーリング ポリシーを作成するには、以下のコマンドを実行します。
gcloud compute instance-groups managed set-autoscaling \ fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}} \ --max-num-replicas 2 \ --target-load-balancing-utilization 0.60 gcloud compute instance-groups managed set-autoscaling \ fancy-be-mig \ --zone={{{project_0.default_zone | zone}}} \ --max-num-replicas 2 \ --target-load-balancing-utilization 0.60

このコマンドによって、マネージド インスタンス グループにオートスケーラーが作成されます。このオートスケーラーはロードバランサの使用率が 60% を超えるとインスタンスを自動的に追加し、60% を下回るとインスタンスを削除します。

コンテンツ配信ネットワークを有効にする

スケーリングに役立つもう一つの機能として、コンテンツ配信ネットワーク サービスがあります。このサービスを有効にすると、フロントエンドにキャッシュを提供できます。

• フロントエンド サービスで以下のコマンドを実行します。
gcloud compute backend-services update fancy-fe-frontend \ --enable-cdn --global

ユーザーが HTTP(S) ロードバランサを経由してコンテンツをリクエストすると、リクエストは Google Front End（GFE）に届きます。GFE はユーザーのリクエストにレスポンスを返すにあたって最初に Cloud CDN キャッシュ内を探します。レスポンスがキャッシュに保存されていた場合、GFE はそれをユーザーに送信します。これを「キャッシュ ヒット」と呼びます。

レスポンスがキャッシュに保存されていなかった場合、GFE はリクエストをバックエンドに直接送信します。このリクエストに対するレスポンスをキャッシュに保存できる場合、GFE はそのレスポンスを Cloud CDN キャッシュに保存して、以降のリクエストで使用できるようにします。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Compute Engine をスケーリングする

タスク 8. ウェブサイトを更新する

インスタンス テンプレートを更新する

既存のインスタンス テンプレートを編集することはできません。ただし、現在のインスタンスはステートレスであり、起動スクリプトですべての構成が行われます。そのため、インスタンス テンプレートを変更するだけで、テンプレートの設定を変更することができます。このタスクでは、サイズの大きいマシンタイプを使用するように簡単な変更を行い、それを push します。

後述の手順に沿って、以下の操作を行います。

• インスタンス テンプレートのベースとして機能する frontend インスタンスを更新します。更新する際、インスタンス テンプレート イメージの更新されたバージョンにファイルを配置します。その後、インスタンス テンプレートを更新し、新しいテンプレートをロールアウトして、最後にマネージド インスタンス グループのインスタンスにファイルが存在することを確認します。

• インスタンス テンプレートのマシンタイプを e2-standard-2 から e2-small に切り替えて変更します。

1. 以下のコマンドを実行して、フロントエンド インスタンスのマシンタイプを変更します。
gcloud compute instances set-machine-type frontend \ --zone={{{project_0.default_zone | zone}}} \ --machine-type e2-small
2. 以下のコマンドを実行して、新しいインスタンス テンプレートを作成します。
gcloud compute instance-templates create fancy-fe-new \ --region=$REGION \ --source-instance=frontend \ --source-instance-zone={{{project_0.default_zone | zone}}}
3. 以下のコマンドを使用して、更新したインスタンス テンプレートをマネージド インスタンス グループにロールアウトします。
gcloud compute instance-groups managed rolling-action start-update fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}} \ --version template=fancy-fe-new
4. 3 分待ってから、以下のコマンドを実行して更新のステータスをモニタリングします。
watch -n 2 gcloud compute instance-groups managed list-instances fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}}

この処理には数分かかります。

続行する前に、次の状態のインスタンスが 1 つ以上あることを確認します。

• STATUS: RUNNING（実行中）
• ACTION: None（なし）
• INSTANCE_TEMPLATE: fancy-fe-new（新しいテンプレート名）

5. リストにあるマシン名の 1 つをコピーして以下のコマンドで使用します。

6. Ctrl+C キーを押して watch プロセスを終了します。

7. 以下のコマンドを実行して、仮想マシンが新しいマシンタイプ（e2-small）を使用していることを確認します。[VM_NAME] は新しく作成されたインスタンス名に置き換えます。

gcloud compute instances describe [VM_NAME] --zone={{{project_0.default_zone | zone}}} | grep machineType

出力例:

machineType: https://www.googleapis.com/compute/v1/projects/project-name/zones/us-central1-f/machineTypes/e2-small

ウェブサイトに変更を加える

シナリオ: あなたはマーケティング チームから、サイトのホームページを変更するよう依頼されました。マーケティング チームは、会社の概要と販売している製品のより詳しい情報を追加する必要があると考えています。

このセクションでは、マーケティング チームからの依頼に応じたテキストをホームページに追加します。デベロッパーの 1 人が index.js.new というファイルですでにホームページを変更したようです。このファイルを index.js にコピーするだけで、変更を反映できます。以下の手順に沿って適切な変更を行います。

1. 以下のコマンドを実行して、更新されたファイルをコピーして正しいファイル名にします。
cd ~/monolith-to-microservices/react-app/src/pages/Home mv index.js.new index.js
2. ファイルの内容を出力して変更を確認します。
cat ~/monolith-to-microservices/react-app/src/pages/Home/index.js

変更後のコードは次のようになります。

出力:

/* Copyright 2019 Google LLC Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ import React from "react"; import { Box, Paper, Typography } from "@mui/material"; export default function Home() { return ( <Box sx={{ flexGrow: 1 }}> <Paper elevation={3} sx={{ width: "800px", margin: "0 auto", padding: (theme) => theme.spacing(3, 2), }} > <Typography variant="h5">Welcome to the Fancy Store!</Typography> <br /> <Typography variant="body1"> Take a look at our wide variety of products. </Typography> </Paper> </Box> ); }

これで React コンポーネントは更新されましたが、React アプリをビルドして静的ファイルを生成する必要があります。

3. 以下のコマンドを実行して、React アプリケーションをビルドし、monolith の公開ディレクトリにコピーします。
cd ~/monolith-to-microservices/react-app npm install && npm run-script build
4. 次に、以下のコマンドを実行して、このコードをバケットに再度 push します。
cd ~ rm -rf monolith-to-microservices/*/node_modules gcloud storage cp -r monolith-to-microservices gs://fancy-store-{{{project_0.project_id | Project ID}}}/

ローリング置換で変更を push する

1. 以下のコマンドを実行して、すべてのインスタンスを強制的に置換し、更新を pull します。
gcloud compute instance-groups managed rolling-action replace fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}} \ --max-unavailable=100%

注: このローリング置換の例では、--max-unavailable パラメータですべてのマシンを即座に置換するように指定しています。このパラメータを指定しない場合、このコマンドは 1 つのインスタンスをそのままの状態で残し、他のインスタンスを置換します。ここではテストとして、速く処理するためにすべてを即座に置換するように指定します。本番環境では余裕を持たせて、更新中でもウェブサイトのサービスが停止しないようにします。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ウェブサイトを更新する

2. rolling-action replace コマンドを発行してから、インスタンスが処理されるまで 3 分間待ちます。その後、マネージド インスタンス グループのステータスを確認します。以下のコマンドを実行して、サービスのステータスが HEALTHY（正常）であることを確認します。
watch -n 2 gcloud compute backend-services get-health fancy-fe-frontend --global
3. 両方のサービスが表示され、ステータスが HEALTHY になるまで待ちます。

出力例:

backend: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instanceGroups/fancy-fe-mig status: healthStatus: - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-x151 ipAddress: 10.128.0.7 port: 8080 - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-cgrt ipAddress: 10.128.0.11 port: 8080 kind: compute#backendServiceGroupHealth

4. 両方のインスタンスがリスト上に HEALTHY と表示されたら、Ctrl+C キーを押して watch コマンドを終了します。

5. ウェブサイトには http://[LB_IP] でアクセスできます。[LB_IP] はロードバランサに指定した IP アドレスで、以下のコマンドで確認できます。

gcloud compute forwarding-rules list --global

更新された新しいウェブサイトが表示されます。

障害をシミュレーションする

ヘルスチェックが機能することを確認するために、インスタンスにログインしてサービスを停止することにしました。

1. インスタンス名を確認するには、以下のコマンドを実行します。
gcloud compute instance-groups list-instances fancy-fe-mig --zone={{{project_0.default_zone | zone}}}
2. インスタンス名をコピーしてから、以下のコマンドを実行してインスタンスに SSH でアクセスします。INSTANCE_NAME はリストから取得したインスタンス名に置き換えます。
gcloud compute ssh [INSTANCE_NAME] --zone={{{project_0.default_zone | zone}}}

3. 「y」と入力し、Enter キーを 2 回押してパスワードを使用しないようにします。

4. インスタンス内で以下のコマンドを実行して、supervisorctl でアプリケーションを停止します。

sudo supervisorctl stop nodeapp; sudo killall node
5. 以下のコマンドを実行して、インスタンスを終了します。
exit
6. 修復される様子をモニタリングします。
watch -n 2 gcloud compute operations list \ --filter='operationType~compute.instances.repair.*'

このプロセスは完了するまで数分かかります。

以下のように出力されます。

出力:

NAME: repair-1755080598062-63c3c8b99843b-eed8dabc-f1833ea3 TYPE: compute.instances.repair.recreateInstance TARGET: us-east4-c/instances/fancy-fe-tn40 HTTP_STATUS: 200 STATUS: DONE TIMESTAMP: 2025-08-13T03:23:18.062-07:00

マネージド インスタンス グループがインスタンスを再作成して修復したことがわかります。

7. また、ナビゲーション メニュー > [Compute Engine] > [VM インスタンス] に移動して、コンソールからモニタリングすることもできます。

お疲れさまでした

このデモでは、Compute Engine でウェブサイトをデプロイ、スケーリング、更新しました。また、Compute Engine でのマネージド インスタンス グループ、ロードバランサ、ヘルスチェックの操作についても確認しました。

次のステップと詳細情報

• マネージド インスタンス グループでの自動修復とヘルスチェック
• 事例紹介動画「Google Cloud でスケーラブルなウェブ アプリケーションをホストする」

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

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

マニュアルの最終更新日: 2026 年 6 月 19 日

ラボの最終テスト日: 2026 年 6 月 19 日

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