従来のマルチリージョン アプリケーション ロードバランサへのリクエストの転送

このガイドでは、次のような処理を行う Google Cloud HTTPS ロードバランサを作成する方法を示します。

  • リクエストの URL パスに基づいてバックエンド サービスを選択する。
  • クライアントに近いバックエンドにリクエストを転送する(マルチリージョンのロード バランシング)。

始める前に、外部アプリケーション ロードバランサのコンセプトを理解してください。

簡単な例については、Compute Engine バックエンドを使用した外部アプリケーション ロードバランサの設定をご覧ください。HTTP の書き換えやリダイレクトなどの高度なルーティングについては、外部アプリケーション ロードバランサのトラフィック管理をご覧ください。

概要

このガイドでは、リクエスト URL のパスに基づいてトラフィックを転送し、トラフィックを複数のリージョンに分散するロードバランサを作成する手順について説明します。ここでは、米国のリージョン(us-central1-b ゾーン)と欧州のリージョン(eu-west1-b ゾーン)に、合計 8 つの Compute Engine インスタンスを作成します。次に、これらのインスタンスにトラフィックをルーティングするロードバランサを作成します。

手順を完了すると、ロードバランサは次のような構成になります。

  • /video で始まる URL パスを含むトラフィックは、1 つのバックエンド サービスにルーティングされます。
  • このパターンと一致しない URL パスを含むトラフィックは、別のバックエンド サービスにルーティングされます。

このご利用方法についてのドキュメントでは、次の図に示す構成を作成します。

マルチリージョンの HTTPS 負荷分散(クリックして拡大)
マルチリージョンの HTTPS 負荷分散(クリックして拡大)

