Compute Engine および Cloud Storage を使用して、復元可能なウォーム ウェブサーバーをデプロイする

Last reviewed 2021-06-23 UTC

---

このドキュメントは、運用と管理チームで作業するアーキテクトと担当者を対象としています。このドキュメントでは、Google Cloud で独自のデプロイに使用できるパターンの例について説明します。

このアーキテクチャでは、ロードバランサは、コンテンツを提供するマネージド インスタンス グループ内の Compute Engine インスタンスにトラフィックを転送します。停止した場合、外部アプリケーションロードバランサ構成を更新し、Cloud Storage の静的サイトにフェイルオーバーします。

このソリューションをデプロイするには、ご自分で管理し、このドキュメントで使用する登録済みドメイン名が必要です。

本番環境のデプロイでは、このドキュメントに示されている数よりも多くのファイルとマネージド インスタンス グループの仮想マシン（VM）上のアプリケーション コードがウェブサイトに含まれている可能性があります。Cloud Storage は、機能が最も少ない制限付きの静的バージョンをホストします。ウォーム フェイルオーバー シナリオでは、マネージド インスタンス グループが回復し、完全なウェブサイト エクスペリエンスを表示するためのトラフィックを提供できるようになるまで、ユーザーにはこの限定された Web サイトが表示されます。

アーキテクチャ

このアーキテクチャでは、リソースをデプロイして次の画像のような環境を作ります。

フェイルオーバーする必要がある場合は、次の図に示すように、ロードバランサ構成を更新して、トラフィックを Cloud Storage に転送します。

このウォーム フェイルオーバー パターンは、プライマリ リージョンに障害が発生したときにのみ使用する別のマネージド インスタンス グループを別のリージョンで稼働させることで、費用のバランスを取っています。Cloud Storage を使用する静的サイトの費用は、別のマネージド インスタンス グループを実行するよりも低コストですが、ホスティング オプション間でロードバランサの構成を更新するため、わずかな遅延が発生します。Cloud Storage でのウェブサイトのエクスペリエンスは限定されていますが、これは、利用できないウェブサイトや、カスタマー エクスペリエンスが脆弱な場合よりも優れています。

外部アプリケーション ロードバランサの代わりに Cloud DNS を使用してフェイルオーバーを制御する代替方法については、Compute Engine と Cloud Storage で Cloud DNS を使用して復元可能なウォーム ウェブサーバーをデプロイするをご覧ください。このパターンは、Cloud DNS を保有している、または使用する場合に有用です。

Google Cloud で信頼性の高いアプリケーションを実行するには、サービス停止を処理するようにアプリケーション インフラストラクチャを設計することをおすすめします。アプリケーションやビジネスニーズに応じて、コールド フェイルオーバー、ウォーム フェイルオーバー、ホット フェイルオーバーのパターンが必要になることがあります。お客様のアプリケーションに最適なアプローチを判断する方法については、障害復旧計画ガイドをご覧ください。

このドキュメントでは基本的な Apache ウェブサーバーを使用しますが、インフラストラクチャのデプロイ手法は、作成する必要がある他のアプリケーション環境にも同様に適用されます。

目標

• カスタム VM イメージを使用してリージョン マネージド インスタンス グループを作成する。
• Cloud Storage バケットを作成する。
• 外部アプリケーション ロードバランサを作成して構成する。
• 更新されたロードバランサの構成で、ウォーム ウェブサーバーのフェイルオーバーをテストする。
• 更新されたロードバランサの構成を使用して、復元とフェイルバックをテストする。

料金

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

• Compute Engine
• ネットワーキング
• Cloud Storage

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

始める前に

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

2. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

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

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

4. Compute Engine API を有効にします。

   API を有効にする

5. Google Cloud CLI をインストールします。

6. gcloud CLI を初期化するには:

   gcloud init

7. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

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

8. Google Cloud プロジェクトで課金が有効になっていることを確認します。

9. Compute Engine API を有効にします。

   API を有効にする

10. Google Cloud CLI をインストールします。

11. gcloud CLI を初期化するには:

    gcloud init

Google Cloud CLI をインストールせずに、Google Cloud コンソールで Google Cloud CLI を実行できます。Google Cloud コンソールで gcloud CLI を実行するには、Cloud Shell を使用します。

