このページは Cloud Translation API によって翻訳されました。

Compute Engine を使用して Google Cloud でウェブアプリをホストしてスケーリングする

1. はじめに

Google Cloud にウェブサイトをデプロイする方法は数多くあり、ソリューションごとに特長、機能、制御レベルが異なります。Compute Engine では、ウェブサイトの実行に使用するインフラストラクチャを細かく制御できますが、Google Kubernetes Engine や App Engine などのソリューションと比べて運用管理が少し必要になります。Compute Engine を使用すると、仮想マシンやロードバランサなど、インフラストラクチャのさまざまな側面をきめ細かく制御できます。本日は、サンプルアプリ（Fancy Store の e コマースウェブサイト）をデプロイし、Compute Engine でウェブサイトのデプロイとスケーリングを簡単に行う方法をご紹介します。

学習内容

Compute Engine インスタンスを作成する方法
ソースインスタンスからインスタンステンプレートを作成する方法
マネージドインスタンスグループを作成する方法
ヘルスチェックと自動修復を設定する方法
HTTP(S) ロードバランシングの作成方法
ロードバランサのヘルスチェックを作成する方法
キャッシュにコンテンツ配信ネットワークを使用する方法

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

前提条件

このラボで使用するコンセプトの初歩的な概要については、以下の資料をご確認ください。
Google Cloud Platform へようこそ - GCP の基礎
Google Cloud Compute Engine スタートガイド
Google Cloud Storage を使ってみる
スタートガイド: Cloud Shell

2. 環境のセットアップ

セルフペース型の環境設定

Cloud コンソールにログインして、新しいプロジェクトを作成するか、既存のプロジェクトを再利用しますGmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。

プロジェクト ID を忘れないようにしてください。プロジェクト ID はすべての Google Cloud プロジェクトを通じて一意の名前にする必要があります（上記の名前はすでに使用されているので使用できません）。以降、このコードラボでは PROJECT_ID と呼びます。

次に、Google Cloud リソースを使用するために、Cloud Console で課金を有効にする必要があります。

このコードラボを実行しても、費用はほとんどかからないはずです。このチュートリアル以外で請求が発生しないように、リソースのシャットダウン方法を説明する「クリーンアップ」セクションの手順に従うようにしてください。Google Cloud の新規ユーザーは、$300 USD 分の無料トライアルプログラムをご利用いただけます。

Compute Engine API を有効にする

次に、Compute Engine API を有効にする必要があります。API を有効にするには、API の利用規約に同意し、請求に関する責任を負う必要があります。

Cloud Shell で次のコマンドを実行して、Compute Engine API を有効にします。

gcloud services enable compute.googleapis.com

Cloud Shell

Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では Cloud 上で動作するコマンドライン環境である Cloud Shell を使用します。

この Debian ベースの仮想マシンには、必要な開発ツールがすべて揃っています。永続的なホームディレクトリが 5 GB 用意されており、Google Cloud で稼働するため、ネットワークのパフォーマンスと認証が大幅に向上しています。つまり、この Codelab に必要なのはブラウザだけです（はい、Chromebook で動作します）。

Cloud Console から Cloud Shell を有効にするには、[Cloud Shell をアクティブにする] をクリックします（環境のプロビジョニングと接続に若干時間を要します）。

Screen Shot 2017-06-14 at 10.13.43 PM.png

Cloud Shell に接続すると、すでに認証は完了しており、プロジェクトに各自の PROJECT_ID が設定されていることがわかります。

gcloud auth list

コマンド出力

Credentialed accounts:
 - <myaccount>@<mydomain>.com (active)

gcloud config list project

コマンド出力

[core]
project = <PROJECT_ID>

なんらかの理由でプロジェクトが設定されていない場合は、次のコマンドを実行します。

gcloud config set project <PROJECT_ID>

PROJECT_ID が見つからない場合は、設定手順で使用した ID を確認するか、Cloud コンソールダッシュボードで確認します。

Cloud Shell では、デフォルトで環境変数もいくつか設定されます。これらの変数は、以降のコマンドを実行する際に有用なものです。

echo $GOOGLE_CLOUD_PROJECT

コマンド出力

<PROJECT_ID>

最後に、デフォルトのゾーンとプロジェクト構成を設定します。

gcloud config set compute/zone us-central1-f

さまざまなゾーンを選択できます。詳しくは、リージョンとゾーン。

Cloud Storage バケットを作成する

