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 をアクティブにする」アイコン をクリックします。

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

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

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

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

gcloud auth list

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

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

出力:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

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

gcloud config list project

出力:

[core] project = <project_ID>

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

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

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

Cloud コンソールで次の 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 バケットを作成します。

gsutil mb gs://fancy-store-$DEVSHELL_PROJECT_ID 注: Cloud Shell 内で $DEVSHELL_PROJECT_ID 環境変数を使用することで、オブジェクトの名前を一意にすることができます。Google Cloud 内のすべてのプロジェクト ID は一意なので、他の名前の末尾にプロジェクト 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 をインストールする mkdir /opt/nodejs curl https://nodejs.org/dist/v16.14.0/node-v16.14.0-linux-x64.tar.gz | tar xvzf - -C /opt/nodejs --strip-components=1 ln -s /opt/nodejs/bin/node /usr/bin/node ln -s /opt/nodejs/bin/npm /usr/bin/npm # Google Cloud Storage バケットからアプリケーションのソースコードを取得する mkdir /fancy-store gsutil -m 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 /opt/app # ノードアプリを実行するように 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 に置き換えます。

startup-script.sh 内のコードの行は、次のようになります。

gs://fancy-store-{{{project_0.project_id | Project ID}}}/monolith-to-microservices/microservices/* /fancy-store/

6. startup-script.sh ファイルを保存しますが、まだ閉じないでください。

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

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

8. startup-script.sh ファイルを閉じます。

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

gsutil cp ~/monolith-to-microservices/startup-script.sh gs://fancy-store-$DEVSHELL_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 するようにコーディングすることもできます。今回はデモであるため、簡単な方法で構成します。本番環境では、コードの外部に環境変数を保存するようにします。

1. クローンを作成したコードをバケットにコピーします。