環境を準備する

このセクションでは、リソース名とロケーションの変数を定義します。これらの変数は、リソースをデプロイするときに Google Cloud CLI コマンドによって使用されます。

このドキュメントを通じて、特に断りのない限り、Cloud Shell またはローカル開発環境ですべてのコマンドを入力します。

1. PROJECT_ID は実際のプロジェクト ID に置き換えます。必要に応じて、リソースの検索と識別を行うことができるように独自の名前接頭辞を指定します（例: app）。

   2 つのリージョン（us-west1 や us-west2 など）と、そのリージョン内のゾーン（us-west1-a など）を指定します。このゾーンでは、マネージド インスタンス グループのイメージの作成に使用する初期のベース VM の作成場所を定義します。

   最後に、静的ウェブサイトに使用されるドメイン（example.com など）を設定します。

   PROJECT_ID=PROJECT_ID
   NAME_SUFFIX=app
   REGION1=us-west1
   REGION2=us-west2
   ZONE=us-west1-a
   DOMAIN=example.com
   

VPC とサブネットの作成

VM にネットワーク アクセスを提供するには、Virtual Private Cloud（VPC）とサブネットを作成します。2 つのリージョン内にマネージド インスタンス グループが必要なので、リージョンごとに 1 つのサブネットを作成します。お客様の環境で使用されている IP アドレスの範囲を管理するためのカスタム サブネット モードの利点については、カスタムモードの VPC ネットワークを使用するをご覧ください。

1. カスタム サブネット モードで VPC を作成します。

   gcloud compute networks create network-$NAME_SUFFIX --subnet-mode=custom
   

2. 新しい VPC で、リージョンごとに 1 つずつ、2 つのサブネットを作成します。ネットワーク範囲に適合する独自のアドレス範囲（10.1.0.0/20 や 10.2.0.0/20 など）を定義します。

   gcloud compute networks subnets create \
       subnet-$NAME_SUFFIX-$REGION1 \
       --network=network-$NAME_SUFFIX \
       --range=10.1.0.0/20 \
       --region=$REGION1
   
   gcloud compute networks subnets create \
       subnet-$NAME_SUFFIX-$REGION2 \
       --network=network-$NAME_SUFFIX \
       --range=10.2.0.0/20 \
       --region=$REGION2
   

ファイアウォール ルールの作成

VPC 内でネットワーク トラフィックが正しく流れるようにするには、ファイアウォール ルールを使用します。

1. ロードバランサおよびマネージド インスタンス グループ用のウェブ トラフィックとヘルスチェックを許可するファイアウォール ルールを作成します。

   gcloud compute firewall-rules create allow-http-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --direction=INGRESS \
       --priority=1000 \
       --action=ALLOW \
       --rules=tcp:80 \
       --source-ranges=0.0.0.0/0 \
       --target-tags=http-server
   
   gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --action=allow \
       --direction=ingress \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --target-tags=allow-health-check \
       --rules=tcp:80
   

   HTTP ルールでは、http-serverタグが適用されている VM や、0.0.0.0/0 範囲を使用している送信元からのトラフィックを許可します。ヘルスチェック ルールでは、Google Cloud のデフォルトが設定されており、プラットフォームがリソースの健全性を正しくチェックできるようになっています。

2. ベース VM イメージの初期設定で SSH トラフィックを許可するには、--source-rangeパラメータを使用してファイアウォール ルールを環境に合わせて適用します。組織で使用するソース範囲を決定するには、ネットワーク チームの協力が必要な場合があります。

   注意: すべてのトラフィックを許可するような広い 0.0.0.0/0 範囲の使用はおすすめしません。トラフィックを単一の IP アドレスに限定するには、/32 ネットワーク マスク（35.230.62.163/32 など）を使用します。

   IP_ADDRESS_SCOPE を独自の IP アドレス スコープに置き換えます。

   gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --direction=INGRESS \
       --priority=1000 \
       --action=ALLOW \
       --rules=tcp:22 \
       --source-ranges=IP_ADDRESS_SCOPE
   

