概要

Google Cloud HTTP(S) ロード バランシングは、Google の世界中のポイント オブ プレゼンス（POP）で Google ネットワークのエッジに実装されています。HTTP(S) ロードバランサを送信先とするユーザー トラフィックは、ユーザーに最も近い POP に入った後、Google のグローバル ネットワークでロードバランスされて、十分な容量がある最も近いバックエンドに送られます。

Google Cloud Armor の IP 拒否 / 許可ルールを使用すると、ユーザーや悪意のあるトラフィックに最も近い Google Cloud のエッジで、HTTP(S) ロードバランサへのアクセスを制限または許可できます。これにより、悪意のあるユーザーまたはトラフィックがリソースを消費したり、Virtual Private Cloud（VPC）ネットワークに侵入したりすることを防止できます。

次の図に示されるように、このラボではグローバルなバックエンドを使って HTTP ロードバランサを構成します。次に、ロードバランサのストレステストを実施し、Google Cloud Armor でストレステストの IP アドレスを拒否リストに登録します。

目標

このラボでは、次のタスクの実行方法について学びます。

• ヘルスチェックのファイアウォール ルールを作成する
• Cloud Router を使用して 2 つのリージョン NAT 構成を作成する
• インスタンス テンプレートを 2 つ構成する
• マネージド インスタンス グループを 2 つ作成する
• HTTP ロードバランサを IPv4 と IPv6 で構成する
• HTTP ロードバランサのストレステストを実施する
• IP アドレスを拒否リストに登録して HTTP ロードバランサへのアクセスを制限する

設定と要件

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

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

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

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

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

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

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

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

Google Cloud Shell の有効化

Google Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。

Google Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールで、右上のツールバーにある [Cloud Shell をアクティブにする] ボタンをクリックします。

   

2. [続行] をクリックします。

環境がプロビジョニングされ、接続されるまでしばらく待ちます。接続した時点で認証が完了しており、プロジェクトに各自のプロジェクト ID が設定されます。次に例を示します。

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

• 次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

出力:

Credentialed accounts: - @.com (active)

出力例:

Credentialed accounts: - google1623327_student@qwiklabs.net

• 次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project =

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: gcloud ドキュメントの全文については、 gcloud CLI の概要ガイド をご覧ください。

タスク 1. ヘルスチェックのファイアウォール ルールを構成する

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

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

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

1. Cloud コンソールのナビゲーション メニュー（）で、[VPC ネットワーク] > [ファイアウォール] を選択します。
   ICMP、internal、RDP、SSH のファイアウォール ルールがすでにあります。

   各 Google Cloud プロジェクトには、default ネットワークとこれらのファイアウォール ルールが始めから用意されています。

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

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

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

注: 送信元 IP 範囲に「/22」と「/16」が含まれていることを確認してください。

4. [tcp] を選択し、ポート「80」を指定します。
5. [作成] をクリックします。

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

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

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

代わりに Cloud NAT サービスをセットアップして、これらの VM インスタンスが外部へのリクエストを行えるようにします。これにより、起動時に Apache ウェブサーバーと PHP をインストールできるようにします。us-central1 リージョンと europe-west1 リージョンのそれぞれにあるマネージド インスタンス グループごとに、Cloud Router を作成します。これらの Cloud Router の構成は次のタスクで行います。

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

1. Cloud コンソールのナビゲーション メニュー（）で、[ネットワーク サービス] > [Cloud NAT] を選択します。

2. [開始] をクリックします。

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

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

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

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

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

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

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

nat-europe について、同じ手順を繰り返します。

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

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

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   ゲートウェイの名前	nat-europe
   ネットワーク	default
   リージョン	europe-west1
   [Cloud Router] > [新しいルーターを作成]	名前を「nat-router-europe-west1」に指定

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

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

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

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

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

インスタンス テンプレートを構成する

インスタンス テンプレートは、VM インスタンスとマネージド インスタンス グループの作成に使用できる API リソースです。このテンプレートでは、マシンタイプ、ブートディスク イメージ、サブネット、ラベル、その他のインスタンス プロパティを定義します。

1. Cloud コンソールのナビゲーション メニュー（）で、[Compute Engine] > [インスタンス テンプレート] を選択します。

2. [インスタンス テンプレートを作成] をクリックします。

