内部 HTTP(S) 負荷分散の設定

このドキュメントでは、Compute Engine VM で実行するサービス用の内部 HTTP(S) 負荷分散を構成する手順を説明します。

GKE Pod で実行するサービスのロード バランシングを構成するには、スタンドアロン NEG を使用したコンテナ ネイティブのロード バランシングと、内部 HTTP(S) ロードバランサをスタンドアロン NEG に接続するのセクションをご覧ください。

Private Service Connect を使用して Google API とサービスにアクセスできるようにロード バランシングを構成するには、コンシューマ HTTP(S) サービス コントロールを使用した Private Service Connect の構成をご覧ください。

内部 HTTP(S) ロード バランシングの設定は、次の 2 つの部分に分かれます。

  • 前提となる作業を行う(必要なアカウントに適切な権限を付与し、Virtual Private Cloud(VPC)ネットワークを準備するなど)。
  • ロードバランサのリソースを設定する。

このガイドに進む前に、次の内容を理解しておいてください。

権限

このガイドに従うには、プロジェクト内でインスタンスを作成してネットワークを変更できる必要があります。そのためにはプロジェクトのオーナーまたは編集者であるか、または次の Compute Engine IAM のロールをすべて持っている必要があります。

タスク 必要なロール
ネットワーク、サブネット、負荷分散コンポーネントの作成 ネットワーク管理者
ファイアウォール ルールの追加と削除 セキュリティ管理者
インスタンスの作成 インスタンス管理者

詳細については、次のガイドをご覧ください。

設定の概要

内部 HTTP(S) 負荷分散は、次のような構成フローで構成できます。図の中で番号の付いている項目については、図の後で簡単に説明します。

内部 HTTP(S) 負荷分散のコンポーネント - 番号付き(クリックして拡大)
内部 HTTP(S) 負荷分散のコンポーネント - 番号付き(クリックして拡大)

この例では、1 つのバックエンド サービスと 2 つのバックエンド グループがある us-west1 リージョンの VPC ネットワークに、内部 HTTP(S) ロードバランサを作成しています。

この図は次のことを示しています。

  1. 2 つのサブネットがある VPC ネットワーク:

    1. サブネットの 1 つは、バックエンド(インスタンス グループと NEG)と転送ルールに使用されます。プライマリ IP アドレスの範囲は 10.1.2.0/24 です。

    2. もう 1 つのサブネットは、us-west1 リージョンのプロキシ専用サブネットです。内部 HTTP(S) ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを 1 つ作成する必要があります。リージョンのプロキシ専用サブネットは、リージョン内のすべての内部 HTTP(S) ロードバランサで共有されます。内部 HTTP(S) ロードバランサからサービスのバックエンドに送信されるパケットのソースアドレスは、プロキシ専用サブネットから割り当てられます。この例では、リージョンのプロキシ専用サブネットのプライマリ IP アドレスの範囲は 10.129.0.0/23 であり、これが推奨サブネット サイズです。詳細については、内部 HTTP(S) ロードバランサのプロキシ専用サブネットをご覧ください。

  2. ネットワーク内のプロキシ専用サブネット トラフィック フローを許可するファイアウォール ルール。10.129.0.0/23(この例ではプロキシ専用サブネットの範囲)からの TCP ポート 804438080 トラフィックを許可する 1 つのルールが追加されることになります。ヘルスチェック プローブ用の別のファイアウォール ルール。

  3. バックエンド インスタンス。この図の例では、次のバックエンドをデプロイしています。

    1. Compute Engine VM
    2. スタンドアロン ネットワーク エンドポイント グループ(NEG)に追加された Google Kubernetes Engine(GKE)バックエンド
  4. インスタンス グループと NEG:

    1. Compute Engine VM デプロイのマネージド インスタンス グループまたは非マネージド インスタンス グループ
    2. GKE デプロイの NEG

    各ゾーンで、デプロイ要件に基づいてバックエンド グループタイプを組み合わせることができます。

  5. バックエンドの準備状況を報告するリージョン ヘルスチェック。

  6. バックエンドの使用状況と健全性をモニタリングするリージョン バックエンド サービス。

  7. リージョン URL マップはリクエストの URL を解析し、リクエスト URL のホストとパスに基づいて特定のバックエンド サービスにリクエストを転送します。

  8. リージョン ターゲット HTTP または HTTPS プロキシ。ユーザーからリクエストを受け取り、URL マップに転送します。HTTPS の場合、リージョン SSL 証明書リソースを構成します。HTTPS 負荷分散を構成する場合、ターゲット プロキシは SSL 証明書を使用して SSL トラフィックを復号します。ターゲット プロキシは、HTTP または HTTPS を使用してトラフィックをインスタンスに転送できます。

  9. ロードバランサの内部 IP アドレスを含む転送ルール。受信リクエストをターゲット プロキシに転送します。

    転送ルールに関連付けられた内部 IP アドレス。--purpose フラグが PRIVATE に設定されている任意の(同じネットワークとリージョンにある)サブネットから取得できます。次のことに注意してください。

    • IP アドレスは、バックエンド インスタンス グループと同じサブネットから取得できます(必須ではありません)。
    • IP アドレスは、--purpose フラグが INTERNAL_HTTPS_LOAD_BALANCER に設定されている予約済みプロキシ専用サブネットからは取得しないでください。

