概要

Google Cloud は、TCP/UDP トラフィックの内部ロード バランシング機能を備えています。内部ロード バランシングにより、内部仮想マシン インスタンスのみにアクセス可能なプライベート ロード バランシング IP アドレスの背後でサービスを実行、スケールできます。

このラボでは、同じリージョン内に 2 つのマネージド インスタンス グループを作成し、次のネットワーク図のように、バックエンドとしてインスタンス グループを使用する内部ロードバランサを構成してテストします。

目標

このラボでは、次のタスクを行う方法を学びます。

• 内部トラフィックおよびヘルスチェックのファイアウォール ルールを構成する
• Cloud Router を使用して NAT 構成を作成する
• インスタンス テンプレートを 2 つ構成する
• マネージド インスタンス グループを 2 つ作成する
• 内部ロードバランサを構成してテストする

設定と要件

各ラボでは、新しい Google Cloud プロジェクトとリソースセットを一定時間無料で利用できます。

1. Qwiklabs にシークレット ウィンドウでログインします。

2. ラボのアクセス時間（例: 1:15:00）に注意し、時間内に完了できるようにしてください。
   一時停止機能はありません。必要な場合はやり直せますが、最初からになります。

3. 準備ができたら、[ラボを開始] をクリックします。

4. ラボの認証情報（ユーザー名とパスワード）をメモしておきます。この情報は、Google Cloud Console にログインする際に使用します。

5. [Google Console を開く] をクリックします。

6. [別のアカウントを使用] をクリックし、このラボの認証情報をコピーしてプロンプトに貼り付けます。
   他の認証情報を使用すると、エラーが発生したり、料金の請求が発生したりします。

7. 利用規約に同意し、再設定用のリソースページをスキップします。

タスク 1. 内部トラフィックおよびヘルスチェックのファイアウォール ルールを構成する

10.10.0.0/16 の範囲のソースからの内部トラフィック接続を許可するファイアウォール ルールを構成します。このルールは、サブネットにあるクライアントからの受信トラフィックを許可します。

ヘルスチェックでは、ロードバランサのどのインスタンスが新しい接続を受け取れるかを確認します。HTTP ロード バランシングでは、ロード バランシング インスタンスへのヘルスチェックのプローブが、130.211.0.0/22 と 35.191.0.0/16 の範囲のアドレスから接続を行います。ファイアウォール ルールでこの接続を許可する必要があります。

my-internal-app ネットワークを調べる

RDP、SSH、ICMP トラフィック用のファイアウォール ルールが適用され、subnet-a と subnet-b を備えたネットワーク my-internal-app があらかじめ構成されています。

• Cloud コンソールのナビゲーション メニュー（）で [VPC ネットワーク] > [VPC ネットワーク] の順にクリックします。
  subnet-a および subnet-b の 2 つのサブネットを持つ my-internal-app ネットワークがあることがわかります。

  Google Cloud プロジェクトはいずれも デフォルト ネットワークで開始します。また、ネットワーク図に示されているように my-internal-app ネットワークがあらかじめ作成されています。

  マネージド インスタンス グループを subnet-a と subnet-b に作成します。内部ロードバランサはリージョン サービスなので、どちらのサブネットも リージョン内にあります。マネージド インスタンス グループは別々のゾーンに配置されるため、サービスはゾーン障害の影響を免れることができます。

10.10.0.0/16 の範囲の任意のソースからのトラフィックを許可するファイアウォール ルールを作成する

10.10.0.0/16 のサブネットのトラフィックを許可するファイアウォール ルールを作成します。

1. ナビゲーション メニュー（）で、[VPC ネットワーク] > [ファイアウォール] の順にクリックします。
   app-allow-icmp と app-allow-ssh-rdp のファイアウォール ルールがあることがわかります。

   これらはあらかじめ作成されているものです。

2. [ファイアウォール ルールを作成] をクリックします。

3. 次のように指定し、残りの設定はデフォルトのままにします。

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   名前	fw-allow-lb-access
   ネットワーク	my-internal-app
   ターゲット	指定されたターゲットタグ
   ターゲットタグ	backend-service
   ソースフィルタ	IPv4 範囲
   送信元 IPv4 範囲	10.10.0.0/16
   プロトコルとポート	すべて許可