3. [名前] に「us-central1-template」と入力します。

4. [リージョン] で [us-central1] を選択します。

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

6. [管理] をクリックします。

7. [メタデータ] で [+ 項目を追加] をクリックし、次の値を指定します。

   キー	値
   startup-script-url	gs://cloud-training/gcpnet/httplb/startup.sh

注: startup-script-url は、インスタンスの起動時に実行されるスクリプトを指定します。このスクリプトが Apache をインストールして、クライアント IP や、VM インスタンスの名前、リージョン、ゾーンを含めるようスタートページを変更します。このスクリプトについて詳しくは、スクリプトのリファレンス ガイドをご覧ください。

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

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

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   ネットワーク タグ	allow-health-checks
   [ネットワーク インターフェース] > [ネットワーク]	default
   サブネットワーク	default (us-central1)
   外部 IP	なし

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

注: ネットワーク タグの allow-health-checks によって、これらのインスタンスにヘルスチェックのファイアウォール ルールが適用されます。

11. [作成] をクリックします。インスタンス テンプレートの作成が完了するまで待ちます。

12. 次に、us-central1-template をコピーして、もう 1 つのインスタンス テンプレートを作成する準備をします。[us-central1-template] をクリックします。us-central1-template に関する情報が表示されます。

13. ページの上部の方にある [同様のものを作成] をクリックします。

14. [名前] に「europe-west1-template」と入力します。

15. [リージョン] で [europe-west1] を選択します。

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

17. [ネットワーキング] > [ネットワーク インターフェース] をクリックします。

18. [サブネットワーク] として [default (europe-west1)] を選択し、[完了] をクリックします。

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

マネージド インスタンス グループを作成する

us-central1 と europe-west1 にマネージド インスタンス グループを作成します。

1. ナビゲーション メニューで [Compute Engine] > [インスタンス グループ] をクリックします。

2. [インスタンス グループの作成] をクリックします。

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

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   名前	us-central1-mig
   ロケーション	マルチゾーン
   リージョン	us-central1
   インスタンス テンプレート	us-central1-template
   自動スケーリング > Autoscaling signals	[CPU 使用率] をクリックし、[CPU 使用率の目標値] を 80 に設定
   初期化期間	45
   インスタンスの最小数	1
   インスタンスの最大数	5

注: マネージド インスタンス グループには、負荷の増減に基づいて、マネージド インスタンス グループのインスタンスを自動的に追加または削除できる自動スケーリング機能が備わっています。自動スケーリングによってトラフィックの増加をアプリケーションで適切に処理できるようになり、リソースの必要性が低下した場合には費用を抑えることができます。自動スケーリングのポリシーを定義しておけば、測定された負荷に基づいて自動的にスケーリングが実行されます。

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

   europe-west1 の europe-west1-mig について、同じ手順を繰り返します。

5. [インスタンス グループを作成] をクリックします。

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

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   名前	europe-west1-mig
   ロケーション	マルチゾーン
   リージョン	europe-west1
   インスタンス テンプレート	europe-west1-template
   自動スケーリング > Autoscaling signals	[CPU 使用率] をクリックし、[CPU 使用率の目標値] を 80 に設定
   初期化期間	45
   インスタンスの最小数	1
   インスタンスの最大数	5

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

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

バックエンドを確認する

両方のリージョンで VM インスタンスが作成されていることを確認し、それらの HTTP サイトにアクセスします。

1. ナビゲーション メニューで、[Compute Engine] > [VM インスタンス] をクリックします。
   名前が「us-central1-mig」と「europe-west1-mig」で始まるインスタンスが存在します。

   これらのインスタンスはマネージド インスタンス グループに含まれています。

2. Cloud コンソールで、ヨーロッパに配置された VM インスタンスの名前とゾーンをメモします。（この後これらの値を使用する必要があります）

3. Google Cloud Platform のメニューで、[Cloud Shell をアクティブにする]（）をクリックして Cloud Shell を開きます。プロンプトが表示されたら、[続行] をクリックします。

4. Cloud Shell で次のコマンドを実行して、ヨーロッパにある VM インスタンスで SSH コマンドを実行します。

gcloud compute ssh <INSTANCE_NAME> --zone <ZONE>

