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

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 に 2 つのインスタンス、ゾーン 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 で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。このラボでの作業はすべて、ブラウザから実行できます。

Cloud Shell にログインしてプロジェクト 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 は完了です。

学習した内容

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