内部アプリケーション ロードバランサの概要

このドキュメントでは、内部アプリケーション ロードバランサの構成に必要なコンセプトについて説明します。

Google Cloud 内部アプリケーション ロードバランサは、プロキシベースのレイヤ 7 ロードバランサです。これを使用すると、1 つの内部 IP アドレスの背後でサービスを実行し、スケールできます。この内部アプリケーション ロードバランサは、Compute Engine、Google Kubernetes Engine（GKE）、Cloud Run などのさまざまな Google Cloud プラットフォームでホストされているバックエンドに HTTP / HTTPS のトラフィックを分散します。詳細については、アプリケーション ロードバランサの概要: ユースケースをご覧ください。

運用モード

内部アプリケーション ロードバランサは、次のモードで構成できます。

  • リージョン内部アプリケーション ロードバランサ。これは、オープンソースの Envoy プロキシをベースにマネージド サービスとして実装されるリージョン ロードバランサです。リージョン モードでは、すべてのクライアントとバックエンドが指定されたリージョンに配置されるため、リージョンのコンプライアンスが必要な場合に役立ちます。このロードバランサを使用すると、HTTP(S) パラメータに基づく豊富なトラフィック制御機能が使用できます。ロードバランサの構成を終えると、トラフィックのニーズに応じて Envoy プロキシが自動的に割り当てられます。

  • クロスリージョン内部アプリケーション ロードバランサこれは、オープンソースの Envoy プロキシでマネージド サービスとして実装されるマルチリージョン ロードバランサです。クロスリージョン モードを使用すると、グローバルに分散しているバックエンド サービスにトラフィックをロードバランスできます。たとえば、最も近いバックエンドにトラフィックを転送するトラフィック管理ができます。このロードバランサは高可用性も実現します。バックエンドを複数のリージョンに配置すると、単一リージョンにおける障害を回避できます。1 つのリージョンのバックエンドが停止した場合、トラフィックを別のリージョンにフェイルオーバーできます。クロスリージョン内部アプリケーション ロードバランサはプレビュー版です。

    次の表に、リージョン モードとクロスリージョン モードの重要な違いを示します。

    機能 リージョン内部アプリケーション ロードバランサ クロスリージョン内部アプリケーション ロードバランサ
    ロードバランサの仮想 IP アドレス（VIP） 特定の Google Cloud リージョンのサブネットから割り振られます。 特定の Google Cloud リージョンのサブネットから割り振られます。

    複数のリージョンの VIP アドレスは、同じグローバル バックエンド サービスを共有できます。DNS ベースのグローバル ロード バランシングを構成するには、DNS ルーティング ポリシーを使用して、クライアント リクエストを最も近い VIP アドレスに転送します。
    クライアント アクセス デフォルトでは、グローバルにアクセス可能ではありません。
    必要に応じて、グローバル アクセスを有効にすることができます。    		 常にグローバルにアクセス可能任意の Google Cloud リージョンのクライアントがロードバランサにトラフィックを送信できます。
    ロードバランスされたバックエンド リージョン バックエンド。
    ロードバランサは、ロードバランサのプロキシと同じリージョンにあるバックエンドにのみトラフィックを送信できます。    		 グローバル バックエンド。
    ロードバランサは、任意のリージョンのバックエンドにトラフィックを送信できます。
    高可用性とフェイルオーバー 同じリージョン内の正常なバックエンドへの自動フェイルオーバー。 同一または異なるリージョンの正常なバックエンドへの自動フェイルオーバー。

モードを特定する

Cloud コンソール

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

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

  2. [ロードバランサ] タブに、ロードバランサのタイプ、プロトコル、リージョンが表示されます。リージョンが空の場合、ロードバランサはクロスリージョン モードになっています。次の表に、ロードバランサのモードを識別する方法を示します。

    ロードバランサ モード ロードバランサの種類 アクセスタイプ リージョン
    リージョン内部アプリケーション ロードバランサ アプリケーション 内部 リージョンを指定
    クロスリージョン内部アプリケーション ロードバランサ アプリケーション 内部

gcloud

  1. ロードバランサのモードを確認するには、次のコマンドを実行します。

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

    コマンド出力で、ロード バランシング スキーム、リージョン、ネットワーク ティアを確認します。次の表に、ロードバランサのモードを識別する方法を示します。

    ロードバランサ モード ロード バランシング スキーム 転送ルール
    リージョン内部アプリケーション ロードバランサ INTERNAL_MANAGED リージョン
    クロスリージョン内部アプリケーション ロードバランサ INTERNAL_MANAGED グローバル

アーキテクチャとリソース

次の図は、各モードの内部アプリケーション ロードバランサに必要な Google Cloud リソースを示しています。

リージョン

この図は、プレミアム ティアにリージョン内部アプリケーション ロードバランサをデプロイした場合のコンポーネントを示しています。

リージョン内部アプリケーション ロードバランサのコンポーネント。
リージョン内部アプリケーション ロードバランサのコンポーネント（クリックして拡大）。

クロスリージョン

次の図は、同じ VPC ネットワーク内のプレミアム ティアにクロスリージョン内部アプリケーション ロードバランサをデプロイした場合のコンポーネントを示しています。各グローバル転送ルールは、クライアントの接続に使用するリージョン IP アドレスを使用します。

クロスリージョン内部アプリケーション ロードバランサ。
クロスリージョン内部アプリケーション ロードバランサのコンポーネント（クリックして拡大）。