ネットワークとサブネットの構成

ロードバランサのバックエンド用とロードバランサのプロキシ用の 2 つのサブネットが存在する VPC ネットワークが必要です。内部 HTTP(S) ロードバランサはリージョンです。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 を使用します。

バックエンドのネットワークとサブネットの構成

Console

  1. Google Cloud Console で [VPC ネットワーク] ページに移動します。
    [VPC ネットワーク] ページに移動
  2. [VPC ネットワークを作成] をクリックします。
  3. [名前] に「lb-network」と入力します。
  4. [サブネット] セクションで次の設定を行います。
    • [サブネット作成モード] を [カスタム] に設定します。
    • [新しいサブネット] セクションに、次の情報を入力します。
      • 名前: backend-subnet
      • リージョン: us-west1
      • IP アドレス範囲: 10.1.2.0/24
    • [完了] をクリックします。
  5. [作成] をクリックします。

gcloud

  1. gcloud compute networks create コマンドを使用してカスタム VPC ネットワークを作成します。

    gcloud compute networks create lb-network --subnet-mode=custom
    
  2. 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
    

API

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",
}

プロキシ専用サブネットの構成

このプロキシ専用サブネットは、us-west1 リージョン内のすべての内部 HTTP(S) ロードバランサのためのサブネットです。

Console

Google Cloud Console を使用している場合は、しばらく待ってから、負荷分散ページでプロキシ専用サブネットを作成できます。

gcloud

gcloud compute networks subnets create コマンドを使用して、プロキシ専用サブネットを作成します。

gcloud compute networks subnets create proxy-only-subnet \
  --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
  --role=ACTIVE \
  --region=us-west1 \
  --network=lb-network \
  --range=10.129.0.0/23

API

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": "INTERNAL_HTTPS_LOAD_BALANCER",
  "role": "ACTIVE"
}

ファイアウォール ルールの構成

この例では、次のファイアウォール ルールを使用します。

  • fw-allow-ssh負荷分散されたインスタンスに適用される内向きルール。任意のアドレスから TCP ポート 22 への SSH 接続を許可します。このルールには、送信元の IP 範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲を指定できます。この例では、ターゲットタグ allow-ssh を使用しています。

  • fw-allow-health-check負荷分散されているインスタンスに適用される上り(内向き)ルール。Google Cloud ヘルスチェック システム(130.211.0.0/2235.191.0.0/16)からのすべての TCP トラフィックを許可します。この例では、ターゲットタグ load-balanced-backend を使用しています。

  • fw-allow-proxies負荷分散されているインスタンスに適用される上り(内向き)ルール。内部 HTTP(S) ロードバランサが管理するプロキシからポート 804438080 への TCP トラフィックを許可します。この例では、ターゲットタグ load-balanced-backend を使用しています。