この図のイベントの順序は次のとおりです。

  1. クライアントが https://www.example.com/video/concert という URL にアクセスして、転送ルールで定義された外部 IP アドレスにコンテンツのリクエストを送信します。 リクエストでは、IPv4 または IPv6 を使用できます。両方のプロトコルの転送ルールがあります。
  2. 転送ルールによって、リクエストがターゲット HTTPS プロキシに転送されます。
  3. ターゲット プロキシは、URL マップで設定されたルールを使用して、リクエストを受信するバックエンド サービスを決定します。/video を含むリクエスト(https://www.example.com/video/concert など)が video-backend-service に送信されます。その他の URL パスは、デフォルトのサービス web-backend-service に送信されます。
  4. ロードバランサは、クライアントの負荷や近さに基づいて、リクエストを処理するバックエンド サービスのインスタンス グループを決定し、そのグループに属するインスタンスの 1 つにリクエストを送信します。
  5. その結果、そのインスタンスによって、各ユーザーが要求したコンテンツが配信されます。video インスタンスは動画コンテンツを、www インスタンスはその他のすべてのコンテンツをそれぞれ配信します。

この例では、ロードバランサはクライアントからの HTTPS リクエストを受け付け、バックエンドに HTTP としてプロキシしています。また、ロードバランサで HTTP リクエストを受け付けるように構成し、HTTPS を使用してバックエンドにリクエストをプロキシすることもできます。

始める前に

以下の手順では、プロジェクトが 1 つ必要になります。プロジェクトが存在しない場合は、プロジェクトを設定します。これらの手順は、カスタムモードの Virtual Private Cloud(VPC)ネットワークの作成方法を示しています。カスタムのファイアウォール ルールを設定して、トラフィックがインスタンスに届くようにすることも必要です。

コマンドラインから作業する場合は、gcloud コマンドライン ツールをインストールします。このツールのコンセプトとインストールについては、gcloud の概要をご覧ください。

権限

このガイドの手順を完了するには、プロジェクトで Compute Engine インスタンスを作成する権限が必要です。プロジェクトのオーナーまたは編集者のロール、あるいは次に示す Compute Engine IAM ロールが必要です。

タスク 必要なロール
インスタンスの作成 Compute インスタンス管理者
ファイアウォール ルールの追加と削除 セキュリティ管理者
ロードバランサのコンポーネントの作成 ネットワーク管理者
プロジェクトの作成(省略可) プロジェクト作成者

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

設定

省略可: 新しいプロジェクトの作成

このチュートリアルを続行する前に、resourcemanager.projects.create 権限を持つユーザーで新しいプロジェクトを作成してください。これにより、ガイドの最後でクリーンアップが簡単になります。

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

この例では、次の VPC ネットワーク、リージョン、サブネットを使用します。

  • ネットワーク: ネットワークは、lb-network という名前のカスタムモードの VPC ネットワークです。

  • 2 つの異なるリージョンのサブネット:

    • us-subnet は、10.1.10.0/24 をプライマリ IP 範囲として使用し、us-central1 リージョンに配置されます。
    • eu-subnet は、10.1.11.0/24 をプライマリ IP 範囲として使用し、europe-west1 リージョンに配置されます。

サンプルのネットワークとサブネットを作成する方法は次のとおりです。

コンソール

  1. Google Cloud コンソールの [VPC ネットワーク] ページに移動します。

    [VPC ネットワーク] に移動

  2. [VPC ネットワークを作成] をクリックします。

  3. [名前] に「lb-network」と入力します。

  4. [サブネット] セクションで、最初のサブネットを作成します。

    • [サブネット作成モード] を [カスタム] に設定します。
    • [新しいサブネット] セクションに、次の情報を入力します。
      • 名前: us-subnet
      • リージョン: us-central1
      • IP アドレス範囲: 10.1.10.0/24
      • [完了] をクリックします。
  5. [サブネット] セクションで、[サブネットの追加] をクリックし、2 つ目のサブネットを作成します。

    • [新しいサブネット] セクションに、次の情報を入力します。
      • 名前: eu-subnet
      • リージョン: europe-west1
      • IP アドレス範囲: 10.1.11.0/24
      • [完了] をクリックします。
  6. [作成] をクリックします。

gcloud

  1. カスタム VPC ネットワークを作成します。

    gcloud compute networks create lb-network --subnet-mode=custom
    
  2. us-subnet を作成します。

    gcloud compute networks subnets create us-subnet \
      --network=lb-network \
      --range=10.1.10.0/24 \
      --region=us-central1
    
  3. eu-subnet を作成します。

    gcloud compute networks subnets create eu-subnet \
      --network=lb-network \
      --range=10.1.11.0/24 \
      --region=europe-west1
    

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

デフォルトの上り(内向き)拒否ルールは、バックエンド インスタンスへの受信トラフィックをブロックします。ロードバランサからのトラフィックや、Google Cloud ヘルスチェック システムからのトラフィックがブロックされます。新しいファイアウォール ルールを作成して、デフォルトのルールを上書きし、トラフィックがインスタンスに届くようにする必要があります。

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

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

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

コンソール

  1. Google Cloud コンソールで [ファイアウォール ポリシー] ページに移動します。

    [ファイアウォール ポリシー] に移動

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

    1. [名前] に「fw-allow-ssh」と入力します。
    2. [ネットワーク] で、[lb-network] を選択します。
    3. [ターゲット] で [指定されたターゲットタグ] を選択します。
    4. [ターゲットタグ] フィールドに「allow-ssh」を入力します。
    5. [ソースフィルタ] を [IPv4 範囲] に設定します。
    6. [送信元 IPv4 範囲] を 0.0.0.0/0 に設定します。
    7. [プロトコルとポート] で [指定したプロトコルとポート] をオンにします。
    8. [TCP] チェックボックスをオンにして、ポート番号に「22」と入力します。
    9. [作成] をクリックします。
  3. [ファイアウォール ルールを作成] をクリックして、2 つ目のファイアウォール ルールを作成します。

    1. [名前] に「fw-allow-health-check-and-proxy」と入力します。
    2. [ネットワーク] で、[lb-network] を選択します。
    3. [ターゲット] で [指定されたターゲットタグ] を選択します。
    4. [ターゲットタグ] フィールドに「allow-health-check」を入力します。
    5. [ソースフィルタ] を [IPv4 範囲] に設定します。
    6. [送信元 IPv4 範囲] を 130.211.0.0/2235.191.0.0/16 に設定します。
    7. [プロトコルとポート] で [指定したプロトコルとポート] を選択します。
    8. [TCP] チェックボックスをオンにして、ポート番号に「80,443」と入力します。
    9. [作成] をクリックします。

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 ヘルスチェックが TCP ポート 80443 でバックエンド システムと通信ができるように、fw-allow-health-check-and-proxy ルールを作成します。

    gcloud compute firewall-rules create fw-allow-health-check-and-proxy \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-health-check \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --rules=tcp:80,tcp:443
    

インスタンスの作成

Compute Engine バックエンドでロードバランサを設定するには、VM がインスタンス グループに属している必要があります。このガイドでは、Apache が実行されている Linux VM でマネージド インスタンス グループを作成する方法について説明します。

このマネージド インスタンス グループの VM で外部 HTTPS ロードバランサのバックエンド サーバーを実行します。わかりやすく説明するために、バックエンド サーバーはそれぞれ独自のホスト名を提供します。

この例では、8 台の仮想マシン(VM)インスタンスを作成します。このうちの 4 台により動画コンテンツが配信され、4 台によってその他のすべてのコンテンツが配信されます。起動スクリプトを使用して、インスタンスごとに固有のホームページを持つ Apache ウェブサーバー ソフトウェアをインストールします。VM 上の任意のウェブサーバーを使用できます。この例では、Apache がインストールされています。

コンソール

インスタンス テンプレートを作成します。

  1. Google Cloud コンソールで、[インスタンス テンプレート] ページに移動します。

    [インスタンス テンプレート] に移動

    1. [インスタンス テンプレートを作成] をクリックします。
    2. [名前] に「video-us-template」と入力します。
    3. [ブートディスク] が Debian GNU/Linux 10 (buster) などの Debian イメージに設定されていることを確認します。以降の手順では、apt-get などの Debian でのみ使用できるコマンドを使用します。
    4. [詳細オプション] をクリックします。
    5. [ネットワーキング] をクリックして次のフィールドを構成します。
      1. [ネットワーク タグ] に「allow-health-check」と「allow-ssh」を入力します。
      2. [ネットワーク インターフェース] で、次のように選択します。
        • ネットワーク: lb-network
        • サブネット: us-subnet
    6. [管理] をクリックします。[起動スクリプト] フィールドに次のスクリプトを入力します。

      #! /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)"
      mkdir -p /var/www/html/video
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html /var/www/html/video/index.html
      systemctl restart apache2
      
    7. [作成] をクリックします。

  2. マネージド インスタンス グループを作成します。Google Cloud コンソールで、[インスタンス グループ] ページに移動します。

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

    1. [インスタンス グループを作成] をクリックします。
    2. [新しいマネージド インスタンス グループ(ステートレス)] を選択します。詳細については、ステートレス MIG とステートフル MIG をご覧ください。
    3. [名前] に「ig-video-us」と入力します。
    4. [ロケーション] で [シングルゾーン] を選択します。
    5. [リージョン] で、使用するリージョンを選択します。この例では us-central1 を使用しています。
    6. [ゾーン] で us-central1-b を選択します。
    7. [インスタンス テンプレート] で video-us-template を選択します。
    8. [自動スケーリング モード] で [Off:do not autoscale] を選択します。
    9. [インスタンスの最大数] に「2」と入力します。
    10. [作成] をクリックします。

gcloud

  1. インスタンス テンプレートを作成します。

    gcloud compute instance-templates create video-us-template \
       --region=us-central1 \
       --network=lb-network \
       --subnet=us-subnet \
       --tags=allow-health-check,allow-ssh \
       --image-family=debian-10 \
       --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)"
         mkdir -p /var/www/html/video
         echo "Page served from: $vm_hostname" | \
         tee /var/www/html/index.html /var/www/html/video/index.html
         systemctl restart apache2'
    
  2. 作成したテンプレートに基づいて、マネージド インスタンス グループを作成します。

    gcloud compute instance-groups managed create ig-video-us \
       --template=video-us-template --size=2 --zone=us-central1-b
    

4 つのインスタンス グループにこの手順を繰り返します。各インスタンス グループのインスタンス グループ名、テンプレート名、リージョン、ゾーンを次のように変更します。

  • ig-video-usvideo-us-templateus-central1-b(この例で示す)
  • ig-video-euvideo-eu-templateeurope-west1-b
  • ig-www-uswww-us-templateus-central1-b
  • ig-www-euwww-europe-templateeurope-west1-b