各内部アプリケーション ロードバランサは、次の Google Cloud 構成リソースを使用します。

プロキシ専用サブネット

前の図では、プロキシ専用サブネットには、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。内部アプリケーション ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを 1 つ作成する必要があります。

次の表に、リージョン モードとクロスリージョン モードでのプロキシ専用サブネットの違いを示します。

ロードバランサ モード プロキシ専用サブネットの --purpose フラグの値
リージョン内部アプリケーション ロードバランサ

REGIONAL_MANAGED_PROXY

リージョン ロードバランサとクロスリージョン ロードバランサで同じサブネットを共有することはできません

リージョンと VPC ネットワーク内のすべてのリージョン Envoy ベースのロードバランサは、同じプロキシ専用サブネットを共有します。
クロスリージョン内部アプリケーション ロードバランサ

GLOBAL_MANAGED_PROXY

リージョン ロードバランサとクロスリージョン ロードバランサで同じサブネットを共有することはできません

ロードバランサが構成される各リージョンで、クロスリージョンの Envoy ベースのロードバランサにはプロキシ専用サブネットが必要です。同じリージョンとネットワークにあるクロスリージョン ロードバランサ プロキシは、同じプロキシ専用サブネットを共有します。

さらに、

  • プロキシ専用サブネットは Envoy プロキシにのみ使用され、バックエンドには使用されません。
  • リージョンと VPC ネットワーク内のすべての内部アプリケーション ロードバランサのバックエンド VM またはエンドポイントは、プロキシ専用サブネットからの接続を受信します。
  • 内部アプリケーション ロードバランサの IP アドレスは、プロキシ専用サブネットにはありません。ロードバランサの IP アドレスは、後述する内部マネージド転送ルールで定義します。

転送ルールと IP アドレス

転送ルールは、IP アドレス、ポート、プロトコルに基づいて、ターゲット プロキシとバックエンド サービスからなるロード バランシング構成にトラフィックをルーティングします。

各転送ルールは、アプリケーションの DNS レコードで使用できる単一のリージョン IP アドレスを参照します。使用できる静的 IP アドレスを予約するか、Cloud Load Balancing から割り当てます。推奨されているのは静的 IP アドレスの予約です。静的アドレスを予約しない場合、転送ルールを削除して新しく作り直すたびに DNS レコードを編集して、新しく割り当てられたエフェメラル IP アドレスに直す必要があるからです。

クライアントは IP アドレスとポートを使用してロードバランサの Envoy プロキシに接続します。転送ルールの IP アドレスはロードバランサの IP アドレスです（仮想 IP アドレスまたは VIP と呼ぶこともあります）。ロードバランサに接続するクライアントは、HTTP バージョン 1.1 以降を使用する必要があります。サポートされているプロトコルの一覧については、ロードバランサの機能をご覧ください。

転送ルールに関連付けられた内部 IP アドレスは、バックエンドと同じネットワークとリージョンにあるサブネットから取得できます。

アプリケーション ロードバランサの転送ルールでは、1～65535 の単一ポートを参照できます。複数のポートをサポートするには、複数の転送ルールを構成する必要があります。複数の転送ルールを構成して、同じ内部 IP アドレス（VIP）を使用し、同じターゲット HTTP(S) プロキシを参照できます。ただし、IP アドレス、ポート、プロトコルの組み合わせが各転送ルールで一意である必要があります。これにより、共有 URL マップを持つ単一のロードバランサを複数のアプリケーションのプロキシとして使用できます。

次の表に、リージョン モードとクロスリージョン モードの転送ルールの違いを示します。

ロードバランサ モード 転送ルール、IP アドレス、プロキシ専用サブネット --purpose クライアントからロードバランサのフロントエンドへのルーティング
リージョン内部アプリケーション ロードバランサ

リージョン転送ルール

リージョン IP アドレス

ロード バランシング スキーム:

INTERNAL_MANAGED

プロキシ専用サブネット --purpose:

REGIONAL_MANAGED_PROXY

IP アドレス --purpose:

SHARED_LOADBALANCER_VIP

グローバル アクセスを有効にして、任意のリージョンのクライアントがロードバランサにアクセスできるようにします。また、バックエンドもロードバランサと同じリージョンに存在する必要があります。
クロスリージョン内部アプリケーション ロードバランサ

グローバル転送ルール

リージョン IP アドレス

ロード バランシング スキーム:

INTERNAL_MANAGED

プロキシ専用サブネット --purpose:

GLOBAL_MANAGED_PROXY

IP アドレス --purpose:

SHARED_LOADBALANCER_VIP

グローバル アクセスはデフォルトで有効になっており、任意のリージョンのクライアントがロードバランサにアクセスできます。バックエンドは複数のリージョンに配置できます。

ターゲット プロキシ

ターゲット HTTP(S) プロキシは、クライアントからの HTTP(S) 接続を終端します。HTTP(S) プロキシは、URL マップを参照してトラフィックをバックエンドに転送する方法を決定します。ターゲット HTTPS プロキシは、SSL 証明書を使用してクライアントに対して自身を認証します。

ロードバランサは、元のクライアント リクエストの Host ヘッダーを保持します。また、ロードバランサは X-Forwarded-For ヘッダーに 2 つの IP アドレスを追加します。

  • ロードバランサに接続するクライアントの IP アドレス
  • ロードバランサの転送ルールの IP アドレス

