1. はじめに
高度なトラフィック管理（Envoy）を備えた外部 HTTPS ロードバランサの Codelab へようこそ。
高度なトラフィック管理機能を含む最新バージョンの HTTP(S) 外部ロードバランサには、既存の従来のグローバル外部 HTTP(S) ロードバランサのすべての機能が含まれていますが、高度なトラフィック管理機能のリストは増え続けています。これらの機能の一部はロードバランサに新しく追加されたもので、一部は既存の機能の強化です。これらの機能の一部を以下に示します。
- 重み付けによるトラフィック分割
- リクエストのミラーリング
- 外れ値検出
- リクエストの再試行
- フォールト インジェクション
- 追加のバックエンド セッション アフィニティのオプション
- 追加のヘッダー変換のオプション
- クロスオリジン リソース シェアリング（CORS）
- 新しいロード バランシング アルゴリズム
学習内容
- マネージド インスタンス グループと関連する VPC ルールとファイアウォール ルールを設定する方法
- 新しいロードバランサの高度なトラフィック管理機能の使用方法
- 高度なトラフィック管理機能が意図したとおりに動作していることを検証する方法。
必要なもの
- ネットワーキングと HTTP に関する基本的な知識
- Unix / Linux コマンドラインに関する基本的な知識
Codelab のトポロジとユースケース
図 1 - HTTP ロードバランサのルーティング トポロジ
このコードラボでは、東部、西部、中部に 1 つずつ、3 つのマネージド インスタンス グループを設定します。グローバル外部 HTTPS ロードバランサを作成します。ロードバランサは、Envoy ベースのロードバランサがサポートする高度な機能のリストからいくつかの機能を利用します。デプロイが完了したら、シミュレートされた負荷を生成し、設定した構成が適切に機能していることを確認します。
2. 設定と要件
セルフペース型の環境設定
- Google Cloud Console にログインして、プロジェクトを新規作成するか、既存のプロジェクトを再利用します。Gmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。
- プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列です。いつでも更新できます。
- プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です（設定後は変更できません）。Cloud コンソールでは一意の文字列が自動生成されます。通常は、この内容を意識する必要はありません。ほとんどの Codelab では、プロジェクト ID（通常は
PROJECT_IDと識別されます）を参照する必要があります。生成された ID が好みではない場合は、ランダムに別の ID を生成できます。または、ご自身で試して、利用可能かどうかを確認することもできます。このステップ以降は変更できず、プロジェクトを通して同じ ID になります。 - なお、3 つ目の値として、一部の API が使用するプロジェクト番号があります。これら 3 つの値について詳しくは、こちらのドキュメントをご覧ください。
- 次に、Cloud のリソースや API を使用するために、Cloud コンソールで課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルの終了後に請求が発生しないようにリソースをシャットダウンするには、作成したリソースを削除するか、プロジェクトを削除します。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアル プログラムをご利用いただけます。
Cloud Shell を起動する
Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。
Google Cloud Console で、右上のツールバーにある Cloud Shell アイコンをクリックします。
プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。
この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。この Codelab での作業はすべて、ブラウザ内から実行できます。インストールは不要です。
始める前に
Cloud Shell で、プロジェクト ID が設定されていることを確認します。
gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
PROJECT_ID=[YOUR-PROJECT-NAME]
echo $PROJECT_ID
API を有効にする
必要なサービスをすべて有効にする
gcloud services enable compute.googleapis.com gcloud services enable logging.googleapis.com gcloud services enable monitoring.googleapis.com
3. VPC ネットワークを作成する
VPC ネットワークを作成する
Cloud Shell から
gcloud compute networks create httplbs --subnet-mode=auto
出力
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/httplbs]. NAME: httplbs SUBNET_MODE: AUTO BGP_ROUTING_MODE: REGIONAL IPV4_RANGE: GATEWAY_IPV4:
VPC ファイアウォール ルールを作成する
VPC を作成したら、ファイアウォール ルールを作成します。ファイアウォール ルールは、すべての IP がテスト アプリケーションのウェブサイトの外部 IP にポート 80 で HTTP トラフィックとしてアクセスできるようにするために使用されます。
Cloud Shell から
gcloud compute firewall-rules create httplb-allow-http-rule \ --allow tcp:80 \ --network httplbs \ --source-ranges 0.0.0.0/0 \ --priority 700
出力
Creating firewall...working..Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls/httplb-allow-http-rule]. Creating firewall...done. NAME: httplb-allow-http-rule NETWORK: httplbs DIRECTION: INGRESS PRIORITY: 700 ALLOW: tcp:80 DENY: DISABLED: False
4. マネージド インスタンス グループを設定する
HTTP ロードバランサで使用されるバックエンド リソースのパターンを含むマネージド インスタンス グループを設定する必要があります。まず、各リージョンで作成される VM の構成を定義するインスタンス テンプレートを作成します。次に、各リージョンのバックエンドに対して、インスタンス テンプレートを参照するマネージド インスタンス グループを作成します。
マネージド インスタンス グループは、スコープ内のゾーンまたはリージョンに設定できます。このラボ演習では、3 つのリージョン マネージド インスタンス グループ（us-east1、us-west1、us-central1 に 1 つずつ）を作成します。
このセクションでは、インスタンスの作成時に参照される、事前に作成された起動スクリプトを確認できます。この起動スクリプトは、ウェブ アプリケーションのシミュレーションに使用するウェブサーバー機能をインストールして有効にします。こちらのスクリプトをご参照ください。
東、西、中央のインスタンス テンプレートを作成する
最初のステップは、us-east-1 インスタンス テンプレートを作成することです。
Cloud Shell から
gcloud compute instance-templates create us-east1-template \
--region=us-east1 \
--network=httplbs \
--tags=http-server, \
--image-family=debian-12 \
--image-project=debian-cloud \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2'
出力
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-east1-template]. NAME: us-east1-template MACHINE_TYPE: n1-standard-1 PREEMPTIBLE: CREATION_TIMESTAMP: 2021-11-11T11:02:37.511-08:00
次のステップでは、us-west-1 インスタンス テンプレートを作成します。
Cloud Shell から
gcloud compute instance-templates create us-west1-template \
--region=us-west1 \
--network=httplbs \
--tags=http-server, \
--image-family=debian-12 \
--image-project=debian-cloud \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2'
出力
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-west1-template]. NAME: us-west1-template MACHINE_TYPE: n1-standard-1 PREEMPTIBLE: CREATION_TIMESTAMP: 2021-11-11T11:03:08.577-08:00
次のステップでは、us-central-1 インスタンス テンプレートを作成します。
Cloud Shell から
gcloud compute instance-templates create us-central1-template \
--region=us-central1 \
--network=httplbs \
--tags=http-server, \
--image-family=debian-12 \
--image-project=debian-cloud \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2'
出力
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-central1-template]. NAME: us-central1-template MACHINE_TYPE: n1-standard-1 PREEMPTIBLE: CREATION_TIMESTAMP: 2021-11-11T11:03:44.179-08:00
次の gcloud コマンドを使用して、インスタンス テンプレートが正常に作成されたことを確認できます。
Cloud Shell から
gcloud compute instance-templates list
出力
NAME MACHINE_TYPE PREEMPTIBLE CREATION_TIMESTAMP us-central1-template n1-standard-1 2021-11-09T09:25:37.263-08:00 us-east1-template n1-standard-1 2021-11-09T09:24:35.275-08:00 us-west1-template n1-standard-1 2021-11-09T09:25:08.016-08:00
東、西、中央のマネージド インスタンス グループを作成する
ここで、先ほど作成したインスタンス テンプレートからマネージド インスタンス グループを作成する必要があります。
Cloud Shell から
gcloud compute instance-groups managed create us-east1-mig \ --base-instance-name=us-east1-mig \ --size=1 \ --template=us-east1-template \ --zone=us-east1-b
出力
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-east1-b/instanceGroupManagers/us-east1-mig]. NAME: us-east1-mig LOCATION: us-east1-b SCOPE: zone BASE_INSTANCE_NAME: us-east1-mig SIZE: 0 TARGET_SIZE: 1 INSTANCE_TEMPLATE: us-east1-template AUTOSCALED: no
Cloud Shell から
gcloud compute instance-groups managed create us-west1-mig \ --base-instance-name=us-west1-mig \ --size=1 \ --template=us-west1-template \ --zone=us-west1-a
出力
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroupManagers/us-west1-mig]. NAME: us-west1-mig LOCATION: us-west1-a SCOPE: zone BASE_INSTANCE_NAME: us-west1-mig SIZE: 0 TARGET_SIZE: 1 INSTANCE_TEMPLATE: us-west1-template AUTOSCALED: no
Cloud Shell から
gcloud compute instance-groups managed create us-central1-mig \ --base-instance-name=us-central1-mig \ --size=1 \ --template=us-central1-template \ --zone=us-central1-a
出力
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-central1-a/instanceGroupManagers/us-central1-mig]. NAME: us-central1-mig LOCATION: us-central1-a SCOPE: zone BASE_INSTANCE_NAME: us-central1-mig SIZE: 0 TARGET_SIZE: 1 INSTANCE_TEMPLATE: us-central1-template AUTOSCALED: no
次の gcloud コマンドを使用して、インスタンス グループが正常に作成されたことを確認できます。
Cloud Shell から
gcloud compute instance-groups list
出力
NAME LOCATION SCOPE NETWORK MANAGED INSTANCES us-central1-mig us-central1 zone httplbs Yes 1 us-west1-mig us-west1 zone httplbs Yes 1 us-east1-mig us-east1 zone httplbs Yes 1
ウェブサーバーの機能を確認する
各インスタンスは、次の内容をレンダリングする単純な PHP スクリプトを使用して Apache ウェブサーバーを実行するように構成されています。
ウェブサーバーが正しく機能していることを確認するには、[Compute Engine] -> [VM インスタンス] に移動します。新しいインスタンス（us-east1-mig-xxx など）がインスタンス グループの定義に従って作成されていることを確認します。
次に、ブラウザでウェブ リクエストを送信して、ウェブサーバーが実行されていることを確認します（起動に 1 分ほどかかることがあります）。Compute Engine の [VM インスタンス] ページで、インスタンス グループによって作成されたインスタンスを選択し、その外部（パブリック）IP をクリックします。
または、ブラウザで http://<IP_Address> に移動します。
5. ロードバランサを設定する
ヘルスチェックの作成
まず、サービスが正常に稼働していることを確認するための基本的なヘルスチェックを作成する必要があります。ここでは基本的なヘルスチェックを作成しますが、より高度なカスタマイズも可能です。
Cloud Shell から
gcloud compute health-checks create http http-basic-check \
--port 80
外部 IP アドレスを予約する
このステップでは、後でロードバランサに接続されるグローバルに利用可能な静的 IP アドレスを予約する必要があります。
Cloud Shell から
gcloud compute addresses create lb-ipv4-2 \
--ip-version=IPV4 \
--global
予約した IP アドレスをメモしておきます。
gcloud compute addresses describe lb-ipv4-2 \
--format="get(address)" \
--global
バックエンド サービスを作成する
次に、前に作成したマネージド インスタンス グループごとにバックエンド サービスを作成する必要があります。東部、西部、中部で 1 つずつ。
東リージョンのマネージド インスタンス グループのバックエンド サービスを作成する。
Cloud Shell から
gcloud compute backend-services create east-backend-service \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-basic-check \
--global
West マネージド インスタンス グループのバックエンド サービスを作成します。
Cloud Shell から
gcloud compute backend-services create west-backend-service \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-basic-check \
--global
Central マネージド インスタンス グループのバックエンド サービスを作成します。
Cloud Shell から
gcloud compute backend-services create central-backend-service \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-basic-check \
--global
バックエンド サービスに MIG を追加する
各アプリケーション クラスタのバックエンド サービスを作成したので、先ほど作成したマネージド インスタンス グループを各バックエンド サービスに追加する必要があります。
バックエンド サービスに East MIG を追加します。
Cloud Shell から
gcloud compute backend-services add-backend east-backend-service \
--balancing-mode='UTILIZATION' \
--instance-group=us-east1-mig \
--instance-group-zone=us-east1-b \
--global
バックエンド サービスに West MIG を追加します。
Cloud Shell から
gcloud compute backend-services add-backend west-backend-service \
--balancing-mode='UTILIZATION' \
--instance-group=us-west1-mig \
--instance-group-zone=us-west1-a \
--global
バックエンド サービスに中央 MIG を追加します。
Cloud Shell から
gcloud compute backend-services add-backend central-backend-service \
--balancing-mode='UTILIZATION' \
--instance-group=us-central1-mig \
--instance-group-zone=us-central1-a \
--global
URL マップを作成する
このラボの高度なトラフィック管理機能は、URL マップに存在します。構成を含む .yaml ファイルを作成する必要があります。.yaml ファイル内で /roundrobbin のプレフィックス一致を作成したため、/roundrobbin に一致するトラフィックのみがこれらの構成の影響を受けます。トラフィックの 50% が east-backend-service に、トラフィックの 50% が west-backend-service に送信されるように指定しました。また、すべてのレスポンスにレスポンス ヘッダー値 {test} を追加しました。最後に、すべてのトラフィックを central-backend-service にミラーリングするように追加しました。トラフィックは複製され、テストのみを目的としてここに送信されます。
この例を .yaml ファイルとしてマシンに保存します。
defaultService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
kind: compute #urlMap
name: web-map-http
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /roundrobbin
priority: 2
headerAction:
responseHeadersToAdd:
- headerName: test
headerValue: value
replace: True
routeAction:
weightedBackendServices:
- backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
weight: 50
- backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/west-backend-service
weight: 50
retryPolicy:
retryConditions: ['502', '504']
numRetries: 3
perTryTimeout:
seconds: 1
nanos: 50
requestMirrorPolicy:
backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/central-backend-service
マシンからドキュメントをインポートして、URL マップを作成します。ソースパスは、.yaml ファイルの保存場所によって異なります。
Cloud Shell から
gcloud compute url-maps import web-map-http \ --source /Users/[USERNAME]/Documents/Codelab/lbconfig.yaml \ --global
HTTP フロントエンドを作成する
ロードバランサの作成の最後のステップは、フロントエンドの作成です。これにより、前に予約した IP アドレスが、作成したロードバランサの URL マップにマッピングされます。
Cloud Shell から
gcloud compute target-http-proxies create http-lb-proxy-adv \
--url-map=web-map-http
次に、前に予約した IP アドレスを HTTP プロキシにマッピングするグローバル転送ルールを作成する必要があります。
Cloud Shell から
gcloud compute forwarding-rules create http-content-rule \
--load-balancing-scheme EXTERNAL_MANAGED \
--address=lb-ipv4-2 \
--global \
--target-http-proxy=http-lb-proxy-adv \
--ports=80
6. 高度なトラフィック機能が動作していることを確認する
実装されたトラフィック分割機能が機能していることを確認するには、負荷を生成する必要があります。これを行うには、負荷をシミュレートする新しい VM を作成します。
SSH を許可するファイアウォール ルールを作成する
トラフィックを生成する VM に SSH 接続するには、まず、VM への SSH トラフィックを許可するファイアウォール ルールを作成する必要があります。
Cloud Shell から
gcloud compute firewall-rules create fw-allow-ssh \
--network=httplbs \
--action=allow \
--direction=ingress \
--target-tags=allow-ssh \
--rules=tcp:22
出力
NAME NETWORK DIRECTION PRIORITY ALLOW DENY DISABLED fw-allow-ssh httplbs INGRESS 1000 tcp:22 False
Siege-vm を作成する
次に、負荷の生成に使用する siege-vm を作成します。
Cloud Shell から
gcloud compute instances create siege-vm \
--network=httplbs \
--zone=us-east4-c \
--machine-type=e2-medium \
--tags=allow-ssh,http-server \
--metadata=startup-script='sudo apt-get -y install siege'
出力
NAME ZONE MACHINE_TYPE INTERNAL_IP EXTERNAL_IP STATUS siege-vm us-east4-c e2-medium 10.150.0.3 34.85.218.119 RUNNING
次に、作成した VM に SSH 接続できます。作成したら、[SSH] をクリックしてターミナルを起動し、接続します。
接続したら、次のコマンドを実行して負荷を生成します。外部 HTTP ロードバランサ用に先ほど予約した IP アドレスを使用します。
Cloud Shell から
siege -c 250 http://[$lb-ipv4-2]/roundrobbin
出力
New configuration template added to /home/cloudcurriculumdeveloper/.siege Run siege -C to view the current settings in that file [alert] Zip encoding disabled; siege requires zlib support to enable it: No such file or directory ** SIEGE 4.0.2 ** Preparing 250 concurrent users for battle. The server is now under siege...
負荷分散を確認する
Siege が実行されているので、トラフィックが東と西のマネージド インスタンス グループに均等に分散されていることを確認します。また、トラフィック ミラーリングが機能し、トラフィックが中央のマネージド インスタンス グループに送信されていることも確認できます。
Cloud コンソールのナビゲーション メニューで、[ネットワーク サービス] > [ロード バランシング] をクリックします。ロードバランサ web-map-http を選択します。[モニタリング] タブに移動すると、次のグラフが表示されます。
この MIG へのトラフィック分割をリアルタイムで確認できます。50/50 のラウンドロビン分割を構成したため、トラフィックは均等に分割されます。
作成したトラフィック ミラーリング ポリシーが機能していることを確認するには、central-backend-service マネージド インスタンス グループの使用率を確認する必要があります。これを行うには、[コンピューティング]、[Compute Engine]、[インスタンス グループ] に移動して、us-central1-mig を選択します。次に、[モニタリング] タブに移動します。
グラフにデータが入力され、トラフィックがこのマネージド インスタンス グループにミラーリングされたことが示されます。
Stop the Siege
高度なトラフィック分割が機能していることを確認したので、siege を停止します。これを行うには、siege-vm の SSH ターミナルに戻り、Ctrl+C キーを押して実行中の siege を停止します。
送信されるレスポンス ヘッダーを検証する
クリーンアップする前に、適切なレスポンス ヘッダーが HTTP ロードバランサから送信されていることを簡単に検証できます。コンテンツ値を含むヘッダー テストを送信するように構成していました。Cloud Shell から curl コマンドを実行すると、想定どおりのレスポンスが返されます。
Cloud Shell から
curl -svo /dev/null http://lb-ipv4-2/roundrobbin
出力
* Trying lb-ipv4-2..
* TCP_NODELAY set
* Connected to lb-ipv4-2 ( lb-ipv4-2) port 80 (#0)
> GET /roundrobbin HTTP/1.1
> Host: lb-ipv4-2
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< date: Wed, 10 Nov 2021 17:05:27 GMT
< server: envoy
< Content-Length: 273
< content-type: text/html; charset=iso-8859-1
< via: 1.1 google
< test: value
<
{ [273 bytes data]
* Connection #0 to host 34.149.2.26 left intact
* Closing connection 0
7. ラボのクリーンアップ
ラボ環境が完了したので、削除します。次のコマンドを実行して、テスト環境を削除してください。
Cloud Shell から
gcloud compute instances delete siege-vm --zone=us-east4-c gcloud compute forwarding-rules delete http-content-rule --global gcloud compute target-http-proxies delete http-lb-proxy-adv gcloud compute url-maps delete web-map-http gcloud compute backend-services delete east-backend-service --global gcloud compute backend-services delete west-backend-service --global gcloud compute backend-services delete central-backend-service --global gcloud compute addresses delete lb-ipv4-2 --global gcloud compute health-checks delete http-basic-check gcloud compute instance-groups managed delete us-east1-mig --zone us-east1-b gcloud compute instance-groups managed delete us-west1-mig --zone us-west1-a gcloud compute instance-groups managed delete us-central1-mig --zone us-central1-a gcloud compute instance-templates delete "us-east1-template" gcloud compute instance-templates delete "us-west1-template" gcloud compute instance-templates delete "us-central1-template" gcloud compute firewall-rules delete httplb-allow-http-rule gcloud compute firewall-rules delete fw-allow-ssh gcloud compute networks delete httplbs
8. 完了
高度なトラフィック管理（Envoy）を使用した外部 HTTPs ロードバランサの Codelab を完了しました。
学習した内容
- マネージド インスタンス グループと関連する VPC ルールとファイアウォール ルールを設定する方法
- 新しいロードバランサの高度なトラフィック管理機能の使用方法
- 高度なトラフィック管理機能が意図したとおりに動作していることを検証する方法。
次のステップ
- URL の書き換え、CORS ヘッダーの追加など、他の高度なルーティング機能をお試しください（リンク）。