3. ファイアウォール ルールを作成したら、3 つのルールが追加されていることを確認します。

   gcloud compute firewall-rules list \
       --project=$PROJECT_ID \
       --filter="NETWORK=network-$NAME_SUFFIX"
   

   次の出力例は、3 つのルールが正しく作成されたことを示しています。

   NAME                    NETWORK      DIRECTION  PRIORITY  ALLOW
   allow-health-check-app  network-app  INGRESS    1000      tcp:80
   allow-http-app          network-app  INGRESS    1000      tcp:80
   allow-ssh-app           network-app  INGRESS    1000      tcp:22
   

ベース VM イメージの作成と構成

追加構成なしでデプロイする同じ VM を作成するには、カスタム VM イメージを使用します。このイメージは、OS と Apache の構成をキャプチャし、次のステップでマネージド インスタンス グループの各 VM を作成するために使用されます。

注: このドキュメントでは、ベース VM とイメージを手動で作成して構成します。本番環境のデプロイでは、既存のデプロイツールとパイプラインを使用して、このプロセスを可能な限り自動化します。詳細については、Terraform、Cloud Build、GitOps を使用してインフラストラクチャをコードとして管理するをご覧ください。

VM で、永続ディスク上に基本的な index.html ファイルを作成し、/var/www/example.comにマウントします。/etc/apache2/sites-available/example.com.conf の Apache 構成ファイルは、マウントされた永続ディスクの場所からウェブ コンテンツを提供します。

次の図は、永続ディスクに保存されている、Apache が提供する基本の HTML ページを示しています。

この環境は次の手順で構築します。

1. 永続ディスクがアタッチされたベース VM を作成します。

   gcloud compute instances create vm-base-$NAME_SUFFIX \
       --zone=$ZONE \
       --machine-type=n1-standard-1 \
       --subnet=subnet-$NAME_SUFFIX-$REGION1 \
       --tags=http-server \
       --image=debian-10-buster-v20210420 \
       --image-project=debian-cloud \
       --boot-disk-size=10GB \
       --boot-disk-type=pd-balanced \
       --boot-disk-device-name=vm-base-$NAME_SUFFIX \
       --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX
   

   このドキュメントの冒頭で定義したパラメータを使用して VM に名前を付け、正しいサブネットに接続します。名前はブートディスクとデータディスクのパラメータからも割り当てられます。

2. シンプルなウェブサイトをインストールして構成するには、まず SSH を使用してベース VM に接続します。

   gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE
   

3. VM への SSH セッションで、任意のエディタで VM を構成するスクリプトを作成します。次の例では、Nano をエディタとして使用しています。

   nano configure-vm.sh
   

   このファイルに次の構成スクリプトを貼り付けます。

   #!/bin/bash
   
   NAME_SUFFIX=app
   
   # Create directory for the basic website files
   sudo mkdir -p /var/www/example.com
   sudo chmod a+w /var/www/example.com
   sudo chown -R www-data: /var/www/example.com
   
   # Find the disk name, then format and mount it
   DISK_NAME="google-disk-base-$NAME_SUFFIX"
   DISK_PATH="$(find /dev/disk/by-id -name "${DISK_NAME}" | xargs -I '{}' readlink -f '{}')"
   
   sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_PATH
   sudo mount -o discard,defaults $DISK_PATH /var/www/example.com
   
   # Install Apache
   sudo apt-get update && sudo apt-get -y install apache2
   
   # Write out a basic HTML file to the mounted persistent disk
   sudo tee -a /var/www/example.com/index.html >/dev/null <<'EOF'
   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   EOF
   
   # Write out an Apache configuration file
   sudo tee -a /etc/apache2/sites-available/example.com.conf >/dev/null <<'EOF'
   <VirtualHost *:80>
           ServerName www.example.com
   
           ServerAdmin webmaster@localhost
           DocumentRoot /var/www/example.com
   
           ErrorLog ${APACHE_LOG_DIR}/error.log
           CustomLog ${APACHE_LOG_DIR}/access.log combined
   </VirtualHost>
   EOF
   
   # Enable the Apache configuration file and reload service
   sudo a2dissite 000-default
   sudo a2ensite example.com.conf
   sudo systemctl reload apache2
   

   このドキュメントの冒頭で設定した値（app など）と一致するように NAME_SUFFIX 変数を更新します。