受信リクエストに X-Forwarded-For ヘッダーがない場合、ヘッダーの値はこの 2 つの IP アドレスだけです。リクエストに X-Forwarded-For ヘッダーがある場合、ロードバランサへのリクエスト中にプロキシによって記録された IP アドレスなどの他の情報は 2 つの IP アドレスの前に保持されます。ロードバランサは、このヘッダーの最後の 2 つの IP アドレスより前の IP アドレスを確認しません。

バックエンド サーバーとしてプロキシを実行している場合、このプロキシは通常、より多くの情報を X-Forwarded-For ヘッダーに追加するため、ソフトウェアでこれを考慮する必要がある場合があります。ロードバランサからプロキシされたリクエストは、プロキシ専用サブネットの IP アドレスから送信されます。バックエンド インスタンスのプロキシでは、このアドレスに加えて、バックエンド インスタンスの独自の IP アドレスを記録する場合があります。

アプリケーションで処理する必要があるトラフィックの種類に応じて、ターゲット HTTP プロキシまたはターゲット HTTPS プロキシを使用して、ロードバランサを構成できます。

次の表は、各モードで内部アプリケーション ロードバランサに必要なターゲット プロキシ API を示しています。

ターゲット プロキシ リージョン内部アプリケーション ロードバランサ クロスリージョン内部アプリケーション ロードバランサ
HTTP regionTargetHttpProxies グローバル targetHttpProxies
HTTPS regionTargetHttpsProxies グローバル targetHttpsProxies

SSL 証明書

ターゲット HTTPS プロキシを使用する内部アプリケーション ロードバランサには、ロードバランサの構成の一部として秘密鍵と SSL 証明書が必要です。

次の表に、各モードの内部アプリケーション ロードバランサが必要とする SSL 証明書のタイプを示します。

ロードバランサ モード SSL 証明書の種類
リージョン内部アプリケーション ロードバランサ

Compute Engine リージョン SSL 証明書

Certificate Manager のセルフマネージド証明書と Google マネージド証明書。

Certificate Manager では、次のタイプの Google マネージド証明書がサポートされています。

ロードバランサ認証を使用する Google マネージド証明書はサポートされていません。
クロスリージョン内部アプリケーション ロードバランサ

Certificate Manager のセルフマネージド証明書と Google マネージド証明書。

Certificate Manager では、次のタイプの Google マネージド証明書がサポートされています。

ロードバランサ認証を使用した Google マネージド証明書はサポートされていません。

Compute Engine SSL 証明書はサポートされていません。

URL マップ

ターゲット HTTP(S) プロキシは、URL マップを使用して、HTTP 属性（リクエストパス、Cookie、ヘッダーなど）に基づいてルーティングを決定します。このルーティングの決定に基づいて、プロキシは特定のバックエンド サービスにクライアントのリクエストを転送します。URL マップには、ヘッダーの書き換え、クライアントへのリダイレクトの送信、タイムアウト ポリシーの構成など、追加のアクションを指定できます。

次の表に、各モードで内部アプリケーション ロードバランサが必要とする URL マップのタイプを示します。

ロードバランサ モード URL マップのタイプ
リージョン内部アプリケーション ロードバランサ リージョン URL マップ
クロスリージョン内部アプリケーション ロードバランサ グローバル URL マップ

バックエンド サービス

バックエンド サービスは、Compute Engine VM を含むインスタンス グループ、Cloud Run、GKE コンテナを含む NEG など、正常なバックエンドにリクエストを分散します。

バックエンド サービスは、HTTP、HTTPS または HTTP/2 の各プロトコルをサポートします。HTTP/2 は TLS でのみサポートされます。クライアントとバックエンドで同じリクエスト プロトコルを使用する必要はありません。たとえば、クライアントは HTTP/2 を使用してロードバランサにリクエストを送信できます。また、ロードバランサはこれらのトラフィックを HTTP/1.1 でバックエンドに送信できます。

次の表に、各モードの内部アプリケーション ロードバランサが必要とするバックエンド サービスタイプを示します。

ロードバランサ モード バックエンド サービスのタイプ
リージョン内部アプリケーション ロードバランサ リージョン バックエンド サービス
クロスリージョン内部アプリケーション ロードバランサ グローバル バックエンド サービス

次の表に、各モードで内部アプリケーション ロードバランサがサポートするバックエンド機能を示します。


ロードバランサ モード		 バックエンド サービスでサポートされるバックエンド バックエンド バケットのサポート Google Cloud Armor のサポート Cloud CDN のサポート IAP のサポート Service Extensions のサポート
インスタンス グループ ゾーン NEG インターネット NEG サーバーレス NEG ハイブリッド NEG Private Service Connect NEG
リージョン内部アプリケーション ロードバランサ 1
Cloud Run
クロスリージョン内部アプリケーション ロードバランサ 2
Cloud Run
（任意のリージョン。バックエンド サービスごとに 1 つのみ）

1 GKE で GCE_VM_IP_PORT タイプのエンドポイントを使用します。スタンドアロン ゾーン NEG を使用するか、Ingress を使用します。

2 GKE で GCE_VM_IP_PORT タイプのエンドポイントを使用します。スタンドアロン ゾーン NEG を使用します。

詳細については、バックエンド サービスの概要をご覧ください。

バックエンドと VPC ネットワーク

すべてのバックエンドは同じ VPC ネットワークに配置する必要があります。VPC ネットワーク ピアリングで接続された VPC ネットワークであっても、異なる VPC ネットワークにバックエンドを配置することはできません。ピアリングされた VPC ネットワーク内のクライアント システムがロードバランサにアクセスする方法については、内部アプリケーション ロードバランサと接続されたネットワークをご覧ください。

