このチュートリアルでは、アプリケーション ロードバランサを使用して、異なるリージョンにプロビジョニングされている Compute Engine VM で動作する Microsoft インターネット インフォメーション サービス（IIS）ウェブサーバーにトラフィックを分散する方法について説明します。
目的
このチュートリアルでは、サイト www.example.com に対するトラフィックをロード バランシングして次のようにする方法について説明します。
- 受信リクエストは、最も近いリージョンに転送します。
- インスタンスに障害が発生した場合や、処理能力の上限に達した場合は、ロードバランサがリクエストを、同じまたは異なるリージョンにあり応答がある他のインスタンスに転送します。
このシナリオの構成では、単一のグローバル IP アドレスを介してリクエストを行う外部アプリケーション ロードバランサを使用します。この IP アドレスで、接続タイプが HTTP と HTTPS のどちらであるかに応じて受信リクエストをルーティングできます。HTTPS リクエストの場合は、リクエストを送信したクライアントとロードバランサの間で SSL / TLS 暗号化が実装されます。
次の図は、ロードバランサのアーキテクチャを示しています。
このロードバランサは、構成の柔軟性を高めるために複数のコンポーネントで構成されます。各コンポーネントの詳細については、外部アプリケーション ロードバランサの概要をご覧ください。
このチュートリアルでは、目標を達成するために次のタスクを行う方法について説明します。
- バックエンド インスタンスを設定する。
- ロード バランシング サービスを作成して構成する。
- バックエンドにトラフィックを送信する。
- バックエンドへのアクセスを制限する。
- 停止のシミュレーションを行う。
費用
このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。
- Compute Engine virtual machine (VM) instances
- Compute Engine persistent disks
- Optional: Google-managed SSL certificate
- Windows Server 2016 machine images
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。
始める前に
- 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, BigQuery, and Cloud Firestore API を有効にします。
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
-
Compute Engine, BigQuery, and Cloud Firestore API を有効にします。
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
- リモート デスクトップ プロトコル（RDP）クライアントをインストールします。詳細については、Microsoft リモート デスクトップ クライアントをご覧ください。RDP クライアントがすでにインストールされている場合は、このタスクをスキップできます。
- リソースをプロビジョニングするゾーンとリージョンを決定します。アーキテクチャ図は、US と EU のリージョンの異なるゾーンにデプロイされたリソースを示しています。これは参考用です。任意のリージョン / ゾーンにリソースをデプロイできます。
- 省略可: 外部アプリケーション ロードバランサの概要を読んで理解します。
バックエンド インスタンスを設定する
このセクションでは、異なるリージョンに 2 つのバックエンド サービスを作成します。各バックエンド サービスに 2 つのバックエンド インスタンスを含め、それぞれ Windows Server 2016 で Microsoft IIS ウェブサーバーを実行します。サーバーを 1 つずつ手動で構成する手間を省くため、1 つのサーバー インスタンスからディスク イメージを作成し、そのイメージを使用して残りのサーバー インスタンスを作成します。
Compute Engine インスタンスの作成と構成
ソースイメージとして使用するインスタンスを作成するには:
Google Cloud Marketplace から、任意のゾーンの Compute Engine で Microsoft IIS を実行する Windows Server 2016 のインスタンスを起動して、ソースイメージ インスタンスへの外部の HTTP、HTTPS、RDP トラフィックを許可するファイアウォール ルールを設定します。
Google Cloud コンソールで Cloud Marketplace の [ASP.NET Framework] ページに移動します。
[運用開始] をクリックします。
[デプロイ名] フィールドに「src-img」と入力します。
[ゾーン] フィールドで、イメージをデプロイするゾーンを選択します。
[Windows Server OS Version] フィールドで [2016] を選択します。
[Networking - Firewall] セクションでは、次のオプションのみを選択します。
- HTTP トラフィックを許可する
- HTTPS トラフィックを許可する
- Allow RDP traffic
利用規約に同意し、[デプロイ] をクリックします。
Compute Engine インスタンスの作成が完了するまで待ちます。
ソースイメージ インスタンスを構成する
新しいソースイメージ インスタンスを構成するには、ソースイメージ インスタンスの新しい Windows ユーザーを作成し、RDP 接続を確立します。
Google Cloud コンソールで [VM インスタンス] ページに移動します。
ソースイメージ インスタンス（
src-img）の名前をクリックします。[Windows パスワードを設定] をクリックします。
[新しい Windows パスワードの設定] ダイアログで、ユーザー名を追加して [設定] をクリックし、インスタンスのユーザー アカウントを作成します。
表示されたパスワードをコピーし、ダイアログを閉じます。
[RDP] プルダウンをクリックし、[RDP ファイルをダウンロード] オプションを選択して、インスタンスの RDP ファイルをダウンロードします。このファイルを RDP クライアントで使用することで、インスタンスに接続できます。詳細については、Microsoft リモート デスクトップ クライアントをご覧ください。
ソースイメージ インスタンスとの RDP 接続を確立したら、IIS のデフォルト ウェブ ディレクトリにデフォルトのホームページを追加します。
ソースイメージ インスタンスで、管理者として PowerShell を開きます。
新しいホームページをデフォルトの IIS ウェブ ディレクトリ
C:\inetpub\wwwrootに作成します。Echo '<!doctype html><html><body><h1>Hello World!</h1></body></html>' > C:\inetpub\wwwroot\index.html
ソースイメージ インスタンスからコンテンツを配信できることを確認する
Google Cloud コンソールで [VM インスタンス] ページに移動します。
インスタンスの外部 IP アドレスをクリックし、前のステップで作成したホームページが表示されることを確認します。
ソースイメージ インスタンスから再利用可能な Windows Server 2016 イメージを作成する
ソースイメージ インスタンスが適切に構成され、コンテンツを配信できることを確認したら、インスタンスのルート永続ディスクから再利用可能なディスク イメージを作成します。
- ソースイメージ インスタンスで、管理者として PowerShell を開きます。
システムのクローンを作成する準備として、次のコマンドを実行します。
GCESysprep
GCESysprepオペレーションが完了すると、RDP セッションが自動的に切断されます。ローカルマシンで次のコマンドを実行して、ソース インスタンスを削除します。ただし、インスタンスのルート永続ディスクは残します。
gcloud compute instances delete src-img \ --keep-disks=boot \ --zone=INSTANCE_ZONE
INSTANCE_ZONEは、ソース インスタンスのゾーンに置き換えます。インスタンスを削除したら、削除せずに残したルート永続ディスクから新しいイメージを作成します。
gcloud compute images create win-be-img \ --source-disk=src-img \ --source-disk-zone=IMAGE_ZONE
IMAGE_ZONEは、ソースイメージを作成するゾーンに置き換えます。
ソースイメージを使用してインスタンス テンプレートを作成する
構成した Windows サーバーのディスク イメージをインスタンス テンプレートのソースイメージとして使用します。このテンプレートは、新しいインスタンスで 2 つのマネージド インスタンス グループを構成するときに使用します。
ローカルマシンで次のコマンドを実行して、ソースイメージとして win-be-img を使用し、インスタンス タグとして rdp-tag と www-tag を使用するインスタンス テンプレートを作成します。
gcloud compute instance-templates create win-be-tmpl \
--tags=rdp-tag,www-tag \
--image=win-be-img
各リージョンのマネージド インスタンス グループを作成する
各リージョンで、マネージド インスタンス グループを作成します。各インスタンス グループを作成後、前の手順で定義したインスタンス テンプレートに基づいて、2 つの同一インスタンスが自動的に挿入されます。これらのインスタンス グループは、後でロードバランサを構成するときにバックエンド ターゲットとして使用します。
マネージド インスタンス グループを作成する手順は次のとおりです。
ローカルマシンで次のコマンドを実行して、イメージを作成したゾーンに新しいマネージド インスタンス グループを作成し、そこに 2 つの同一インスタンスを自動で作成します。
gcloud compute instance-groups managed create MANAGED_INSTANCE_GROUP_NAME_1 \ --base-instance-name=BASE_INSTANCE_NAME_1 \ --size=2 \ --zone=ZONE_1 \ --template=win-be-tmpl
次のように置き換えます。
MANAGED_INSTANCE_GROUP_NAME_1: マネージド インスタンスの名前BASE_INSTANCE_NAME_1: ベース インスタンスの名前ZONE_1: マネージド インスタンスをデプロイするゾーン。
2 つ目のゾーンにマネージド インスタンス グループを作成します。
gcloud compute instance-groups managed create MANAGED_INSTANCE_GROUP_NAME_2 \ --base-instance-name=BASE_INSTANCE_NAME_2 \ --size=2 \ --zone=ZONE_2 \ --template=win-be-tmpl
次のように置き換えます。
MANAGED_INSTANCE_GROUP_NAME_2: マネージド インスタンスの名前BASE_INSTANCE_NAME_2: ベース インスタンスの名前ZONE_2: マネージド インスタンスをデプロイするゾーン。
バックエンド インスタンスが実行されていることを確認する
Google Cloud コンソールで [VM インスタンス] ページに移動します。
各バックエンドの外部 IP アドレスをクリックして、前の手順で作成したホームページが表示されることを確認します。
ロード バランシング サービスを作成して構成する
Compute Engine 負荷分散サービスには複数のコンポーネントがあります。このセクションでは、それらのコンポーネントを作成して連携させます。
ローカルマシンで次のコマンドを実行して、新しいヘルスチェックを作成します。ロードバランサは、このチェックを使用してバックエンド インスタンスの応答を確認します。
gcloud compute http-health-checks create basic-check
バックエンド サービスを作成します。
gcloud compute backend-services create BACKEND_SERVICE_NAME \ --protocol=HTTP \ --http-health-checks=basic-check \ --global
BACKEND_SERVICE_NAMEは、バックエンド サービスの名前に置き換えます。インスタンス グループをバックエンド サービスのバックエンド ターゲットとして追加します。
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --instance-group=MANAGED_INSTANCE_GROUP_NAME_1 \ --instance-group-zone=ZONE_1 gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --instance-group=MANAGED_INSTANCE_GROUP_NAME_2 \ --instance-group-zone=ZONE_2
あらゆるインスタンスへの受信リクエストをすべて振り向けるデフォルトの URL マップを作成します。
gcloud compute url-maps create lb-map \ --default-service=BACKEND_SERVICE_NAME
SSL 証明書リソースを作成します。このリソースは、ロードバランサでトラフィックの暗号化と復号に使用します。
秘密鍵と認証局が発行した SSL 証明書を入手済みの場合は、それらを使用し、次のコマンドを実行して新しい
SSLCertificateリソースを作成できます。秘密鍵と証明書がない場合は、テスト用の Google マネージド SSL 証明書または自己署名証明書を作成して使用できます。詳しくは、SSL 証明書をご覧ください。次のコマンドを実行して SSL 証明書リソースを作成します。
gcloud compute ssl-certificates create www-cert \ --certificate CRT_FILE_PATH \ --private-key KEY_FILE_PATH
次のように置き換えます。
CRT_FILE_PATH: 証明書のローカル ファイルのパスKEY_FILE_PATH: 秘密鍵のファイルパス
URL マップにリクエストをルーティングするターゲットの HTTP プロキシと HTTPS プロキシを作成します。プロキシはロードバランサの一部であり、HTTPS ロード バランシング用の SSL 証明書を保持するため、この手順で証明書も読み込みます。
gcloud compute target-http-proxies create http-lb-proxy \ --url-map=lb-map gcloud compute target-https-proxies create https-lb-proxy \ --url-map lb-map \ --ssl-certificate SSL_CERT
以下の内容に応じて SSL_CERT を置き換えます。
- SSL 証明書と秘密鍵を使用して SSLCertificate リソースを作成した場合は、
SSL_CERTを www-cert に置き換えます。 - Google マネージド SSL 証明書または自己署名 SSL 証明書を使用している場合は、
SSL_CERTを証明書の名前に置き換えます。
- SSL 証明書と秘密鍵を使用して SSLCertificate リソースを作成した場合は、
ロードバランサで確実にトラフィックを受信するように、ロードバランサのグローバル転送ルールにグローバル静的 IP アドレスを割り当てる必要があります。
グローバル静的 IP アドレス リソースを作成するには、次のコマンドを実行します。
gcloud compute addresses create lb-ip \ --global \ --network-tier=PREMIUM
IP アドレスはメモしておいてください。
HTTP と HTTPS の受信リクエスト用にグローバル転送ルールを 2 つ作成します。それぞれの転送ルールにより、IP アドレス、IP プロトコル、ポートの指定に応じて、作成したいずれかのターゲット プロキシにトラフィックが送信されます。
-
グローバル外部アプリケーション ロードバランサの場合は、
load-balancing-scheme=EXTERNAL_MANAGEDを指定して gcloud CLI コマンドを使用します。この設定では、高度なトラフィック管理機能が提供されます。 - 従来のアプリケーション ロードバランサの場合は、
load-balancing-scheme=EXTERNALを使用します。
gcloud compute forwarding-rules create http-fwd-rule \ --load-balancing-scheme=LOAD_BALANCING_SCHEME \ --network-tier=PREMIUM \ --address=lb-ip \ --global \ --target-http-proxy=http-lb-proxy \ --ports=80 gcloud compute forwarding-rules create https-fwd-rule \ --load-balancing-scheme=LOAD_BALANCING_SCHEME \ --network-tier=PREMIUM \ --address=lb-ip \ --global \ --target-https-proxy=https-lb-proxy \ --ports=443
-
グローバル外部アプリケーション ロードバランサの場合は、
グローバル転送ルールを作成した後、構成が反映されるまでに数分かかることがあります。進行状況を確認するには、Google Cloud コンソールで構成をモニタリングするか、ローカルマシンで次のコマンドを実行します。
gcloud compute backend-services get-health BACKEND_SERVICE_NAME
バックエンドにトラフィックを送信する
ロード バランシング サービスの構成が完了したので、転送ルールへのトラフィックの送信を開始できます。また、別のインスタンスに分散されるトラフィックを監視できます。
次のようにバックエンドにトラフィックを送信します。
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
[フロントエンド] タブを選択します。
デフォルトのホームページを表示するには、[アドレス] 列の IP アドレスをクリックします。
バックエンドへのアクセスを制限する
ここまでの作業に問題がないことを確認したら、インスタンスでロード バランシング サービスからの HTTP または HTTPS トラフィックのみを受け入れるようにファイアウォール ルールを変更します。
Google Cloud コンソールで [ファイアウォール] ページに移動します。
ポート
tcp:80への外部アクセスを許可するファイアウォール ルールの名前をクリックします。[編集] をクリックして、ファイアウォール ルールを編集します。
[送信元 IPv4 範囲] フィールドで、値
0.0.0.0/0を削除し、「130.211.0.0/22」と入力します。これにより、ファイアウォール ルールで許可されるソース IP が130.211.0.0/22の範囲に制限されます。これは HTTPS ロード バランシング ヘルスチェックの IP 範囲です。[保存] をクリックします。
Google Cloud コンソールで [VM インスタンス] ページに移動します。
各インスタンスの外部 IP アドレスをクリックして、インスタンスにアクセスできなくなったことを確認します。
停止のシミュレーションを行う
レスポンスできるインスタンス間でのロード バランシングの様子を確認するには、リージョン内の 1 つ以上のインスタンスで停止のシミュレーションを行います。
インスタンスでのリクエストの受信を停止するには:
- インスタンスへの RDP 接続を確立します。
- インスタンスで、管理者として PowerShell を開きます。
次のコマンドを実行して、インスタンスに適用する新しいファイアウォール ルールを作成します。このコマンドを実行すると、ヘルス チェッカーからのヘルスチェック トラフィックがブロックされ、ロードバランサからインスタンスへの新しい HTTP 接続もすべて阻止されます。
netsh advfirewall firewall add rule name="Outage Test" protocol=tcp dir=in localport=80 action=block remoteip=130.211.0.0/22
ローカルマシンで次のコマンドを実行して、インスタンスのステータスが
UNHEALTHYになったことを確認します。gcloud compute backend-services get-health BACKEND_SERVICE_NAME
インスタンスのステータスが
UNHEALTHYになったら、ロードバランサにリクエストを送信します。レスポンスできるインスタンスからのみレスポンスが返されます。停止のシミュレーションが終了したら、ファイアウォール ルールを削除してインスタンスの接続を復元します。レスポンスを返さないインスタンスで管理者として PowerShell を開き、次のコマンドを実行してルールを削除します。
netsh advfirewall firewall delete rule name="Outage Test"
クリーンアップ
チュートリアルが終了したら、作成したリソースをクリーンアップして、割り当ての使用を停止し、課金されないようにできます。次のセクションで、リソースを削除または無効にする方法を説明します。
プロジェクトを削除する
課金を停止する最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。
Delete a Google Cloud project:
gcloud projects delete PROJECT_ID
リソースを個別に削除する
プロジェクト用に作成したすべてのリソース（イメージ、インスタンス テンプレート、インスタンス グループ、ヘルスチェック、バックエンド サービス、URL マップ、HTTP プロキシ、アドレス、転送ルール）は、個別に削除する必要があります。VM インスタンスは、次のコマンドを実行するまで削除できません。
ローカルマシンで次のコマンドを実行して、チュートリアル用に作成したリソースを削除します。
- HTTP/S 転送ルールを削除します。
gcloud compute forwarding-rules delete https-fwd-rule --global
gcloud compute forwarding-rules delete http-fwd-rule --global
- グローバル静的 IP アドレスを削除します。
gcloud compute addresses delete lb-ip --global
- HTTP/S プロキシを削除します。
gcloud compute target-https-proxies delete https-lb-proxy
gcloud compute target-http-proxies delete http-lb-proxy
- SSL 証明書を削除します。
gcloud compute ssl-certificates delete SSL_CERT
- URL マップを削除します。
gcloud compute url-maps delete lb-map
- バックエンド サービスを削除します。
gcloud compute backend-services delete BACKEND_SERVICE_NAME --global
- HTTP ヘルスチェックを削除します。
gcloud compute http-health-checks delete basic-check
- マネージド インスタンス グループを削除します。
gcloud compute instance-groups managed delete MANAGED_INSTANCE_GROUP_NAME_1 --zone=ZONE_1
gcloud compute instance-groups managed delete MANAGED_INSTANCE_GROUP_NAME_2 --zone=ZONE_2
- インスタンス テンプレートを削除します。
gcloud compute instance-templates delete win-be-tmpl
- イメージを削除します。
gcloud compute images delete IMAGE_NAME
- ディスクを削除します。
gcloud compute disks delete DISK_NAME
次のステップ
- ロードバランスされた IIS ウェブサーバーをデプロイするチュートリアルを行う。
- Google Cloud アーキテクチャ フレームワークのベスト プラクティスを確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。