注: [送信元 IPv4 範囲] には「/16 」を含めます。

4. [作成] をクリックします。

ヘルスチェックのルールを作成する

ヘルスチェックを許可するファイアウォール ルールを作成します。

1. ナビゲーション メニュー（）で、[VPC ネットワーク] > [ファイアウォール] の順にクリックします。

2. [ファイアウォール ルールを作成] をクリックします。

3. 次のように指定し、残りの設定はデフォルトのままにします。

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   名前	fw-allow-health-checks
   ネットワーク	my-internal-app
   ターゲット	指定されたターゲットタグ
   ターゲットタグ	backend-service
   ソースフィルタ	IPv4 範囲
   送信元 IPv4 範囲	130.211.0.0/22 と 35.191.0.0/16
   プロトコルとポート	指定したプロトコルとポート

注: [送信元 IPv4 範囲] には「/22」と「/16」を含めます。

4. 「TCP」の隣のチェックボックスをオンにし、ポート「80」を指定します。
5. [作成] をクリックします。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 内部トラフィックおよびヘルスチェックのファイアウォール ルールを構成する

タスク 2. Cloud Router を使用して NAT 構成を作成する

タスク 3 で設定する Google Cloud VM バックエンド インスタンスは、外部 IP アドレスでは構成されません。

代わりに Cloud NAT サービスを設定して、これらの VM インスタンスが Cloud NAT からのみ送信トラフィックを送信し、ロードバランサを介して受信トラフィックを受信するようにします。

Cloud Router インスタンスを作成する

1. Cloud コンソールのナビゲーション メニュー（）> [すべてのプロダクトを表示] で、[ネットワーキング] > [ネットワーク サービス] > [Cloud NAT] をクリックします。

2. [使ってみる] をクリックします。

3. 次のように指定し、残りの設定はデフォルトのままにします。

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   ゲートウェイの名前	nat-config
   ネットワーク	my-internal-app
   リージョン

4. [Cloud Router] をクリックし、[新しいルーターを作成] を選択します。

5. [名前] に「nat-router-」と入力します。

6. [作成] をクリックします。

7. [Cloud NAT ゲートウェイの作成] で、[作成] をクリックします。

注: NAT ゲートウェイの [ステータス] が [実行中] に変わるまで待ってから、次のタスクに進みます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Cloud Router を使用して NAT 構成を作成する

タスク 3. インスタンス テンプレートを構成し、インスタンス グループを作成する

マネージド インスタンス グループが、インスタンス テンプレートを使用して同一インスタンスのグループを作成します。これらを使用して、内部ロードバランサのバックエンドを作成します。

このタスクは、ラボの開始時にすでに実施されています。各インスタンス グループ VM に SSH で接続し、後述のコマンドを実行して環境を設定する必要があります。

1. ナビゲーション メニューで、[Compute Engine] > [VM インスタンス] をクリックします。
   instance-group-1 と instance-group-2 で始まるインスタンスがあることがわかります。

2. instance-group-1 の横にある [SSH] ボタンをクリックして、この VM に SSH で接続します。

3. ブラウザでの SSH による VM への接続を許可するよう求めるプロンプトが表示されたら、[承認] をクリックします。

4. 次のコマンドを実行して、インスタンスの起動スクリプトを再実行します。

sudo google_metadata_script_runner startup

5. instance-group-2 に対して前述の手順を繰り返します。

6. 両方の起動スクリプトの実行が完了するまで待ってから、各 VM の SSH ターミナルを閉じます。起動スクリプトの出力に、次のメッセージが示されます。

Finished running startup scripts.

バックエンドを確認する

VM インスタンスが両方のサブネットで作成されていることを確認し、バックエンドの HTTP サイトにアクセスするためのユーティリティ VM を作成します。

1. ナビゲーション メニューで、[Compute Engine] > [VM インスタンス] をクリックします。
   instance-group-1 と instance-group-2 で始まるインスタンスがあることがわかります。

   これらのインスタンスは別個のゾーンにあり、その内部 IP アドレスは subnet-a と subnet-b の CIDR ブロックに含まれています。

2. [インスタンスを作成] をクリックします。