バックエンドのサブセット化

バックエンドのサブセット化は、リージョン内部アプリケーション ロードバランサでサポートされている機能で、各プロキシ インスタンスにバックエンドのサブセットを割り当てることでパフォーマンスとスケーラビリティを向上させます。

デフォルトでは、バックエンドのサブセット化は無効になっています。この機能を有効にする方法については、内部アプリケーション ロードバランサのバックエンドのサブセット化をご覧ください。

ヘルスチェック

各バックエンド サービスは、ロードバランサからの接続を受信するバックエンドの稼働状況を定期的に監視するヘルスチェックを指定します。これにより、処理不能なバックエンドにリクエストが送信されるリスクを軽減できます。ヘルスチェックでは、アプリケーション自体が動作するかどうかはチェックされません。

ヘルスチェック プローブでは、上り（内向き）許可ファイアウォール ルールを作成してヘルスチェック プローブがバックエンド インスタンスに到達できるようにする必要があります。通常、ヘルスチェック プローブは Google の一元化されたヘルスチェックの仕組みにより発信されます。ただし、ハイブリッド NEG の場合、ヘルスチェックはプロキシ専用サブネットから開始します。詳細については、ハイブリッド NEG の概要の分散 Envoy ヘルスチェックをご覧ください。

ヘルスチェック プロトコル

必須ではなく、常に可能というわけでもありませんが、バックエンド サービスのプロトコルに一致するプロトコルでヘルスチェックを使用することをおすすめします。たとえば、バックエンドに対する HTTP/2 の接続性を最も正確にテストできるのは HTTP/2 ヘルスチェックです。一方、ハイブリッド NEG バックエンドを使用する内部アプリケーション ロードバランサは、gRPC ヘルスチェックをサポートしていません。サポートされているヘルスチェック プロトコルの一覧については、ロード バランシング機能をご覧ください。

次の表に、各モードで内部アプリケーション ロードバランサによってサポートされているヘルスチェックのスコープを示します。

ロードバランサ モード ヘルスチェックのタイプ
リージョン内部アプリケーション ロードバランサ リージョン
クロスリージョン内部アプリケーション ロードバランサ グローバル

ヘルスチェックの詳細については、以下をご覧ください。

ファイアウォール ルール

内部アプリケーション ロードバランサには、次のファイアウォール ルールが必要です。

これらの範囲については、ファイアウォール ルールの要件にいくつかの例外があります。

  • ハイブリッド NEG では、Google のヘルスチェック プローブ範囲を許可リストに登録する必要はありません。ただし、1 つのバックエンド サービスでハイブリッド NEG とゾーン NEG の組み合わせを使用している場合は、ゾーン NEG の Google ヘルスチェック プローブ範囲を許可リストに登録する必要があります。
  • リージョン インターネット NEG の場合、ヘルスチェックは省略可能です。リージョン インターネット NEG を使用するロードバランサからのトラフィックは、プロキシ専用サブネットから発信されます。このトラフィックは、Cloud NAT により、手動または自動的に割り振られた NAT IP アドレスに NAT 変換されます。このトラフィックには、ヘルスチェック プローブと、ロードバランサからバックエンドへのユーザー リクエストの両方が含まれます。詳細については、リージョン NEG: 下り（外向き）に Cloud NAT を使用するをご覧ください。

クライアント アクセス

クライアントは、同じネットワークまたは、VPC ネットワーク ピアリングを使用して接続された VPC ネットワークに配置できます。

リージョン内部アプリケーション ロードバランサの場合、クライアントは、デフォルトでロードバランサと同じリージョンに存在しなければなりません。グローバル アクセスを有効にして、任意のリージョンのクライアントがロードバランサにアクセスできるようにします。

クロスリージョン内部アプリケーション ロードバランサの場合、グローバル アクセスはデフォルトで有効になっています。任意のリージョンのクライアントがロードバランサにアクセスできます。

次の表に、リージョン内部アプリケーション ロードバランサのクライアント アクセスの概要を示します。

グローバル アクセスが無効な場合 グローバル アクセスが有効な場合
クライアントはロードバランサと同じリージョンになければなりません。また、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。 クライアントはどのリージョンにでも配置できます。ただし、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。
オンプレミス クライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを介してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、ロードバランサと同じリージョンになければなりません。 オンプレミス クライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを使用してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、どのリージョンにでも配置できます。

共有 VPC のアーキテクチャ

内部アプリケーション ロードバランサは、共有 VPC を使用するネットワークをサポートします。組織は、共有 VPC を使用して複数のプロジェクトのリソースを共通の VPC ネットワークに接続できるため、そのネットワークの内部 IP を使用して、安全で効率的な相互通信を行うことができます。共有 VPC についてまだよく理解していない場合は、共有 VPC の概要のドキュメントをご覧ください。

共有 VPC ネットワーク内で内部アプリケーション ロードバランサを構成するには、多くの方法があります。デプロイの種類に関係なく、ロードバランサのすべてのコンポーネントを同じ組織に配置する必要があります。

サブネットと IP アドレス フロントエンド コンポーネント バックエンド コンポーネント

共有 VPC ホスト プロジェクトで必要なネットワークとサブネット（プロキシ専用サブネットを含む）を作成します。