これらのファイアウォール ルールがない場合は、デフォルトの上り拒否ルールによってバックエンド インスタンスへの受信トラフィックがブロックされます。

ターゲットタグは、バックエンド インスタンスを定義します。ターゲットタグがない場合、ファイアウォール ルールは VPC ネットワーク内のすべてのバックエンド インスタンスに適用されます。バックエンド VM を作成する場合は、マネージド インスタンス グループの作成の説明に沿って、指定したターゲットタグを忘れずに含めてください。

Console

  1. Google Cloud Console の [ファイアウォール ルール] ページに移動します。
    [ファイアウォール ルール] ページに移動
  2. [ファイアウォール ルールを作成] をクリックして、SSH 接続の受信を許可するルールを作成します。
    • 名前: fw-allow-ssh
    • ネットワーク: lb-network
    • トラフィックの方向: 上り(内向き)
    • 一致したときのアクション: 許可
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: allow-ssh
    • ソースフィルタ: IPv4 の範囲
    • 送信元 IPv4 範囲: 0.0.0.0/0
    • プロトコルとポート:
      • 指定されたプロトコルとポートを選択します。
      • [tcp] チェックボックスをオンにして、ポート番号に「22」と入力します。
  3. [作成] をクリックします。
  4. [ファイアウォール ルールを作成] をもう一度クリックして、Google Cloud ヘルスチェックを許可するルールを作成します。
    • 名前: fw-allow-health-check
    • ネットワーク: lb-network
    • トラフィックの方向: 上り(内向き)
    • 一致したときのアクション: 許可
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: load-balanced-backend
    • ソースフィルタ: IPv4 の範囲
    • 送信元 IPv4 範囲: 130.211.0.0/2235.191.0.0/16
    • プロトコルとポート:
      • 指定されたプロトコルとポートを選択します。
      • [tcp] チェックボックスをオンにして、ポート番号に「80」と入力します。
        このルールは、ヘルスチェックに使用されているプロトコルとポートのみに制限することをおすすめします。プロトコルとポートに tcp:80 を使用すると、Google Cloud はポート 80 で HTTP を使用して VM に接続できますが、ポート 443 では HTTPS を使用して VM に接続することはできません。
  5. [作成] をクリックします。
  6. [ファイアウォール ルールを作成] をもう一度クリックをして、ロードバランサのプロキシ サーバーがバックエンドに接続できるようにするルールを作成します:
    • 名前: fw-allow-proxies
    • ネットワーク: lb-network
    • トラフィックの方向: 上り(内向き)
    • 一致したときのアクション: 許可
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: load-balanced-backend
    • ソースフィルタ: IPv4 の範囲
    • 送信元 IPv4 範囲: 10.129.0.0/23
    • プロトコルとポート:
      • 指定されたプロトコルとポートを選択します。
      • [tcp] チェックボックスをオンにして、ポート番号に「80, 443, 8080」と入力します。
  7. [作成] をクリックします。

gcloud

  1. ネットワーク タグ 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
    
  2. 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
    
  3. 内部 HTTP(S) ロードバランサのプロキシにバックエンドへの接続を許可する 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
    

API

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"
}

VM ベースのサービスを使用した内部 HTTP(S) ロード バランシングの構成

このセクションでは、Compute Engine VM 上で実行されるサービスに必要な構成について説明します。クライアント VM は、転送ルールで構成した IP アドレスとポートに接続されます。クライアント アプリケーションがこの IP アドレスとポートにトラフィックを送信すると、内部 HTTP(S) ロードバランサの URL マップに従ってバックエンド仮想マシン(VM)にリクエストが転送されます。

この例では、エフェメラル内部 IP アドレスの割り当てを許可せずに、内部 HTTP(S) ロードバランサの転送ルールに予約済み内部 IP アドレスを明示的に設定しています。転送ルールの IP アドレスは予約しておくことをおすすめします。

転送ルールの IP アドレスには、backend-subnet を使用します。プロキシ専用サブネットを使用すると、転送ルールの作成に失敗します。

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