Cloud Storage バケットを使用して、ビルドしたコードと起動スクリプトを格納します。Cloud Shell で次のコマンドを実行して、新しい Cloud Storage バケットを作成します。

gsutil mb gs://fancy-store-$DEVSHELL_PROJECT_ID

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

monolith-to-microservices リポジトリに基づく Fancy Store の既存の e コマースウェブサイトをウェブサイトのベースとして使用します。Compute Engine へのデプロイに集中できるように、リポジトリからソースコードのクローンを作成します。後でコードを少し更新して、Compute Engine での更新が簡単であることを確認します。

コードリポジトリのクローンをプロジェクトに自動的に作成できるだけでなく、[Cloud Shell で開く] から Cloud Shell と組み込みのコードエディタを開くこともできます。

または、Cloud Shell 内で次のコマンドを使用して、リポジトリのクローンを手動で作成することもできます。

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

Cloud Shell のコマンドプロンプトで、コードの最初のビルドを実行して、アプリをローカルで実行できるようにします。スクリプトの実行には数分かかる場合があります。

./setup.sh

デューデリジェンスを実施し、アプリをテストしてください。次のコマンドを実行して、ウェブサーバーを起動します。

cd microservices
npm start

出力:

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

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

新しいウィンドウが開き、Fancy Store のフロントエンドの動作を確認できます。

ウェブサイトを閲覧した後、このウィンドウは閉じることができます。ウェブサーバープロセスを停止するには、ターミナルウィンドウで Control+C（Macintosh では Command+C）を押します。

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

作業用の開発環境が用意できたので、Compute Engine インスタンスをいくつかデプロイできます。以下の手順を実施します。

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

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

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

Cloud Shell リボンの鉛筆アイコンをクリックして、コードエディタを開きます。

monolith-to-microservices フォルダに移動します。[ファイル] をクリック >新しいファイル] を選択して、startup-script.sh というファイルを作成します。

新しいファイルに次のコードを貼り付けます。このコードの一部は、貼り付け後に編集します。

#!/bin/bash

# Install logging monitor. The monitor will automatically pick up logs sent to
# syslog.
curl -s "https://storage.googleapis.com/signals-agents/logging/google-fluentd-install.sh" | bash
service google-fluentd restart &

# Install dependencies from apt
apt-get update
apt-get install -yq ca-certificates git build-essential supervisor psmisc

# Install nodejs
mkdir /opt/nodejs
curl https://nodejs.org/dist/v8.12.0/node-v8.12.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

# Get the application source code from the Google Cloud Storage bucket.
mkdir /fancy-store
gsutil -m cp -r gs://fancy-store-[DEVSHELL_PROJECT_ID]/monolith-to-microservices/microservices/* /fancy-store/

# Install app dependencies.
cd /fancy-store/
npm install

# Create a nodeapp user. The application will run as this user.
useradd -m -d /home/nodeapp nodeapp
chown -R nodeapp:nodeapp /opt/app

# Configure supervisor to run the node app.
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

次に、コードエディタで [DEVSHELL_PROJECT_ID] というテキストを探し、次のコマンドの出力に置き換えます。

echo $DEVSHELL_PROJECT_ID

出力例:

my-gce-codelab-253520

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

gs://fancy-store-my-gce-codelab-253520/monolith-to-microservices/microservices/* /fancy-store/

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

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

作成した startup-script.sh ファイルを、先ほど作成した Cloud Storage バケットにコピーします。

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 インスタンスは、自動的にサービスアカウントを使用してこのサービスアカウントにアクセスできるようになります。

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

インスタンスが起動すると、Cloud Storage バケットからコードを pull するため、いくつかの構成変数を見てみましょう。

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

cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

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

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

Cloud Shell で次のコマンドを実行して、f1-micro インスタンスを作成します。このインスタンスを、以前に作成した起動スクリプトを使用するように構成し、バックエンドインスタンスとしてタグ付けすることで、後で特定のファイアウォールルールを適用できるようにします。

gcloud compute instances create backend \
    --machine-type=f1-micro \
    --image=debian-9-stretch-v20190905 \
    --image-project=debian-cloud \
    --tags=backend \
    --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-$DEVSHELL_PROJECT_ID/startup-script.sh

バックエンドへの接続を設定する

アプリのフロントエンドをデプロイする前に、デプロイしたバックエンドを指すように構成を更新する必要があります。