ロードバランサの内部 IP アドレスは、ホスト プロジェクトまたはサービス プロジェクトのいずれかで定義できますが、ホスト プロジェクト内の目的の共有 VPC ネットワークのサブネットを使用する必要があります。アドレス自体は、参照先サブネットのプライマリ IP 範囲から取得します。

 リージョン内部 IP アドレス、転送ルール、ターゲット HTTP(S) プロキシ、関連付けられた URL マップは、同じプロジェクトで定義する必要があります。このプロジェクトは、ホスト プロジェクトまたはサービス プロジェクトにできます。 次のいずれかを行います。
  • バックエンド サービスとバックエンド（インスタンス グループ、サーバーレス NEG、その他のサポートされているバックエンド タイプ）を、フロントエンド コンポーネントと同じサービス プロジェクトに作成します。
  • 必要な数のサービス プロジェクトで、バックエンド サービスとバックエンド（インスタンス グループ、サーバーレス NEG、その他のサポートされているバックエンド タイプ）を作成します。1 つの URL マップで複数のプロジェクトのバックエンド サービスを参照できます。このタイプのデプロイは、プロジェクト間のサービス参照と呼ばれます。

各バックエンド サービスは、参照するバックエンドと同じプロジェクトで定義する必要があります。バックエンド サービスに関連するヘルスチェックも、バックエンド サービスと同じプロジェクトで定義する必要があります。

共有 VPC ホスト プロジェクトですべてのロード バランシング コンポーネントとバックエンドを作成できますが、このタイプのデプロイではネットワーク管理とサービス開発の責任が分離されません。

サービス プロジェクト内のすべてのロードバランサ コンポーネントとバックエンド

次のアーキテクチャ図は、すべてのロードバランサのコンポーネントとバックエンドがサービス プロジェクト内にある標準の共有 VPC デプロイを示しています。このデプロイタイプは、すべてのアプリケーション ロードバランサでサポートされています。

ロードバランサは、ホスト プロジェクトの IP アドレスとサブネットを使用します。クライアントは、ロードバランサと同じ共有 VPC ネットワークとリージョンにある場合、内部アプリケーション ロードバランサにアクセスできます。クライアントは、ホスト プロジェクト、接続されたサービス プロジェクト、または任意の接続されたネットワークに配置できます。

共有 VPC ネットワーク上の内部アプリケーション ロードバランサ
共有 VPC ネットワーク上の内部アプリケーション ロードバランサ

共有 VPC 環境におけるサーバーレス バックエンド**

サーバーレス NEG バックエンドを使用する内部アプリケーション ロードバランサの場合、バッキング Cloud Run サービス、バックエンド サービス、サーバーレス NEG は同じサービス プロジェクトに存在する必要があります。ロードバランサのフロントエンド コンポーネント（転送ルール、ターゲット プロキシ、URL マップ）は、ホスト プロジェクト、バックエンド コンポーネントと同じサービス プロジェクト、または同じ共有 VPC 環境内のサービス プロジェクトのいずれかに作成できます。

プロジェクト間のサービス参照

このモデルでは、ロードバランサのフロントエンドと URL マップはホスト プロジェクトまたはサービス プロジェクトに存在します。ロードバランサのバックエンド サービスとバックエンドは、共有 VPC 環境のプロジェクト間で分散できます。プロジェクト間のバックエンド サービスは 1 つの URL マップで参照できます。これは、プロジェクト間のサービス参照と呼ばれます。

プロジェクト間のサービス参照を使用すると、組織は 1 つの一元的なロードバランサを構成し、複数の異なるプロジェクトに分散された数百のサービスにトラフィックをルーティングできます。トラフィック ルーティングのルールおよびポリシーはすべて、1 つの URL マップで一元管理できます。ロードバランサをホスト名と SSL 証明書の組み合わせの 1 つと関連付けることもできます。このため、アプリケーションのデプロイに必要なロードバランサの数を最適化することで、管理性の向上や、運用費および必要な割り当て量の削減につながります。

さらに、プロジェクトを部門ごとに分けて、組織内のロールを分離することもできます。サービス オーナーはサービス プロジェクト内のサービス構築に、ネットワーク チームは別のプロジェクト内のロードバランサのプロビジョニングと維持に専念できます。これらのプロジェクトは、プロジェクト間のサービス参照によって接続できます。

サービス オーナーは、サービスの公開に対する自律性を維持し、ロードバランサを介してサービスにアクセスできるユーザーを制御できます。この仕組みは、Compute ロードバランサ サービス ユーザーのロール（roles/compute.loadBalancerServiceUser）という特別な IAM ロールによって実現されます。

（プロジェクト間のサービス参照の有無にかかわらず）内部アプリケーション ロードバランサの共有 VPC を構成する方法については、共有 VPC を使用して内部アプリケーション ロードバランサを設定するをご覧ください。

プロジェクト間のサービス参照に関する既知の制限事項

  • バックエンド サービスにリージョン インターネット NEG バックエンドがある場合、プロジェクト間のバックエンド サービスを参照することはできません。他のバックエンド タイプはすべてサポートされています。
  • Google Cloud では、複数のプロジェクトで同じ名前を使用するリソース（バックエンド サービスなど）は区別されません。したがって、プロジェクト間のサービス参照を使用する場合は、組織内のプロジェクト間で一意のバックエンド サービス名を使用することをおすすめします。

例 1: ロードバランサのフロントエンドとバックエンドが別のサービス プロジェクトに存在する

次のデプロイの例では、ロードバランサのフロントエンドと URL マップがサービス プロジェクト A に作成され、URL マップはサービス プロジェクト B のバックエンド サービスを参照しています。