このセクションでは、テンプレートとマネージド インスタンス グループの作成方法を説明します。このマネージド インスタンス グループに VM インスタンスを作成し、内部 HTTP(S) ロードバランサのバックエンド サーバーを実行します。クライアントからのトラフィックは、これらのバックエンド サーバーに負荷分散されます。わかりやすく説明するために、バックエンド サーバーはそれぞれ独自のホスト名を提供します。

Cloud Console

  1. Cloud Console の [インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. [インスタンス グループを作成] をクリックします。
  3. 左側の [新しいマネージド インスタンス グループ] を選択します。
  4. [名前] に「l7-ilb-backend-example」と入力します。
  5. [ロケーション] で [シングルゾーン] を選択します。
  6. [リージョン] で us-west1 を選択します。
  7. [ゾーン] で us-west1-a を選択します。
  8. [インスタンス テンプレート] で [新しいインスタンス テンプレートを作成] を選択します。

    1. [名前] に「l7-ilb-backend-template」と入力します。
    2. [ブートディスク] が Debian GNU/Linux 9 (stretch) などの Debian イメージに設定されていることを確認します。以降の手順では、apt-get などの Debian でのみ使用できるコマンドを使用します。
    3. [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] の [管理] タブで、次のスクリプトを [起動スクリプト] フィールドに挿入します。

      #! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      vm_hostname="$(curl -H "Metadata-Flavor:Google" \
      http://169.254.169.254/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2'
      
    4. [ネットワーキング] で、[ネットワーク] に lb-network を選択し、[サブネット] に backend-subnet を選択します。

    5. ネットワーク タグ allow-sshload-balanced-backend を追加します。

    6. [保存して次へ] をクリックします。

  9. グループ内に作成するインスタンスの数を指定します。

    この例では、[自動スケーリング モード] から次の項目を選択できます。

    • 自動スケーリングを構成しない
    • [インスタンス数] に 2 を入力します。

    オプションとして、UI の [自動スケーリング] セクションで、インスタンスの CPU 使用率に基づいてインスタンスを自動的に追加または削除するようにインスタンス グループを構成できます。

  10. [作成] をクリックして、新しいインスタンス グループを作成します。

gcloud

このガイドの gcloud の手順は、Cloud Shell または bash がインストールされた別の環境を使用していることを前提としています。

  1. 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-9 \
    --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://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'
    
  2. 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
    

API

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\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\necho \"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-9"
         },
         "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(S) ロードバランサのリソースを作成する方法について説明します。

  • HTTP ヘルスチェック
  • マネージド インスタンス グループをバックエンドとして使用するバックエンド サービス
  • URL マップ
    • リージョンがターゲット HTTP(S) プロキシに定義されている場合は、必ずリージョン URL マップを参照してください。リージョン URL マップは、受信 URL のホストとパスに定義したルールに基づいて、リクエストをリージョン バックエンド サービスにルーティングします。リージョン URL マップを参照できるのは、同じリージョン内のリージョン ターゲット プロキシのルールのみです。
  • SSL 証明書(HTTPS の場合)
  • ターゲット プロキシ
  • 転送ルール

転送ルールの IP アドレスには、backend-subnet を使用します。プロキシ専用サブネットを使用すると、転送ルールの作成に失敗します。

プロキシの可用性

Google Cloud リージョンによっては、新しいリージョン ロードバランサに対応するのに十分なプロキシ容量がない場合があります。その場合、ロードバランサの作成時に Cloud Console でプロキシの可用性に関する警告メッセージが表示されます。この問題を解決するには、次のいずれかを行います。

  • ロードバランサに別のリージョンを選択します。これは、別のリージョンにバックエンドがある場合には現実的な選択肢となります。
  • プロキシ専用サブネットがすでに割り当てられている VPC ネットワークを選択します。
  • 容量の問題が解決するまで待ちます。

Cloud Console

ロードバランサ タイプの選択

  1. Google Cloud Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. [HTTP(S) 負荷分散] で [設定を開始] をクリックします。
  3. [VM 間のみ] を選択します。この設定は、ロードバランサが内部であることを意味します。
  4. [続行] をクリックします。