バックエンドの外部 IP アドレスを取得します。これは、バックエンドインスタンスの [EXTERNAL_IP] タブで次のコマンドで確認できます。

gcloud compute instances list

出力例:

NAME     ZONE           MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP   STATUS
backend  us-central1-a  f1-micro                   10.128.0.2   34.68.223.88  RUNNING

Cloud Shell のコードエディタで、フォルダ monolith-to-microservices に移動し、react-app を使用します。コードエディタメニューから、[View] >[非表示ファイル] を切り替えて、.env ファイルを表示します。

バックエンドの外部 IP アドレスを指すように .env ファイルを編集します。以下の [BACKEND_ADDRESS] は、gcloud ツールの前のコマンドで特定したバックエンドインスタンスの外部 IP アドレスを表します。

REACT_APP_ORDERS_URL=http://[BACKEND_ADDRESS]:8081/api/orders
REACT_APP_PRODUCTS_URL=http://[BACKEND_ADDRESS]:8082/api/products

ファイルを保存します。

次のコマンドを使用して、react-app を再ビルドします。再ビルドすると、フロントエンドのコードが更新されます。

cd ~/monolith-to-microservices/react-app
npm install && npm run-script build

アプリコードを 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 \
    --machine-type=f1-micro \
    --image=debian-9-stretch-v20190905 \
    --image-project=debian-cloud \
    --tags=frontend \
    --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-$DEVSHELL_PROJECT_ID/startup-script.sh

ネットワークの構成

フロントエンドではポート 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

これでウェブサイトが機能するようになりました。フロントエンドの外部 IP アドレスを確認します。このアドレスは、フロントエンドインスタンスの EXTERNAL_IP で確認できます。

gcloud compute instances list

出力例:

NAME      ZONE           MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP      STATUS
backend   us-central1-a  f1-micro                   10.128.0.2   104.198.235.171  RUNNING
frontend  us-central1-a  f1-micro                   10.128.0.3   34.69.141.9      RUNNING

インスタンスが起動して構成されるまでに数分かかることがあります。次のコマンドを実行して、アプリの準備状況をモニタリングします。

watch -n 5 curl http://[EXTERNAL_IP]:8080

次のような出力が表示されたら、ウェブサイトの準備は完了しています。コマンドプロンプトで Control+C（Macintosh では Command+C）を押して watch コマンドをキャンセルします。

新しいウェブブラウザのタブで http://[FRONTEND_ADDRESS]:8080 にアクセスしてウェブサイトにアクセスします。[FRONTEND_ADDRESS] は、上記で確認した EXTERNAL_IP です。

[Products]（商品）ページと [Orders]（注文）ページに移動してみます。こちらも動作するはずです。

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

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

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

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

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

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

まず、両方のインスタンスを停止する必要があります。

gcloud compute instances stop frontend

gcloud compute instances stop backend

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

gcloud compute instance-templates create fancy-fe \
    --source-instance=frontend

gcloud compute instance-templates create fancy-be \
    --source-instance=backend

インスタンステンプレートが作成されたことを確認します。

gcloud compute instance-templates list

出力例:

NAME      MACHINE_TYPE  PREEMPTIBLE  CREATION_TIMESTAMP
fancy-be  f1-micro                   2019-09-12T07:52:57.544-07:00
fancy-fe  f1-micro                   2019-09-12T07:52:48.238-07:00

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

フロントエンド用とバックエンド用の 2 つのマネージドインスタンスグループを作成します。これらのマネージドインスタンスグループでは、前に作成したインスタンステンプレートを使用して、各グループで 2 つのインスタンスが起動するように構成します。インスタンスには、「base-instance-name」に基づいて自動的に名前が付けられランダムな文字が付加されて表示されます。

gcloud compute instance-groups managed create fancy-fe-mig \
    --base-instance-name fancy-fe \
    --size 2 \
    --template fancy-fe

gcloud compute instance-groups managed create fancy-be-mig \
    --base-instance-name fancy-be \
    --size 2 \
    --template fancy-be

このアプリケーションでは、フロントエンドマイクロサービスがポート 8080 で動作し、バックエンドマイクロサービスがポート 8081（注文用）とポート 8082（プロダクト用）で実行されます。これらは標準ポートではないため、識別するために名前付きポートを指定します。名前付きポートは Key-Value ペアのメタデータで、サービス名とサービスを実行するポートを表します。名前付きポートをインスタンスグループに割り当てることで、そのインスタンスグループに含まれるすべてのインスタンスでサービスを利用することができます。この情報はロードバランサによって使用されます。ロードバランサは後で構成します。