4. ファイルを書き出してエディタを終了します。たとえば、Nano では、Ctrl-O を使用してファイルを書き出してから Ctrl-X で終了します。

5. 構成スクリプトを実行可能にして、実行します。

   chmod +x configure-vm.sh
   ./configure-vm.sh
   

6. VM への SSH セッションを終了します。

   exit
   

7. VM の IP アドレスを取得し、curl を使用して基本的なウェブページを表示します。

   curl $(gcloud compute instances describe vm-base-$NAME_SUFFIX \
       --zone $ZONE \
       --format="value(networkInterfaces.accessConfigs.[0].natIP)")
   

   次の出力例に示すように、基本のウェブサイトが返されます。

   <!doctype html>
   
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   

   このステップでは、Apache が正しく構成され、アタッチされた永続ディスクからページが読み込まれることを確認します。以降のセクションでは、このベース VM を使用してイメージを作成し、起動スクリプトでインスタンス テンプレートを構成します。

Compute Engine リソースのデプロイ

このウォーム フェイルオーバー パターンでは、マネージド インスタンス グループを使用して VM を実行します。マネージド インスタンス グループは 2 つのリージョンで実行され、各グループが VM の健全性をモニタリングします。障害が発生し、VM の 1 つが故障した場合、マネージド インスタンス グループは VM を再作成します。この構成では、Cloud Storage の静的サイトへのウォームフェイルオーバーがなくても、高可用性アプリケーションが作成されます。

1. イメージを作成する前に、VM を停止する必要があります。

   gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE
   

2. 次のコマンドセットを実行して、VM イメージ、インスタンス テンプレート、マネージド インスタンス グループを作成します。

   # Create the base VM images
   gcloud compute images create image-$NAME_SUFFIX \
       --source-disk=vm-base-$NAME_SUFFIX \
       --source-disk-zone=$ZONE
   
   gcloud compute images create image-disk-$NAME_SUFFIX \
       --source-disk=disk-base-$NAME_SUFFIX \
       --source-disk-zone=$ZONE
   
   # Create instance templates
   gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION1 \
       --machine-type=n1-standard-1 \
       --subnet=projects/$PROJECT_ID/regions/$REGION1/subnetworks/subnet-$NAME_SUFFIX-$REGION1 \
       --region=$REGION1 \
       --tags=http-server \
       --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'mount\ -a \
       --image=image-$NAME_SUFFIX \
       --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes
   
   gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION2 \
       --machine-type=n1-standard-1 \
       --subnet=projects/$PROJECT_ID/regions/$REGION2/subnetworks/subnet-$NAME_SUFFIX-$REGION2 \
       --region=$REGION2 \
       --tags=http-server \
       --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'mount\ -a \
       --image=image-$NAME_SUFFIX \
       --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes
   
   # Create a health check for VM instances
   gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX \
       --port 80
   
   # Create the managed instance groups
   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION1 \
       --template=template-$NAME_SUFFIX-$REGION1 \
       --size=2 \
       --region=$REGION1 \
       --health-check=http-basic-check-$NAME_SUFFIX
   
   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION2 \
       --template=template-$NAME_SUFFIX-$REGION2 \
       --size=2 \
       --region=$REGION2 \
       --health-check=http-basic-check-$NAME_SUFFIX
   

ロードバランサの作成と構成

ユーザーがお客様のウェブサイトにアクセスできるようにするには、マネージド インスタンス グループで実行されている VM へのトラフィックを許可する必要があります。また、マネージド インスタンス グループにゾーン障害がある場合、トラフィックを新しい VM に自動的にリダイレクトする必要もあります。

次のセクションでは、80 番ポートの HTTP トラフィック用のバックエンド サービスを備えた外部ロードバランサを作成し、前のステップで作成したヘルスチェックを使用して、外部 IP アドレスをバックエンド サービスにマッピングします。

詳細については、シンプルな外部 HTTP ロードバランサの設定方法をご覧ください。