ロードバランサの準備

  1. ロードバランサの [名前] に「l7-ilb-map」と入力します。
  2. [リージョン] で us-west1 を選択します。
  3. [ネットワーク] で lb-network を選択します。
  4. ウィンドウを開いたままにして続行します。

プロキシ専用サブネットの予約

内部 HTTP(S) 負荷分散の場合は、プロキシ専用サブネットを予約します。

  1. [サブネットの予約] をクリックします。
  2. [名前] に「proxy-only-subnet」と入力します。
  3. [IP アドレス範囲] に「10.129.0.0/23」と入力します。
  4. [追加] をクリックします。

バックエンド サービスの構成

  1. [バックエンドの設定] をクリックします。
  2. [バックエンド サービスの作成または選択] メニューから [バックエンド サービスを作成] を選択します。
  3. バックエンド サービスの [名前] を l7-ilb-backend-service に設定します。
  4. [バックエンド タイプ] をインスタンス グループ設定します。
  5. [新しいバックエンド] セクションで、次の操作を行います。
    1. [インスタンス グループ] を l7-ilb-backend-example に設定します。
    2. [ポート番号] を 80 に設定します。
    3. [分散モード] を Utilization に設定します。
    4. [完了] をクリックします。
  6. [ヘルスチェック] セクションで、[ヘルスチェックを作成] を選択し、次のパラメータを選択します。
    1. 名前: l7-ilb-basic-check
    2. プロトコル: HTTP
    3. ポート: 80
    4. [保存して次へ] をクリックします。
  7. [作成] をクリックします。

URL マップの構成

[ホストとパスのルール] をクリックします。l7-ilb-backend-service が、ホストまたはパスが一致しない場合に使用される唯一のバックエンド サービスであることを確認します。

トラフィック管理の詳細については、トラフィック管理の設定をご覧ください。

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

HTTP の場合:

  1. [フロントエンドの設定] をクリックします。
  2. [フロントエンド IP とポートの追加] をクリックします。
  3. [名前] を l7-ilb-forwarding-rule に設定します。
  4. [プロトコル] を HTTP に設定します。
  5. [サブネットワーク] を backend-subnet に設定します。
  6. [内部 IP] で [静的内部 IP アドレスの予約] を選択します。
  7. 表示されるパネルで、次の情報を入力します。
    1. 名前: l7-ilb-ip
    2. [静的 IP アドレス] セクションで、[ユーザー選択] を選択します。
    3. [カスタム IP アドレス] セクションに「10.1.2.99」と入力します。
    4. [予約] をクリックします。
  8. [ポート] を 80 に設定します。
  9. [完了] をクリックします。

HTTPS の場合:

クライアントとロードバランサ間で HTTPS を使用する場合は、プロキシを構成するために 1 つ以上の SSL 証明書リソースが必要になります。SSL 証明書リソースの作成方法については、SSL 証明書をご覧ください。現在、内部 HTTP(S) ロードバランサでは Google マネージド証明書がサポートされません。

  1. [フロントエンドの設定] をクリックします。
  2. [フロントエンド IP とポートの追加] をクリックします。
  3. [名前] フィールドに「l7-ilb-forwarding-rule」と入力します。
  4. [プロトコル] フィールドで HTTPS (includes HTTP/2) を選択します。
  5. [サブネットワーク] を backend-subnet に設定します。
  6. [内部 IP] で [静的内部 IP アドレスの予約] を選択します。
  7. 表示されるパネルで、次の情報を入力します。
    1. 名前: l7-ilb-ip
    2. [静的 IP アドレス] セクションで、[ユーザー選択] を選択します。
    3. [カスタム IP アドレス] セクションに「10.1.2.99」と入力します。
    4. [予約] をクリックします。
  8. HTTPS トラフィックを許可するように、ポート443 に設定されていることを確認します。
  9. [証明書] プルダウン リストをクリックします。
    1. プライマリ SSL 証明書として使用しようとしているセルフマネージド SSL 証明書リソースがすでにある場合は、プルダウン メニューから選択します。
    2. そうでない場合は、[新しい証明書を作成] を選択します。
      1. [名前] に「l7-ilb-cert」と入力します。
      2. 該当するフィールドに PEM 形式のファイルをアップロードします。
        • 公開鍵証明書
        • 証明書チェーン
        • 秘密鍵
      3. [作成] をクリックします。
  10. プライマリ SSL 証明書リソースに加えて証明書リソースを追加するには、次の手順に沿って操作します。
    1. [証明書を追加] をクリックします。
    2. [証明書] リストから証明書を選択するか、[新しい証明書の作成] をクリックし、上記の手順を行います。
  11. [完了] をクリックします。