gcloud compute instance-groups set-named-ports fancy-fe-mig \ 
    --named-ports frontend:8080

gcloud compute instance-groups set-named-ports fancy-be-mig \
    --named-ports orders:8081,products:8082

自動修復を構成する

アプリの可用性を高め、アプリが応答していることを確認するには、マネージドインスタンスグループに対して自動修復ポリシーを構成します。

自動修復ポリシーは、アプリベースのヘルスチェックを使用して、アプリが期待どおりに応答していることを確認します。デフォルトの動作であるインスタンスが RUNNING 状態かどうかを検証するのは、単純にアプリのレスポンスを確認するほうが正確です。

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

フロントエンドとバックエンドで 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

ヘルスチェックプローブがポート 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

ヘルスチェックを各サービスに適用します。

gcloud compute instance-groups managed update fancy-fe-mig \
    --health-check fancy-fe-hc \
    --initial-delay 300

gcloud compute instance-groups managed update fancy-be-mig \
    --health-check fancy-be-hc \
    --initial-delay 300

Codelab に進み、自動修復でグループ内のインスタンスをモニタリングできるように、しばらく待ちます。後で、障害をシミュレートして自動修復をテストします。

6. ロードバランサの作成

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

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

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

Google Cloud ではさまざまな種類のロードバランシングを提供していますが、ここではトラフィックに HTTP(S) ロードバランシングを使用します。HTTP(S) ロードバランシングは次のように構成されています。

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

各サービスのトラフィックに対応可能なインスタンスを判断するためのヘルスチェックを作成します。

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

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

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

バックエンドサービスを追加します。

gcloud compute backend-services add-backend fancy-fe-frontend \
  --instance-group fancy-fe-mig \
  --instance-group-zone us-central1-f \
  --global

gcloud compute backend-services add-backend fancy-be-orders \
  --instance-group fancy-be-mig \
  --instance-group-zone us-central1-f \
  --global

gcloud compute backend-services add-backend fancy-be-products \
  --instance-group fancy-be-mig \
  --instance-group-zone us-central1-f \
  --global

URL マップを作成します。URL マップは、どの URL がどのバックエンドサービスにつながるのかを定義します。

gcloud compute url-maps create fancy-map \
  --default-service fancy-fe-frontend

パスマッチャーを作成して、/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"

作成された URL マップに関連付けるプロキシを作成します。

gcloud compute target-http-proxies create fancy-proxy \
  --url-map fancy-map

パブリック IP アドレスとポートをプロキシに関連付けるグローバル転送ルールを作成します。

gcloud compute forwarding-rules create fancy-http-rule \
  --global \
  --target-http-proxy fancy-proxy \
  --ports 80

構成の更新

新しい静的 IP アドレスが割り当てられたので、フロントエンドのコードを更新して、以前使用したエフェメラルアドレスでバックエンドインスタンスを参照していたアドレスではなく、新しいアドレスを参照する必要があります。

Cloud Shell で、react-app フォルダに移動します。このフォルダに、構成が格納されている .env ファイルがあります。

cd ~/monolith-to-microservices/react-app/

ロードバランサの IP アドレスを確認します。

gcloud compute forwarding-rules list --global

出力例:

NAME                    REGION  IP_ADDRESS     IP_PROTOCOL  TARGET
fancy-http-rule          34.102.237.51  TCP          fancy-proxy

任意のテキストエディタ（GNU nano など）で .env ファイルを編集し、ロードバランサのパブリック IP アドレスを参照します。[LB_IP] はバックエンドインスタンスの外部 IP アドレスを表します。

REACT_APP_ORDERS_URL=http://[LB_IP]/api/orders
REACT_APP_PRODUCTS_URL=http://[LB_IP]/api/products

フロントエンドのコードが更新される React-app を再ビルドします。

cd ~/monolith-to-microservices/react-app
npm install && npm run-script build

アプリケーションコードを GCS バケットにコピーします。

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 restart fancy-fe-mig \
    --max-unavailable 100%

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

rolling-action restart コマンドの発行後、インスタンスが処理されるまで約 30 秒待ちます。次に、インスタンスがリストに表示されるまで、マネージドインスタンスグループのステータスを確認します。