3. 次のように指定し、残りの設定はデフォルトのままにします。

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   名前	utility-vm
   リージョン
   ゾーン
   シリーズ	E2
   マシンタイプ	e2-medium（2 vCPU、4 GB メモリ）
   ブートディスク	Debian GNU/Linux 11（bullseye）

4. [詳細オプション] をクリックします。

5. [ネットワーキング] をクリックします。

6. [ネットワーク インターフェース] で、プルダウンをクリックして編集モードにします。

7. 次のように指定し、残りの設定はデフォルトのままにします。

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   ネットワーク	my-internal-app
   サブネットワーク	subnet-a
   プライマリ内部 IP	エフェメラル（カスタム）
   カスタムのエフェメラル IP アドレス	10.10.20.50
   外部 IPv4 アドレス	なし

8. [完了] をクリックします。

9. [作成] をクリックします。

10. バックエンド サーバーの内部 IP アドレスはそれぞれ 10.10.20.2 と 10.10.30.2 です。

注: IP アドレスが異なる場合は、後述の 2 つの curl コマンドで置き換えてください。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 インスタンス テンプレートを構成し、インスタンス グループを作成する

11. utility-vm で [SSH] をクリックし、ターミナルを起動して接続します。

12. ブラウザでの SSH による VM への接続を許可するよう求めるプロンプトが表示されたら、[承認] をクリックします。

13. instance-group-1-xxxx のスタートページを確認するには、次のコマンドを実行します。

curl 10.10.20.2

出力は次のようになります。

出力:

<h1>Internal Load Balancing Lab</h1><h2>Client IP</h2>Your IP address : 10.10.20.50<h2>Hostname</h2>Server Hostname: instance-group-1-1zn8<h2>Server Location</h2>Region and Zone:

14. instance-group-2-xxxx のスタートページを確認するには、次のコマンドを実行します。

curl 10.10.30.2

出力は次のようになります。

出力:

<h1>Internal Load Balancing Lab</h1><h2>Client IP</h2>Your IP address : 10.10.20.50<h2>Hostname</h2>Server Hostname: instance-group-2-q5wp<h2>Server Location</h2>Region and Zone:

注: これで、内部ロードバランサがトラフィックを双方のバックエンドに送信することがわかります。

15. utility-vm の SSH ターミナルを閉じます。

exit

タスク 4. 内部ロードバランサを構成する

以下のネットワーク図に示されるように、内部ロードバランサを構成して、2 つのバックエンド（ の instance-group-1 と の instance-group-2) 間でトラフィックを分散します。

構成を開始する

1. Cloud コンソールのナビゲーション メニュー（）> [すべてのプロダクトを表示] で、[ネットワーキング] > [ネットワーク サービス] > [ロード バランシング] をクリックします。
2. [ロードバランサを作成] をクリックします。
3. [ロードバランサのタイプ] で [ネットワーク ロードバランサ（TCP / UDP / SSL）] を選択し、[次へ] をクリックします。
4. [プロキシまたはパススルー] で [パススルー ロードバランサ] を選択し、[次へ] をクリックします。
5. [インターネット接続または内部] で [内部] を選択し、[次へ] をクリックします。
6. [構成] をクリックします。

7. [名前] に「my-ilb」と入力します。
8. [リージョン] に「」と入力します。
9. [ネットワーク] に「my-internal-app」と入力します。

リージョン バックエンド サービスを構成する

バックエンド サービスは、インスタンス グループをモニタリングして設定使用量の超過を防ぎます。

1. [バックエンドの構成] をクリックします。

2. 次のように指定し、残りの設定はデフォルトのままにします。

   プロパティ	値（指定されたオプションを選択）
   インスタンス グループ	instance-group-1 ()

3. [完了] をクリックします。

4. [バックエンドを追加] をクリックします。

5. [インスタンス グループ] で [instance-group-2 ()] を選択します。

6. [完了] をクリックします。

7. [ヘルスチェック] で [ヘルスチェックを作成] を選択します。

8. 次のように指定し、残りの設定はデフォルトのままにします。

   プロパティ	値（指定されたオプションを選択）
   名前	my-ilb-health-check
   プロトコル	TCP
   ポート	80
   チェック間隔	10 秒
   タイムアウト	5秒
   正常しきい値	2
   異常しきい値	3