構成の完了

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

gcloud

  1. gcloud compute health-checks create http コマンドを使用して HTTP ヘルスチェックを定義します。

    gcloud compute health-checks create http l7-ilb-basic-check \
       --region=us-west1 \
       --use-serving-port
    
  2. 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
    
  3. 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
    
  4. gcloud compute url-maps create コマンドを使用して、URL マップを作成します。

    gcloud compute url-maps create l7-ilb-map \
      --default-service=l7-ilb-backend-service \
      --region=us-west1
    
  5. ターゲット プロキシを作成します。

    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 の場合:

    SSL 証明書リソースの作成方法については、SSL 証明書をご覧ください。現在、内部 HTTP(S) ロードバランサでは Google マネージド証明書がサポートされません。

    ファイルパスを変数名に割り当てます。

    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
    
  6. 転送ルールを作成します。

    カスタム ネットワークでは、転送ルールでサブネットを参照する必要があります。このサブネットは、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=10.1.2.99 \
      --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=10.1.2.99 \
      --ports=443 \
      --region=us-west1 \
      --target-https-proxy=l7-ilb-proxy \
      --target-https-proxy-region=us-west1
    

API

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": "10.1.2.99",
"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 の場合:

証明書と秘密鍵ファイルを読み取り、SSL 証明書を作成します。次の例では、Python でこの処理を行います。

from pprint import pprint
from googleapiclient import discovery
from oauth2client.client import GoogleCredentials
credentials = GoogleCredentials.get_application_default()
service = discovery.build('compute', 'v1', credentials=credentials)

# Project ID for this request

project = 'PROJECT_ID'

# Region for this request

region = 'REGION'

# Read the cert into memory

with open('CERTIFICATE_FILE') as f:
    _temp_cert = f.read()
f.close()

# Read the private_key into memory

with open('PRIVATE_KEY_FILE') as f:
    _temp_key = f.read()
f.close()

# Now that the certificate and private key are in memory, you can create the
# certificate resource

ssl_certificate_body = {  # "selfLink": string,
                          # cert,
                          # private_key,
    'name': 'CERTIFICATE_NAME',
    'description': 'creating new lb ssl cert',
    'certificate': _temp_cert,
    'privateKey': _temp_key,
    }
request = service.regionSslCertificates().insert(project=project,region=region,
        body=ssl_certificate_body)
response = request.execute()
pprint(response)

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": "10.1.2.99",
"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 インスタンスを作成して接続をテストする

gcloud compute instances create l7-ilb-client-us-west1-a \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --network=lb-network \
    --subnet=backend-subnet \
    --zone=us-west1-a \
    --tags=allow-ssh

ロードバランサをテストする

作成したインスタンスにログインし、内部 HTTP(S) ロードバランサの転送ルールの IP アドレスを介してバックエンドの HTTP(S) サービスに到達可能であること、バックエンド インスタンス間でトラフィックの負荷分散が行われていることをテストします。

各クライアント インスタンスへ SSH を介して接続する

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

IP がホスト名を提供していることを確認する

curl 10.1.2.99

HTTPS テストの場合、curl は次のもので置き換えます。

curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443

-k フラグを指定すると、curl は証明書の検証をスキップします。

100 個のリクエストを実行し負荷分散されていることを確認する

HTTP の場合:

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl --silent 10.1.2.99)"
  done
  echo "***"
  echo "*** Results of load-balancing to 10.1.2.99: "
  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:10.1.2.99:443)"
  done
  echo "***"
  echo "*** Results of load-balancing to 10.1.2.99: "
  echo "***"
  echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
  echo
}

