このドキュメントは、運用と管理チームで作業するアーキテクトと担当者を対象としています。このドキュメントでは、Google Cloud で独自のデプロイに使用できるパターンの例について説明します。
このアーキテクチャでは、Cloud DNS が、コンテンツを処理するマネージド インスタンス グループの Compute Engine インスタンスにトラフィックを誘導します。サービスが停止した場合は、Cloud DNS ゾーンを更新して、Cloud Storage の静的サイトにフェイルオーバーします。
このソリューションをデプロイするには、自身が管理し、このドキュメントに沿って使用する登録済みドメイン名が必要です。
本番環境のデプロイでは、このドキュメントに示されている数よりも多くのファイルとマネージド インスタンス グループの仮想マシン（VM）上のアプリケーション コードがウェブサイトに含まれている可能性があります。Cloud Storage は、機能が最も少ない制限付きの静的バージョンをホストします。ウォーム フェイルオーバー シナリオでは、マネージド インスタンス グループが回復し、完全なウェブサイト エクスペリエンスを表示するためのトラフィックを提供できるようになるまで、ユーザーにはこの限定された Web サイトが表示されます。
アーキテクチャ
このアーキテクチャでは、次の図のようにリソースをデプロイして環境を作成します。
フェイルオーバーする必要がある場合は、次の図に示すように、Cloud DNS 構成を更新して、トラフィックを Cloud Storage に転送します。
このウォーム フェイルオーバー パターンは、プライマリ リージョンに障害が発生したときにのみ使用する別のマネージド インスタンス グループを別のリージョンで稼働させることで、費用のバランスを取っています。Cloud Storage を使用する静的サイトの費用は、別のマネージド インスタンス グループを実行するよりも低コストですが、ホスティング オプション間で Cloud DNS を更新する際に、わずかな遅延が発生します。Cloud Storage でのウェブサイトのエクスペリエンスは限定されていますが、完全に利用できないウェブサイトや、劣悪なカスタマー エクスペリエンスよりも優れています。
Cloud DNS の代わりに外部アプリケーション ロードバランサを使用してフェイルオーバーを制御する代替方法については、Compute Engine と Cloud Storage を使用して復元可能なウォーム ウェブサーバーをデプロイするをご覧ください。このパターンは、Cloud DNS を保有していない、または使用しない場合に有用です。
Google Cloud で信頼性の高いアプリケーションを実行するには、サービス停止を処理するようにアプリケーション インフラストラクチャを設計することをおすすめします。アプリケーションやビジネスニーズに応じて、コールド フェイルオーバー、ウォーム フェイルオーバー、ホット フェイルオーバーのパターンが必要になることがあります。お客様のアプリケーションに最適なアプローチを判断する方法については、障害復旧計画ガイドをご覧ください。
このドキュメントでは基本的な Apache ウェブサーバーを使用しますが、インフラストラクチャのデプロイ手法は、作成する必要がある他のアプリケーション環境にも同様に適用されます。
目標
- カスタム VM イメージを使用してリージョン マネージド インスタンス グループを作成する。
- Cloud Storage バケットを作成する。
- Cloud DNS ゾーンを作成して構成する。
- 更新した Cloud DNS レコードでウェブサーバーのウォーム フェイルオーバーをテストする。
- 更新された Cloud DNS レコードで復旧とフェイルバックをテストする。
料金
このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
始める前に
組織で定義されているセキュリティの制約により、次の手順を完了できない場合があります。トラブルシューティング情報については、制約のある Google Cloud 環境でアプリケーションを開発するをご覧ください。
- 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.
-
Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
-
Compute Engine API を有効にします。
- Google Cloud CLI をインストールします。
-
gcloud CLI を初期化するには:
gcloud init
-
Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
-
Compute Engine API を有効にします。
- Google Cloud CLI をインストールします。
-
gcloud CLI を初期化するには:
gcloud init
Google Cloud CLI をインストールせずに、Google Cloud コンソールで Google Cloud CLI を実行できます。Google Cloud コンソールで gcloud CLI を実行するには、Cloud Shell を使用します。
環境を準備する
このセクションでは、リソース名とロケーションの変数を定義します。これらの変数は、リソースをデプロイするときに Google Cloud CLI コマンドによって使用されます。
このデプロイでは、特に断りのない限り、すべてのコマンドを Cloud Shell またはローカルの開発環境で入力します。
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 ネットワークを使用するをご覧ください。
カスタム サブネット モードで VPC を作成します。
gcloud compute networks create network-$NAME_SUFFIX --subnet-mode=custom新しい 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 内でネットワーク トラフィックが正しく流れるようにするには、ファイアウォール ルールを使用します。
ロードバランサおよびマネージド インスタンス グループ用のウェブ トラフィックとヘルスチェックを許可するファイアウォール ルールを作成します。
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:80HTTP ルールでは、
http-serverタグが適用されている VM や、0.0.0.0/0範囲を使用している送信元からのトラフィックを許可します。ヘルスチェック ルールでは、Google Cloud のデフォルトが設定されており、プラットフォームがリソースの健全性を正しくチェックできるようになっています。ベース VM イメージの初期設定で SSH トラフィックを許可するには、
--source-rangeパラメータを使用してファイアウォール ルールを環境に合わせて適用します。組織で使用するソース範囲を決定するには、ネットワーク チームの協力が必要な場合があります。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 つのルールが追加されていることを確認します。
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 で、永続ディスク上に基本的な index.html ファイルを作成し、/var/www/example.comにマウントします。/etc/apache2/sites-available/example.com.conf の Apache 構成ファイルは、マウントされた永続ディスクの場所からウェブ コンテンツを提供します。
次の図は、永続ディスクに保存されている、Apache が提供する基本の HTML ページを示しています。
この環境は次の手順で構築します。
永続ディスクがアタッチされたベース 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 に名前を付け、正しいサブネットに接続します。名前はブートディスクとデータディスクのパラメータからも割り当てられます。
シンプルなウェブサイトをインストールして構成するには、まず SSH を使用してベース VM に接続します。
gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONEVM への 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変数を更新します。ファイルを書き出してエディタを終了します。たとえば、Nano では、
Ctrl-Oを使用してファイルを書き出してからCtrl-Xで終了します。構成スクリプトを実行可能にして、実行します。
chmod +x configure-vm.sh ./configure-vm.shVM への SSH セッションを終了します。
exitVM の 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 の静的サイトへのウォームフェイルオーバーがなくても、高可用性アプリケーションが作成されます。
イメージを作成する前に、VM を停止する必要があります。
gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE次のコマンドセットを実行して、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 トラフィック用のバックエンド サービスを備えた外部 HTTPS ロードバランサを作成し、前のステップで作成したヘルスチェックを使用して、外部 IP アドレスをバックエンド サービスにマッピングします。
詳細については、シンプルな外部 HTTP ロードバランサの設定方法をご覧ください。
アプリケーション用のロードバランサを作成して構成します
# 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ウェブ トラフィックの転送ルールの IP アドレスを取得します。
IP_ADDRESS=$(gcloud compute forwarding-rules describe http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress)")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 からのこの限定されたウェブサイトが表示されます。
Cloud Storage バケットで使用するドメインを確認します。
使用する所有ドメイン名に一致する Cloud Storage バケットを作成します。
gsutil mb gs://static-web.$DOMAINexample.comなどのように、このドキュメントの冒頭で定義されたDOMAIN変数が使用されます。この例では、静的ファイルをstatic-web.example.comに保存します。次のステップで、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基本的な HTML ファイルを Cloud Storage バケットにアップロードします。
gsutil cp index.html gs://static-web.$DOMAINユーザーが静的ウェブ コンテンツを閲覧できるようにするには、Cloud Storage バケットに適切な権限を設定します。
gsutil iam ch allUsers:objectViewer gs://static-web.$DOMAINindex.htmlファイルをデフォルトのウェブページとして提供するように Cloud Storage バケットを構成します。gsutil web set -m index.html gs://static-web.$DOMAIN
DNS ゾーンとレコードの作成
マネージド インスタンス グループで障害が発生したときに、トラフィックを Cloud Storage 上のウォーム静的サイトに転送するために、Cloud DNS ゾーンを作成します。通常の状況では、この DNS ゾーンは外部ロードバランサを介して、前のセクションで作成したマネージド インスタンス グループにトラフィックを転送します。
Cloud DNS ゾーンの作成
gcloud dns managed-zones create zone-$NAME_SUFFIX \ --dns-name=$DOMAIN \ --description="DNS zone for warm site failover"example.comなどのように、このドキュメントの冒頭で定義されたDOMAIN変数が使用されます。Cloud DNS ゾーンの詳細情報を取得します。
gcloud dns managed-zones describe zone-$NAME_SUFFIX次の出力例は、ゾーンの
nameServers（ns-cloud-b1.googledomains.comなど）を示しています。[...] kind: dns#managedZone name: zone-app nameServers: - ns-cloud-b1.googledomains.com. - ns-cloud-b2.googledomains.com. - ns-cloud-b3.googledomains.com. - ns-cloud-b4.googledomains.com.Cloud DNS はドメインに対して信頼できるものでなければなりません。Cloud DNS ゾーンを指すネームサーバー（NS）レコードをドメイン登録事業者で作成します。前のステップで返されたネームサーバー アドレスを使用します。
詳細と Google Domains の使用例については、ネームサーバーの更新方法をご覧ください。
Cloud DNS ゾーンで、前のセクションで取得したロードバランサの IP アドレスを使用して
wwwのレコードを追加します。gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction add $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIXこのレコードは、ロードバランサ経由でウェブサイトのユーザー リクエストをマネージド インスタンス グループに転送します。TTL は 300 秒に設定されており、ユーザーの DNS レコードのキャッシュ保存期間を短縮します。
静的ウェブサイトの Cloud Storage バケットで使用するレコードを作成します。
gcloud dns record-sets transaction add c.storage.googleapis.com. \ --name=static-web.$DOMAIN \ --ttl=300 \ --type=CNAME \ --zone=zone-$NAME_SUFFIXこの例では、サブドメインとして
static-webを使用しています。c.storage.googleapis.com.を残します。ここでも TTL は 300 秒に設定され、ユーザーの DNS レコードのキャッシュ保存期間が短くなります。最後に、DNS レコードの追加をゾーンに commit します。
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
DNS ゾーンとレコードの確認とテスト
ゾーン障害をシミュレーションする前に、リソースのデプロイを確認してみましょう。次の図に示すように、すべてのリソースが環境をサポートするために作成されました。
- Cloud DNS ゾーンレコードは、ユーザーをマネージド インスタンス グループ VM 全体に分散するようにロードバランサに誘導します。
- Cloud Storage バケットは、マネージド インスタンス グループに障害が発生した場合に、静的ウェブページをホストするように構成されています。
- Cloud DNS ゾーンは Cloud Storage の静的サイトを使用するように構成されていますが、現在はストレージ バケットへのリクエストを解決していません。
DNS レコードを表示し、解決策をテストするには、Cloud DNS サーバーに対してアドレスを解決する必要があります。本番環境のデプロイでは、アドレスが正しく解決することをテストして確認し、独自の DNS サーバーを更新して適切に解決するようにします。このドキュメントでは、独自の DNS サーバーの更新手順ではなく、通常時およびフェイルオーバー時にトラフィックが正しく流れることを確認する方法のみを取り上げます。
Cloud DNS ゾーンの詳細情報を再度取得します。
gcloud dns managed-zones describe zone-$NAME_SUFFIX次の出力例は、ゾーンの
nameServers（ns-cloud-b1.googledomains.comなど）を示しています。[...] kind: dns#managedZone name: zone-app nameServers: - ns-cloud-b1.googledomains.com. - ns-cloud-b2.googledomains.com. - ns-cloud-b3.googledomains.com. - ns-cloud-b4.googledomains.com.これらのネームサーバーのいずれかに対して Cloud DNS ゾーンの
wwwレコードを解決するには、digコマンドを使用します。dig @ns-cloud-b1.googledomains.com www.$DOMAINこの例では、前の
describeコマンドから返されたns-cloud-b1.googledomains.comネームサーバー アドレスを使用します。前のコマンドの出力に表示された、独自のネームサーバー アドレスを指定します。次の出力例は、レコードがロードバランサの IP アドレスに解決することを表しています。このネームサーバーを使用してアドレスにアクセスした場合、例えば Cloud DNS ネームサーバーで
curlと--resolveのパラメータを使用すると、ロードバランサの後ろにあるマネージド インスタンス グループの 1 つからデフォルト ページが表示されます。; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com www.example.com ; (1 server found) [...] ;; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 300 IN A 35.227.253.90digコマンドをもう一度使用して、Cloud Storage 内の静的ウェブサイトの DNS レコードを確認します。dig @ns-cloud-b1.googledomains.com static-web.$DOMAIN次の出力例は、レコードがストレージ バケットから静的コンテンツを提供できる Cloud Storage に解決することを示しています。
; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com static-web.example.com ; (1 server found) [...] ;; QUESTION SECTION: ;static-web.example.com. IN A ;; ANSWER SECTION: static-web.example.com. 300 IN CNAME c.storage.googleapis.com.
Cloud Storage バケットへのフェイルオーバー
本番環境では、マネージド インスタンス グループに問題発生すると、Cloud Monitoring や他のモニタリング ソリューションを使用してアラートが表示されることがあります。このアラートは、Cloud DNS レコードを更新してトラフィックを Cloud Storage がホストする静的ウェブサイトにリダイレクトする前に、障害の範囲を理解するよう人間に促します。別の方法としては、モニタリング ソリューションを使用して、マネージド インスタンス グループの障害に自動的に対応する方法があります。
フェイルオーバーが発生すると、Cloud DNS は次の図に示すように、Cloud Storage がホストする静的ウェブサイトへのトラフィックを解決します。
トラフィックを Cloud Storage に転送するために、Cloud DNS レコードを更新することが最も適切なアクションであると、お客様またはモニタリング ソリューションが判断した場合、既存の DNS の A レコードを更新します。このドキュメントでは、Cloud DNS レコードを手動で更新して、トラフィックを Cloud Storage がホストする静的ウェブサイトにリダイレクトします。
Cloud DNS レコードをフェイルオーバーするには、ロードバランサに解決する既存の
Aレコードを削除します。gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction remove $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIXCloud Storage がホストするコンテンツを参照する
wwwのCNAMEレコードを作成します。gcloud dns record-sets transaction add static-web.$DOMAIN \ --name=www.$DOMAIN. \ --ttl=30 \ --type=CNAME \ --zone=zone-$NAME_SUFFIXCloud DNS ゾーンの更新を commit します。
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIXdigコマンドを使用して、wwwレコードが Cloud Storage 静的ウェブサイトのアドレスに解決するようになったことを確認します。dig @ns-cloud-b1.googledomains.com www.$DOMAIN次の出力例は、
www.example.comレコードが Cloud Storage の静的ウェブサイトの CNAME レコードに解決することを示しています。www.example.comへのアクセス リクエストは、Cloud Storage バケットにリダイレクトされ、静的な Web サイトが表示されます。; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com www.example.com ; (1 server found) [...] ;; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 30 IN CNAME static-web.example.com. static-web.example.com. 300 IN CNAME c.storage.googleapis.com.
マネージド インスタンス グループへのフェイルバック
マネージド インスタンス グループの問題が解決したら、Cloud DNS レコードを再度更新することで、負荷分散されたマネージド インスタンス グループからのコンテンツの提供を再開できます。この判断は、マネージド インスタンス・グループの健全性に関する Cloud モニタリング分析情報を使用して、人間が行うことができます。あるいは、マネージド インスタンス グループの健全性が回復したときに、自動化で対応することもできます。このドキュメントでは、Cloud DNS レコードを手動で更新します。
フェイルバックすると、次の画像に示すように、Cloud DNS はトラフィックをマネージド インスタンス グループに再度解決します。
Cloud Storage がホストするコンテンツへのトラフィックをリダイレクトする
wwwCNAME レコードを削除します。gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction remove static-web.$DOMAIN \ --name=www.$DOMAIN \ --ttl=30 \ --type=CNAME \ --zone=zone-$NAME_SUFFIXマネージド インスタンス グループの前に、ロードバランサを指す
Aレコードを再度追加します。gcloud dns record-sets transaction add $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIXCloud DNS ゾーンの更新を commit します。
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIXdigコマンドをもう一度使用して、wwwレコードがマネージド インスタンス グループの前にあるロードバランサのアドレスに解決することを確認します。dig @ns-cloud-b1.googledomains.com www.$DOMAIN次の出力例では、レコードがロードバランサの IP アドレスに解決し、トラフィックがマネージド インスタンス グループの 1 つから提供されることを示しています。
; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com www.example.com ; (1 server found) [...] ;; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 300 IN A 35.227.253.90
クリーンアップ
このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。
このドキュメントで作成した個別のリソースを削除するには、次の手順を行います。
DNS ゾーンとレコードを削除します。
touch empty-file gcloud dns record-sets import -z zone-$NAME_SUFFIX \ --delete-all-existing \ empty-file rm empty-file gcloud dns managed-zones delete zone-$NAME_SUFFIXCloud Storage バケットを削除します。
gsutil rm -r gs://static-web.$DOMAINロードバランサの構成を削除します。
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 backend-services delete \ web-backend-service-$NAME_SUFFIX --global --quietマネージド インスタンス グループとヘルスチェックを削除します。
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インスタンス テンプレート、イメージ、ベース 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ファイアウォール ルールを削除します。
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サブネットと 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 を保有していない、または使用しない場合に有用です。
- 独自のアプリケーションに最適なアプローチや、使用する復旧メソッドを決定する方法については、障害復旧計画ガイドをご覧ください。
- コールド フェイルオーバーやホット フェイルオーバーなど、アプリケーションのその他のパターンについて、アプリケーションの障害復旧シナリオで確認する。
- スケールと可用性を扱うその他の方法について、スケーラブルで復元性の高いアプリのパターンで確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。