5. プロンプトが表示されたら、[承認] をクリックします。
6. 続行を確認するメッセージが表示されたら、「Y」と入力します。
7. パスフレーズの入力を求められたら、Enter キーまたは Return キーを押します。これにより、空のパスフレーズが生成されます。
8. 空のパスフレーズを確定するために、再度 Enter キーまたは Return キーを押します。しばらくすると、Cloud Shell が IAP トンネルを使用してヨーロッパにある VM インスタンスとの SSH 接続を確立します。これで、Cloud Shell のコマンドラインを VM インスタンスのコマンドラインとして使用できるようになります。
9. コマンドラインで次のように入力します。

curl localhost

startup-script-url スクリプトの一部としてインストールされた Apache のスタートページが表示されます。このスクリプトによって、スタートページはクライアント IP、VM インスタンスの名前、リージョン、ゾーンを含むように変更されています。

10. us-central リージョンにあるインスタンスの内部 IP アドレスをコピーします。
11. 次のコマンドを実行して接続をテストします。

curl $IP_Address 注: 値 $IP_Address は、us-central1 インスタンスの内部 IP に置き換えます。

12. 「exit」と入力して SSH セッションを終了します。

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

次に、下のネットワーク図に示されているように、HTTP ロードバランサを構成して、2 つのバックエンド（us-central1 の us-central1-mig と europe-west1 の europe-west1-mig）の間でトラフィックを分散します。

構成を開始する

1. ナビゲーション メニューで、[ネットワーク サービス] > [ロード バランシング] を選択します。
2. [ロードバランサを作成] をクリックします。
3. [ロードバランサのタイプ] で [アプリケーション ロードバランサ（HTTP / HTTPS）] を選択し、[次へ] をクリックします。
4. [インターネット接続または内部] で [インターネット接続（外部）] を選択し、[次へ] をクリックします。
5. [グローバルまたはシングル リージョンのデプロイ] で [グローバル ワークロードに最適] を選択し、[次へ] をクリックします。
6. [ロードバランサの世代] で [従来のアプリケーション ロードバランサ] を選択し、[次へ] をクリックします。
7. [構成] をクリックします。
8. [ロードバランサの名前] に「http-lb」と入力します。

バックエンドを構成する

バックエンド サービスによって、受信トラフィックが、接続されている 1 つ以上のバックエンドに振り向けられます。各バックエンドは、1 つのインスタンス グループと、追加の提供容量メタデータで構成されます。

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

2. [バックエンド サービスとバックエンド バケット] で、[バックエンド サービスを作成] をクリックします。

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

   プロパティ	値（指定されたオプションを選択）
   名前	http-backend
   バックエンド タイプ	インスタンス グループ
   インスタンス グループ	us-central1-mig
   ポート番号	80
   分散モード	レート
   最大 RPS	50
   容量	100

注: この構成は、ロードバランサが us-central1-mig の各インスタンスの 1 秒あたりのリクエスト数（RPS）を 50 以下に維持しようとすることを意味します。

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

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

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

   プロパティ	値（指定されたオプションを選択）
   インスタンス グループ	europe-west1-mig
   ポート番号	80
   分散モード	使用率
   バックエンドの最大使用率	80
   容量	100

注: この構成は、ロードバランサが europe-west1-mig の各インスタンスの CPU 使用率を 80% 以下に維持しようとすることを意味します。

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

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

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

   プロパティ	値（指定されたオプションを選択）
   名前	http-health-check
   プロトコル	TCP
   ポート	80

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

10. [保存] をクリックします。
11. [ロギングを有効にする] チェックボックスをオンにします。
12. [サンプルレート] を「1」に設定します。
13. [作成] をクリックします。

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

ホストとパスのルールで、トラフィックの転送方法を決定します。たとえば、動画のトラフィックと静的トラフィックをそれぞれ異なるバックエンドに転送できます。ただし、このラボではホストとパスのルールは構成しません。

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

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

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   プロトコル	HTTP
   IP バージョン	IPv4
   IP アドレス	エフェメラル
   ポート	80

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

4. [フロントエンドの IP とポートを追加] をクリックします。

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

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   プロトコル	HTTP
   IP バージョン	IPv6
   IP アドレス	自動割り当て
   ポート	80

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

