ネットワーク ロードバランサをターゲット プールからリージョン バックエンド サービスに移行する

1. はじめに

このガイドでは、既存のネットワーク ロードバランサをターゲット プール バックエンドからリージョン バックエンド サービスに移行する手順について説明します。

学習内容

• リージョン バックエンド サービスのメリットを理解する
• ターゲット プールを使用してネットワーク ロードバランサを作成する
• ターゲット プールの検証を実行する
• 非マネージド インスタンス グループを使用してリージョン バックエンド サービスを作成する
• ターゲット プールからバックエンド サービスへの移行を実行する
• バックエンド サービスの検証を実行する

必要なもの

• ロードバランサの経験

2. ネットワーク ロード バランシングのリージョン バックエンド サービスの概要

ネットワーク ロード バランシングにより、Google Cloud のお客様は、Google Cloud リージョン内の仮想マシン全体に外部トラフィックを効率的に分散できます。お客様がより簡単に受信トラフィックを管理し、ロードバランサの動作を制御できるように、ネットワーク負荷分散に新しくバックエンド サービスのサポートを追加しました。これにより、お客様のデプロイのスケーリング、速度、パフォーマンス、復元性が改善されます。しかも、管理が簡単です。

Google は現在、ネットワーク ロード バランシングでバックエンド サービスをサポートしています。これは、以前のアプローチであるターゲット プールに比べて、はるかに進化した手法です。バックエンド サービスは、ロードバランサがどのように受信トラフィックをアタッチされたバックエンドに分散し、ロードバランサの動作を細かく制御するかを定義します。

3. リージョン バックエンド サービスのメリット

ロードバランサとしてリージョン バックエンド サービスを選択することで、ご利用の環境に数々のメリットがもたらされます。

リージョン バックエンド サービスを導入してすぐに次のようなメリットを得られます。

• 統合ヘルスチェックによる高精度のヘルスチェック - リージョン バックエンド サービスを使用すると、負荷分散のヘルスチェック機能をフル活用でき、旧式の HTTP ヘルスチェックによる制約を回避できます。ネットワーク ロードバランシングのお客様は、コンプライアンス上の理由から、カスタム リクエストおよびレスポンス文字列または HTTPS をサポートする TCP ヘルスチェックを希望することが一般的でした。
• フェイルオーバー グループによる復元性の改善 - フェイルオーバー グループを使用することで、あるインスタンス グループをプライマリに、別のグループをセカンダリに指定し、アクティブ グループのインスタンスの状態が特定のしきい値を下回った場合にトラフィックをフェイルオーバーできます。このフェイルオーバー メカニズムをより細かく制御するには、keepalived や pacemaker などのエージェントを使用し、バックエンド インスタンスの状態の変化に応じて、正常ヘルスチェックまたは失敗ヘルスチェックを公開します。
• マネージド インスタンス グループによるスケーラビリティと高可用性 - リージョン バックエンド サービスはバックエンドとしてマネージド インスタンス グループをサポートします。バックエンドの仮想マシン インスタンス用にテンプレートを指定し、CPU の利用率やその他のモニタリング指標に基づいて、自動スケーリングを利用できるようになります。

前述の点に加えて、コネクション ドレインを利用することで接続指向プロトコル（TCP）に対応し、大規模デプロイのプログラミング時間を短縮できます。

Codelab ネットワーク トポロジ

このガイドでは、既存のネットワーク ロードバランサをターゲット プール バックエンドからリージョン バックエンド サービスに移行する手順について説明します。

リージョン バックエンド サービスに移行すれば、非レガシー ヘルスチェック（TCP、SSL、HTTP、HTTPS、HTTP/2 向け）、マネージド インスタンス グループ、コネクション ドレイン、フェイルオーバー ポリシーなどの機能を利用できます。

このガイドでは、次のサンプル ターゲット プールベースのネットワーク ロードバランサを移行して、代わりにリージョン バックエンド サービスを使用する手順について説明します。

前: ターゲット プールを使用したネットワーク ロードバランシング