1. アプリケーション用のロードバランサを作成して構成します

   # Configure port rules for HTTP port 80
   gcloud compute instance-groups set-named-ports \
       instance-group-$NAME_SUFFIX-$REGION1 \
       --named-ports http:80 \
       --region $REGION1
   
   gcloud compute instance-groups set-named-ports \
       instance-group-$NAME_SUFFIX-$REGION2 \
       --named-ports http:80 \
       --region $REGION2
   
   # Create a backend service and add the managed instance groups to it
   gcloud compute backend-services create \
       web-backend-service-$NAME_SUFFIX \
       --protocol=HTTP \
       --port-name=http \
       --health-checks=http-basic-check-$NAME_SUFFIX \
       --global
   
   gcloud compute backend-services add-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$REGION1 \
       --instance-group-region=$REGION1 \
       --global
   
   gcloud compute backend-services add-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$REGION2 \
       --instance-group-region=$REGION2 \
       --global
   
   # Create a URL map for the backend service
   gcloud compute url-maps create web-map-http-$NAME_SUFFIX \
       --default-service web-backend-service-$NAME_SUFFIX
   
   # Configure forwarding for the HTTP traffic
   gcloud compute target-http-proxies create \
       http-lb-proxy-$NAME_SUFFIX \
       --url-map web-map-http-$NAME_SUFFIX
   
   gcloud compute forwarding-rules create \
       http-content-rule-$NAME_SUFFIX \
       --global \
       --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \
       --ports=80
   

2. ウェブ トラフィックの転送ルールの IP アドレスを取得します。

   IP_ADDRESS=$(gcloud compute forwarding-rules describe http-content-rule-$NAME_SUFFIX \
       --global \
       --format="value(IPAddress)")
   

3. curl を使用するか、ウェブブラウザを開いて、前のステップで作成したロードバランサの IP アドレスを使用してウェブサイトを表示します。

   curl $IP_ADDRESS
   

   ロードバランサがデプロイを完了し、バックエンドにトラフィックが正しく転送されるまでに数分かかります。ロードバランサがまだデプロイ中の場合は、HTTP 404 エラーが返されます。必要に応じて、数分待ってからもう一度ウェブサイトにアクセスしてください。

   次の出力例に示すように、基本のウェブサイトが返されます。

   <!doctype html>
   
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   

Storage バケットの作成と構成

Cloud Storage は、静的なウェブサイト ファイルを保持するために使用されます。この基本的な例では、VM とは若干異なるテキストを含む単一のファイルを作成します。

本番環境のデプロイでは、このドキュメントに示されている数よりも多くのファイルとマネージド インスタンス グループ VM 上のアプリケーション コードがウェブサイトに含まれている可能性があります。Cloud Storage でホストされている静的なバージョンは、最小限の機能を提供するより限定的なバージョンであることが多いです。ウォーム フェイルオーバーのシナリオでは、マネージド インスタンス グループが復旧し、完全なウェブサイト エクスペリエンスのためのトラフィックを提供できるようになるまで、Cloud Storage からのこの限定されたウェブサイトが表示されます。

1. Cloud Storage バケットで使用するドメインを確認します。

2. 使用する所有ドメイン名に一致する Cloud Storage バケットを作成します。

   gsutil mb gs://static-web.$DOMAIN
   

   example.com などのように、このドキュメントの冒頭で定義された DOMAIN 変数が使用されます。この例では、静的ファイルをstatic-web.example.comに保存します。

3. 次のステップで、Cloud Storage バケットにコピーするローカル ファイルを作成します。

   cat <<EOF > index.html
   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test static web server with warm failover from Cloud Storage!</p>
   </body>
   </html>
   EOF
   

4. 基本的な HTML ファイルを Cloud Storage バケットにアップロードします。

   gsutil cp index.html gs://static-web.$DOMAIN
   

5. ユーザーが静的ウェブ コンテンツを閲覧できるようにするには、Cloud Storage バケットに適切な権限を設定します。

   gsutil iam ch allUsers:objectViewer gs://static-web.$DOMAIN
   

6. index.html ファイルをデフォルトのウェブページとして提供するように Cloud Storage バケットを構成します。

   gsutil web set -m index.html gs://static-web.$DOMAIN
   

Cloud Storage バケットをロードバランサに追加する