インスタンス グループへの名前付きポートの追加

インスタンス グループごとに HTTP サービスを定義し、ポート名を該当するポートにマッピングします。負荷分散サービスが構成されると、名前を指定したポートにトラフィックが転送されます。

コンソール

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

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

  2. インスタンス グループの名前(ig-video-us など)をクリックし、[グループを編集] をクリックします。

  3. [ポート名のマッピングを指定する] をクリックします。

  4. [項目を追加] をクリックします。

  5. ポート名に「http」と入力します。ポート番号に「80」と入力します。

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

インスタンス グループごとにこの手順を繰り返します。

gcloud

gcloud compute instance-groups unmanaged set-named-ports ig-video-us \
    --named-ports http:80 \
    --zone us-central1-b
gcloud compute instance-groups unmanaged set-named-ports ig-www-us \
    --named-ports http:80 \
    --zone us-central1-b
gcloud compute instance-groups unmanaged set-named-ports ig-video-eu \
    --named-ports http:80 \
    --zone europe-west1-b
gcloud compute instance-groups unmanaged set-named-ports ig-www-eu \
    --named-ports http:80 \
    --zone europe-west1-b

外部 IP アドレスの予約

インスタンスが稼働状態になったため、次にロード バランシングに必要なサービスをセットアップします。このセクションでは、デベロッパーが作成したロードバランサにユーザーが接続する際に使用する、2 つのグローバル静的外部 IP アドレスを作成します。

コンソール

  1. Google Cloud コンソールで、[外部 IP アドレス] ページに移動します。

    [外部 IP アドレス] に移動

  2. [静的アドレスを予約] をクリックして、IPv4 アドレスを予約します。

  3. [名前] に「lb-ipv4-1」を割り当てます。

  4. ネットワーク階層を [プレミアム] に設定します。

  5. [IP バージョン] を IPv4 に設定します。

  6. [タイプ] で [グローバル] をオンにします。

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

  8. もう一度、[静的アドレスを予約] をクリックして、IPv6 アドレスを予約します。

  9. lb-ipv6-1 の [名前] を割り当てます。

  10. ネットワーク階層を [プレミアム] に設定します。

  11. [IP バージョン] を IPv6 に設定します。

  12. [タイプ] が [グローバル] に設定されていることを確認します。

    この例ではロードバランサは、プレミアム ティア ネットワークを使用します。スタンダード階層ネットワークを使用するロードバランサでは、リージョン IP アドレスを使用します。スタンダード階層の場合、IPv6 アドレスは使用できません。

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

gcloud

  1. IPv4 アドレスを予約します。

    gcloud compute addresses create lb-ipv4-1 \
      --ip-version=IPV4 \
      --network-tier=PREMIUM \
      --global
    
  2. IPv6 アドレスを予約します。

    gcloud compute addresses create lb-ipv6-1 \
      --ip-version=IPV6 \
      --network-tier=PREMIUM \
      --global
    

負荷分散リソースの構成

ロードバランサ機能には、接続済みの複数のリソースが含まれます。このセクションでは、リソースを設定して接続します。以下のとおりです。

  • 名前付きポート。ロードバランサはこれを使用して、トラフィックをインスタンス グループに転送します。
  • ヘルスチェック。インスタンスが正常に機能しているかを確認します。ロードバランサは正常なインスタンスのみにトラフィックを送信します。
  • 容量、セッション アフィニティ、ヘルスチェックのステータスを追跡するバックエンド サービス。バックエンド サービスは、容量とインスタンスの正常性に基づいて、バックエンド VM またはエンドポイントにリクエストを送信します。
  • リクエストの URL のホストとパスに基づいて特定のバックエンド サービスへのリクエストの転送にロードバランサが使用する、URL マップ
  • SSL 証明書のリソースSSL 証明書リソースには、HTTPS クライアントが接続するときにロードバランサが TLS を終了するために使用する SSL 証明書情報が含まれます。複数の SSL 証明書を使用できます。Google マネージド SSL 証明書またはセルフマネージド SSL 証明書を任意に組み合わせることができます。複数の SSL 証明書を使用する場合は、証明書ごとに SSL 証明書リソースを作成する必要があります。
  • ロードバランサが URL マップと SSL 証明書をグローバル転送ルールに関連付けるために使用するターゲット HTTPS プロキシ
  • 2 つのグローバル転送ルール(IPv4 と IPv6 にそれぞれ 1 つずつ)。グローバルな外部 IP アドレス リソースを保持します。グローバル転送ルールは、受信リクエストをターゲット プロキシに転送します。

Console

ロードバランサに名前を付ける

  1. Google Cloud コンソールの [ロード バランシング] ページに移動します。
    ロードバランサの作成
  2. [アプリケーション ロードバランサ(HTTP/S)] カードで [構成を開始] をクリックします。
  3. [インターネット接続または内部専用] で [インターネットから自分の VM へ] を選択します。
  4. [グローバル / リージョン] で、以下のいずれかを選択します。
    • 従来のアプリケーション ロードバランサの場合は、[従来のアプリケーション ロードバランサ] を選択します。
    • グローバル外部アプリケーション ロードバランサの場合は、[グローバル外部アプリケーション ロードバランサ] を選択します。
  5. [続行] をクリックします。
  6. ロードバランサの [名前] に「web-map」と入力します。
  7. ウィンドウを開いたままにして続行します。

www インスタンスのバックエンド サービスとヘルスチェックを構成する

