このドキュメントでは、Compute Engine VM で実行するサービス用にリージョン内部アプリケーション ロードバランサを構成する手順について説明します。
Google Kubernetes Engine(GKE)Pod で実行するサービスのロード バランシングを構成するには、スタンドアロン NEG を使用したコンテナ ネイティブのロード バランシングとリージョン内部アプリケーション ロードバランサとスタンドアロン NEG の接続をご覧ください。
Private Service Connect を使用して Google API とサービスにアクセスできるようにロード バランシングを構成するには、コンシューマー HTTP(S) サービス コントロールを使用した Private Service Connect の構成をご覧ください。
内部アプリケーション ロードバランサの設定は、次の 2 つの部分に分かれます。
- 前提となる作業を行う(必要なアカウントに適切な権限を付与し、Virtual Private Cloud(VPC)ネットワークを準備するなど)。
- ロードバランサのリソースを設定する。
このガイドに進む前に、次の内容を理解しておいてください。
- 内部アプリケーション ロードバランサの概要(制限事項セクションを含む)
- VPC ファイアウォール ルールの概要
権限
このガイドに従うには、プロジェクト内でインスタンスを作成してネットワークを変更できる必要があります。そのためにはプロジェクトのオーナーまたは編集者であるか、または次の Compute Engine IAM のロールをすべて持っている必要があります。
タスク | 必要なロール |
---|---|
ネットワーク、サブネット、ロードバランサ コンポーネントの作成 | Compute ネットワーク管理者 |
ファイアウォール ルールの追加と削除 | Compute セキュリティ管理者 |
インスタンスの作成 | Compute インスタンス管理者 |
詳細については、次のガイドをご覧ください。
設定の概要
内部アプリケーション ロードバランサは、次の構成フローの概要で説明されているように構成できます。図の中で番号の付いている項目については、図の後で簡単に説明します。
この例では、1 つのバックエンド サービスと 2 つのバックエンド グループがある us-west1
リージョンの VPC ネットワークに、内部アプリケーション ロードバランサを作成しています。
この図は次のことを示しています。
2 つのサブネットがある VPC ネットワーク:
サブネットの 1 つは、バックエンド(インスタンス グループ)と転送ルールに使用されます。プライマリ IP アドレスの範囲は
10.1.2.0/24
です。もう一つのサブネットは、
us-west1
リージョンのプロキシ専用サブネットです。内部アプリケーション ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを 1 つ作成する必要があります。リージョンのプロキシ専用サブネットは、リージョン内のすべての内部アプリケーション ロードバランサで共有されます。内部アプリケーション ロードバランサからサービスのバックエンドに送信されるパケットのソースアドレスは、プロキシ専用サブネットから割り当てられます。この例では、リージョンのプロキシ専用サブネットのプライマリ IP アドレスの範囲は10.129.0.0/23
であり、これが推奨サブネット サイズです。詳細については、プロキシ専用サブネットをご覧ください。
ネットワーク内のプロキシ専用サブネット トラフィック フローを許可するファイアウォール ルール。
10.129.0.0/23
(この例ではプロキシ専用サブネットの範囲)からの TCP ポート80
、443
、8080
トラフィックを許可する 1 つのルールが追加されることになります。ヘルスチェック プローブ用の別のファイアウォール ルール。バックエンドの Compute Engine VM インスタンス。
Compute Engine VM デプロイのマネージド インスタンス グループまたは非マネージド インスタンス グループ
各ゾーンで、デプロイ要件に基づいてバックエンド グループタイプを組み合わせることができます。
バックエンドの準備状況を報告するリージョン ヘルスチェック。
バックエンドの使用状況と健全性をモニタリングするリージョン バックエンド サービス。
リージョン URL マップはリクエストの URL を解析し、リクエスト URL のホストとパスに基づいて特定のバックエンド サービスにリクエストを転送します。
リージョン ターゲット HTTP または HTTPS プロキシ。ユーザーからリクエストを受け取り、URL マップに転送します。HTTPS の場合、リージョン SSL 証明書リソースを構成します。HTTPS 負荷分散を構成する場合、ターゲット プロキシは SSL 証明書を使用して SSL トラフィックを復号します。ターゲット プロキシは、HTTP または HTTPS を使用してトラフィックをインスタンスに転送できます。
ロードバランサの内部 IP アドレスを含む転送ルール。受信リクエストをターゲット プロキシに転送します。
転送ルールに関連付けられた内部 IP アドレスは、同じネットワークとリージョンにある任意のサブネットから取得できます。次の条件に注意してください。
- IP アドレスは、バックエンド インスタンス グループと同じサブネットから取得できます(必須ではありません)。
- IP アドレスは、
--purpose
フラグがREGIONAL_MANAGED_PROXY
に設定されている予約済みプロキシ専用サブネットからは取得しないでください。 - 内部 IP アドレスを複数の転送ルールと共有する場合は、IP アドレスの
--purpose
フラグをSHARED_LOADBALANCER_VIP
に設定します。
この例では、エフェメラル内部 IP アドレスの割り振りを許可せずに、リージョン内部アプリケーション ロードバランサの転送ルールに予約済み内部 IP アドレスを使用しています。転送ルールの IP アドレスは予約しておくことをおすすめします。
ネットワークとサブネットを構成する
ロードバランサのバックエンド用とロードバランサのプロキシ用の 2 つのサブネットが存在する VPC ネットワークが必要です。内部アプリケーション ロードバランサはリージョンごとです。VPC ネットワーク内のトラフィックは、送信元がロードバランサと同じリージョンのサブネット内にある場合、ロードバランサに転送されます。
この例では、次の VPC ネットワーク、リージョン、サブネットを使用します。
ネットワーク。ネットワークは、
lb-network
という名前のカスタムモードの VPC ネットワークです。バックエンドのサブネット。
us-west1
リージョンのbackend-subnet
という名前のサブネット。プライマリ IP 範囲として10.1.2.0/24
を使用します。プロキシのサブネット。
us-west1
リージョンのproxy-only-subnet
という名前のサブネット。プライマリ IP 範囲として10.129.0.0/23
を使用します。
また、グローバル アクセスを示すため、この例では別のリージョンとサブネットに 2 つ目のテスト クライアント VM を作成します。
- リージョン:
europe-west1
- サブネット:
europe-subnet
(プライマリ IP アドレス範囲は10.3.4.0/24
)
ネットワークとサブネットを構成する
Google Cloud コンソールの [VPC ネットワーク] ページに移動します。
[VPC ネットワークを作成] をクリックします。
[名前] に「
lb-network
」と入力します。[サブネット] セクションで、[サブネット作成モード] を [カスタム] に設定します。
ロードバランサのバックエンド用のサブネットを作成します。[新しいサブネット] セクションに、次の情報を入力します。
- 名前:
backend-subnet
- リージョン:
us-west1
- IP アドレス範囲:
10.1.2.0/24
- 名前:
[完了] をクリックします。
[サブネットを追加] をクリックします。
グローバル アクセスを示すためにサブネットを作成します。[新しいサブネット] セクションに、次の情報を入力します。
- 名前:
europe-subnet
- リージョン:
europe-west1
- IP アドレス範囲:
10.3.4.0/24
- 名前:
[完了] をクリックします。
[作成] をクリックします。
gcloud compute networks create
コマンドを使用してカスタム VPC ネットワークを作成します。gcloud compute networks create lb-network --subnet-mode=custom
gcloud compute networks subnets create
コマンドを使用して、us-west1
リージョンのlb-network
ネットワークにサブネットを作成します。gcloud compute networks subnets create backend-subnet \ --network=lb-network \ --range=10.1.2.0/24 \ --region=us-west1
gcloud compute networks subnets create
コマンドを使用して、europe-west1
リージョンのlb-network
ネットワークにサブネットを作成します。gcloud compute networks subnets create europe-subnet \ --network=lb-network \ --range=10.3.4.0/24 \ --region=europe-west1
networks.insert
メソッドに POST
リクエストを送信します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID /global/networks { "routingConfig": { "routingMode": "REGIONAL" }, "name": "lb-network", "autoCreateSubnetworks": false }
subnetworks.insert
メソッドに POST
リクエストを送信します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID /regions/us-west1/subnetworks { "name": "backend-subnet", "network": "projects/PROJECT_ID /global/networks/lb-network", "ipCidrRange": "10.1.2.0/24", "region": "projects/PROJECT_ID /regions/us-west1", }
subnetworks.insert
メソッドに POST
リクエストを送信します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID /regions/europe-west1/subnetworks { "name": "europe-subnet", "network": "projects/PROJECT_ID /global/networks/lb-network", "ipCidrRange": "10.3.4.0/24", "region": "projects/PROJECT_ID /regions/europe-west1", }
プロキシ専用サブネットを構成する
このプロキシ専用サブネットは、lb-network
の us-west1
リージョン内のすべてのリージョン Envoy ベースのロードバランサ用です。
Google Cloud コンソールを使用している場合は、しばらく待ってから、[ロード バランシング] ページでプロキシ専用サブネットを作成できます。
プロキシ専用サブネットを今すぐ作成する場合は、次の手順を行います。
Google Cloud コンソールの [VPC ネットワーク] ページに移動します。
VPC ネットワークの名前
lb-network
をクリックします。[サブネットを追加] をクリックします。
[名前] に「
proxy-only-subnet
」と入力します。[リージョン] で
us-west1
を選択します。[目的] を [リージョン マネージド プロキシ] に設定します。
[IP アドレス範囲] に「
10.129.0.0/23
」と入力します。[追加] をクリックします。
gcloud compute networks subnets
create
コマンドを使用して、プロキシ専用サブネットを作成します。
gcloud compute networks subnets create proxy-only-subnet \ --purpose=REGIONAL_MANAGED_PROXY \ --role=ACTIVE \ --region=us-west1 \ --network=lb-network \ --range=10.129.0.0/23
subnetworks.insert
メソッドを使用してプロキシ専用サブネットを作成します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/projects/PROJECT_ID /regions/us-west1/subnetworks { "name": "proxy-only-subnet", "ipCidrRange": "10.129.0.0/23", "network": "projects/PROJECT_ID /global/networks/lb-network", "region": "projects/PROJECT_ID /regions/us-west1", "purpose": "REGIONAL_MANAGED_PROXY", "role": "ACTIVE" }
ファイアウォール ルールを構成する
この例では、次のファイアウォール ルールを使用します。
fw-allow-ssh
。ロードバランスされたインスタンスに適用される上り(内向き)ルール。任意のアドレスから TCP ポート22
への SSH 接続を許可します。このルールには、送信元の IP 範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲を指定できます。この例では、ターゲットタグallow-ssh
を使用して、ファイアウォール ルールが適用される VM を識別します。fw-allow-health-check
。 ロードバランスされたインスタンスに適用される上り(内向き)ルール。これによって、Google Cloud ヘルスチェック システム(130.211.0.0/22
と35.191.0.0/16
)からのすべての TCP トラフィックが許可されます。この例では、ターゲットタグload-balanced-backend
を使用して、ファイアウォール ルールが適用される VM を識別しています。fw-allow-proxies
。ロードバランスされたインスタンスに適用される上り(内向き)ルール。内部アプリケーション ロードバランサが管理するプロキシからポート80
、443
、8080
への TCP トラフィックを許可します。この例では、ターゲットタグload-balanced-backend
を使用して、ファイアウォール ルールが適用される VM を識別します。
これらのファイアウォール ルールがない場合は、デフォルトの上り(内向き)拒否ルールによってバックエンド インスタンスへの受信トラフィックがブロックされます。
ターゲットタグは、バックエンド インスタンスを定義します。ターゲットタグがない場合、ファイアウォール ルールは VPC ネットワーク内のすべてのバックエンド インスタンスに適用されます。バックエンド VM を作成する場合は、マネージド インスタンス グループの作成の説明に沿って、指定したターゲットタグを忘れずに含めてください。
Google Cloud コンソールで [ファイアウォール ポリシー] ページに移動します。
[ファイアウォール ルールを作成] をクリックして、SSH 接続の受信を許可するルールを作成します。
- 名前:
fw-allow-ssh
- ネットワーク:
lb-network
- トラフィックの方向: 上り(内向き)
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
allow-ssh
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲:
0.0.0.0/0
- プロトコルとポート:
- 指定されたプロトコルとポートを選択します。
- [TCP] チェックボックスをオンにして、ポート番号に「
22
」と入力します。
- 名前:
[作成] をクリックします。
[ファイアウォール ルールを作成] をもう一度クリックして、Google Cloud ヘルスチェックを許可するルールを作成します。
- 名前:
fw-allow-health-check
- ネットワーク:
lb-network
- トラフィックの方向: 上り(内向き)
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
load-balanced-backend
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲:
130.211.0.0/22
と35.191.0.0/16
- プロトコルとポート:
- 指定されたプロトコルとポートを選択します。
- [TCP] チェックボックスをオンにして、ポート番号に「
80
」と入力します。
このルールは、ヘルスチェックに使用されているプロトコルとポートのみに制限することをおすすめします。プロトコルとポートにtcp:80
を使用すると、Google Cloud はポート80
で HTTP を使用して VM に接続できますが、ポート443
では HTTPS を使用して VM に接続することはできません。
- 名前:
[作成] をクリックします。
[ファイアウォール ルールを作成] をもう一度クリックをして、ロードバランサのプロキシ サーバーがバックエンドに接続できるようにするルールを作成します。
- 名前:
fw-allow-proxies
- ネットワーク:
lb-network
- トラフィックの方向: 上り(内向き)
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
load-balanced-backend
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲:
10.129.0.0/23
- プロトコルとポート:
- 指定されたプロトコルとポートを選択します。
- [TCP] チェックボックスをオンにして、ポート番号に「
80, 443, 8080
」と入力します。
- 名前:
[作成] をクリックします。
ネットワーク タグ
allow-ssh
を使用して、VM との SSH 接続を許可するfw-allow-ssh
ファイアウォール ルールを作成します。source-ranges
を省略すると、Google Cloud は任意の送信元を対象とするものとしてルールを解釈します。gcloud compute firewall-rules create fw-allow-ssh \ --network=lb-network \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22
Google Cloud ヘルスチェックを許可する
fw-allow-health-check
ルールを作成します。この例では、ヘルスチェック プローブからのすべての TCP トラフィックを許可します。ただし、必要に応じてポートの範囲を狭く構成することもできます。gcloud compute firewall-rules create fw-allow-health-check \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=load-balanced-backend \ --rules=tcp
内部アプリケーション ロードバランサのプロキシがバックエンドに接続できるように
fw-allow-proxies
ルールを作成します。source-ranges
を、プロキシ専用サブネットの割り振り範囲に設定します(例:10.129.0.0/23
)。gcloud compute firewall-rules create fw-allow-proxies \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=
source-range \ --target-tags=load-balanced-backend \ --rules=tcp:80,tcp:443,tcp:8080
firewalls.insert
メソッドに POST
リクエストを送り、fw-allow-ssh
ファイアウォール ルールを作成します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID /global/firewalls { "name": "fw-allow-ssh", "network": "projects/PROJECT_ID /global/networks/lb-network", "sourceRanges": [ "0.0.0.0/0" ], "targetTags": [ "allow-ssh" ], "allowed": [ { "IPProtocol": "tcp", "ports": [ "22" ] } ], "direction": "INGRESS" }
firewalls.insert
メソッドに POST
リクエストを送り、fw-allow-health-check
ファイアウォール ルールを作成します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID /global/firewalls { "name": "fw-allow-health-check", "network": "projects/PROJECT_ID /global/networks/lb-network", "sourceRanges": [ "130.211.0.0/22", "35.191.0.0/16" ], "targetTags": [ "load-balanced-backend" ], "allowed": [ { "IPProtocol": "tcp" } ], "direction": "INGRESS" }
firewalls.insert
メソッドのプロキシ サブネット内で TCP トラフィックを許可する fw-allow-proxies
ファイアウォール ルールを作成します。PROJECT_ID
は、実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID /global/firewalls { "name": "fw-allow-proxies", "network": "projects/PROJECT_ID /global/networks/lb-network", "sourceRanges": [ "10.129.0.0/23" ], "targetTags": [ "load-balanced-backend" ], "allowed": [ { "IPProtocol": "tcp", "ports": [ "80" ] }, { "IPProtocol": "tcp", "ports": [ "443" ] }, { "IPProtocol": "tcp", "ports": [ "8080" ] } ], "direction": "INGRESS" }
ロードバランサの IP アドレスを予約する
デフォルトでは、各転送ルールに 1 つの IP アドレスが使用されます。共有 IP アドレスを予約すると、複数の転送ルールで同じ IP アドレスを使用できます。ただし、Private Service Connect を使用してロードバランサを公開する場合は、転送ルールに共有 IP アドレスを使用しないでください。
転送ルールの IP アドレスには、backend-subnet
を使用します。プロキシ専用サブネットを使用すると、転送ルールの作成に失敗します。
Google Cloud コンソールを使用してスタンドアロンの内部 IP アドレスを予約できます。
- [VPC ネットワーク] ページに移動します。
- 環境間のハイブリッド接続の構成に使用したネットワークをクリックします。
- [静的内部 IP アドレス] をクリックして、[静的アドレスを予約] をクリックします。
- [名前] に「
l7-ilb-ip-address
」と入力します。 - [サブネット] で [
backend-subnet
] を選択します。 - 予約する IP アドレスを指定する場合は、[静的 IP アドレス] の下で、[自分で選択] を選択し、[カスタム IP アドレス] に入力します。それ以外の場合、サブネットの IP アドレスは自動的に割り当てられます。
- この IP アドレスを複数の転送ルールで使用する場合は、[目的] で [共有] を選択します。
- [予約] をクリックして、プロセスを終了します。
gcloud CLI を使用して
compute addresses create
コマンドを実行します。gcloud compute addresses create l7-ilb-ip-address \ --region=us-west1 \ --subnet=backend-subnet
複数の転送ルールで同じ IP アドレスを使用する場合は、
--purpose=SHARED_LOADBALANCER_VIP
を指定します。割り振られた IP アドレスを表示するには、
compute addresses describe
コマンドを使用します。gcloud compute addresses describe l7-ilb-ip-address \ --region=us-west1
マネージド VM インスタンス グループのバックエンドを作成する
このセクションでは、インスタンス グループ テンプレートとマネージド インスタンス グループの作成方法について説明します。このマネージド インスタンス グループには、サンプルのリージョン内部アプリケーション ロードバランサのバックエンド サーバーを実行する VM インスタンスが用意されています。インスタンス グループに HTTP サービスを定義し、ポート名を適切なポートにマッピングできます。ロードバランサのバックエンド サービスは、名前付きポートにトラフィックを転送します。クライアントからのトラフィックは、バックエンド サーバーにロードバランスされます。わかりやすく説明するために、バックエンド サーバーはそれぞれのホスト名をコンテンツとして提供します。
インスタンス テンプレートを作成します。Google Cloud コンソールで [インスタンス テンプレート] ページに移動します。
- [インスタンス テンプレートを作成] をクリックします。
- [名前] に「
l7-ilb-backend-template
」と入力します。 - [ブートディスク] が Debian GNU/Linux 12 (bookworm) などの Debian イメージに設定されていることを確認します。以降の手順では、
apt-get
などの Debian でのみ使用できるコマンドを使用します。 - [詳細オプション] をクリックします。
- [ネットワーキング] をクリックして次のフィールドを構成します。
- [ネットワーク タグ] に「
allow-ssh
」と「load-balanced-backend
」を入力します。 - [ネットワーク インターフェース] で、次のように選択します。
- ネットワーク:
lb-network
- サブネット:
backend-subnet
- ネットワーク:
- [ネットワーク タグ] に「
[管理] をクリックします。[起動スクリプト] フィールドに次のスクリプトを入力します。
#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2
[作成] をクリックします。
マネージド インスタンス グループを作成します。Google Cloud コンソールで、[インスタンス グループ] ページに移動します。
- [インスタンス グループを作成] をクリックします。
- [新しいマネージド インスタンス グループ(ステートレス)] を選択します。詳細については、ステートレス MIG とステートフル MIG をご覧ください。
- [名前] に「
l7-ilb-backend-example
」と入力します。 - [ロケーション] で [シングルゾーン] を選択します。
- [リージョン] で
us-west1
を選択します。 - [ゾーン] で、[
us-west1-a
] を選択します。 - [インスタンス テンプレート] で [
l7-ilb-backend-template
] を選択します。 グループ内に作成するインスタンスの数を指定します。
この例では、[自動スケーリング] で次のオプションを指定します。
- [自動スケーリング モード] で [
Off:do not autoscale
] を選択します。 - [インスタンスの最大数] に「
2
」と入力します。
オプションとして、UI の [自動スケーリング] セクションで、インスタンスの CPU 使用率に基づいてインスタンスを自動的に追加または削除するようにインスタンス グループを構成できます。
- [自動スケーリング モード] で [
[作成] をクリックします。
このガイドの gcloud
の手順は、Cloud Shell または bash がインストールされた別の環境を使用していることを前提としています。
gcloud compute instance-templates create
コマンドを使用して、HTTP サーバーで VM インスタンス テンプレートを作成します。gcloud compute instance-templates create l7-ilb-backend-template \ --region=us-west1 \ --network=lb-network \ --subnet=backend-subnet \ --tags=allow-ssh,load-balanced-backend \ --image-family=debian-12 \ --image-project=debian-cloud \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'
gcloud compute instance-groups managed create
コマンドを使用して、ゾーンにマネージド インスタンス グループを作成します。gcloud compute instance-groups managed create l7-ilb-backend-example \ --zone=us-west1-a \ --size=2 \ --template=l7-ilb-backend-template
instanceTemplates.insert
メソッドを使用してインスタンス テンプレートを作成します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID /global/instanceTemplates { "name":"l7-ilb-backend-template", "properties":{ "machineType":"e2-standard-2", "tags":{ "items":[ "allow-ssh", "load-balanced-backend" ] }, "metadata":{ "kind":"compute#metadata", "items":[ { "key":"startup-script", "value":"#! /bin/bash\napt-get update\napt-get install apache2 -y\na2ensite default-ssl\na2enmod ssl\n vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://metadata.google.internal/computeMetadata/v1/instance/name)\"\n echo \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nsystemctl restart apache2" } ] }, "networkInterfaces":[ { "network":"projects/PROJECT_ID /global/networks/lb-network", "subnetwork":"regions/us-west1/subnetworks/backend-subnet", "accessConfigs":[ { "type":"ONE_TO_ONE_NAT" } ] } ], "disks":[ { "index":0, "boot":true, "initializeParams":{ "sourceImage":"projects/debian-cloud/global/images/family/debian-12" }, "autoDelete":true } ] } }
instanceGroupManagers.insert
メソッドを使用して、各ゾーンにマネージド インスタンス グループを作成します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID /zones/{zone}/instanceGroupManagers { "name": "l7-ilb-backend-example", "zone": "projects/PROJECT_ID /zones/us-west1-a", "instanceTemplate": "projects/PROJECT_ID /global/instanceTemplates/l7-ilb-backend-template", "baseInstanceName": "l7-ilb-backend-example", "targetSize": 2 }
ロードバランサを構成する
この例では、次のリージョン内部アプリケーション ロードバランサ リソースの作成方法を示します。
- HTTP ヘルスチェック
- マネージド インスタンス グループをバックエンドとして使用するバックエンド サービス
- URL マップ
- リージョンがターゲット HTTP(S) プロキシに定義されている場合は、必ずリージョン URL マップを参照してください。リージョン URL マップは、受信 URL のホストとパスに定義したルールに基づいて、リクエストをリージョン バックエンド サービスにルーティングします。リージョン URL マップを参照できるのは、同じリージョン内のリージョン ターゲット プロキシのルールのみです。
- SSL 証明書(HTTPS の場合)
- ターゲット プロキシ
- 転送ルール
プロキシの可用性
Google Cloud リージョンによっては、新しいロードバランサに対応するのに十分なプロキシ容量がない場合があります。その場合、ロードバランサの作成時に Google Cloud コンソールでプロキシの可用性に関する警告メッセージが表示されます。この問題を解決するには、次のいずれかを行います。
- ロードバランサに別のリージョンを選択します。これは、別のリージョンにバックエンドがある場合には現実的な選択肢となります。
- プロキシ専用サブネットがすでに割り当てられている VPC ネットワークを選択します。
容量の問題が解決するまで待ちます。
構成を開始する
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
- [ロードバランサを作成] をクリックします。
- [ロードバランサの種類] で [アプリケーション ロードバランサ(HTTP / HTTPS)] を選択し、[次へ] をクリックします。
- [インターネット接続または内部] で [内部] を選択し、[次へ] をクリックします。
- [クロスリージョンまたはシングル リージョンのデプロイ] で [リージョン ワークロードに最適] を選択し、[次へ] をクリックします。
- [構成] をクリックします。
基本構成
- ロードバランサの名前に「
l7-ilb-map
」と入力します。 - [リージョン] で、
us-west1
を選択します。 - [ネットワーク] で
lb-network
を選択します。
プロキシ専用サブネットを予約する
プロキシ専用サブネットを予約します。
- [サブネットの予約] をクリックします。
- [名前] に「
proxy-only-subnet
」と入力します。 - [IP アドレス範囲] に「
10.129.0.0/23
」と入力します。 - [追加] をクリックします。
バックエンド サービスの構成
- [バックエンドの設定] をクリックします。
- [バックエンド サービスの作成または選択] メニューから [バックエンド サービスを作成] を選択します。
- バックエンド サービスの名前を
l7-ilb-backend-service
に設定します。 - [バックエンド タイプ] をインスタンス グループに設定します。
- [新しいバックエンド] セクションで、次の操作を行います。
- [インスタンス グループ] を
l7-ilb-backend-example
に設定します。 - [ポート番号] を
80
に設定します。 - [分散モード] を [使用率] に設定します。
- [完了] をクリックします。
- [インスタンス グループ] を
- [ヘルスチェック] リストで、次のパラメータを指定して [ヘルスチェックを作成] をクリックします。
- 名前:
l7-ilb-basic-check
- プロトコル:
HTTP
- ポート:
80
- [保存] をクリックします。
- 名前:
- [作成] をクリックします。
URL マップを構成する
[ホストとパスのルール] をクリックします。
[モード] で、[単純なホストとパスのルール] を選択します。
l7-ilb-backend-service
が、ホストとパスが一致しなかった場合に使用される唯一のバックエンド サービスであることを確認します。
トラフィック管理の詳細については、トラフィック管理の設定をご覧ください。
フロントエンドを構成する
HTTP の場合:
- [フロントエンドの構成] をクリックします。
- 転送ルールの名前を
l7-ilb-forwarding-rule
に設定します。 - [プロトコル] を
HTTP
に設定します。 - [サブネットワーク] を
backend-subnet
に設定します。 - [ポート] を
80
に設定します。 - [IP アドレス] リストから [
l7-ilb-ip-address
] を選択します。 - [完了] をクリックします。
HTTPS の場合:
- [フロントエンドの構成] をクリックします。
- 転送ルールの名前を
l7-ilb-forwarding-rule
に設定します。 - [プロトコル] を
HTTPS (includes HTTP/2)
に設定します。 - [サブネットワーク] を
backend-subnet
に設定します。 - HTTPS トラフィックを許可するように、[ポート] が
443
に設定されていることを確認します。 - [IP アドレス] リストから [
l7-ilb-ip-address
] を選択します。 - [証明書] プルダウン リストをクリックします。
- プライマリ SSL 証明書として使用しようとしているセルフマネージド SSL 証明書リソースがすでにある場合は、リストから選択します。
- そうでない場合は、[新しい証明書を作成] を選択します。
- 証明書の名前を
l7-ilb-cert
に設定します。 - 該当するフィールドに PEM 形式のファイルをアップロードします。
- 公開鍵証明書
- 証明書チェーン
- 秘密鍵
- [作成] をクリックします。
- 証明書の名前を
- プライマリ SSL 証明書リソースに加えて証明書リソースを追加するには、次の手順に沿って操作します。
- [証明書を追加] をクリックします。
- [証明書] リストから証明書を選択するか、[新しい証明書の作成] をクリックし、上記の操作を行います。
[SSL ポリシー] リストから SSL ポリシーを選択します。必要に応じて、SSL ポリシーを作成します。手順は次のとおりです。
- [SSL ポリシー] リストで、[ポリシーを作成] を選択します。
- SSL ポリシーの名前を入力します。
- TLS の最小バージョンを選択します。デフォルト値は TLS 1.0 です。
- 事前構成された Google マネージド プロファイルのいずれかを選択するか、SSL 機能を個別に選択できるカスタム プロファイルを選択します。[有効な機能] と [無効な機能] が表示されます。
- [保存] をクリックします。
SSL ポリシーを作成していない場合は、デフォルトの Google Cloud SSL ポリシーが適用されます。
[完了] をクリックします。
構成を確認する
- [確認と完了] をクリックします。
- ロードバランサの構成を確認します。
- 省略可: [同等のコード] をクリックして、ロードバランサの作成に使用する REST API リクエストを表示します。
- [作成] をクリックします。
gcloud compute health-checks create http
コマンドを使用して HTTP ヘルスチェックを定義します。gcloud compute health-checks create http l7-ilb-basic-check \ --region=us-west1 \ --use-serving-port
gcloud compute backend-services create
コマンドを使用してバックエンド サービスを定義します。gcloud compute backend-services create l7-ilb-backend-service \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=HTTP \ --health-checks=l7-ilb-basic-check \ --health-checks-region=us-west1 \ --region=us-west1
gcloud compute backend-services add-backend
コマンドを使用して、バックエンド サービスにバックエンドを追加します。gcloud compute backend-services add-backend l7-ilb-backend-service \ --balancing-mode=UTILIZATION \ --instance-group=l7-ilb-backend-example \ --instance-group-zone=us-west1-a \ --region=us-west1
gcloud compute url-maps create
コマンドを使用して、URL マップを作成します。gcloud compute url-maps create l7-ilb-map \ --default-service=l7-ilb-backend-service \ --region=us-west1
ターゲット プロキシを作成します。
HTTP の場合:
内部 HTTP ロードバランサの場合は、
gcloud compute target-http-proxies create
コマンドを使用してターゲット プロキシを作成します。gcloud compute target-http-proxies create l7-ilb-proxy \ --url-map=l7-ilb-map \ --url-map-region=us-west1 \ --region=us-west1
HTTPS の場合:
Compute Engine または Certificate Manager の証明書を作成できます。Certificate Manager を使用して証明書を作成するには、次のいずれかの方法を使用します。
- リージョン セルフマネージド証明書。リージョン セルフマネージド証明書の作成と使用については、リージョン セルフマネージド証明書をデプロイするをご覧ください。証明書マップはサポートされていません。
リージョンの Google マネージド証明書。証明書マップはサポートされていません。
Certificate Manager では、次のタイプのリージョン Google マネージド証明書がサポートされています。
- プロジェクトごとの DNS 認証を使用するリージョン Google マネージド証明書。詳細については、リージョン Google マネージド証明書をデプロイするをご覧ください。
- Certificate Authority Service を使用するリージョン Google マネージド(プライベート)証明書。詳細については、CA Service を使用してリージョン Google マネージド証明書をデプロイするをご覧ください。
転送ルールを作成します。
カスタム ネットワークでは、転送ルールでサブネットを参照する必要があります。このサブネットは、VM サブネットでありプロキシ専用サブネットではありません。
HTTP の場合:
適切なフラグを設定して
gcloud compute forwarding-rules create
コマンドを実行します。gcloud compute forwarding-rules create l7-ilb-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=l7-ilb-ip-address \ --ports=80 \ --region=us-west1 \ --target-http-proxy=l7-ilb-proxy \ --target-http-proxy-region=us-west1
HTTPS の場合:
適切なフラグを設定して
gcloud compute forwarding-rules create
コマンドを実行し、転送ルールを作成します。gcloud compute forwarding-rules create l7-ilb-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=l7-ilb-ip-address \ --ports=443 \ --region=us-west1 \ --target-https-proxy=l7-ilb-proxy \ --target-https-proxy-region=us-west1
証明書を作成したら、証明書をターゲット プロキシに直接関連付けます。
ファイルパスを変数名に割り当てます。
export LB_CERT=path to PEM-formatted file
export LB_PRIVATE_KEY=path to PEM-formatted file
gcloud compute ssl-certificates create
コマンドを使用してリージョン SSL 証明書を作成します。gcloud compute ssl-certificates create l7-ilb-cert \ --certificate=$LB_CERT \ --private-key=$LB_PRIVATE_KEY \ --region=us-west1
リージョン SSL 証明書を使用して、
gcloud compute target-https-proxies create
コマンドでターゲット プロキシを作成します。gcloud compute target-https-proxies create l7-ilb-proxy \ --url-map=l7-ilb-map \ --region=us-west1 \ --ssl-certificates=l7-ilb-cert
regionHealthChecks.insert
メソッドに POST
リクエストを送り、ヘルスチェックを作成します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID /regions/{region}/healthChecks { "name": "l7-ilb-basic-check", "type": "HTTP", "httpHealthCheck": { "portSpecification": "USE_SERVING_PORT" } }
regionBackendServices.insert
メソッドに POST
リクエストを送り、リージョン バックエンド サービスを作成します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID /regions/us-west1/backendServices { "name": "l7-ilb-backend-service", "backends": [ { "group": "projects/PROJECT_ID /zones/us-west1-a/instanceGroups/l7-ilb-backend-example", "balancingMode": "UTILIZATION" } ], "healthChecks": [ "projects/PROJECT_ID /regions/us-west1/healthChecks/l7-ilb-basic-check" ], "loadBalancingScheme": "INTERNAL_MANAGED" }
regionUrlMaps.insert
メソッドに POST
リクエストを送り、URL マップを作成します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID /regions/us-west1/urlMaps { "name": "l7-ilb-map", "defaultService": "projects/PROJECT_ID /regions/us-west1/backendServices/l7-ilb-backend-service" }
HTTP の場合:
regionTargetHttpProxies.insert
メソッドに POST
リクエストを送り、ターゲット HTTP プロキシを作成します。PROJECT_ID
は、実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID /regions/us-west1/targetHttpProxy { "name": "l7-ilb-proxy", "urlMap": "projects/PROJECT_ID /global/urlMaps/l7-ilb-map", "region": "us-west1" }
forwardingRules.insert
メソッドに POST
リクエストを送り、転送ルールを作成します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID /regions/us-west1/forwardingRules { "name": "l7-ilb-forwarding-rule", "IPAddress": "IP_ADDRESS ", "IPProtocol": "TCP", "portRange": "80-80", "target": "projects/PROJECT_ID /regions/us-west1/targetHttpProxies/l7-ilb-proxy", "loadBalancingScheme": "INTERNAL_MANAGED", "subnetwork": "projects/PROJECT_ID /regions/us-west1/subnetworks/backend-subnet", "network": "projects/PROJECT_ID /global/networks/lb-network", "networkTier": "PREMIUM" }
HTTPS の場合:
Compute Engine または Certificate Manager の証明書を作成できます。Certificate Manager を使用して証明書を作成するには、次のいずれかの方法を使用します。
- リージョン セルフマネージド証明書。リージョン セルフマネージド証明書の作成と使用については、リージョン セルフマネージド証明書をデプロイするをご覧ください。証明書マップはサポートされていません。
リージョンの Google マネージド証明書。証明書マップはサポートされていません。
Certificate Manager では、次のタイプのリージョン Google マネージド証明書がサポートされています。
- プロジェクトごとの DNS 認証を使用するリージョン Google マネージド証明書。詳細については、リージョン Google マネージド証明書をデプロイするをご覧ください。
- Certificate Authority Service を使用するリージョン Google マネージド(プライベート)証明書。詳細については、CA Service を使用してリージョン Google マネージド証明書をデプロイするをご覧ください。
証明書を作成したら、証明書をターゲット プロキシに直接関連付けます。
証明書と秘密鍵ファイルを読み取り、SSL 証明書を作成します。次の例では、Python でこの処理を行います。
regionTargetHttpsProxies.insert
メソッドに POST
リクエストを送り、ターゲット HTTPS プロキシを作成します。PROJECT_ID
は、実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID /regions/us-west1/regionTargetHttpsProxy { "name": "l7-ilb-proxy", "urlMap": "projects/PROJECT_ID /regions/us-west1/urlMaps/l7-ilb-map", "sslCertificates": /projects/PROJECT_ID/regions/us-west1/sslCertificates/SSL_CERT_NAME }
forwardingRules.insert
メソッドに POST
リクエストを送り、転送ルールを作成します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID /regions/us-west1/forwardingRules { "name": "l7-ilb-forwarding-rule", "IPAddress": "IP_ADDRESS ", "IPProtocol": "TCP", "portRange": "80-80", "target": "projects/PROJECT_ID /regions/us-west1/targetHttpsProxies/l7-ilb-proxy", "loadBalancingScheme": "INTERNAL_MANAGED", "subnetwork": "projects/PROJECT_ID /regions/us-west1/subnetworks/backend-subnet", "network": "projects/PROJECT_ID /global/networks/lb-network", "networkTier": "PREMIUM", }
ロードバランサをテストする
ロードバランサをテストするには、クライアント VM を作成します。VM との SSH セッションを確立して、VM からロードバランサにトラフィックを送信します。
VM インスタンスを作成して接続をテストする
Google Cloud コンソールで [VM インスタンス] ページに移動します。
[インスタンスを作成] をクリックします。
[名前] を
l7-ilb-client-us-west1-a
に設定します。[ゾーン] を
us-west1-a
に設定します。[詳細オプション] をクリックします。
[ネットワーキング] をクリックして次のフィールドを構成します。
- [ネットワーク タグ] に「
allow-ssh
」と入力します。 - [ネットワーク インターフェース] で、次のように選択します。
- ネットワーク:
lb-network
- サブネット:
backend-subnet
- ネットワーク:
- [ネットワーク タグ] に「
[作成] をクリックします。
gcloud compute instances create l7-ilb-client-us-west1-a \ --image-family=debian-12 \ --image-project=debian-cloud \ --network=lb-network \ --subnet=backend-subnet \ --zone=us-west1-a \ --tags=allow-ssh
ロードバランサにトラフィックを送信する
作成したインスタンスにログインし、リージョン内部アプリケーション ロードバランサの転送ルールの IP アドレスを介してバックエンドの HTTP(S) サービスに到達可能であることと、バックエンド インスタンス間でトラフィックのロード バランシングが行われていることをテストします。
SSH を介して各クライアント インスタンスに接続する
gcloud compute ssh l7-ilb-client-us-west1-a \ --zone=us-west1-a
ロードバランサの IP アドレスを取得する
割り振られた IP アドレスを表示するには、gcloud compute addresses describe
コマンドを使用します。
gcloud compute addresses describe l7-ilb-ip-address \ --region=us-west1
IP アドレスがホスト名を提供していることを確認する
IP_ADDRESS は、ロードバランサの IP アドレスに置き換えます。
curlIP_ADDRESS
HTTPS テストの場合、curl
は次のもので置き換えます。
curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:IP_ADDRESS :443
-k
フラグを指定すると、curl は証明書の検証をスキップします。
100 個のリクエストを実行してロードバランスされていることを確認する
IP_ADDRESS は、ロードバランサの IP アドレスに置き換えます。
HTTP の場合:
{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl --silentIP_ADDRESS )" done echo "***" echo "*** Results of load-balancing: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
HTTPS の場合:
{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:IP_ADDRESS :443)" done echo "***" echo "*** Results of load-balancing: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
追加の構成オプション
このセクションでは、代替および追加の構成オプションを提供する構成例を示します。これらのタスクはすべて省略可です。また、任意の順序で行うことができます。
グローバル アクセスを有効にする
リージョン内部アプリケーション ロードバランサとリージョン内部プロキシ ネットワーク ロードバランサのグローバル アクセスを有効にして、すべてのリージョンのクライアントがアクセスできるようにします。サンプルのロードバランサのバックエンドは、引き続き 1 つのリージョン(us-west1
)に配置する必要があります。
既存のリージョン転送ルールを変更して、グローバル アクセスを有効にすることはできません。この目的のために新しい転送ルールを作成し、以前の転送ルールを削除する必要があります。また、グローバル アクセスを有効にして転送ルールを作成した後に、これを変更することはできません。グローバル アクセスを無効にするには、新しいリージョン アクセス転送ルールを作成し、以前のグローバル アクセス転送ルールを削除する必要があります。
グローバル アクセスを構成するには、次の変更を行います。
ロードバランサの転送ルールを新規作成します。
Google Cloud コンソールの [ロード バランシング] ページに移動します。
[名前] 列で、ロードバランサをクリックします。
[フロントエンドの構成] をクリックします。
[フロントエンド IP とポートの追加] をクリックします。
新しい転送ルールの名前とサブネットの詳細を入力します。
[サブネットワーク] で [backend-subnet] を選択します。
[IP アドレス] は、既存の転送ルールと同じ IP アドレスを選択するか、新しい IP アドレスを予約するか、エフェメラル IP アドレスを使用します。複数の転送ルールで同じ IP アドレスを使用するには、IP アドレスの作成時に IP アドレス
--purpose
フラグをSHARED_LOADBALANCER_VIP
に設定します。[ポート番号] に「
110
」と入力します。[グローバル アクセス] で [有効] を選択します。
[完了] をクリックします。
[更新] をクリックします。
--allow-global-access
フラグを使用してロードバランサの新しい転送ルールを作成します。HTTP の場合:
gcloud compute forwarding-rules create l7-ilb-forwarding-rule-global-access \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=10.1.2.99 \ --ports=80 \ --region=us-west1 \ --target-http-proxy=l7-ilb-proxy \ --target-http-proxy-region=us-west1 \ --allow-global-access
HTTPS の場合:
gcloud compute forwarding-rules create l7-ilb-forwarding-rule-global-access \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=10.1.2.99 \ --ports=443 \ --region=us-west1 \ --target-https-proxy=l7-ilb-proxy \ --target-https-proxy-region=us-west1 \ --allow-global-access
gcloud compute forwarding-rules describe
コマンドを使用すると、転送ルールでグローバル アクセスが有効になっているかどうかを確認できます。次に例を示します。gcloud compute forwarding-rules describe l7-ilb-forwarding-rule-global-access \ --region=us-west1 \ --format="get(name,region,allowGlobalAccess)"
グローバル アクセスが有効になっている場合、転送ルールの名前とリージョンの出力の後に
True
という単語が表示されます。
クライアント VM を作成してグローバル アクセスをテストする
Google Cloud コンソールで [VM インスタンス] ページに移動します。
[インスタンスを作成] をクリックします。
[名前] を
europe-client-vm
に設定します。[ゾーン] を
europe-west1-b
に設定します。[詳細オプション] をクリックします。
[ネットワーキング] をクリックして次のフィールドを構成します。
- [ネットワーク タグ] に「
allow-ssh
」と入力します。 - [ネットワーク インターフェース] で、次のように選択します。
- ネットワーク:
lb-network
- サブネット:
europe-subnet
- ネットワーク:
- [ネットワーク タグ] に「
[作成] をクリックします。
europe-west1-b
ゾーンにクライアント VM を作成します。
gcloud compute instances create europe-client-vm \ --zone=europe-west1-b \ --image-family=debian-12 \ --image-project=debian-cloud \ --tags=allow-ssh \ --subnet=europe-subnet
VM クライアントに接続して接続性をテストする
ssh
を使用してクライアント インスタンスに接続します。gcloud compute ssh europe-client-vm \ --zone=europe-west1-b
us-west1
リージョンのvm-client
からと同じように、ロードバランサへの接続をテストします。curl http://10.1.2.99
セッション アフィニティを有効にする
これらの手順は、バックエンド サービスが生成された Cookie アフィニティ、ヘッダー フィールド アフィニティ、HTTP Cookie アフィニティを使用できるように、サンプルのリージョン内部アプリケーション ロードバランサまたはクロスリージョン内部アプリケーション ロードバランサのバックエンド サービスを更新する方法を示しています。
生成された Cookie アフィニティが有効な場合、ロードバランサは最初のリクエストで Cookie を発行します。同じ Cookie を持つ後続のリクエストは、ロードバランサによって同じバックエンド仮想マシン(VM)インスタンスまたはエンドポイントに送信されます。この例では、Cookie の名前は GCILB
です。
ヘッダー フィールド アフィニティが有効になっている場合、ロードバランサは、--custom-request-header
フラグで指定された HTTP ヘッダーの値に基づいて、ネットワーク エンドポイント グループ(NEG)のバックエンド VM またはエンドポイントにリクエストをルーティングします。ヘッダー フィールド アフィニティは、ロード バランシングの局所性ポリシーが RING_HASH
または MAGLEV
であり、バックエンド サービスのコンシステント ハッシュが HTTP ヘッダーの名前を指定している場合にのみ有効です。
HTTP Cookie アフィニティが有効になっている場合、ロードバランサは、HTTP_COOKIE
フラグ(およびオプションの --affinity-cookie-ttl
フラグ)で指定された HTTP Cookie に基づいて、NEG のバックエンド VM またはエンドポイントにリクエストをルーティングします。クライアントが HTTP リクエストで Cookie を提供しない場合、プロキシは Cookie を生成し、それを Set-Cookie
ヘッダーでクライアントに返します。HTTP Cookie アフィニティは、ロード バランシングの局所性ポリシーが RING_HASH
または MAGLEV
であり、バックエンド サービスのコンシステント ハッシュが HTTP Cookie を指定している場合にのみ有効です。
バックエンド サービスのためのセッション アフィニティを有効化または変更するには、次に示す手順を行ってください。
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
- [バックエンド] をクリックします。
- l7-ilb-backend-service(この例で作成したバックエンド サービスの名前)をクリックし、[編集] をクリックします。
- [バックエンド サービスの詳細] ページで、[詳細構成] をクリックします。
- [セッション アフィニティ] で、必要なセッション アフィニティのタイプを選択します。
- [更新] をクリックします。
バックエンド サービスを別のタイプのセッション アフィニティに更新するには、次の Google Cloud CLI コマンドを使用します。
gcloud compute backend-services update l7-ilb-backend-service \ --session-affinity=[GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | CLIENT_IP] \ --region=us-west1
セッション アフィニティを設定するには、backendServices/patch
メソッドに PATCH リクエストを行います。
PATCH https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/regionBackendServices/l7-ilb-backend-service { "sessionAffinity": ["GENERATED_COOKIE" | "HEADER_FIELD" | "HTTP_COOKIE" | "CLIENT_IP" ] }
ロードバランサにトラフィックを送信できるクライアントを制限する
これらのクライアントで下り(外向き)ファイアウォール ルールを構成することで、クライアントが内部アプリケーション ロードバランサ転送ルール VIP に接続できないように制限できます。サービス アカウントまたはタグに基づいて、これらのファイアウォール ルールを特定のクライアント VM に設定します。
ファイアウォール ルールを使用して、インバウンド トラフィックを特定の内部アプリケーション ロードバランサ転送ルール VIP に制限することはできません。同じ VPC ネットワーク上で、転送ルール VIP と同じリージョンにあるクライアントは通常、転送ルール VIP にトラフィックを送信できます。
さらに、バックエンドへのすべてのリクエストは、プロキシ専用サブネットの範囲内の IP アドレスを使用するプロキシから送信されます。クライアントが使用する転送ルール VIP に基づいて、これらのバックエンドでの上り(内向き)トラフィックを許可または拒否するファイアウォール ルールを作成することはできません。
下り(外向き)ファイアウォール ルールを使用して、ロードバランサの転送ルール VIP へのトラフィックを制限する方法の例を次に示します。
クライアント VM を特定するには、制限する特定の VM にタグを付けます。これらのタグは、ファイアウォール ルールをタグ付けされたクライアント VM に関連付けるために使用されます。次の手順で TARGET_TAG
フィールドにタグを追加します。
これを行うには、単一のファイアウォール ルールまたは複数のルールを使用します。
単一の下り(外向き)ファイアウォール ルール
タグ付けされたクライアント VM からロードバランサの VIP へのすべての下り(外向き)トラフィックを拒否する 1 つの下り(外向き)ファイアウォール ルールを構成できます。
Google Cloud コンソールで [ファイアウォール ルール] ページに移動します。
[ファイアウォール ルールを作成] をクリックして、タグ付けされたクライアント VM からロードバランサの VIP への下り(外向き)トラフィックを拒否するルールを作成します。
- 名前:
fr-deny-access
- ネットワーク:
lb-network
- 優先度:
100
- トラフィックの方向: 下り(外向き)
- 一致したときのアクション: 拒否
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
TARGET_TAG
- 送信先フィルタ: IP 範囲
- 送信先 IP 範囲:
10.1.2.99
- プロトコルとポート:
- 指定されたプロトコルとポートを選択します。
- [tcp] チェックボックスをオンにして、ポート番号に「
80
」と入力します。
- 名前:
[作成] をクリックします。
複数の下り(外向き)ファイアウォール ルール
よりスケーラブルなアプローチでは 2 つのルールを設定します。デフォルトの優先度の低いルールは、すべてのクライアントによるロードバランサの VIP へのアクセスを制限します。2 番目の優先度の高いルールは、タグ付けされたクライアントのサブセットによるロードバランサの VIP へのアクセスを許可します。タグ付けされた VM のみが VIP にアクセスできます。
Google Cloud コンソールで [ファイアウォール ルール] ページに移動します。
[ファイアウォール ルールを作成] をクリックして、デフォルトでアクセスを拒否する優先度の低いルールを作成します。
- 名前:
fr-deny-all-access-low-priority
- ネットワーク:
lb-network
- 優先度:
200
- トラフィックの方向: 下り(外向き)
- 一致したときのアクション: 拒否
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
TARGET_TAG
- 送信先フィルタ: IP 範囲
- 送信先 IP 範囲:
10.1.2.99
- プロトコルとポート:
- 指定されたプロトコルとポートを選択します。
- [TCP] チェックボックスをオンにして、ポート番号に「
80
」と入力します。
- 名前:
[作成] をクリックします。
[ファイアウォール ルールを作成] をクリックして、特定のタグ付けされたインスタンスからのトラフィックを許可する優先度の高いルールを作成します。
- 名前:
fr-allow-some-access-high-priority
- ネットワーク:
lb-network
- 優先度:
100
- トラフィックの方向: 下り(外向き)
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
TARGET_TAG
- 送信先フィルタ: IP 範囲
- 送信先 IP 範囲:
10.1.2.99
- プロトコルとポート:
- 指定されたプロトコルとポートを選択します。
- [TCP] チェックボックスをオンにして、ポート番号に「
80
」と入力します。
- 名前:
[作成] をクリックします。
クライアント VM を特定するには、制限する特定の VM にタグを付けます。次に、これらの手順の TARGET_TAG
フィールドにタグを追加します。
これを行うには、単一のファイアウォール ルールまたは複数のルールを使用します。
単一の下り(外向き)ファイアウォール ルール
タグ付けされたクライアント VM からロードバランサの VIP へのすべての下り(外向き)トラフィックを拒否する 1 つの下り(外向き)ファイアウォール ルールを構成できます。
gcloud compute firewall-rules create fr-deny-access \ --network=lb-network \ --action=deny \ --direction=egress \ --rules=tcp \ --priority=100 \ --destination-ranges=10.1.2.99 \ --target-tags=TARGET_TAG
複数の下り(外向き)ファイアウォール ルール
よりスケーラブルなアプローチとして 2 つのルールを設定するという方法もあります。1 つのルールはデフォルトの優先度の低いルールで、すべてのクライアントに対してロードバランサの VIP へのアクセスを制限します。もう 1 つは優先度の高いルールで、タグ付きのクライアントのサブセットに対してロードバランサの VIP へのアクセスを許可します。タグ付けされた VM のみが VIP にアクセスできます。
優先度の低いルールを作成します。
gcloud compute firewall-rules create fr-deny-all-access-low-priority \ --network=lb-network \ --action=deny \ --direction=egress \ --rules=tcp \ --priority=200 \ --destination-ranges=10.1.2.99
優先度の高いルールを作成します。
gcloud compute firewall-rules create fr-allow-some-access-high-priority \ --network=lb-network \ --action=allow \ --direction=egress \ --rules=tcp \ --priority=100 \ --destination-ranges=10.1.2.99 \ --target-tags=
TARGET_TAG
タグの代わりにサービス アカウントを使用してアクセスを制御するには、ファイアウォール ルールの作成時に --target-tags
フラグの代わりに --target-service-accounts
オプションを使用します。
サブネットに基づく内部アプリケーション ロードバランサのバックエンドへのアクセス制限をスケーリングする
前のセクションで説明したように、転送ルールの数が増えるにつれ、個別のファイアウォール ルールの維持や、ロードバランスされた新しい IP アドレスの既存ルールへの追加が行いにくくなります。これを防ぐ 1 つの方法は、予約済みサブネットから転送ルールの IP アドレスを割り振ることです。タグ付けされたインスタンスまたはサービス アカウントからのトラフィックは、ファイアウォール ルールの宛先範囲として予約済みサブネットを使用することで、許可またはブロックできます。これにより、VIP ごとの下り(外向き)ファイアウォール ルールを維持しなくても、転送ルール VIP のグループへのアクセスを効果的に制御できます。
その他の必要なロードバランサ リソースをすべて個別に作成することを前提として、手順の概要は次のとおりです。
転送ルールに負荷分散された IP アドレスを割り振るために使用するリージョン サブネットを作成します。
gcloud compute networks subnets create l7-ilb-restricted-subnet \ --network=lb-network \ --region=us-west1 \ --range=10.127.0.0/24
サブネットからアドレスを取得する転送ルールを作成します。次の例では、前の手順で作成したサブネットのアドレス
10.127.0.1
を使用します。gcloud compute forwarding-rules create l7-ilb-forwarding-rule-restricted \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=l7-ilb-restricted-subnet \ --address=10.127.0.1 \ --ports=80 \ --region=us-west1 \ --target-http-proxy=l7-ilb-proxy \ --target-http-proxy-region=us-west1
転送ルールのサブネット(
l7-ilb-restricted-subnet
)内の IP アドレス範囲を宛先とするトラフィックを制限するファイアウォール ルールを作成します。gcloud compute firewall-rules create restrict-traffic-to-subnet \ --network=lb-network \ --action=deny \ --direction=egress \ --rules=tcp:80 \ --priority=100 \ --destination-ranges=10.127.0.0/24 \ --target-tags=
TARGET_TAG
バックエンドのサブセット化を構成する
バックエンドのサブセット化は、各プロキシ インスタンスにバックエンドのサブセットを割り当てることで、パフォーマンスとスケーラビリティを向上させます。バックエンド サービスに対して有効にすると、次のように、各プロキシ インスタンスが使用するバックエンドの数がバックエンドのサブネット化によって調整されます。
ロードバランサに参加するプロキシ インスタンスの数が増えると、サブセットのサイズは減少します。
ネットワーク内のバックエンドの合計数が単一のプロキシ インスタンスの容量を超えると、バックエンドのサブセット化が有効になっているサービスごとにサブセットのサイズが自動的に縮小されます。
この例では、リージョン内部アプリケーション ロードバランサリソースを作成し、バックエンドのサブセット化を有効にする方法を示しています。
- 構成例を使用して、リージョン バックエンド サービス
l7-ilb-backend-service
を作成します。 バックエンドのサブセット化を有効にするには、
--subsetting-policy
フラグをCONSISTENT_HASH_SUBSETTING
として指定します。ロード バランシング スキームをINTERNAL_MANAGED
に設定します。バックエンドのサブセット化で
l7-ilb-backend-service
を更新するには、次のgcloud
コマンドを使用します。gcloud beta compute backend-services update l7-ilb-backend-service \ --region=us-west1 \ --subsetting-policy=CONSISTENT_HASH_SUBSETTING
regionBackendServices/patch
メソッドにPATCH
リクエストを送信します。PATCH https://compute.googleapis.com/compute/beta/projects/
PROJECT_ID /regions/us-west1/backendServices/l7-ilb-backend-service { "subsetting": { "policy": CONSISTENT_HASH_SUBSETTING } }
localityLbPolicy
ポリシーを設定して、バックエンド ロード バランシングを調整することもできます。詳細については、トラフィック ポリシーをご覧ください。
複数の内部転送ルールで同じ IP アドレスを使用する
複数の内部転送ルールで同じ内部 IP アドレスを共有するには、IP アドレスを予約して --purpose
フラグを SHARED_LOADBALANCER_VIP
に設定する必要があります。
gcloud compute addresses createSHARED_IP_ADDRESS_NAME \ --region=REGION \ --subnet=SUBNET_NAME \ --purpose=SHARED_LOADBALANCER_VIP
クライアント HTTP キープアライブ タイムアウトを更新する
前の手順で作成したロードバランサは、クライアント HTTP キープアライブ タイムアウトのデフォルト値で構成されています。クライアントの HTTP キープアライブ タイムアウトを更新するには、次の操作を行います。
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
- 変更するロードバランサの名前をクリックします。
- [ 編集] をクリックします。
- [フロントエンドの構成] をクリックします。
- [高度な機能] を開きます。[HTTP キープアライブ タイムアウト] にタイムアウト値を入力します。
- [更新] をクリックします。
- 変更を確認するには、[確認と完了] をクリックして、[更新] をクリックします。
HTTP ロードバランサの場合は、gcloud compute target-http-proxies update
コマンドを使用してターゲット HTTP プロキシを更新します。
gcloud compute target-http-proxies updateTARGET_HTTP_PROXY_NAME \ --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \ --region=REGION
HTTPS ロードバランサの場合は、gcloud compute target-https-proxies update
コマンドを使用してターゲット HTTPS プロキシを更新します。
gcloud compute target-https-proxies updateTARGET_HTTP_PROXY_NAME \ --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \ --regionREGION
次のように置き換えます。
TARGET_HTTP_PROXY_NAME
: ターゲット HTTP プロキシの名前。TARGET_HTTPS_PROXY_NAME
: ターゲット HTTPS プロキシの名前。HTTP_KEEP_ALIVE_TIMEOUT_SEC
: HTTP キープアライブ タイムアウト値(5~600 秒)。
次のステップ
- アプリケーション ロードバランサを IPv6 に変換する
- リージョン内部アプリケーション ロードバランサの概要
- Envoy ベースのロードバランサ向けプロキシ専用サブネット
- セルフマネージド SSL 証明書の使用
- ロードバランサの設定をクリーンアップする