この場合、サービス プロジェクト A のネットワーク管理者またはロードバランサ管理者は、サービス プロジェクト B のバックエンド サービスにアクセスする必要があります。サービス プロジェクト B の管理者は、サービス プロジェクト B のバックエンド サービスを参照するサービス プロジェクト A のロードバランサ管理者に compute.loadBalancerServiceUser IAM ロールを付与します。

サービス プロジェクト内のロードバランサのフロントエンドと URL マップ
ロードバランサのフロントエンドとバックエンドが別のサービス プロジェクトに存在する

例 2: ホスト プロジェクト内のロードバランサのフロントエンドと、サービス プロジェクトのバックエンド

このタイプのデプロイでは、ロードバランサのフロントエンドと URL マップがホスト プロジェクトに作成され、バックエンド サービス（とバックエンド）がサービス プロジェクトに作成されます。

この場合、ホスト プロジェクトのネットワーク管理者またはロードバランサ管理者は、サービス プロジェクトのバックエンド サービスにアクセスする必要があります。サービス プロジェクトの管理者は、サービス プロジェクトのバックエンド サービスを参照するホスト プロジェクト A のロードバランサ管理者に compute.loadBalancerServiceUser IAM ロールを付与します。

ホスト プロジェクト内のロードバランサのフロントエンドと URL マップ
ホスト プロジェクト内のロードバランサのフロントエンドと URL マップ

タイムアウトと再試行

内部アプリケーション ロードバランサは、次の種類のタイムアウトをサポートします。

タイムアウトの種類と説明 デフォルト値 カスタム値のサポート
バックエンド サービスのタイムアウト

リクエストとレスポンスのタイムアウトロードバランサが HTTP リクエストの最初のバイトをバックエンドに送信してから、バックエンドが HTTP レスポンスの最後のバイトを返すまでの最長時間を表します。リクエストまたはレスポンスのタイムアウト内に HTTP レスポンス全体がロードバランサに返されなかった場合、残りのレスポンス データは破棄されます。
  • バックエンド サービスのサーバーレス NEG の場合: 60 分
  • バックエンド サービスの他のバックエンド タイプの場合: 30 秒
クライアント HTTP キープアライブ タイムアウト
クライアントとロードバランサのマネージド Envoy プロキシの間の TCP 接続がアイドル状態である最長時間（同じ TCP 接続が複数の HTTP リクエストに使用される場合があります）。		 10 分（600 秒）
バックエンド HTTP キープアライブ タイムアウト
ロードバランサのマネージド Envoy プロキシとバックエンド間の TCP 接続がアイドル状態である最長時間。（同じ TCP 接続が複数の HTTP リクエストに使用される場合があります）。		 10 分（600 秒）

バックエンド サービスのタイムアウト

構成可能なバックエンド サービス タイムアウトは、バックエンドが HTTP リクエストを処理し、対応する HTTP レスポンスを返すまでロードバランサが待機する最長時間を表します。サーバーレス NEG を除き、バックエンド サービスのタイムアウトのデフォルト値は 30 秒です。

たとえば、500 MB のファイルをダウンロードする場合、バックエンド サービスのタイムアウトの値が 90 秒であれば、ロードバランサはバックエンドが 500 MB ファイル全体を 90 秒以内で配信すると想定します。バックエンド サービスのタイムアウトには、バックエンドが完全な HTTP レスポンスを送信するのに十分でない時間を構成することもできます。この状況では、少なくともロードバランサがバックエンドから HTTP レスポンス ヘッダーを受け取った場合、ロードバランサは完全なレスポンス ヘッダーと、バックエンド サービスのタイムアウト内で取得できる可能な限り多くのレスポンス本文を返します。

バックエンド サービスのタイムアウトは、HTTP レスポンスを処理するためにバックエンドが待機する必要のある最長時間に設定する必要があります。バックエンドで実行されているソフトウェアが HTTP リクエストを処理し、レスポンス全体を返すためにさらに時間が必要な場合は、バックエンド サービスのタイムアウト値を増やす必要があります。

バックエンド サービスのタイムアウトは、1～2,147,483,647 秒の値を受け入れます。ただし、あまりに大きい値は実用的な構成オプションではありません。バックエンド サービスがタイムアウトになるまで基盤となる TCP 接続が維持されるとは限りません。クライアント システムでは、TCP 接続の持続時間に依存するのではなく、再試行ロジックを実装する必要があります。

内部アプリケーション ロードバランサで使用される WebSocket 接続の場合、アクティブな WebSocket 接続はバックエンド サービスのタイムアウトに従いません。アイドル状態の WebSocket 接続は、バックエンド サービスのタイムアウト後に終了します。

Google Cloud では、サービスを提供する Envoy ソフトウェア タスクを定期的に再起動したり、その数を変更しています。バックエンド サービスのタイムアウト値が長いほど、Envoy タスクの再起動または置換によって TCP 接続が終了する可能性が高くなります。

バックエンド サービスのタイムアウトを構成するには、次のいずれかの方法を使用します。

クライアント HTTP キープアライブ タイムアウト

クライアント HTTP キープアライブ タイムアウトは、TCP 接続が（ダウンストリーム）クライアントと Envoy プロキシ間でアイドル状態になっている最長時間を表します。クライアントの HTTP キープアライブ タイムアウト値は 600 秒に固定されています。

HTTP キープアライブ タイムアウトは TCP アイドル タイムアウトとも呼ばれています。