バックエンド サービスベースのネットワーク ロードバランサのデプロイ結果は次のようになります。

移行後: リージョン バックエンド サービスを使用したネットワーク ロードバランシング

この例では、従来のターゲット プールベースのネットワーク ロードバランサを使用し、ゾーン us-central-1a とゾーン us-central-1c にそれぞれ 2 つのインスタンスがあることを前提としています。

このような移行に必要な大まかな手順は次のとおりです。

1. ターゲット プール インスタンスをインスタンス グループにグループ化します。バックエンド サービスは、マネージド インスタンス グループまたは非マネージド インスタンス グループでのみ動作します。1 つのターゲット プールに配置できるインスタンスの数に制限はありませんが、インスタンス グループには最大サイズがあります。ターゲット プールのインスタンスがこの最大数を超えている場合は、複数のインスタンス グループにバックエンドを分割する必要があります。既存のデプロイにバックアップ ターゲット プールが含まれている場合は、それらのインスタンスに別々のインスタンス グループを作成します。このインスタンス グループは、フェイルオーバー グループとして構成されます。
2. リージョン バックエンド サービスを作成します。バックアップ ターゲット プールがデプロイに含まれている場合、バックエンド サービスを作成するとともにフェイルオーバー率を指定する必要があります。これは、以前ターゲット プールのデプロイ用に構成したフェイルオーバー率と一致する必要があります。
3. バックエンド サービスにインスタンス グループ（事前に作成したもの）を追加します。デプロイにバックアップ ターゲット プールが含まれている場合は、バックエンド サービスに追加する際に、対応するフェイルオーバー インスタンス グループに –failover フラグを設定します。
4. 新しいバックエンド サービスを参照する転送ルールを構成します。次の 2 つのオプションがあります。

• （推奨）バックエンド サービスを参照するように既存の転送ルールを更新します。または
• バックエンド サービスを参照する新しい転送を作成します。この場合、ロードバランサのフロントエンドに新しい IP アドレスを作成する必要があります。次に、DNS 設定を変更して、以前のターゲット プールベースのロードバランサの IP アドレスを新しい IP アドレスにシームレスに移行します。

セルフペース型の環境設定

1. Cloud コンソールにログインして、新しいプロジェクトを作成するか、既存のプロジェクトを再利用しますGmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。

注: console.cloud.google.com という URL を覚えておくと、Cloud コンソールに簡単にアクセスできます。

プロジェクト ID を忘れないようにしてください。プロジェクト ID はすべての Google Cloud プロジェクトを通じて一意の名前にする必要があります（上記の名前はすでに使用されているので使用できません）。以降、このコードラボでは PROJECT_ID と呼びます。

注: Gmail アカウントを使用している場合は、デフォルトの場所の設定は [組織なし] のままにしてかまいません。Google Workspace アカウントを使用している場合は、組織に適した場所を選択してください。

2. 次に、Google Cloud リソースを使用するために、Cloud Console で課金を有効にする必要があります。

このコードラボを実行しても、費用はほとんどかからないはずです。このチュートリアル以外で請求が発生しないように、リソースのシャットダウン方法を説明する「クリーンアップ」セクションの手順に従うようにしてください。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアル プログラムをご利用いただけます。

Cloud Shell の起動

Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。

GCP Console で右上のツールバーにある Cloud Shell アイコンをクリックします。

プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。

この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。このラボでの作業はすべて、ブラウザから実行できます。

cloudshell にログインして、プロジェクト ID を設定します。

gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]

Perform setting your projectID:
projectid=YOUR-PROJECT-ID

echo $projectid

4. VPC ネットワークを作成する

VPC ネットワーク

Cloud Shell から

gcloud compute networks create network-lb --subnet-mode custom

サブネットの作成

Cloud Shell から

gcloud compute networks subnets create network-lb-subnet \
        --network network-lb --range 10.0.0.0/24 --region us-central1

ファイアウォール ルールを作成する

Cloud Shell から

