クラウド エンジニアは、ソリューションをフォールト トレラントかつスケーラブルにする必要があります。アプリケーションは多層となる場合もあります。このため、アーキテクチャにデプロイされているすべての仮想マシン（VM）インスタンスを一般公開する必要がない場合でも、これらのインスタンスはスケーラブルで障害に対処可能である必要があります。また、ソリューション内の VM 間でトラフィックのバランスを取る必要もあります。こうした理由から、アーキテクチャで最も重要なサービスの一つは、トラフィックを処理およびリダイレクトし、ヘルスチェックを継続的に行える、復元力が高くスケーラブルなロードバランサです。

AWS では、インターネットに接続されたロードバランサを使用して、パブリック IP アドレスを持つ Elastic Compute Cloud（EC2）インスタンスにトラフィックを分散できます。複数層があるアプリケーションでは、通常、バックエンド インスタンスはフロントエンドにのみ接続され、外部 IP は割り当てられていません。このシナリオでは、インターネット接続と内部のネットワーク ロードバランサを組み合わせて使用できます。

バックエンド VM インスタンスが公開されていない場合でも、セキュリティ パッチとアップデートをダウンロードできる必要があります。ネットワーク アドレス変換（NAT）ゲートウェイを設定して、パブリック インターネットとの一方向通信を実現します。この場合、プライベート VM インスタンスはインターネットへの接続を開始できますが、インターネットから VM インスタンスへの接続を開始することはできません。

フォールト トレランス、費用対効果、高可用性（HA）を実現するには、Amazon Machine Image（AMI）、起動テンプレート、自動スケーリング グループを組み合わせて使用します。これにより、需要の増加に動的に対応し、不要になったリソースを解放し、ヘルスチェックを実行して、インスタンスが常に稼働していることを保証します。

ここでは、Google Cloud でトラフィックを管理し、サービスを効率的にスケールする方法について説明します。

概要

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. 内部トラフィックおよびヘルスチェックのファイアウォール ルールを構成する

このタスクでは、アプリケーションの内部トラフィック接続とヘルスチェック プローブを許可するようにファイアウォール ルールを構成します。既存のネットワークを調べ、指定した IP 範囲からのトラフィックを許可する新しいファイアウォール ルールを作成します。

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 があらかじめ構成されています。

• Google 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 構成を作成する

このタスクでは、Cloud Router インスタンスを作成し、バックエンド インスタンスがアウトバウンド トラフィックを送信できるように Cloud NAT を構成します。

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

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

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

1. Google Cloud コンソールのタイトル バーにある検索フィールドに「ネットワーク サービス」と入力し、[プロダクトとページ] セクションの [ネットワーク サービス] をクリックします。

2. [ネットワーク サービス] ページで、[ネットワーク サービス] の横にある固定アイコンをクリックします。

3. [Cloud NAT] をクリックします。

4. [開始] をクリックして NAT ゲートウェイを構成します。

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

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

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

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

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

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

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

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

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

このタスクでは、事前構成されたインスタンス テンプレートとマネージド インスタンス グループを確認します。既存のインスタンスで起動スクリプトを実行し、ユーティリティ VM を作成してバックエンド インスタンスへの接続をテストします。

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

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

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

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

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

3. [マシンの構成] ページで次のように設定し、残りの設定はデフォルトのままにします。

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

4. [OS とストレージ] をクリックします。

5. 表示されるイメージが「Debian GNU/Linux 12（bookworm）」でない場合は、[変更] をクリックして [Debian GNU/Linux 12（bookworm）] を選択し、[選択] をクリックします。

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

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

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

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

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

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

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

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

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

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

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

14. 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: {{{project_0.default_zone | Zone 1}}}

15. 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: {{{project_0.default_zone_2 | Zone 2}}}

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

16. 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|Zone2}}} 注: 想定どおりに、トラフィックは内部ロードバランサ（10.10.30.5）からバックエンドに転送されています。

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

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 トラフィックを許可するファイアウォール ルールも作成しました。次に、それらのインスタンス グループの内部ネットワーク ロードバランサを構成してテストしました。

AWS では、ネットワーク アドレス変換（NAT）ゲートウェイ、自動スケーリング グループ、Elastic Load Balancer（ELB）などの一般的なパターンを使用して、Elastic Compute Cloud（EC2）インスタンスを非公開に保ちます。このソリューションにより、EC2 インスタンスはフロントエンド インスタンスと通信し、パブリック インターネットからアップデートを安全にダウンロードできます。

Google Cloud では、内部ネットワーク ロードバランサを使用して、同じ Google Cloud リージョン内のインスタンスまたはマネージド インスタンス グループ（MIG）にトラフィックを分散できます。バックエンドが複数のリージョンにまたがって分散されている場合は、グローバル ロードバランサが必要になります。これは外部としてのみデプロイできます。内部ネットワーク ロードバランサは、次の種類のトラフィックに使用できます。

• TCP / UDP（パススルー）
• HTTP / HTTPS
• TCP（プロキシ）

外部 IP を持たないインスタンスがインターネットへのアウトバウンド接続を開始できるようにするには、Cloud NAT 構成を作成します。

ラボを終了する

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

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

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

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

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

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

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