ロードバランサには、2 つのバックエンド サービスと、その両方に対応するヘルスチェックが必要になります。この例では、ロードバランサはクライアントからの HTTPS リクエストを終了し、HTTP を使用してバックエンドと通信します。これを行うには、バックエンド プロトコルとヘルスチェックのための HTTP を指定します。

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

  1. [バックエンドの構成] をクリックします。
  2. [バックエンド サービスを作成または選択] プルダウン メニューで、マウスポインタを [バックエンド サービス] に合わせ、[バックエンド サービスを作成] を選択します。
  3. バックエンド サービスの [名前] を web-backend-service に設定します。
  4. [バックエンド タイプ] が [インスタンス グループ] に設定されていることを確認してください。
  5. [プロトコル] プルダウン メニューで、[HTTP] を選択します。
  6. [名前付きポート] フィールドに「http」と入力します。
  7. [バックエンド] で、[インスタンス グループ] を ig-www-us に設定します。
  8. ロードバランサとインスタンスの間のトラフィックに対しては、[ポート番号] を 80 に設定します。
  9. 残りのフィールドはデフォルト値のままにします。
  10. [新しいバックエンド] ウィンドウの下部にある [完了] をクリックします。
  11. [バックエンドを追加] をクリックしてステップを繰り返し、インスタンス グループ ig-www-eu を選択します。
  12. ウィンドウを開いたままにして続行します。

www インスタンスのヘルスチェックの構成

  1. [ヘルスチェック] の [バックエンドの構成] ウィンドウで、[ヘルスチェックを作成] または [別のヘルスチェックを作成] を選択します。
  2. HTTP ヘルスチェックを作成するには、次のヘルスチェック パラメータを設定します。
    • 名前: http-basic-check-www
    • プロトコル: HTTP
    • ポート: 80
  3. [保存して次へ] をクリックします。
  4. [作成] をクリックします。

video インスタンスのバックエンドとヘルスチェックを構成する

  1. 上記の手順を繰り返して、2 番目のバックエンド サービスに video-backend-service という名前を付け、ig-video-usig-video-eu のインスタンス グループを割り当てます。
  2. 同じ手順に従ってヘルスチェックを作成しますが、ヘルスチェック http-basic-check-video に名前を付けます。ヘルスチェックの名前は一意である必要があります。

ホストとパスのルールを構成する