gcloud compute --project=$projectid firewall-rules create www-firewall-network-lb --direction=INGRESS --priority=1000 --network=network-lb --action=ALLOW --rules=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=network-lb-tag

非マネージド インスタンスを作成する

ゾーンごとに 2 つのインスタンスを作成する（us-central1-a と us-central1-c）

Cloud Shell からインスタンス 1 を作成する

gcloud compute instances create www1 \
--subnet network-lb-subnet \
--image-family debian-9 \
--image-project debian-cloud \
--zone us-central1-a \
--tags network-lb-tag \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo service apache2 restart
echo '<!doctype html><html><body><h1>www1</h1></body></html>' | tee /var/www/html/index.html"

Cloud Shell からインスタンス 2 を作成する

gcloud compute instances create www2 \
--subnet network-lb-subnet \
--image-family debian-9 \
--image-project debian-cloud \
--zone us-central1-a \
--tags network-lb-tag \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo service apache2 restart 
echo '<!doctype html><html><body><h1>www2</h1></body></html>' | tee /var/www/html/index.html"

Cloud Shell からインスタンス 3 を作成する

gcloud compute instances create www3 \
--subnet network-lb-subnet \
--image-family debian-9 \
--image-project debian-cloud \
--zone us-central1-c \
--tags network-lb-tag \
--metadata startup-script="#! /bin/bash
sudo apt-get update 
sudo apt-get install apache2 -y 
sudo service apache2 restart 
echo '<!doctype html><html><body><h1>www3</h1></body></html>' | tee /var/www/html/index.html"

Cloud Shell からインスタンス 4 を作成する

gcloud compute instances create www4 \
--subnet network-lb-subnet \
--image-family debian-9 \
--image-project debian-cloud \
--zone us-central1-c \
--tags network-lb-tag \
--metadata startup-script="#! /bin/bash
sudo apt-get update 
sudo apt-get install apache2 -y 
sudo service apache2 restart
echo '<!doctype html><html><body><h1>www4</h1></body></html>' | tee /var/www/html/index.html"

この VM インスタンスへの外部トラフィックを許可するファイアウォール ルールを作成する

Cloud Shell から

gcloud compute --project=$projectid firewall-rules create www-firewall-network-lb --direction=INGRESS --priority=1000 --network=network-lb --action=ALLOW --rules=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=network-lb-tag

ロードバランサに使用する静的外部 IP アドレスを作成する

Cloud Shell から

gcloud compute addresses create network-lb-ip-1 \
    --region us-central1

レガシー HTTP ヘルスチェック リソースを追加する

Cloud Shell から

gcloud compute http-health-checks create basic-check

5. 転送ルールとターゲット プールを作成する

ターゲット プールを作成する

gcloud compute target-pools create www-pool \
            --region us-central1 --http-health-check basic-check

インスタンスをターゲット プール us-central1-a に追加します

gcloud compute target-pools add-instances www-pool \
--instances www1,www2 \
--instances-zone us-central1-a

インスタンスをターゲット プール us-central1-c に追加する

gcloud compute target-pools add-instances www-pool \
--instances www3,www4 \
--instances-zone us-central1-c

転送ルールを追加する

gcloud compute forwarding-rules create www-rule \
--region us-central1 \
--ports 80 \
--address network-lb-ip-1 \
--target-pool www-pool

ターゲット プールの機能を確認する

[ロードバランサ] → [フロントエンド]（www-rule）を選択して、フロントエンドの IP アドレスを特定します。

ワークステーションのターミナルから curl コマンドを使用して外部 IP アドレスにアクセスし、4 つのターゲット インスタンス間のロード バランシングを確認します。検証が完了したらターミナルを閉じます。

while true; do curl -m1 IP_ADDRESS; done

6. ネットワーク ロードバランサをターゲット プールからバックエンド サービスに移行する

バックエンド サービスの統合ヘルスチェックを作成する

gcloud compute health-checks create tcp my-tcp-health-check --port 80 --region us-central1