ロードバランサのクライアント HTTP キープアライブ タイムアウトは、ダウンストリーム クライアントまたはプロキシで使用される HTTP キープアライブ（TCP アイドル）タイムアウトよりも大きくする必要があります。ダウンストリーム クライアントの HTTP キープアライブ（TCP アイドル）タイムアウトがロードバランサのクライアント HTTP キープアライブ タイムアウトよりも大きい場合、競合状態が発生する可能性があります。ダウンストリーム クライアントから見ると、確立済みの TCP 接続が、ロードバランサで許可されている時間よりも長くアイドル状態になる可能性があります。ロードバランサが TCP 接続が終了したとみなすと、ダウンストリーム クライアントはパケットを送信することができます。その場合、ロードバランサは TCP reset（RST）パケットで応答します。

バックエンド HTTP キープアライブ タイムアウト

内部アプリケーション ロードバランサは、（ダウンストリーム）クライアントと Envoy プロキシ間の最初の TCP 接続と、Envoy プロキシとバックエンド間の 2 番目の TCP 接続を使用するプロキシです。

ロードバランサの 2 番目の TCP 接続は、リクエストごとに終了せず、複数の HTTP リクエストとレスポンスを処理できるように、開いている状態を維持する場合があります。バックエンド HTTP キープアライブ タイムアウトは、ロードバランサとバックエンド間の TCP アイドル タイムアウトを定義します。バックエンド HTTP キープアライブ タイムアウトは WebSocket には適用されません。

バックエンド キープアライブ タイムアウトは 10 分（600 秒）に固定されており、変更できません。ロードバランサのバックエンド キープアライブ タイムアウトは、バックエンドで実行されているソフトウェアで使用されるキープアライブ タイムアウトよりも短くする必要があります。これにより、バックエンドのオペレーティング システムが TCP reset（RST）で TCP 接続を終了する可能性のある競合状態を回避できます。ロードバランサのバックエンド キープアライブ タイムアウトは構成できないため、HTTP キープアライブ（TCP アイドル）タイムアウト値が 600 秒を超えるように、バックエンド ソフトウェアを構成する必要があります。

次の表に、一般的なウェブサーバー ソフトウェアのキープアライブ タイムアウト値を変更するために必要な変更を示します。

ウェブサーバー ソフトウェア パラメータ デフォルト設定 推奨される設定
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

再試行

再試行を構成するには、URL マップで再試行ポリシーを使用します。デフォルトの再試行回数（numRetries）は 1 回です。デフォルトのタイムアウト（perTryTimeout）は 30 秒です。perTryTimeout は最大で 24 時間に構成できます。

再試行ポリシーがない場合、HTTP 本文のないリクエスト（GET リクエストなど）が HTTP 502、503、または 504 のレスポンスを返したときに 1 回だけ再試行されます。

HTTP POST リクエストは再試行されません。

再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。

詳細については、内部アプリケーション ロードバランサのロギングとモニタリングをご覧ください。

接続ネットワークへのアクセス

接続ネットワークから VPC ネットワーク内の内部アプリケーション ロードバランサにアクセスする方法は、次のとおりです。

  • VPC ネットワーク ピアリング
  • Cloud VPN と Cloud Interconnect

詳細な例については、内部アプリケーション ロードバランサと接続ネットワークをご覧ください。

フェイルオーバー

バックエンドが異常な状態になると、トラフィックは正常なバックエンドに自動的にリダイレクトされます。

次の表に、各モードでのフェイルオーバーの動作を示します。

ロードバランサ モード フェイルオーバーの動作 すべてのバックエンドが異常な場合の動作
リージョン内部アプリケーション ロードバランサ

同じリージョン内の正常なバックエンドへの自動フェイルオーバー。

Envoy プロキシは、構成されたトラフィック分散に基づいて、リージョン内の正常なバックエンドにトラフィックを送信します。

 HTTP 503 を返す
クロスリージョン内部アプリケーション ロードバランサ

同じリージョンまたは他のリージョン内の正常なバックエンドへの自動フェイルオーバー。

トラフィックは、構成されたトラフィック分散に基づいて、複数のリージョンにまたがる正常なバックエンド間で分散されます。

 HTTP 503 を返す

高可用性とクロスリージョン フェイルオーバー

クロスリージョン内部アプリケーション ロードバランサを使用すると、複数のリージョンのバックエンドを使用するグローバル バックエンド サービスを作成することで、サービスの可用性を向上させることができます。特定のリージョンのバックエンドが停止した場合、トラフィックは別のリージョンに正常にフェイルオーバーされます。

クロスリージョン フェイルオーバーのデプロイは次のとおりです。

  • VPC ネットワークの us-west1 リージョンにフロントエンド VIP アドレスを持つクロスリージョン内部アプリケーション ロードバランサがあります。クライアントも us-west1 リージョンにあります。
  • Google Cloud リージョンの us-west1 と us-east1 のバックエンドを参照するグローバル バックエンド サービス。
  • us-west1 リージョンのバックエンドが停止している場合、トラフィックは us-east1 リージョンにフェイルオーバーされます。
クロスリージョン フェイルオーバー デプロイでのクロスリージョン内部アプリケーション ロードバランサ。
クロスリージョン フェイルオーバー デプロイでのクロスリージョン内部アプリケーション ロードバランサ（クリックして拡大）

