1. はじめに
高度なトラフィック管理(Envoy)を使用した外部 HTTPS LB の Codelab へようこそ。
高度なトラフィック管理を備えた最新バージョンの HTTP(S) 外部ロードバランサには、既存の従来のグローバル外部 HTTP(S) ロードバランサのすべての機能が含まれていますが、高度なトラフィック管理機能は増え続けています。これらの機能の一部は Google のロードバランサの新機能であり、一部は既存の機能を拡張するものです。その一部を以下に示します。
- 重み付けによるトラフィック分割
- ミラーリングをリクエストする
- 外れ値検出
- 再試行のリクエスト
- フォールト インジェクション
- 追加のバックエンド セッション アフィニティ オプション
- その他のヘッダー変換オプション
- クロスオリジン リソース シェアリング(CORS)
- 新しいロード バランシング アルゴリズム
学習内容
- マネージド インスタンス グループおよび関連する VPC とファイアウォール ルールを設定する方法
- 新しいロードバランサの高度なトラフィック管理機能を使用する方法
- 高度なトラフィック管理機能が意図したとおりに動作していることを検証する方法。
必要なもの
- ネットワーキングの基礎と HTTP の知識
- Unix / Linux コマンドラインに関する基本的な知識
Codelab のトポロジとユースケース
図 1 - HTTP ロードバランサのルーティング トポロジ
この Codelab では、3 つのマネージド インスタンス グループ(East、West、Central)を設定します。グローバル外部 HTTPS ロードバランサを作成します。ロードバランサは、Envoy ベースのロードバランサがサポートする高度な機能のいくつかの機能を利用します。デプロイ後、負荷のシミュレーションを行い、設定した構成が適切に機能していることを確認します。
2. 設定と要件
セルフペース型の環境設定
- Google Cloud Console にログインして、プロジェクトを新規作成するか、既存のプロジェクトを再利用します。Gmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。
- プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列で、いつでも更新できます。
- プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です(設定後は変更できません)。Cloud Console により一意の文字列が自動生成されます(通常は内容を意識する必要はありません)。ほとんどの Codelab では、プロジェクト ID を参照する必要があります(通常、プロジェクト ID は「
PROJECT_ID
」の形式です)。好みの文字列でない場合は、別のランダムな ID を生成するか、独自の ID を試用して利用可能であるかどうかを確認することができます。プロジェクトの作成後、ID は「フリーズ」されます。 - 3 つ目の値として、一部の API が使用するプロジェクト番号があります。これら 3 つの値について詳しくは、こちらのドキュメントをご覧ください。
- 次に、Cloud のリソースや API を使用するために、Cloud Console で課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルを終了した後に課金が発生しないようにリソースをシャットダウンするには、Codelab の最後にある「クリーンアップ」の手順を行います。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアル プログラムをご利用いただけます。
Cloud Shell の起動
Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell(Cloud 上で動作するコマンドライン環境)を使用します。
GCP Console で右上のツールバーにある Cloud Shell アイコンをクリックします。
プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。
この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。このラボでの作業はすべて、ブラウザから実行できます。
始める前に
Cloud Shell 内で、プロジェクト ID が設定されていることを確認します。
gcloud config list project
gcloud config set project [実際のプロジェクト名]
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(HTTP トラフィック用のポート 80)にアクセスできるようにするために使用します。
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 の構成を定義します。次に、各リージョンのバックエンドについて、インスタンス テンプレートを参照するマネージド インスタンス グループを作成します。
マネージド インスタンス グループのスコープは、ゾーンまたはリージョンに設定できます。このラボ演習では、us-east1、us-west1、us-central1 にそれぞれ 1 つずつ、合計 3 つのリージョン マネージド インスタンス グループを作成します。
このセクションでは、インスタンス作成時に参照される、事前に作成された起動スクリプトを示します。この起動スクリプトにより、ウェブ アプリケーションをシミュレートするウェブサーバー機能をインストールして有効にします。このスクリプトを自由に使ってみてください。
東、西、中央のインスタンス テンプレートを作成する
まず、us-east-1 インスタンス テンプレートを作成します。
Cloud Shell から
gcloud compute instance-templates create us-east1-template \ --region=us-east1 \ --network=httplbs \ --tags=http-server, \ --image-family=debian-9 \ --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-9 \ --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-9 \ --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
East、West、Central マネージド インスタンス グループを作成する
次に、前に作成したインスタンス テンプレートからマネージド インスタンス グループを作成する必要があります。
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] > [制限します。インスタンス グループの定義に従って新しいインスタンス(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 つは東、西、中部です。
East マネージド インスタンス グループのバックエンド サービスを作成する。
Cloud Shell から
gcloud beta 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 beta compute backend-services create west-backend-service \ --load-balancing-scheme=EXTERNAL_MANAGED \ --protocol=HTTP \ --port-name=http \ --health-checks=http-basic-check \ --global
セントラル マネージド インスタンス グループのバックエンド サービスを作成する。
Cloud Shell から
gcloud beta compute backend-services create central-backend-service \ --load-balancing-scheme=EXTERNAL_MANAGED \ --protocol=HTTP \ --port-name=http \ --health-checks=http-basic-check \ --global
バックエンド サービスに MIG を追加する
アプリケーション クラスタごとにバックエンド サービスを作成したら、前に作成したマネージド インスタンス グループを各バックエンド サービスに追加する必要があります。
バックエンド サービスに東部 MIG を追加します。
Cloud Shell から
gcloud beta compute backend-services add-backend east-backend-service \ --balancing-mode='UTILIZATION' \ --instance-group=us-east1-mig \ --instance-group-zone=us-east1-b \ --global
バックエンド サービスに西 MIG を追加します。
Cloud Shell から
gcloud beta 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 beta 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 beta compute url-maps import web-map-http \ --source /Users/[USERNAME]/Documents/Codelab/lbconfig.yaml \ --global
HTTP フロントエンドを作成する
ロードバランサ作成の最後の手順は、フロントエンドの作成です。これにより、前に予約した IP アドレスが、作成したロードバランサの URL マップにマッピングされます。
Cloud Shell から
gcloud beta compute target-http-proxies create http-lb-proxy-adv \ --url-map=web-map-http
次に、先ほど予約した IP アドレスを HTTP プロキシにマッピングするグローバル転送ルールを作成する必要があります。
Cloud Shell から
gcloud beta 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 を実行したところで、トラフィックが East と West のマネージド インスタンス グループに均等に分散されていることも確認します。さらに、トラフィックのミラーリングが機能していることと、トラフィックが中央のマネージド インスタンス グループに送信されていることも確認します。
Cloud コンソールのナビゲーション メニューで、[ネットワーク サービス] >ロード バランシング。[バックエンド] をクリックします。下のスクリーンショットに示す詳細メニューをクリックします。
[バックエンド サービス] タブに移動して、east-backend-service を選択します。
この MIG へのトラフィック分割をリアルタイムで確認できます。レートをメモしておきます。すぐに west-backend-service と比較できます。
同様に、west-backend-service に移動します。このサービスに送信されるトラフィックも表示されます。トラフィックの 50/50 ラウンドロビン分割を構成したため、レートは east-backend-service で見たものと同様のはずです。
作成したトラフィック ミラーリング ポリシーが機能していることを確認するには、central-backend-service マネージド インスタンス グループの使用率を確認する必要があります。これを行うには、[Compute]、[Compute Engine]、[インスタンス グループ] に移動して [us-central1-mig] を選択します。次に、[モニタリング] タブに移動します。
このマネージド インスタンス グループにトラフィックがミラーリングされたことを示すグラフが表示されます。
Siege をやめて
高度なトラフィック分割が機能していることを確認できたので、今度は Siege を止めましょう。そのためには、siege-vm の SSH ターミナルに戻り、Ctrl+C キーを押して siege の実行を停止します。
送信されたレスポンス ヘッダーを検証する
クリーンアップする前に、HTTP ロードバランサから適切なレスポンス ヘッダーが送信されていることを簡単に検証できます。content の値を含むヘッダーテストを送信するように構成しました。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 gcloud alpha compute forwarding-rules delete http-content-rule --global gcloud alpha compute target-http-proxies delete http-lb-proxy-adv gcloud alpha compute url-maps delete web-map-http gcloud alpha compute backend-services delete east-backend-service --global gcloud alpha compute backend-services delete west-backend-service --global gcloud alpha 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 LB の Codelab は終了です。
学習した内容
- マネージド インスタンス グループおよび関連する VPC とファイアウォール ルールを設定する方法
- 新しいロードバランサの高度なトラフィック管理機能を使用する方法
- 高度なトラフィック管理機能が意図したとおりに動作していることを検証する方法。
次のステップ
- URL の書き換え、CORS ヘッダーの追加など、その他の高度なルーティング機能をお試しください(リンク)