静的ウェブ コンテンツをホストするように Cloud Storage バケットを作成して構成すると、ロードバランサはそのトラフィックを転送する方法に関する情報が必要になります。

ロードバランサの作成と構成で、マネージド インスタンス グループのバックエンド サービスを作成しました。バックエンド サービスには URL マップがあり、HTTP ターゲット プロキシは、ロードバランサ経由でユーザーを VM に誘導するのに役立ちます。

トラフィックを Cloud Storage バケットに転送できるようにするには、ストレージ バケット用の新しいバックエンドと URL マップを使用してロードバランサを構成します。フェイルオーバーが必要な場合は、この構成を使用するようにロードバランサを更新します。

1. Cloud Storage バケットのバックエンドを追加します。

   gcloud compute backend-buckets create \
       web-bucket-$NAME_SUFFIX \
       --gcs-bucket-name=static-web.$DOMAIN
   

2. バックエンドへのトラフィックのフローを可能にする URL マップを作成します。

   gcloud compute url-maps create \
       web-map-http-bucket-$NAME_SUFFIX \
       --default-backend-bucket=web-bucket-$NAME_SUFFIX
   

3. ゾーン障害をシミュレーションする前に、リソースのデプロイを確認します。次の図に示すように、すべてのリソースが環境をサポートするために作成されました。

   

   • ロードバランサは、トラフィックを 2 つのマネージド インスタンス グループに転送します。それぞれのマネージド インスタンス グループには、基本的なウェブサイトを実行する 2 つの VM が含まれています。
   • Cloud Storage バケットは、マネージド インスタンス グループに障害が発生した場合に、静的ページをホストするように構成されています。
   • ロードバランサは Cloud Storage の静的サイトを使用するように構成されていますが、現在ストレージ バケットにトラフィックを転送しません。

Cloud Storage バケットへのフェイルオーバー

本番環境では、マネージド インスタンス グループに問題発生すると、Cloud Monitoring や他のモニタリング ソリューションを使用してアラートが表示されることがあります。このアラートは、ロードバランサを更新してトラフィックを Cloud Storage がホストする静的ウェブサイトにリダイレクトする前に、障害の範囲を理解するよう人間に促します。別の方法としては、モニタリング ソリューションを使用して、マネージド インスタンス グループの障害に自動的に対応する方法があります。

次の図に示すように、フェイルオーバーが発生すると、外部アプリケーション ロードバランサが Cloud Storage でホストされている静的ウェブサイトにトラフィックを転送します。

ユーザーまたはモニタリング ソリューションが、最も適切なアクションはストレージ バケットにトラフィックを転送するようにロードバランサを更新することであると判断した場合、前のセクションで作成した URL マップを使用するように HTTP プロキシ ターゲットを更新します。このドキュメントでは、トラフィックを Cloud Storage でホストされている静的ウェブサイトにリダイレクトするようにロードバランサを手動で更新します。

1. 既存の HTTP プロキシ ターゲットを更新して、Cloud Storage バケット用の URL マップを使用します。

   gcloud compute target-http-proxies update \
       http-lb-proxy-$NAME_SUFFIX \
       --url-map=web-map-http-bucket-$NAME_SUFFIX
   

2. 次に curl を使用するか、ウェブブラウザを開いてロードバランサの IP アドレスにアクセスします。

   curl $IP_ADDRESS
   

   次の出力例に示すように、Cloud Storage から静的ウェブサイトが返されます。

   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test static web server with warm failover from Cloud Storage!</p>
   </body>
   </html>
   

   ロードバランサの構成が更新され、Cloud Storage バケットにトラフィックを正しく転送するまでに数分かかることがあります。必要に応じて、数分待ってからもう一度ウェブサイトにアクセスしてください。

マネージド インスタンス グループへのフェイルバック

マネージド インスタンス グループの問題が解決されたら、URL マップの構成を再度更新することで、ロードバランスされたマネージド インスタンス グループのコンテンツに戻ることができます。この判断は、マネージド インスタンス・グループの健全性に関する Cloud Monitoring 分析情報を使用して、人間が行うことができます。あるいは、マネージド インスタンス グループの健全性が回復したときに、自動化で対応することもできます。このドキュメントでは、ロードバランサの構成を手動で更新します。