watch -n 5 gcloud compute instance-groups list-instances fancy-fe-mig

リストにアイテムが表示されたら、Control+C（Macintosh では Command+C）を押して watch コマンドを終了します。

サービスが正常と表示されていることを確認します。

watch -n 5 gcloud compute backend-services get-health fancy-fe-frontend --global

出力例:

---
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

リストにアイテムが表示されたら、Control+C（Macintosh では Command+C）を押して watch コマンドを終了します。

これで、アプリケーションは http://[LB_IP] でアクセス可能になります。[LB_IP] はロードバランサに指定した IP アドレスで、次のコマンドで確認できます。

gcloud compute forwarding-rules list --global

7. Compute Engine のスケーリング

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

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

自動スケーリングポリシーを作成するには、Cloud Shell で次のコマンドを実行します。具体的には、マネージドインスタンスグループにオートスケーラーを作成して、ロードバランサの使用率が 60% を超えるとインスタンスを自動的に追加し、60% を下回るとインスタンスを削除します。

gcloud compute instance-groups managed set-autoscaling \
  fancy-fe-mig \
  --max-num-replicas 5 \
  --target-load-balancing-utilization 0.60

gcloud compute instance-groups managed set-autoscaling \
  fancy-be-mig \
  --max-num-replicas 5 \
  --target-load-balancing-utilization 0.60

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

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

gcloud compute backend-services update fancy-fe-frontend \
    --enable-cdn --global

ユーザーがロードバランサにコンテンツをリクエストすると、リクエストは Google フロントエンドに到着します。Google フロントエンドはまず、ユーザーのリクエストに対するレスポンスを Cloud CDN キャッシュで検索します。フロントエンドは、キャッシュに保存されているレスポンスを見つけると、そのレスポンスをユーザーに送信します。これをキャッシュヒットと呼びます

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

8. ウェブサイトを更新

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

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

インスタンステンプレートのベースとして機能するフロントエンドインスタンスを更新します。更新中は、インスタンステンプレートのイメージの更新バージョンにファイルを配置します。次に、インスタンステンプレートを更新して新しいテンプレートをロールアウトし、マネージドインスタンスグループのインスタンスにファイルが存在することを確認します。

インスタンステンプレートのマシンタイプを変更するには、標準マシンタイプ f1-micro から 4 vCPU と 3,840 MiB RAM を搭載したカスタムマシンタイプに切り替えます。

Cloud Shell で次のコマンドを実行して、frontend インスタンスのマシンタイプを変更します。

gcloud compute instances set-machine-type frontend --machine-type custom-4-3840

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

gcloud compute instance-templates create fancy-fe-new \
    --source-instance=frontend \
    --source-instance-zone=us-central1-a

更新されたインスタンステンプレートをマネージドインスタンスグループに展開します。

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

更新のステータスをモニタリングします。

watch -n 2 gcloud compute instance-groups managed list-instances fancy-fe-mig

ステータスが RUNNING のインスタンスが 2 つ以上あり、ACTION を None に設定し、INSTANCE_TEMPLATE を新しいテンプレート名（fancy-fe-new）として設定したら、リストにあるマシン名の 1 つをコピーして次のコマンドで使用します。

Control+S（Macintosh では Command+S）を押して監視プロセスを終了します。

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

gcloud compute instances describe [VM_NAME] | grep machineType

出力例:

machineType: https://www.googleapis.com/compute/v1/projects/project-name/zones/us-central1-f/machineTypes/custom-4-3840

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

あなたはマーケティングチームから、サイトのホームページを変更するよう依頼されました。同社は、会社の概要と、実際に販売している商品について、より詳しい情報を提供する必要があると考えています。このセクションでは、マーケティングチームの満足度を高めるために、ホームページにテキストを追加します。デベロッパーの 1 人が index.js.new というファイルですでに変更を作成したようです。ファイルを index.js にコピーすると、変更内容が反映されます。以下の手順に沿って適切な変更を行います。

次のコマンドを実行して、更新したファイルを正しいファイル名でコピーし、その内容を出力して変更を確認します。