cd ~ rm -rf monolith-to-microservices/*/node_modules gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/ 注: できるだけ速く効率的にコピーするために、依存関係のディレクトリである node_modules は削除されます。これらはインスタンスの起動時にインスタンス上に再作成されます。

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

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

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

注: 本番環境では、各マイクロサービスを別々のインスタンスおよびインスタンス グループに分けて、個別にスケーリングできるようにします。今回はデモであるため、両方のバックエンド マイクロサービス（Orders と Products）を同じインスタンスおよびインスタンス グループに配置します。

• 次のコマンドを実行して、起動スクリプトを使用するように構成された e2-standard-2 インスタンスを作成します。バックエンド インスタンスであることを示すためにインスタンスに backend のタグを付け、後で専用のファイアウォール ルールを適用できるようにします。

gcloud compute instances create backend \ --zone=$ZONE \ --machine-type=e2-standard-2 \ --tags=backend \ --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-$DEVSHELL_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 ファイルを表示します。

次のステップでは、.env ファイルを編集してバックエンドの外部 IP を参照します。[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 gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

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

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

• 前回と同じような次のコマンドを実行してフロントエンド インスタンスをデプロイします。ファイアウォールで使用するために、このインスタンスには frontend のタグを付けます。

gcloud compute instances create frontend \ --zone=$ZONE \ --machine-type=e2-standard-2 \ --tags=frontend \ --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-$DEVSHELL_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=$ZONE gcloud compute instances stop backend --zone=$ZONE

2. 次に、各ソース インスタンスからインスタンス テンプレートを作成します。

gcloud compute instance-templates create fancy-fe \ --source-instance-zone=$ZONE \ --source-instance=frontend gcloud compute instance-templates create fancy-be \ --source-instance-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=$ZONE

5. プロンプトが表示されたら、「y」と入力します。

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

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

1. フロントエンド用とバックエンド用の 2 つのマネージド インスタンス グループを作成します。

gcloud compute instance-groups managed create fancy-fe-mig \ --zone=$ZONE \ --base-instance-name fancy-fe \ --size 2 \ --template fancy-fe gcloud compute instance-groups managed create fancy-be-mig \ --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=$ZONE \ --named-ports frontend:8080 gcloud compute instance-groups set-named-ports fancy-be-mig \ --zone=$ZONE \ --named-ports orders:8081,products:8082

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

自動修復を構成する

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

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

注: ロード バランシングと自動修復には、別々のヘルスチェックを使用します。ロード バランシングのヘルスチェックとは、インスタンスがユーザー トラフィックを受信しているかどうかの確認です。そのため、より積極的な実施が可能で、またそのように実施すべきです。そして、必要に応じてトラフィックをリダイレクトすることができるように、レスポンスのないインスタンスをすばやく把握します。 対照的に、自動修復のヘルスチェックでは、障害が発生しているインスタンスが Compute Engine によってプロアクティブに置き換えられるので、このヘルスチェックはロード バランシングのヘルスチェックより慎重に実施しなければなりません。

1. frontend 用と backend 用の両方のヘルスチェックを作成し、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=$ZONE \ --health-check fancy-fe-hc \ --initial-delay 300 gcloud compute instance-groups managed update fancy-be-mig \ --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 ロードバランサの構成は次のとおりです。

1. 受信したリクエストを転送ルールによってターゲットの HTTP プロキシに転送します。
2. ターゲット HTTP プロキシは各リクエストを URL マップと照合し、各リクエストに適したバックエンド サービスを判断します。
3. バックエンド サービスは、バックエンドの処理能力、ゾーン、インスタンスの健全性に基づき、適切なバックエンドに各リクエストを転送します。HTTP ヘルスチェックを使用して各バックエンド インスタンスの健全性を検証します。バックエンド サービスが HTTPS または HTTP/2 のヘルスチェックを使用するように構成されている場合、リクエストは途中で暗号化されてからバックエンド インスタンスに送信されます。
4. ロードバランサとインスタンス間のセッションでは、HTTP、HTTPS、HTTP/2 プロトコルを使用できます。HTTPS または HTTP/2 を使用する場合、バックエンド サービスの各インスタンスには SSL 証明書が必要です。

注: このデモでは、SSL 証明書に関する複雑な手順を避けてシンプルに説明するために、HTTPS ではなく HTTP を使用します。本番環境では、できるだけ HTTPS を使用して暗号化することをおすすめします。

1. 各サービスのトラフィックを処理できるインスタンスを判断するためのヘルスチェックを作成します。

gcloud compute http-health-checks create fancy-fe-frontend-hc \ --request-path / \ --port 8080 gcloud compute http-health-checks create fancy-be-orders-hc \ --request-path /api/orders \ --port 8081 gcloud compute http-health-checks create fancy-be-products-hc \ --request-path /api/products \ --port 8082 注: これらは、ロードバランサ用のヘルスチェックであり、ロードバランサからのトラフィック転送のみを処理します。これにより、マネージド インスタンス グループがインスタンスを再作成することはありません。

2. ロードバランスされたトラフィックの送信先となるバックエンド サービスを作成します。バックエンド サービスでは、先ほど作成したヘルスチェックと名前付きポートを使用します。

gcloud compute backend-services create fancy-fe-frontend \ --http-health-checks fancy-fe-frontend-hc \ --port-name frontend \ --global gcloud compute backend-services create fancy-be-orders \ --http-health-checks fancy-be-orders-hc \ --port-name orders \ --global gcloud compute backend-services create fancy-be-products \ --http-health-checks fancy-be-products-hc \ --port-name products \ --global

3. ロードバランサのバックエンド サービスを追加します。

gcloud compute backend-services add-backend fancy-fe-frontend \ --instance-group-zone=$ZONE \ --instance-group fancy-fe-mig \ --global gcloud compute backend-services add-backend fancy-be-orders \ --instance-group-zone=$ZONE \ --instance-group fancy-be-mig \ --global gcloud compute backend-services add-backend fancy-be-products \ --instance-group-zone=$ZONE \ --instance-group fancy-be-mig \ --global

4. URL マップを作成します。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 gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

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

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

インスタンスは起動時にコードを pull するので、ローリング再起動コマンドを発行します。

gcloud compute instance-groups managed rolling-action replace fancy-fe-mig \ --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=$ZONE \ --max-num-replicas 2 \ --target-load-balancing-utilization 0.60 gcloud compute instance-groups managed set-autoscaling \ fancy-be-mig \ --zone=$ZONE \ --max-num-replicas 2 \ --target-load-balancing-utilization 0.60

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

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

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

• フロントエンド サービスで次のコマンドを実行します。

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=$ZONE \ --machine-type e2-small

2. 新しいインスタンス テンプレートを作成します。

gcloud compute instance-templates create fancy-fe-new \ --region=$REGION \ --source-instance=frontend \ --source-instance-zone=$ZONE

3. 新しいインスタンス テンプレートをマネージド インスタンス グループに展開します。

gcloud compute instance-groups managed rolling-action start-update fancy-fe-mig \ --zone=$ZONE \ --version template=fancy-fe-new

4. 3 分待ってから、次のコマンドを実行して更新のステータスをモニタリングします。

watch -n 2 gcloud compute instance-groups managed list-instances fancy-fe-mig \ --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=$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 gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

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

1. すべてのインスタンスを強制的に置換して、更新を pull します。

gcloud compute instance-groups managed rolling-action replace fancy-fe-mig \ --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=$ZONE

2. インスタンス名をコピーしてから、次のコマンドを実行してインスタンスに SSH でアクセスします。INSTANCE_NAME はリストから取得したインスタンス名に置き換えます。

gcloud compute ssh [INSTANCE_NAME] --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 TYPE TARGET HTTP_STATUS STATUS TIMESTAMP repair-1568314034627-5925f90ee238d-fe645bf0-7becce15 compute.instances.repair.recreateInstance us-central1-a/instances/fancy-fe-1vqq 200 DONE 2019-09-12T11:47:14.627-07:00

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

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

お疲れさまでした

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

次のステップと詳細情報

• マネージド インスタンス グループでの自動修復とヘルスチェック

• 事例紹介動画「Google Cloud でスケーラブルなウェブ アプリケーションをホストする」

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

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

マニュアルの最終更新日: 2024 年 4 月 26 日

ラボの最終テスト日: 2023 年 12 月 15 日

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