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

1. はじめに

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

学習内容

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

必要なもの

• ロードバランサの使用経験

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

Google Cloud のお客様は、ネットワーク ロード バランシングにより、Google Cloud リージョン内の仮想マシン間で外部トラフィックを分散するための強力なツールを利用できます。お客様がより簡単に受信トラフィックを管理し、ロードバランサの動作を制御できるように、ネットワーク負荷分散に新しくバックエンド サービスのサポートを追加しました。これにより、お客様のデプロイにおけるスケール、速度、パフォーマンス、復元力が向上し、すべて管理しやすい方法で実現します。

ネットワーク ロード バランシングによるバックエンド サービスがサポートされるようになりました。これは、以前のターゲット プールのアプローチを大幅に改善したものです。バックエンド サービスは、ロードバランサが接続されたバックエンドに受信トラフィックを分散する方法を定義し、ロードバランサの動作をきめ細かく制御します。

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

ロードバランサとしてリージョン バックエンド サービスを選択すると、環境にさまざまな利点があります。

すぐに使用できるリージョン バックエンド サービスは、次の機能を提供します。

• 統合ヘルスチェックによる高忠実度のヘルスチェック - リージョン バックエンド サービスにより、ロード バランシングのヘルスチェック機能を最大限に活用して、レガシー HTTP ヘルスチェックの制約から解放されました。コンプライアンス上の理由から、ネットワーク ロード バランシングのお客様からは、カスタム リクエストおよびレスポンス文字列または HTTPS をサポートする TCP ヘルスチェックが一般的なリクエストでした。
• フェイルオーバー グループによる復元力の向上 - フェイルオーバー グループを使用すると、1 つのインスタンス グループをプライマリ、もう 1 つのインスタンスをセカンダリとして指定し、アクティブ グループ内のインスタンスの健全性が特定のしきい値を下回ったときにトラフィックをフェイルオーバーできます。フェイルオーバー メカニズムをより詳細に制御するには、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 アカウントもまだお持ちでない場合は、アカウントを作成してください。

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

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

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

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

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

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」をメモします。次のように操作します。

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

また、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 は完了です。

学習した内容

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