1. マネージド インスタンス グループの URL マップを再度使用するように HTTP プロキシ ターゲットを更新します。

   gcloud compute target-http-proxies update \
       http-lb-proxy-$NAME_SUFFIX \
       --url-map=web-map-http-$NAME_SUFFIX
   

2. curl を再度使用するか、ウェブブラウザを開いてロードバランサの IP アドレスにアクセスします。

   curl $IP_ADDRESS
   

   ロードバランサで構成が更新され、トラフィックをマネージド インスタンス グループに正しく転送するまでに、数分かかることがあります。必要に応じて、数分待ってからもう一度ウェブサイトにアクセスしてください。

   次の出力例に示すように、マネージド インスタンス グループのメイン ウェブサイトが返されます。

   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

このドキュメントで作成した個別のリソースを削除するには、次の手順を行います。

1. Cloud Storage バケットを削除します。

   gsutil rm -r gs://static-web.$DOMAIN
   

2. ロードバランサの構成を削除します。

   gcloud compute forwarding-rules delete \
       http-content-rule-$NAME_SUFFIX --global --quiet
   
   gcloud compute target-http-proxies delete \
       http-lb-proxy-$NAME_SUFFIX --quiet
   
   gcloud compute url-maps delete web-map-http-$NAME_SUFFIX --quiet
   
   gcloud compute url-maps delete web-map-http-bucket-$NAME_SUFFIX --quiet
   
   gcloud compute backend-services delete \
       web-backend-service-$NAME_SUFFIX --global --quiet
   
   gcloud compute backend-buckets delete web-bucket-$NAME_SUFFIX --quiet
   

3. マネージド インスタンス グループとヘルスチェックを削除します。

   gcloud compute instance-groups managed delete \
       instance-group-$NAME_SUFFIX-$REGION1 \
       --region=$REGION1 --quiet
   
   gcloud compute instance-groups managed delete \
       instance-group-$NAME_SUFFIX-$REGION2 \
       --region=$REGION2 --quiet
   
   gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet
   

4. インスタンス テンプレート、イメージ、ベース VM、永続ディスクを削除します。

   gcloud compute instance-templates delete \
       template-$NAME_SUFFIX-$REGION1 --quiet
   
   gcloud compute instance-templates delete \
       template-$NAME_SUFFIX-$REGION2 --quiet
   
   gcloud compute images delete image-$NAME_SUFFIX --quiet
   
   gcloud compute images delete image-disk-$NAME_SUFFIX --quiet
   
   gcloud compute instances delete vm-base-$NAME_SUFFIX \
       --zone=$ZONE --quiet
   

5. ファイアウォール ルールを削除します。

   gcloud compute firewall-rules delete \
       allow-health-check-$NAME_SUFFIX --quiet
   
   gcloud compute firewall-rules delete \
       allow-ssh-$NAME_SUFFIX --quiet
   
   gcloud compute firewall-rules delete \
       allow-http-$NAME_SUFFIX --quiet
   

6. サブネットと VPC を削除します。

   gcloud compute networks subnets delete \
       subnet-$NAME_SUFFIX-$REGION1 --region=$REGION1 --quiet
   
   gcloud compute networks subnets delete \
       subnet-$NAME_SUFFIX-$REGION2 --region=$REGION2 --quiet
   
   gcloud compute networks delete network-$NAME_SUFFIX --quiet
   

次のステップ

• 外部アプリケーション ロードバランサの代わりに Cloud DNS を使用してフェイルオーバーを制御する代替方法については、Compute Engine と Cloud Storage で Cloud DNS を使用して復元可能なウォーム ウェブサーバーをデプロイするをご覧ください。このパターンは、Cloud DNS を保有している、または使用する場合に有用です。
• 独自のアプリケーションに最適なアプローチや、使用する復旧メソッドを決定する方法については、障害復旧計画ガイドをご覧ください。
• コールド フェイルオーバーやホット フェイルオーバーなど、アプリケーションのその他のパターンについて、アプリケーションの障害復旧シナリオで確認する。
• スケールと可用性を扱うその他の方法について、スケーラブルで復元性の高いアプリのパターンで確認する。
• Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。