追加の構成オプション

このセクションでは、代替および追加の構成オプションを提供する構成例を示します。これらのタスクはすべて省略可です。これらは任意の順序で実行できます。

セッション アフィニティを有効にする

これらの手順は、バックエンド サービスが生成された Cookie アフィニティ、ヘッダー フィールド アフィニティ、HTTP Cookie アフィニティを使用するように、サンプルの内部 HTTP(S) ロードバランサのバックエンド サービスを更新する方法を示しています。

生成された Cookie アフィニティが有効な場合、ロードバランサは最初のリクエストで Cookie を発行します。同じ Cookie を持つ後続のリクエストは、ロードバランサによって同じバックエンド VM またはエンドポイントに送信されます。内部 HTTP(S) ロードバランサの場合、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 を指定している場合にのみ有効です。

Cloud Console

バックエンド サービスのためのセッション アフィニティを有効化または変更するには、次に示す手順を行ってください。

  1. Google Cloud Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. [バックエンド] をクリックします。
  3. l7-ilb-backend-service(この例で作成したバックエンド サービスの名前)をクリックし、[編集] をクリックします。
  4. [バックエンド サービスの詳細] ページで、[詳細構成] をクリックします。
  5. [セッション アフィニティ] で、必要なセッション アフィニティのタイプをメニューから選択します。
  6. [更新] をクリックします。

gcloud

次の gcloud コマンドを使用して、l7-ilb-backend-service バックエンド サービスをさまざまなタイプのセッション アフィニティに更新します。

gcloud compute backend-services update l7-ilb-backend-service \
    --session-affinity=[GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | CLIENT_IP]
    --region=us-west1

API

セッション アフィニティを設定するには、regionBackendServices/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" ] }

ロードバランサにトラフィックを送信できるクライアントを制限する

これらのクライアントに下り(外向き)ファイアウォール ルールを構成することで、クライアントが内部 HTTP(S) ロードバランサ転送ルール VIP と通信できないように制限できます。サービス アカウントまたはタグに基づいて、これらのファイアウォール ルールを特定のクライアント VM に設定します。

ファイアウォール ルールを使用して、受信トラフィックを特定の内部 HTTP(S) ロードバランサ転送ルール VIP に制限することはできません。同じ VPC ネットワーク上で、転送ルール VIP と同じリージョンにあるクライアントは通常、転送ルール VIP にトラフィックを送信できます。

さらに、バックエンドへのすべてのリクエストは、プロキシ専用サブネットの範囲内の IP アドレスを使用するプロキシから送信されます。クライアントが使用する転送ルール VIP に基づいて、これらのバックエンドでの上り(内向き)トラフィックを許可または拒否するファイアウォール ルールを作成することはできません。

下り(外向き)ファイアウォール ルールを使用して、ロードバランサの転送ルール VIP へのトラフィックを制限する方法の例を次に示します。

Console

クライアント VM を特定するには、制限する特定の VM にタグを付ける必要があります。これらのタグは、ファイアウォール ルールをタグ付けされたクライアント VM に関連付けるために使用されます。次に、これらの手順の TARGET_TAG フィールドにタグを追加します。

これを行うには、単一のファイアウォール ルールまたは複数のルールを使用します。

単一の下り(外向き)ファイアウォール ルール

タグ付けされたクライアント VM からロードバランサの VIP へのすべての下り(外向き)トラフィックを拒否する 1 つの下りファイアウォール ルールを構成できます。

  1. Google Cloud Console の [ファイアウォール ルール] ページに移動します。
    [ファイアウォール ルール] ページに移動
  2. [ファイアウォール ルールを作成] をクリックして、タグ付けされたクライアント VM からロードバランサの VIP への下り(外向き)トラフィックを拒否するルールを作成します。
    • 名前: fr-deny-access
    • ネットワーク: lb-network
    • 優先度: 100
    • トラフィックの方向: 下り(外向き)
    • 一致したときのアクション: 拒否
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: TARGET_TAG
    • 送信先フィルタ: IP 範囲
    • 送信先 IP 範囲: 10.1.2.99
    • プロトコルとポート:
      • 指定されたプロトコルとポートを選択します。
      • [tcp] チェックボックスをオンにして、ポート番号に「80」と入力します。
  3. [作成] をクリックします。