ターゲット プールの既存のインスタンスからインスタンス グループを作成する

gcloud compute --project=$projectid instance-groups unmanaged create www-instance-group-central1a --zone=us-central1-a

gcloud compute --project=$projectid instance-groups unmanaged add-instances www-instance-group-central1a --zone=us-central1-a --instances=www1,www2

ターゲット プールの既存のインスタンスからインスタンス グループを作成する

gcloud compute --project=$projectid instance-groups unmanaged create www-instance-group-central1c --zone=us-central1-c

gcloud compute --project=$projectid instance-groups unmanaged add-instances www-instance-group-central1c --zone=us-central1-c --instances=www3,www4

バックエンド サービスを作成し、新しく作成したヘルスチェックと関連付ける

gcloud compute backend-services create my-backend-service --region us-central1 --health-checks my-tcp-health-check --health-checks-region us-central1 --load-balancing-scheme external

バックエンド サービスを構成し、インスタンス グループを追加する

gcloud compute backend-services add-backend my-backend-service --instance-group www-instance-group-central1a --instance-group-zone us-central1-a --region us-central1

gcloud compute backend-services add-backend my-backend-service --instance-group www-instance-group-central1c --instance-group-zone us-central1-c --region us-central1

バックエンド サービスをサポートするように既存の転送ルールを更新する

次の操作を行って、転送ルール名「www-rule」と関連付けられた IP アドレスをメモします。

[ロードバランサ] → [フロントエンド] を選択

また、4 つのターゲット プールもメモしました。

[ロードバランサ] を選択 → [www-pool] を選択

既存の転送ルールを更新してバックエンド サービスにトラフィックを転送する

gcloud compute forwarding-rules set-target www-rule --region=us-central1 --backend-service my-backend-service --region us-central1

ロードバランサ「www-pool」がフロントエンド「www-rule」で構成されていないことを確認します（下のスクリーンショットを参照）。

[ロードバランサ] → [www-pool] を選択します。

フロントエンド転送ルールがロードバランサ「my-backend-service」に関連付けられていることを確認します。

[ロードバランサ] → [フロントエンド] を選択

ルール名「www-rule」の IP アドレスが保持され、ロードバランサ「my-backend-service」が使用中になったことを確認します。

ワークステーションのターミナルから curl コマンドを使用して外部 IP アドレスにアクセスし、新しく関連付けられたバックエンド サービス間のロード バランシングを確認します。検証が完了したらターミナルを閉じます。

while true; do curl -m1 IP_ADDRESS; done

7. クリーンアップ手順

gcloud compute forwarding-rules delete www-rule --region=us-central1 --quiet
 
gcloud compute backend-services delete my-backend-service --region us-central1 --quiet
 
gcloud compute target-pools delete www-pool --region us-central1 --quiet
 
gcloud compute addresses delete network-lb-ip-1 --region us-central1 --quiet

gcloud compute firewall-rules delete www-firewall-network-lb --quiet
 
gcloud compute instances delete www4 --zone us-central1-c --quiet
 
gcloud compute instances delete www3 --zone us-central1-c --quiet
 
gcloud compute instances delete www2 --zone us-central1-a --quiet

gcloud compute instances delete www1 --zone us-central1-a --quiet
 
gcloud compute networks subnets delete network-lb-subnet --region us-central1 --quiet

gcloud compute networks delete network-lb --quiet

gcloud compute instance-groups unmanaged delete www-instance-group-central1a --zone us-central1-a --quiet

gcloud compute instance-groups unmanaged delete www-instance-group-central1c --zone us-central1-c --quiet

8. 完了

以上で、この Codelab は完了です。

学習した内容

• リージョン バックエンド サービスのメリットを理解する
• ターゲット プールを使用してネットワーク ロードバランサを作成する
• ターゲット プールの検証を実行する
• 非マネージド インスタンス グループを使用してリージョン バックエンド サービスを作成する
• ターゲット プールからバックエンド サービスへの移行を実行する
• バックエンド サービスの検証を実行する