注: HTTP(S) ロード バランシングは、IPv4 アドレスと IPv6 アドレスのクライアント トラフィックに対応しています。クライアントの IPv6 リクエストはグローバル ロード バランシング レイヤで終端し、IPv4 経由でバックエンドにプロキシされます。

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

1. [確認と完了] をクリックします。
2. [バックエンド サービス] と [フロントエンド] を確認します。
3. [作成] をクリックします。
   ロードバランサの作成が完了するまで待ちます。
4. ロードバランサの名前（http-lb）をクリックします。
5. 次のタスクのために、ロードバランサの IPv4 アドレスと IPv6 アドレスをメモしておきます。これ以降は、これらのアドレスをそれぞれ [LB_IP_v4]、[LB_IP_v6] と呼びます。

注: 16 進数形式のアドレスが IPv6 アドレスです。

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

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

バックエンドの HTTP ロードバランサを作成したので、次は、トラフィックがバックエンド サービスに転送されるかどうかを確認します。

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

1. ブラウザで新しいタブを開いて http://[LB_IP_v4] に移動します。[LB_IP_v4] はロードバランサの IPv4 アドレスに置き換えてください。

注: HTTP ロードバランサにアクセスできるようになるまでに数分かかる場合があります。その間に 404 エラーまたは 502 エラーが表示される場合があります。いずれかのバックエンドのページが表示されるまで繰り返し試してください。 注: us-central1 と europe-west1 のどちらが近いかに応じて、us-central1-mig または europe-west1-mig のいずれかのインスタンスにトラフィックが転送されます。

2. ローカル IPv6 アドレスがある場合は、http://[LB_IP_v6] に移動して HTTP ロードバランサの IPv6 アドレスも試してください。[LB_IP_v6] はロードバランサの IPv6 アドレスに置き換えてください。

HTTP ロードバランサのストレステストを実施する

次に、新しい VM を作成し、HTTP ロードバランサに対する負荷をシミュレートして、負荷が高くなるとトラフィックが両方のバックエンドに分散されるかどうかを確認します。

1. Cloud コンソールのナビゲーション メニュー（）で、[Compute Engine] > [VM インスタンス] を選択します。

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

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

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   名前	siege-vm
   リージョン	us-west1
   ゾーン	us-west1-c

注: us-west1 は europe-west1 より us-central1 に近いため、負荷が高すぎる場合を除いてトラフィックは us-central1-mig のみに転送されるはずです。

4. [作成] をクリックします。siege-vm インスタンスの作成が完了するまで待ちます。
5. Cloud Shell プロンプトに対し、次のコマンドを入力して siege-vm との SSH 接続を確立します。

gcloud compute ssh siege-vm --zone us-west1-c

6. 次のコマンドを実行して siege をインストールします。

sudo apt-get -y install siege

7. 次のコマンドを実行して、HTTP ロードバランサの IPv4 アドレスを環境変数に格納します。[LB_IP_v4] はロードバランサの IPv4 アドレスに置き換えてください。

export LB_IP=[LB_IP_v4]

8. echo で確認します。

echo $LB_IP

9. 次のコマンドを実行して負荷をシミュレートします。

siege -c 250 http://$LB_IP

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

出力:

New configuration template added to /home/cloudcurriculumdeveloper/.siege Run siege -C to view the current settings in that file [alert] Zip encoding disabled; siege requires zlib support to enable it: No such file or directory ** SIEGE 4.0.2 ** Preparing 250 concurrent users for battle. The server is now under siege...

10. Cloud コンソールのナビゲーション メニュー（）で、[ネットワーク サービス] > [ロード バランシング] を選択します。
11. http-lb をクリックします。
12. [モニタリング] をクリックします。
13. 北アメリカと 2 つのバックエンドの間のフロントエンドの場所（合計受信トラフィック）を 2～3 分間モニタリングします。
14. siege-vm の SSH ターミナルに戻ります。
15. Ctrl+C キーを押して siege を停止します。

タスク 6. siege-vm を拒否する

Google Cloud Armor を使用して siege-vm を拒否し、この VM インスタンスが HTTP ロードバランサにアクセスできないようにします。

セキュリティ ポリシーを作成する

Google Cloud Armor セキュリティ ポリシーを作成し、siege-vm に対する拒否ルールを設定します。