複数の下り(外向き)ファイアウォール ルール

よりスケーラブルなアプローチでは 2 つのルールを設定します。デフォルトの優先度の低いルールは、すべてのクライアントによるロードバランサの VIP へのアクセスを制限します。2 番目の優先度の高いルールは、タグ付けされたクライアントのサブセットによるロードバランサの VIP へのアクセスを許可します。タグ付けされた VM のみが VIP にアクセスできます。

  1. Google Cloud Console の [ファイアウォール ルール] ページに移動します。
    [ファイアウォール ルール] ページに移動
  2. [ファイアウォール ルールを作成] をクリックして、デフォルトでアクセスを拒否する優先度の低いルールを作成します。
    • 名前: fr-deny-all-access-low-priority
    • ネットワーク: lb-network
    • 優先度: 200
    • トラフィックの方向: 下り(外向き)
    • 一致したときのアクション: 拒否
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: TARGET_TAG
    • 送信先フィルタ: IP 範囲
    • 送信先 IP 範囲: 10.1.2.99
    • プロトコルとポート:
      • 指定されたプロトコルとポートを選択します。
      • [tcp] チェックボックスをオンにして、ポート番号に「80」と入力します。
  3. [作成] をクリックします。
  4. [ファイアウォール ルールを作成] をクリックして、特定のタグ付けされたインスタンスからのトラフィックを許可する優先度の高いルールを作成します。
    • 名前: fr-allow-some-access-high-priority
    • ネットワーク: lb-network
    • 優先度: 100
    • トラフィックの方向: 下り(外向き)
    • 一致したときのアクション: 許可
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: TARGET_TAG
    • 送信先フィルタ: IP 範囲
    • 送信先 IP 範囲: 10.1.2.99
    • プロトコルとポート:
      • 指定されたプロトコルとポートを選択します。
      • [tcp] チェックボックスをオンにして、ポート番号に「80」と入力します。
  5. [作成] をクリックします。

gcloud

クライアント 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 つのルールを設定します。デフォルトの優先度の低いルールは、すべてのクライアントによるロードバランサの VIP へのアクセスを制限します。2 番目の優先度の高いルールは、タグ付けされたクライアントのサブセットによるロードバランサの VIP へのアクセスを許可します。タグ付けされた VM のみが VIP にアクセスできます。

  1. 優先度の低いルールを作成します。

    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
    
  2. 優先度の高いルールを作成します。

    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 を使用します。

サブネットに基づく内部 HTTP(S) ロードバランサのバックエンドへのアクセス制限をスケーリングする

前のセクションで説明したように、転送ルールの数が増えるにつれ、個別のファイアウォール ルールの維持や、既存のルールへの新しい負荷分散 IP の追加を行いにくくなります。これを防ぐ 1 つの方法は、予約済みサブネットから転送ルールの IP アドレスを割り振ることです。タグ付けされたインスタンスまたはサービス アカウントからのトラフィックは、ファイアウォール ルールの宛先範囲として予約済みサブネットを使用することで、許可またはブロックできます。これにより、VIP ごとの下り(外向き)ファイアウォール ルールを維持しなくても、転送ルール VIP のグループへのアクセスを効果的に制御できます。

その他の必要なロードバランサ リソースをすべて個別に作成することを前提として、手順の概要は次のとおりです。

gcloud

  1. 転送ルールに負荷分散された IP アドレスを割り振るために使用するリージョン サブネットを作成します。

    gcloud compute networks subnets create l7-ilb-restricted-subnet \
      --network=lb-network \
      --region=us-west1 \
      --range=10.127.0.0/24
    
  2. 新しく割り当てられたサブネットからアドレスを取得する転送ルールを作成します。この例では、前の手順で作成したサブネットから 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
    
  3. 転送ルールのサブネット(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
    

次のステップ