cd ~/monolith-to-microservices/react-app/src/pages/Home
mv index.js.new index.js
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 { makeStyles } from "@material-ui/core/styles";
import Paper from "@material-ui/core/Paper";
import Typography from "@material-ui/core/Typography";
const useStyles = makeStyles(theme => ({
  root: {
    flexGrow: 1
  },
  paper: {
    width: "800px",
    margin: "0 auto",
    padding: theme.spacing(3, 2)
  }
}));
export default function Home() {
  const classes = useStyles();
  return (
    <div className={classes.root}>
      <Paper className={classes.paper}>
        <Typography variant="h5">
          Fancy Fashion &amp; Style Online
        </Typography>
        <br />
        <Typography variant="body1">
          Tired of mainstream fashion ideas, popular trends and societal norms?
          This line of lifestyle products will help you catch up with the Fancy trend and express your personal style.
          Start shopping Fancy items now!
        </Typography>
      </Paper>
    </div>
  );
}

これで React コンポーネントは更新されましたが、React アプリをビルドして静的ファイルを生成する必要があります。次のコマンドを実行して React アプリをビルドし、monolith の公開ディレクトリにコピーします。

cd ~/monolith-to-microservices/react-app
npm install && npm run-script build

次に、Cloud Storage バケットにコードを再度 push します。

cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

ローリングアップデートで変更を push する

すべてのインスタンスを強制的に再起動して、更新を pull できるようになりました。

gcloud compute instance-groups managed rolling-action restart fancy-fe-mig \
    --max-unavailable=100%

ローリングアクションの再起動コマンドを発行してから約 30 秒待ってから、インスタンスが処理されるまで待ってから、インスタンスがリストに表示されるまでマネージドインスタンスグループのステータスを確認します。

watch -n 5 gcloud compute instance-groups list-instances fancy-fe-mig

リストにアイテムが表示されたら、Control+S（Macintosh では Command+S）を押して watch コマンドを終了します。

次のコマンドを実行して、サービスが healthy と表示されていることを確認します。

watch -n 5 gcloud compute backend-services get-health fancy-fe-frontend --global

出力例:

---
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

リストにアイテムが表示されたら、Control+S（Macintosh では Command+S）を押して watch コマンドを終了します。

コンテンツ配信ネットワーク内のキャッシュされたコンテンツを無効にして、最新のコンテンツが表示されるようにするには、次のコマンドを実行します。

gcloud compute url-maps invalidate-cdn-cache fancy-map \
    --path "/*"

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

gcloud compute forwarding-rules list --global

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

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

ヘルスチェックが機能することを確認するには、インスタンスにログインしてサービスを停止します。インスタンス名を確認するには、次のコマンドを実行します。

gcloud compute instance-groups list-instances fancy-fe-mig

そこから、SSH でインスタンスの 1 つにアクセスします。INSTANCE_NAME はリスト内のいずれかのインスタンスです。

gcloud compute ssh [INSTANCE_NAME]

インスタンスで、supervisorctl を使用してアプリを停止します。

sudo supervisorctl stop nodeapp; sudo killall node

インスタンスを終了します。

exit

修復オペレーションをモニタリングします。

watch -n 5 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

修復が見つかったら、Control+C（Macintosh では Command+S）を実行して watch コマンドを終了します。この時点で、マネージドインスタンスグループはインスタンスを再作成して修復します。

9. クリーンアップ

準備ができたら、プロジェクトを削除するのが、実行したすべてのアクティビティをクリーンアップする最も簡単な方法です。プロジェクトを削除すると、この Codelab で作成したロードバランサ、インスタンス、テンプレートなどが削除され、想定外の請求が繰り返し発生することがなくなります。Cloud Shell で次のコマンドを実行します。ここで、PROJECT_ID はプロジェクト名だけでなく、完全なプロジェクト ID です。

gcloud projects delete [PROJECT_ID]

「Y」と入力して削除を確定してくださいメッセージが表示されます。

10. 完了

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

Compute Engine を使用して Google Cloud でウェブアプリをホストしてスケーリングする

1. はじめに

学習内容

前提条件

2. 環境のセットアップ

セルフペース型の環境設定

Compute Engine API を有効にする

Cloud Shell

コマンド出力

コマンド出力

コマンド出力

Cloud Storage バケットを作成する

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

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

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

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

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

バックエンドへの接続を設定する

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

ネットワークの構成

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

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

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

自動修復を構成する

6. ロードバランサの作成

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

構成の更新

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

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

7. Compute Engine のスケーリング

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

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

8. ウェブサイトを更新

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

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

ローリング アップデートで変更を push する

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

9. クリーンアップ

10. 完了

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

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

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

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

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

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

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

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

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

ローリングアップデートで変更を push する