1. Cloud コンソールのナビゲーション メニューで、[Compute Engine] > [VM インスタンス] を選択します。
2. siege-vm の外部 IP をメモします。以降はこれを [SIEGE_IP] と呼びます。

注: HTTP ロードバランサにアクセスしようとしているクライアントの外部 IP アドレスを特定するには、いくつかの方法があります。たとえば、BigQuery の VPC フローログに記録されたトラフィックを調べると、大量の受信リクエストを特定できます。

3. ナビゲーション メニューで、[ネットワーク セキュリティ] > [Cloud Armor] > [Cloud Armor ポリシー] を選択します。

4. [ポリシーの作成] をクリックします。

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

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   名前	deny-siege
   デフォルトのルール アクション	許可

6. [次のステップ] をクリックします。

7. [ルールの追加] をクリックします。

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

   プロパティ	値（値を入力するか、指定されたオプションを選択）
   条件 > 一致	SIEGE_IP を入力
   アクション	拒否
   拒否ステータス	403（アクセス拒否）
   優先度	1000

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

10. [次のステップ] をクリックします。

11. [ターゲットの追加] をクリックします。

12. [種類] で [ロードバランサのバックエンド サービス] を選択します。

13. [ターゲット] で [http-backend] を選択します。

14. [ポリシーを作成] をクリックします。
    ポリシーの作成が完了するまで待ってから次のステップに進みます。

注: デフォルトのルールを [拒否] に設定して、承認されたユーザー（IP アドレス）からのトラフィックのみを許可することもできます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 siege-vm を拒否する

セキュリティ ポリシーを確認する

次に、siege-vm が HTTP ロードバランサにアクセスできなくなったことを確認します。

1. siege-vm の SSH ターミナルに戻ります。
2. ロードバランサにアクセスするには次のコマンドを実行します。

curl http://$LB_IP

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

出力:

<!doctype html><meta charset="utf-8"><meta name=viewport content="width=device-width, initial-scale=1"><title>403</title>403 Forbidden 注: セキュリティ ポリシーが有効になるまでに数分かかる場合があります。バックエンドにアクセスできた場合は、403 Forbidden エラーが表示されるまで繰り返し試してください。

3. ブラウザで新しいタブを開いて http://[LB_IP_v4] に移動します。[LB_IP_v4] はロードバランサの IPv4 アドレスに置き換えてください。

注: デフォルトのルールでトラフィックが許可されているため、ブラウザからは HTTP ロードバランサにアクセスできます。siege-vm からアクセスできないのは、先ほど拒否ルールを実装したからです。

4. 次のコマンドを実行して負荷をシミュレートします。

siege -c 250 http://$LB_IP

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

出力:

[alert] Zip encoding disabled; siege requires zlib support to enable it ** SIEGE 4.0.2 ** Preparing 250 concurrent users for battle. The server is now under siege...

セキュリティ ポリシーのログを調べて、このトラフィックもブロックされているかどうかを確認します。

5. Cloud コンソールのナビゲーション メニューで、[ネットワーク セキュリティ] > [Cloud Armor] > [Cloud Armor ポリシー] を選択します。
6. [deny-siege] をクリックします。
7. [ログ] をクリックします。
8. [ポリシーログを表示] をクリックします。Logs Explorer が起動されます。http-lb ロードバランサのログが表示されます。
9. クエリ結果でログエントリを展開します。
10. [httpRequest] を展開します。

リクエストの送信元が siege-vm の IP アドレスになっているはずです。そうでない場合は、別のログエントリを展開します。

11. [jsonPayload] を展開します。
12. [enforcedSecurityPolicy] を展開します。
    [configuredAction] が DENY に設定されていて、その name として deny-siege が指定されています。

注: Google Cloud Armor セキュリティ ポリシーによって作成されるログを調べると、トラフィックが拒否または許可された日時や、トラフィックの送信元を特定できます。

お疲れさまでした

このラボでは、まず、us-central1 と europe-west1 のバックエンドを使って HTTP ロードバランサを構成しました。次に、VM を使用してロードバランサのストレステストを実施し、Google Cloud Armor でこの VM の IP アドレスを拒否リストに登録しました。また、セキュリティ ポリシーのログを調べて、トラフィックがブロックされた理由を特定しました。

ラボを終了する

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

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

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

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

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

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

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