クロスリージョンの内部アプリケーション ロードバランサは、別のリージョンのプロキシとバックエンドからクライアントにトラフィックを提供することで、リージョンの完全な停止からアプリケーションを保護します。

高可用性のデプロイ例は次のとおりです。

  • VPC ネットワーク内の us-west1 リージョンと us-east1 リージョンにフロントエンド VIP を持つクロスリージョン内部アプリケーション ロードバランサがあります。クライアントは us-west1 リージョンにあります。
  • 2 つのリージョンのフロントエンド VIP を使用してロードバランサにアクセスできるようにし、DNS ルーティング ポリシーを使用してクライアントに最適な VIP を返すことができます。クライアントが地理的に最も近い VIP を使用するように設定する場合は、位置情報ルーティング ポリシーを使用します。
  • DNS ルーティング ポリシーは、リージョンの停止時に VIP が応答していないかどうかを検出し、次に最適な VIP をクライアントに返して、リージョンの停止中でもアプリケーションを維持できます。
高可用性デプロイでのクロスリージョン内部アプリケーション ロードバランサ。
高可用性デプロイでのクロスリージョン内部アプリケーション ロードバランサ（クリックして拡大）

WebSocket のサポート

Google Cloud の HTTP(S) ベースのロードバランサでは、HTTP または HTTPS をバックエンドへのプロトコルとして使用する場合に、WebSocket プロトコルの組み込みサポートを使用できます。ロードバランサに、WebSocket 接続のプロキシを構成する必要はありません。

WebSocket プロトコルは、クライアントとサーバー間で全二重の通信チャネルを提供します。HTTP(S) リクエストによってチャネルが開始されます。プロトコルの詳細については、RFC 6455 をご覧ください。

ロードバランサで HTTP(S) クライアントからの WebSocket Upgrade リクエストが認識され、続いてバックエンド インスタンスから Upgrade の正常終了のレスポンスが送られた場合、現在の接続の存続期間の間、ロードバランサによって双方向トラフィックがプロキシされます。バックエンド インスタンスから Upgrade の正常終了のレスポンスが返されない場合、ロードバランサが接続を終了します。

WebSocket のセッション アフィニティは、他のリクエストの場合と同じように機能します。詳細については、セッション アフィニティをご覧ください。

gRPC のサポート

gRPC は、リモート プロシージャ コール用のオープンソース フレームワークです。これは HTTP/2 標準に基づいています。gRPC のユースケースには次のものがあります。

  • 低レイテンシでスケーラビリティの高い分散システム
  • クラウド サーバーと通信するモバイル クライアントの開発
  • 正確かつ効率的で言語に依存しない新しいプロトコルの設計
  • 拡張、認証、ロギングを可能にする階層型の設計

Google Cloud アプリケーションで gRPC を使用するには、HTTP/2 経由でエンドツーエンドでリクエストをプロキシする必要があります。手順は次のとおりです。

  1. HTTPS ロードバランサを構成します。
  2. ロードバランサからバックエンドへのプロトコルとして HTTP/2 を有効にします。

ロードバランサは、ALPN TLS 拡張を使用して SSL handshake の一部としてクライアントと HTTP/2 をネゴシエートします。

ロードバランサは、ロードバランサとバックエンド インスタンスの間で HTTP/2 を使用するように構成されたロードバランサで、一部のクライアントと HTTPS をネゴシエートしたり安全でない HTTP リクエストを受け入れたりすることもあります。これらの HTTP または HTTPS リクエストはロードバランサによって変換され、リクエストは HTTP/2 経由でバックエンド インスタンスにプロキシされます。

バックエンドで TLS を有効にする必要があります。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。

TLS サポート

デフォルトでは、HTTPS ターゲット プロキシは、クライアントの SSL リクエストを終端するときに TLS 1.0、1.1、1.2、1.3 のみを受け入れます。

内部アプリケーション ロードバランサが HTTPS をバックエンド サービス プロトコルとして使用する場合は、TLS 1.0、1.1、1.2、1.3 をバックエンドにネゴシエートできます。

制限事項

  • リージョンの 1 つのゾーン内のクライアントからのリクエストが、クライアントと同じゾーンにあるバックエンドに送信される保証はありません。セッション アフィニティによってゾーン間の通信は減少しません。

  • 内部アプリケーション ロードバランサは、次の機能に対応していません。

  • 内部アプリケーション ロードバランサは、TLS でのみ HTTP/2 をサポートします。

  • 内部アプリケーション ロードバランサに接続するクライアントは、HTTP バージョン 1.1 以降を使用する必要があります。HTTP 1.0 はサポートされていません。

  • プロキシ専用サブネットで IP アドレスが不足していても、Google Cloud は警告を表示しません。

  • 内部アプリケーション ロードバランサが使用する内部転送ルールには、ポートを 1 つだけ設定する必要があります。

  • 内部アプリケーション ロードバランサは Cloud Trace をサポートしていません。

  • 共有 VPC 環境で Cloud Run と内部アプリケーション ロードバランサを使用する場合、サービス プロジェクトのスタンドアロン VPC ネットワークは、他のサービス（同じ共有 VPC 環境内のサービス プロジェクト内）にデプロイされた他の Cloud Run サービスにトラフィックを送信できます。これは既知の問題であり、この形式のアクセスは今後ブロックされます。

  • バックエンド サービスがタイムアウトになるまで基盤となる TCP 接続が維持されるとは限りません。クライアント システムでは、TCP 接続の持続時間に依存するのではなく、再試行ロジックを実装する必要があります。

次のステップ