ホストとパスのルールによって、ロードバランサの URL マップリソースが構成されます。

  1. 画面の左の列で、[ホストとパスのルール] をクリックします。
  2. 最初の行の右側の列に web-backend-service が表示され、ホストパスの既定のルール Any unmatched (default) によって設定がなされていることを確認します。
  3. 右側の列の 2 行目に video-backend-service が表示されていることを確認します。この行が存在しない場合は、[ホストとパスのルールを追加] をクリックしてから、右の列のプルダウン メニューから [video-backend-service] を選択します。他の列には、次のように値を入力します。
    1. [ホスト] を * に設定します。
    2. [パス] フィールドで次の手順を行います。
      1. /video と入力して Tab キーを押します。
      2. /video/* と入力して Tab キーを押します。

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

フロントエンド構成セクションで、転送ルールや SSL 証明書などのロードバランサのリソースを構成します。また、クライアントとロードバランサ間で使用するプロトコルを選択することもできます。

この例では、クライアントとロードバランサの間で HTTPS を使用しているため、プロキシを構成する SSL 証明書リソースが 1 つ以上必要になります。SSL 証明書リソースの作成方法については、SSL 証明書をご覧ください。Google マネージド証明書を使用することをおすすめします。

  1. [Create global external Application Load Balancer] ページの左パネルで、[フロントエンドの構成] をクリックします。
  2. [名前] フィールドに「https-content-rule」と入力します。
  3. [プロトコル] フィールドで HTTPS を選択します。
  4. ウィンドウを開いたままにして続行します。

IPv4 転送ルールを構成する

  1. [IP バージョン] を IPv4 に設定します。
  2. [IP アドレス] で、先ほど作成した lb-ipv4-1 を選択します。
  3. HTTPS トラフィックを許可するように、ポート443 に設定されていることを確認します。
  4. [証明書] プルダウン リストをクリックします。
    1. プライマリ SSL 証明書として使用しようとしているセルフマネージド SSL 証明書リソースがすでにある場合は、プルダウン メニューから選択します。
    2. そうでない場合は、[新しい証明書を作成] を選択します。
    3. [名前] に「www-ssl-cert」と入力します。
    4. [証明書をアップロードする] か [Google マネージドの証明書を作成する] を選択します。Google マネージド証明書を作成するには、ドメインが必要です。ドメインがない場合は、テスト用に独自の証明書をアップロードできます。
    5. [証明書をアップロードする] を選択した場合は、次の手順を行います。
      1. [公開鍵証明書] フィールドで、次のいずれかを行います。
        • [アップロード] ボタンをクリックし、PEM 形式の証明書ファイルを選択します。
        • PEM 形式の証明書のコンテンツをコピーして貼り付けます。コンテンツは -----BEGIN CERTIFICATE----- で始まり、-----END CERTIFICATE----- で終わる必要があります。
      2. [証明書チェーン] フィールドの場合、次のいずれかを行います。
        • [アップロード] ボタンをクリックし、CA の証明書ファイルを選択します。このファイルには、中間 CA 証明書とルート CA 証明書が含まれている必要があります。
        • 証明書チェーンのコンテンツをコピーして貼り付けます。チェーン内の各証明書は PEM 形式で、-----BEGIN CERTIFICATE----- で始まり、-----END CERTIFICATE----- で終わる必要があります。Google Cloud は証明書チェーンを検証しません。お客様自身で検証していただく必要があります。
        • 証明書チェーンを省略した場合、クライアントが自動的に信頼する公的に信頼された CA によって証明書に署名される必要があります。
      3. [秘密鍵証明書] フィールドで、次のいずれかを行います。
        • [アップロード] ボタンをクリックし、秘密鍵を選択します。秘密鍵は PEM 形式で、パスフレーズで保護されていない必要があります。
        • PEM 形式の秘密鍵のコンテンツをコピーして貼り付けます。RSA 秘密鍵は -----BEGIN RSA PRIVATE KEY----- で始まり、-----END RSA PRIVATE KEY----- で終わる必要があります。ECDSA 秘密鍵は -----BEGIN EC PRIVATE KEY----- で始まり、-----END EC PRIVATE KEY----- で終わる必要があります。
      4. [作成] をクリックします。
    6. [Google マネージドの証明書を作成する] を選択した場合は、[ドメイン] を入力します。
  5. プライマリ SSL 証明書リソースに加えて証明書リソースを追加するには、次の手順に沿って操作します。
    1. [証明書を追加] をクリックします。
    2. [証明書] リストから証明書を選択するか、[新しい証明書の作成] をクリックし、上記の手順を行います。
  6. [QUIC ネゴシエーション] で、次のいずれかのオプションを選択します。
    • 自動(デフォルト): QUIC がネゴシエートされるタイミングを Google が制御できるようにします。現在、[自動] を選択すると、QUIC は無効になります。このオプションを選択すると、今後このロードバランサに対して QUIC ネゴシエーションと HTTP/3 が自動的に有効になります。gcloud と API では、このオプションは NONE と呼ばれます。
    • 有効: ロードバランサがクライアントと QUIC をネゴシエートできるようにします。
    • 無効: ロードバランサがクライアントと QUIC をネゴシエートできないようにします。
  7. [完了] をクリックします。
  8. ウィンドウを開いたままにして続行します。

IPv6 転送ルールを構成する

  1. [フロントエンドの IP とポートを追加] をクリックします。
  2. [名前] に「https-content-ipv6-rule」を入力します。
  3. クライアントとロードバランサ間で HTTPS を使用する場合は、[プロトコル] フィールドで HTTPS を選択します。クライアントとロードバランサ間で HTTP を使用する場合は、HTTP を選択します。
  4. [IP バージョン] を IPv6 に設定します。
  5. [IP] で、先ほど作成した lb-ipv6-1 を選択します。
  6. 443 の [ポート] にはデフォルト値を設定する必要があります。
  7. SSL 証明書リソースをすでに使用している場合は、[証明書] プルダウン メニューから選択します。そうでない場合は、[新しい証明書の作成] を選択します。
    1. [名前] に「www-ssl-cert」と入力します。
    2. 該当するフィールドに、公開鍵証明書(.crt ファイル)、証明書チェーン(.csr ファイル)、秘密鍵(.key ファイル)をアップロードします。
    3. [作成] をクリックします。
  8. プライマリ SSL 証明書リソースに加えて証明書リソースを追加するには、次の手順に沿って操作します。
    1. [証明書を追加] をクリックします。
    2. [証明書] リストから証明書を選択するか、[新しい証明書の作成] をクリックし、上記の手順を行います。
  9. [QUIC ネゴシエーション] で、次のいずれかのオプションを選択します。
    • 自動(デフォルト): QUIC がネゴシエートされるタイミングを Google が制御できるようにします。現在、[自動] を選択すると、QUIC は無効になります。このオプションを選択すると、今後このロードバランサに対して QUIC ネゴシエーションと HTTP/3 が自動的に有効になります。gcloud と API では、このオプションは NONE と呼ばれます。
    • 有効: ロードバランサがクライアントと QUIC をネゴシエートできるようにします。
    • 無効: ロードバランサがクライアントと QUIC をネゴシエートできないようにします。
  10. [完了] をクリックします。

確認と完了

  1. [Create global external Application Load Balancer] ページの左パネルで、[確認と完了] をクリックします。
  2. 現在の設定と作成しようとしている内容を比較します。
  3. 設定に問題がない場合は、[作成] をクリックして外部アプリケーション ロードバランサを作成します。

gcloud

  1. ヘルスチェックを作成します。ロードバランサとバックエンド間で HTTP を使用する場合は、HTTP に gcloud コマンドを使用します。

    gcloud compute health-checks create http http-basic-check \
        --port 80
    
  2. コンテンツ プロバイダごとにバックエンド サービスを作成します。

    HTTP を使用してインスタンスに移動するため、--protocol フィールドを HTTP に設定します。先ほどヘルスチェックとして作成した http-basic-check ヘルスチェックを使用します。

    • グローバル外部アプリケーション ロードバランサの場合は、load-balancing-scheme=EXTERNAL_MANAGED を指定して gcloud CLI コマンドを使用します。この設定では、高度なトラフィック管理機能が提供されます。
    • 従来のアプリケーション ロードバランサの場合は、load-balancing-scheme=EXTERNAL を使用します。
    gcloud compute backend-services create video-backend-service \
        --load-balancing-scheme=LOAD_BALANCING_SCHEME \
        --global-health-checks \
        --protocol=HTTP \
        --port-name=http \
        --health-checks=http-basic-check \
        --global
    
    gcloud compute backend-services create web-backend-service \
        --load-balancing-scheme=LOAD_BALANCING_SCHEME \
        --global-health-checks \
        --protocol=HTTP \
        --port-name=http \
        --health-checks=http-basic-check \
        --global
    
  3. インスタンス グループをバックエンドとしてバックエンド サービスに追加します。バックエンドに含まれるインスタンス グループの容量(最大バックエンド使用率または最大秒間クエリ数)をバックエンドで定義します。この例では、balancing-mode の値を UTILIZATIONmax-utilization の値を 0.8capacity-scaler の値を 1 にそれぞれ設定します。バックエンド サービスをドレインする場合は、capacity-scaler の値を 0 に設定します。

    ig-video-us インスタンス グループを追加します。

    gcloud compute backend-services add-backend video-backend-service \
        --balancing-mode=UTILIZATION \
        --max-utilization=0.8 \
        --capacity-scaler=1 \
        --instance-group=ig-video-us \
        --instance-group-zone=us-central1-b \
        --global
    

    ig-video-eu インスタンス グループを追加します。

    gcloud compute backend-services add-backend video-backend-service \
        --balancing-mode=UTILIZATION \
        --max-utilization=0.8 \
        --capacity-scaler=1 \
        --instance-group=ig-video-eu \
        --instance-group-zone=europe-west1-b \
        --global
    

    ig-www-us インスタンス グループを追加します。

    gcloud compute backend-services add-backend web-backend-service \
        --balancing-mode=UTILIZATION \
        --max-utilization=0.8 \
        --capacity-scaler=1 \
        --instance-group=ig-www-us \
        --instance-group-zone=us-central1-b \
        --global
    

    ig-www-eu インスタンス グループを追加します。

    gcloud compute backend-services add-backend web-backend-service \
        --balancing-mode=UTILIZATION \
        --max-utilization=0.8 \
        --capacity-scaler=1 \
        --instance-group=ig-www-eu \
        --instance-group-zone=europe-west1-b \
        --global
    
  4. 適切なバックエンド サービスにリクエストをルーティングする URL マップを作成します。この場合、--path-rules フラグで定義されたリクエストパスのマッピング(対応付け)により、サイトへの各リクエストの URL パスごとにトラフィックが分割されます。--path-rules リスト内のどのエントリにも一致しないトラフィックは、--default-service flag のエントリに送信されます。

    1. URL マップを作成します。

      gcloud compute url-maps create web-map \
          --default-service web-backend-service
      
    2. URL マップにパスマッチャーを追加し、リクエストのパスマッピングを定義します。

      gcloud compute url-maps add-path-matcher web-map \
          --default-service web-backend-service \
          --path-matcher-name pathmap \
          --path-rules="/video=video-backend-service,/video/*=video-backend-service"
      
  5. HTTPS プロキシで使用する SSL 証明書リソースを作成します。Google マネージド証明書を作成するには、ドメインが必要です。ドメインがない場合は、自己署名 SSL 証明書を使用してテストできます。詳しくは、SSL 証明書のタイプをご覧ください。

    複数の SSL 証明書を使用している場合は、証明書ごとに SSL 証明書リソースを作成する必要があります。

    セルフマネージド SSL 証明書リソースを作成するには、次のコマンドを実行します。

    gcloud compute ssl-certificates create www-ssl-cert \
        --certificate [CRT_FILE_PATH] \
        --private-key [KEY_FILE_PATH]
    

    Google マネージド SSL 証明書リソースを作成するには、次のコマンドを実行します。

    gcloud compute ssl-certificates create www-ssl-cert \
      --domains [DOMAIN]
    
  6. URL マップにリクエストをルーティングするターゲット HTTPS プロキシを作成します。プロキシはロードバランサの一部であり、HTTPS 負荷分散用の SSL 証明書を保持するため、この手順で証明書も読み込みます。

    gcloud compute target-https-proxies create https-lb-proxy \
        --url-map web-map --ssl-certificates www-ssl-cert
    
  7. 2 つのグローバル転送ルールを作成して、作成した IP アドレスごとに受信したリクエストをプロキシに転送します。

    • グローバル外部アプリケーション ロードバランサの場合は、load-balancing-scheme=EXTERNAL_MANAGED を指定して gcloud CLI コマンドを使用します。この設定では、高度なトラフィック管理機能が提供されます。
    • 従来のアプリケーション ロードバランサの場合は、load-balancing-scheme=EXTERNAL を使用します。
    gcloud compute forwarding-rules create https-content-rule \
        --load-balancing-scheme=LOAD_BALANCING_SCHEME \
        --network-tier=PREMIUM \
        --address=lb-ipv4-1 \
        --global \
        --target-https-proxy=https-lb-proxy \
        --ports=443
    
    gcloud compute forwarding-rules create https-content-ipv6-rule \
        --load-balancing-scheme=LOAD_BALANCING_SCHEME \
        --network-tier=PREMIUM \
        --address=lb-ipv6-1 \
        --global \
        --target-https-proxy=https-lb-proxy \
        --ports=443
    

グローバル転送ルールの作成後、構成が全世界に反映されるまで数分かかることがあります。

ドメインをロードバランサに接続する

ロードバランサが作成されたら、ロードバランサに関連付けられた IP アドレスをメモします(例: 30.90.80.100)。ドメイン登録サービスを使用して A レコードを作成し、ドメインがロードバランサを参照するようにします。SSL 証明書に複数のドメインを追加する場合は、それぞれについて A レコードを追加して、すべてがロードバランサの IP アドレスを指すようにする必要があります。たとえば、www.example.comexample.comA レコードを作成するには、次のようにします。

NAME                  TYPE     DATA
www                   A        30.90.80.100
@                     A        30.90.80.100

DNS プロバイダとして Cloud DNS を使用する場合は、レコードの追加、変更、削除をご覧ください。

インスタンスへのトラフィックの送信

負荷分散サービスの構成が完了したので、転送ルールへのトラフィックの送信を開始できます。また、別のインスタンスに送信されるトラフィックをモニタリングできます。

コンソールとウェブブラウザ

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. web-map をクリックして、作成したロードバランサを展開します。

  3. [バックエンド] セクションで、インスタンスが正常であることを確認します。[正常] 列には、4 つのインスタンス グループそれぞれで両方のインスタンスが正常であることが示されます。それ以外の場合は、最初にページを再読み込みしてみてください。インスタンスが正常な状態であることが Google Cloud コンソールに表示されるまでに時間がかかる場合があります。数分経ってもバックエンドが正常に動作しない場合は、ファイアウォールの構成とバックエンド インスタンスに割り当てられているネットワーク タグのセットを確認します。

  4. ロードバランサの IPv4 および IPv6 アドレスを記録します。

    1. Google Cloud コンソールで、[外部 IP アドレス] ページに移動します。

      [外部 IP アドレス] に移動

    2. [名前] で、lb-ipv4-1 および lb-ipv6-1 という名前のアドレスを見つけ、[外部アドレス] 列から関連する値を記録します。

  5. Google マネージド証明書を使用している場合:

    1. 次の DNS レコードを作成します。

    2. 証明書リソースのステータスが ACTIVE であることを確認します。詳しくは、Google マネージド SSL 証明書リソースのステータスをご覧ください。

  6. 次のいずれかに移動して、ウェブブラウザを使用してロードバランサをテストします。

    • https://IP_ADDRESS。ここで、IP_ADDRESS はロードバランサの IPv4 アドレスです。ブラウザに証明書の警告が表示された場合、証明書を信頼するようブラウザで明示的に指示する必要があります。通常、証明書は IP アドレスではなくドメインで構成されているため、警告が表示されます。

    • https://FQDN。ここで、FQDN はロードバランサの IP アドレスを参照するように DNS を構成した完全修飾ドメイン名(FQDN)です。セルフマネージド自己署名 SSL 証明書またはカスタム認証局(CA)によって署名されたセルフマネージド SSL 証明書を使用した場合、証明書またはその CA を信頼するように明示的に構成していない限り、ブラウザは証明書の警告を表示します。セルフマネージド証明書の詳細については、秘密鍵と証明書の作成をご覧ください。

    ページを提供したインスタンスの名前とそのゾーン(Page on ig-www-us-02 in us-central1-b など)を示すコンテンツを含むページがブラウザで表示されます。

  7. ブラウザで、次のいずれかに移動します。

    • https://IP_ADDRESS/video。ここで、IP_ADDRESS はロードバランサの IPv4 アドレスです。

    • https://FQDN/video。ここで、FQDN はロードバランサの IP アドレスを指すように DNS を構成した FQDN です。

    ページを提供した動画インスタンスの名前とそのゾーン(Page on ig-video-us-02 in us-central1-b など)を示すコンテンツを含むページがブラウザで表示されます。

gcloud と curl の使用

  1. ロードバランサの IPv4 および IPv6 アドレスを記録します。

    gcloud compute addresses describe lb-ipv4-1 \
    --format="get(address)" \
    --global
    
    gcloud compute addresses describe lb-ipv6-1 \
    --format="get(address)" \
    --global
    
  2. Google マネージド証明書を使用している場合:

    1. 次の DNS レコードを作成します。

    2. 証明書リソースのステータスが ACTIVE であることを確認します。詳しくは、Google マネージド SSL 証明書リソースのステータスをご覧ください。

      gcloud compute ssl-certificates list
      
  3. これらの URL からのレスポンスをテストするには、curl コマンドを使用します。IP_ADDRESS は、ロードバランサの IPv4 アドレスに置き換えます。

    curl -k https://IP_ADDRESS
    
    curl -k https://IP_ADDRESS/video/
    
  4. これらの URL からのレスポンスをテストするには、curl コマンドを使用します。IP_ADDRESS は、ロードバランサの IPv6 アドレスに置き換えます。IPv6 の場合は、角かっこ([])を使用してアドレスを囲み、-g フラグでグロビングを無効にする必要があります(たとえば、curl -g -6 "https://[2001:DB8::]/")。

    curl -k -g -6 https://[IP_ADDRESS]
    
    curl -k -g -6 https://[IP_ADDRESS]/video/
    

マルチリージョン機能のテスト

異なる地域のユーザーをシミュレートするには、異なるリージョンにある仮想マシン インスタンスの 1 つに接続し、そのインスタンスから curl コマンドを実行して、そのリクエストが最も近いリージョンのインスタンスに送信されることを確認します。

ig-www-us-01 に接続する場合、curl コマンドを実行すると、リクエストが us-central1 のインスタンスに送信されることが示されます。次のような出力が表示されます。Page on ig-www-us-02 in us-central1-b

ig-www-eu-01 に接続する場合、curl コマンドを実行すると、リクエストが europe-west1 のインスタンスに送信されることが示されます。次のような出力が表示されます。Page on ig-www-eu-02 in europe-west1-b

世界中のクライアント システムからテストを実行できます。リージョン内のバックエンドが正常ではなくなるか、容量に達した場合、HTTPS ロードバランサによって、自動的にトラフィックが次に最も近いリージョンに送信されます。

追加の構成オプション

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

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

これらの手順は、バックエンド サービスごとに異なるタイプのセッション アフィニティを構成する方法を示しています。

  • web-backend-service のクライアント IP アドレス セッション アフィニティ
  • video-backend-service の HTTP Cookie セッション アフィニティ

クライアント IP アフィニティが有効になっている場合、ロードバランサは、クライアントの IP アドレスから作成されたハッシュに基づいて、特定のクライアントのリクエストを同じバックエンド VM に送信します。

生成された Cookie アフィニティが有効な場合、ロードバランサは最初のリクエストで Cookie を発行します。同じ Cookie を持つ後続のリクエストは、ロードバランサによって同じバックエンド VM またはエンドポイントに送信されます。外部アプリケーション ロードバランサの場合、Cookie の名前は GCLB になります。

コンソール

web-backend-service のクライアント IP セッション アフィニティを有効にするには:

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. [バックエンド] をクリックします。

  3. web-backend-service(この例で作成したバックエンド サービスの名前)をクリックし、[編集] をクリックします。

  4. [バックエンド サービスの詳細] ページで、[詳細構成] をクリックします。

  5. [セッション アフィニティ] で、メニューから [クライアント IP] を選択します。

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

video-backend-service に対して生成された Cookie セッション アフィニティを有効にするには:

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. [バックエンド] をクリックします。

  3. video-backend-service(この例で作成したバックエンド サービスの 1 つの名前)をクリックし、[編集] をクリックします。

  4. [バックエンド サービスの詳細] ページで、[詳細構成] をクリックします。

  5. [セッション アフィニティ] で、メニューから [生成した Cookie] を選択します。

  6. [更新] をクリックします。

gcloud

クライアント IP セッション アフィニティを指定して、web-backend-service バックエンド サービスを更新するには、次の gcloud コマンドを使用します。

gcloud compute backend-services update web-backend-service \
    --session-affinity=CLIENT_IP \
    --global

次の gcloud コマンドを使用して、生成された Cookie セッション アフィニティを指定して、video-backend-service バックエンド サービスを更新します。

gcloud compute backend-services update video-backend-service \
    --session-affinity=GENERATED_COOKIE \
    --global

API

クライアント IP セッション アフィニティを設定するには、backendServices/patch メソッドに PATCH リクエストを送信します。

PATCH https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/backendServices/web-backend-service
{
  "sessionAffinity": "CLIENT_IP"
}

生成された Cookie セッション アフィニティを設定するには、backendServices/patch メソッドに PATCH リクエストを行います。

PATCH https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/backendServices/video-backend-service
{
  "sessionAffinity": "GENERATED_COOKIE"
}

バックエンド VM から外部 IP アドレスを削除する

外部アプリケーション ロードバランサは、内部 IP アドレスと特別なロードバランサ ルートを使用してバックエンドと通信します。バックエンドのインスタンスでは、ロードバランサとの通信に外部 IP アドレスは使用されません。バックエンドのインスタンスから外部 IP アドレスが除外されるため、セキュリティが強化されます。

バックエンドのインスタンスから外部 IP アドレスを削除するには、次の手順に沿って進めてください。

SSH を使用して外部 IP アドレスを持たないバックエンド インスタンスに接続する必要がある場合は、外部 IP アドレスを持たないインスタンスに接続するをご覧ください。

クリーンアップ

このチュートリアルを終了した後、作成したリソースを削除して、今後料金が発生しないようにします。これらのリソースが独自のプロジェクト内で作成されている場合は、プロジェクト全体を削除することもできます。それ以外の場合は、リソースを個別に削除してください。

プロジェクトの削除

コンソール

  1. Google Cloud コンソールでプロジェクト ページに移動します。

    プロジェクトに移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、 [削除] をクリックします。

  3. ダイアログに PROJECT_ID と入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

gcloud

次のコマンドを実行します。PROJECT_ID はプロジェクト ID で置き換えます。

gcloud projects delete PROJECT_ID

リソースを個別に削除する

Console

ロードバランサを削除する

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. web-map の横のチェックボックスをオンにします。

  3. ページ上部にある [削除] ボタンをクリックします。

  4. バックエンド サービス、ヘルスチェック、SSL 証明書など、すべての追加リソースの横にあるチェックボックスをオンにします。

  5. [ロードバランサと選択したリソースを削除] をクリックします。

インスタンス グループを削除する

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

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

  2. [名前] の横にある上部のチェックボックスをオンにして、すべてのインスタンス グループを選択します。

  3. [削除] をクリックします。

  4. 確認ウィンドウで [削除] をクリックします。

外部 IP アドレスを解放する

  1. Google Cloud コンソールで、[外部 IP アドレス] ページに移動します。

    [外部 IP アドレス] に移動

  2. lb-ipv4-1lb-ipv6-1 の横にあるチェックボックスをオンにします。

  3. [静的アドレスを解放] をクリックします。

  4. 確認ウィンドウで [削除] をクリックします。

ファイアウォール ルールを削除する

  1. Google Cloud コンソールで [ファイアウォール ポリシー] ページに移動します。

    [ファイアウォール ポリシー] に移動

  2. fw-allow-health-check-and-proxyfw-allow-ssh の横にあるチェックボックスをオンにします。

  3. [削除] をクリックします。

  4. 確認ウィンドウで [削除] をクリックします。

VM インスタンスを削除する

  1. Google Cloud コンソールで [VM インスタンス] ページに移動します。

    [VM インスタンス] に移動

  2. [名前] の横にある上部のチェックボックスをオンにして、すべてのインスタンスを選択します。

  3. [削除] をクリックします。

  4. 確認ウィンドウで [削除] をクリックします。

VPC ネットワークを削除する

  1. Google Cloud コンソールの [VPC ネットワーク] ページに移動します。

    [VPC ネットワーク] に移動

  2. [lb-network] をクリックします。

  3. ネットワークの詳細ページで、[VPC ネットワークの削除] をクリックします。

  4. 確認ウィンドウで [削除] をクリックします。

gcloud

ロードバランサを削除する

ロードバランサを削除するには、ロードバランサの各コンポーネントをそれぞれ削除する必要があります。

  1. 特定した転送ルールを削除します。

    gcloud compute forwarding-rules delete https-content-rule \
        --global
    
    gcloud compute forwarding-rules delete https-content-ipv6-rule \
        --global
    
  2. グローバル外部 IP アドレスを削除します。

    gcloud compute addresses delete lb-ipv4-1 \
        --global
    
    gcloud compute addresses delete lb-ipv6-1 \
        --global
    
  3. ターゲット プロキシを削除します。

    gcloud compute target-https-proxies delete https-lb-proxy
    
  4. SSL 証明書を削除します。

    gcloud compute ssl-certificates delete www-ssl-cert
    
  5. URL マップを削除します。

    gcloud compute url-maps delete web-map
    
  6. バックエンド サービスを削除します。

    gcloud compute backend-services delete web-backend-service \
        --global
    
    gcloud compute backend-services delete video-backend-service \
        --global
    
  7. ヘルスチェックを削除します。

    gcloud compute health-checks delete http-basic-check
    

これですべてのロードバランサのリソースが削除されました。

インスタンス グループを削除する

以下に示すコマンドを繰り返して、4 つの非マネージド インスタンス グループを削除します。次のような名前、ゾーンの組み合わせを使用します。必要に応じて INSTANCE_GROUP_NAMEZONE を置き換えます。

  • 名前: ig-www-us、ゾーン: us-central1-b
  • 名前: ig-video-us、ゾーン: us-central1-b
  • 名前: ig-www-eu、ゾーン: europe-west1-b
  • 名前: ig-video-eu、ゾーン: europe-west1-b
gcloud compute instance-groups unmanaged delete INSTANCE_GROUP_NAME \
   --zone=ZONE

VM インスタンスを削除する

以下に示すコマンドを、次のような名前とゾーンの組み合わせを使用して繰り返し、8 つの VM を削除します。必要に応じて VM_NAMEZONE を置き換えます。

  • 名前: ig-www-us-01、ゾーン: us-central1-b
  • 名前: ig-www-us-02、ゾーン: us-central1-b
  • 名前: ig-video-us-01、ゾーン: us-central1-b
  • 名前: ig-video-us-02、ゾーン: us-central1-b
  • 名前: ig-www-eu-01、ゾーン: europe-west1-b
  • 名前: ig-www-eu-02、ゾーン: europe-west1-b
  • 名前: ig-video-eu-01、ゾーン: europe-west1-b
  • 名前: ig-video-eu-02、ゾーン: europe-west1-b
gcloud compute instances delete VM_NAME \
   --zone=ZONE

ファイアウォール ルールを削除する

両方のファイアウォール ルールを削除します。

gcloud compute firewall-rules delete fw-allow-health-check-and-proxy
gcloud compute firewall-rules delete fw-allow-ssh

VPC ネットワークを削除する

  1. us-subnet を削除する

    gcloud compute networks subnets delete us-subnet \
    --region=us-central1
    
  2. eu-subnet を削除する

    gcloud compute networks subnets delete eu-subnet \
    --region=europe-west1
    
  3. VPC ネットワークを削除します。

    gcloud compute networks delete lb-network
    

これでプロジェクトで設定したすべてのリソースが削除されました。

次のステップ