注: ヘルスチェックでは、どのインスタンスが新しい接続を受け取れるかを確認できます。この HTTP ヘルスチェックは、10 秒ごとにインスタンスをポーリングしてレスポンスを最大 5 秒間待機し、2 回連続して成功した場合は成功、3 回連続して失敗した場合は失敗として処理します。

9. [保存] をクリックします。
10. Cloud コンソールの [バックエンドの構成] の横に青いチェックマークが表示されていることを確認します。表示されていない場合は、上のすべてのステップが完了していることを再度確認してください。

フロントエンドを構成する

フロントエンドはバックエンドにトラフィックを転送します。

1. [フロントエンドの構成] をクリックします。

2. 次のように指定し、残りの設定はデフォルトのままにします。

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   サブネットワーク	subnet-b
   [内部 IP] > [IP アドレス]	IP アドレスを作成

3. 次のように指定し、残りの設定はデフォルトのままにします。

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   名前	my-ilb-ip
   静的 IP アドレス	ユーザー指定
   カスタム IP アドレス	10.10.30.5

4. [予約] をクリックします。

5. [ポート] の [ポート番号] に「80」と入力します。

6. [完了] をクリックします。

内部ロードバランサを確認して作成する

1. [確認と完了] をクリックします。
2. [バックエンド] と [フロントエンド] を確認します。
3. [作成] をクリックします。
   ロードバランサが作成されるまで待ち、次のタスクに進みます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 内部ロードバランサを構成する

タスク 5. 内部ロードバランサをテストする

my-ilb の IP アドレスがトラフィックを の instance-group-1 と の instance-group-2 に転送することを確認します。

内部ロードバランサにアクセスする

1. ナビゲーション メニューで、[Compute Engine] > [VM インスタンス] をクリックします。
2. utility-vm で [SSH] をクリックし、ターミナルを起動して接続します。
3. ブラウザでの SSH による VM への接続を許可するよう求めるプロンプトが表示されたら、[承認] をクリックします。
4. 内部ロードバランサによるトラフィックの転送を確認するには、次のコマンドを実行します。

curl 10.10.30.5

出力は次のようになります。

出力:

<h1>Internal Load Balancing Lab</h1><h2>Client IP</h2>Your IP address : 10.10.20.50<h2>Hostname</h2>Server Hostname: instance-group-2-1zn8<h2>Server Location</h2>Region and Zone: {{{project_0.default_zone_2 | Zone 2}}} 注: 想定どおりに、トラフィックは内部ロードバランサ（10.10.30.5）からバックエンドに転送されています。

5. 同じコマンドをさらに数回実行します。

curl 10.10.30.5 curl 10.10.30.5 curl 10.10.30.5 curl 10.10.30.5 curl 10.10.30.5 curl 10.10.30.5 curl 10.10.30.5 curl 10.10.30.5 curl 10.10.30.5 curl 10.10.30.5

の instance-group-1 からと、 の instance-group-2 からのレスポンスを確認できるはずです。確認できない場合は再度コマンドを実行してください。

お疲れさまでした

このラボでは、 リージョンに 2 つのマネージド インスタンス グループを作成しました。また、それらのインスタンスへの HTTP トラフィックと Google Cloud ヘルスチェッカーからの TCP トラフィックを許可するファイアウォール ルールも作成しました。次に、これらのインスタンス グループの内部ロードバランサを構成してテストしました。

ラボを終了する

ラボが完了したら、[ラボを終了] をクリックします。ラボで使用したリソースが Google Cloud Skills Boost から削除され、アカウントの情報も消去されます。

ラボの評価を求めるダイアログが表示されたら、星の数を選択してコメントを入力し、[送信] をクリックします。

星の数は、それぞれ次の評価を表します。

• 星 1 つ = 非常に不満
• 星 2 つ = 不満
• 星 3 つ = どちらともいえない
• 星 4 つ = 満足
• 星 5 つ = 非常に満足

フィードバックを送信しない場合は、ダイアログ ボックスを閉じてください。

フィードバックやご提案の送信、修正が必要な箇所をご報告いただく際は、[サポート] タブをご利用ください。

Copyright 2020 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。