内部 HTTP(S) 負荷分散の概要

Google Cloud 内部 HTTP(S) 負荷分散は、プロキシベースのリージョンのレイヤ 7 ロードバランサです。内部 IP アドレスの背後でサービスを実行し、スケーリングできます。

内部 HTTP(S) 負荷分散は、Compute Engine と Google Kubernetes Engine(GKE)でホストされているバックエンドに HTTP/HTTPS トラフィックを分散します。ロードバランサには、内部 IP アドレスを使用して Virtual Private Cloud(VPC)ネットワークの特定のリージョンでのみアクセスできます。

内部 HTTP(S) 負荷分散は、オープンソースの Envoy プロキシをベースにしたマネージド サービスです。HTTP(S) パラメータに基づく、さまざまなトラフィック制御機能を使用できるようになっています。ロードバランサを構成すると、トラフィックの要件に応じて Envoy プロキシが自動的に割り当てられます。

内部 HTTP(S) ロードバランサは、次のものから構成されます。

  • クライアントがトラフィックを送信する内部 IP アドレス。この IP アドレスにアクセスできるのは、ロードバランサと同じリージョンにあるクライアントだけです。内部クライアントのリクエストは、ネットワークとリージョンの内部に保持されます。
  • ロードバランサがトラフィックを転送する 1 つ以上のバックエンド サービス。バックエンドは、Compute Engine VM、Compute Engine VM のグループ(インスタンス グループ)または GKE ノード(ネットワーク エンドポイント グループ、NEG)です。これらのバックエンドは、ロードバランサと同じリージョンに配置する必要があります。
レイヤ 7 ベースの負荷分散を使用した内部サービス(クリックして拡大)
レイヤ 7 ベースの負荷分散を使用した内部サービス(クリックして拡大)

負荷分散サービスを提供するため、次の 2 つの追加コンポーネントが使用されます。

  • URL マップ。特定のバックエンド サービスにマッピングされるトラフィック制御ルールを定義します。このルールは、HTTP ヘッダーなどのレイヤ 7 パラメータに基づいて作成されます。ロードバランサは、URL マップを使用して受信リクエストを評価し、トラフィックをバックエンド サービスに転送します。また、リダイレクトなどの追加の処理も行います。
  • ヘルスチェック。バックエンドのステータスを定期的に確認し、応答不能なバックエンドにクライアント トラフィックが送信されるリスクを減らします。

内部 HTTP(S) 負荷分散に固有の制限については、制限事項のセクションをご覧ください。

Google Cloud ロードバランサとの相違点については、次のドキュメントをご覧ください。

ユースケース

内部 HTTP(S) 負荷分散には多くのユースケースがあります。このセクションでは、そのいくつかについて説明します。その他の例については、トラフィック管理のユースケースをご覧ください。

パスベース ルーティングによる負荷分散

一般的なユースケースの 1 つとして、サービス間のトラフィックの負荷分散があります。この例では、内部クライアントが動画と画像のコンテンツをリクエストしています。同じベース URL(mygcpservice.internal)を使用してますが、パスは異なります(/video/images)。

内部 HTTP(S) 負荷分散の URL マップに従い、パス /video に対するリクエストは動画のバックエンド サービスに送信され、/images に対するリクエストは画像のバックエンド サービスに送信されます。次の例では、動画と画像のバックエンド サービスは Compute Engine VM で処理されていますが、GKE Pod を使用して処理することもできます。

内部クライアントがロードバランサの内部 IP アドレスにリクエストを送信すると、ロードバランサはこのロジックに従ってリクエストを評価し、適切なバックエンド サービスにリクエストを送信します。

このユースケースは次の図のようになります。

レイヤ 7 ベースの負荷分散を使用した内部(マイクロ)サービス(クリックして拡大)
レイヤ 7 ベースの負荷分散を使用した内部(マイクロ)サービス

レガシー サービスのモダナイゼーション

内部 HTTP(S) 負荷分散は、レガシー アプリケーションのモダナイゼーションに効果的なツールです。

このようなアプリケーションとして、簡単に更新できない規模の大きいモノリシック アプリケーションがあります。この場合、レガシー アプリケーションの前に内部 HTTP(S) ロードバランサをデプロイできます。次に、ロードバランサのトラフィック制御機能を使用して、レガシー アプリケーションの機能に代わる新しいマイクロサービスにトラフィックのサブセットを転送します。

まず始めに、デフォルトですべてのトラフィックがレガシー アプリケーションにルーティングされるように、ロードバランサの URL マップを構成します。これにより、既存の動作が維持されます。レガシー アプリケーションに代わる新しいサービスがデプロイされたら、URL マップを更新し、トラフィックの一部をこの新しいサービスにルーティングします。

ここで、レガシー アプリケーションに動画処理機能があり、内部クライアントが /video にリクエストを送信したときに、この機能が処理される場合について考えてみましょう。この動画サービスは、次のようにマイクロサービスに分割できます。

  1. レガシー アプリケーションの前に内部 HTTP(S) 負荷分散を追加します。
  2. レガシー アプリケーションに代わる動画処理マイクロサービスを作成します。
  3. ロードバランサの URL マップを更新し、パス /video に対するすべてのリクエストをレガシー アプリケーションではなく、新しいマイクロサービスにルーティングします。

別の代替サービスを開発する場合も、この URL マップを更新します。時間の経過とともに、レガシー アプリケーションにルーティングされるリクエストが少なくなっていきます。最終的には、レガシー アプリケーションが提供するすべての機能に代替サービスが存在する状態になります。この時点で、レガシー アプリケーションを廃止できます。

3 層ウェブサービス

内部 HTTP(S) 負荷分散を使用して、従来の 3 層ウェブサービスをサポートできます。次の例は、3 種類の Google Cloud ロードバランサを使用して 3 つの層をスケーリングする方法を示しています。それぞれの層で、トラフィックの種類に応じてロードバランサのタイプが決まります。

  • ウェブ層: インターネットから入ってきたトラフィックが、外部の HTTP(S) ロードバランサによって負荷分散されます。

  • アプリケーション層: リージョン内部の HTTP(S) ロードバランサを使用して、アプリケーション層がスケーリングされます。

  • データベース層: データベース層は、内部 TCP / UDP ロードバランサを使用してスケーリングされます。

次の図に、トラフィックがどのようにそれぞれの層を通過するのかを示します。

  1. 外部 HTTP(S) ロードバランサは、インターネットから入ってきたトラフィックを複数のリージョンにまたがるウェブ フロントエンド インスタンス グループに配信します。
  2. フロントエンドが、リージョン内部の一連の HTTP(S) ロードバランサに HTTP(S) トラフィックを配信します。
  3. 内部 HTTP(S) ロードバランサが、トラフィックをミドルウェア インスタンス グループに配信します。
  4. ミドルウェア インスタンス グループが、トラフィックを内部 TCP / UDP ロードバランサに送り、トラフィックをデータ ストレージ クラスタに負荷分散します。
多層アプリケーションにおける内部層でのレイヤ 7 ベースのルーティング(クリックして拡大)
多層アプリケーションにおける内部層でのレイヤ 7 ベースのルーティング

アクセスの例

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

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

詳細な例については、内部 HTTP(S) 負荷分散と接続されたネットワークをご覧ください。

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

次の図は、内部 HTTP(S) ロードバランサに必要な Google Cloud リソースを示しています。

内部 HTTP(S) 負荷分散コンポーネント(クリックして拡大)
内部 HTTP(S) 負荷分散コンポーネント

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

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

各内部 HTTP(S) ロードバランサは、次の Google Cloud 構成リソースを使用します。

  • 内部マネージド転送ルールは、内部 IP アドレス、ポート、リージョン ターゲット HTTP(S) プロキシを指定します。クライアントは IP アドレスとポートを使用してロードバランサの Envoy プロキシに接続します。転送ルールの IP アドレスはロードバランサの IP アドレス(場合により仮想 IP アドレスまたは VIP と呼ばれる)です。

  • リージョン ターゲット HTTP(S) プロキシ。クライアントからリクエストを受信します。HTTP(S) プロキシは、URL マップを使用してリクエストを評価し、トラフィックのルーティングを決定します。プロキシは、SSL 証明書を使用して通信の認証を行うこともできます。

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

  • リージョン バックエンド サービス。良好な状態のバックエンド(Compute Engine VM を含むインスタンス グループまたは GKE コンテナを含む NEG)にリクエストを分散します。

  • 1 つ以上のバックエンドをバックエンド サービスに接続する必要があります。バックエンドは、次のいずれかの構成のインスタンス グループまたは NEG になります。

    • 管理対象のインスタンス グループ(ゾーン単位またはリージョン単位)
    • 管理対象外のインスタンス グループ(ゾーン単位)
    • ネットワーク エンドポイント グループ(ゾーン単位)

    インスタンス グループと NEG を同じバックエンド サービスで使用することはできません。

  • リージョン ヘルスチェック。バックエンドの準備状況を定期的に監視します。これにより、処理不能なバックエンドにリクエストが送信されるリスクを軽減できます。

SSL 証明書

HTTPS ベースの負荷分散を使用している場合は、ターゲット HTTPS プロキシに 1 つ以上の SSL 証明書をインストールする必要があります。

ターゲット HTTPS プロキシではこれらの証明書を使用して、ロードバランサとクライアントとの間の通信を保護します。

SSL 証明書の上限と割り当てについては、負荷分散の割り当てページの SSL 証明書をご覧ください。

最高レベルのセキュリティを実現するには、HTTPS ロードバランサのデプロイにエンドツーエンドの暗号化を使用します。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。

Google がユーザー トラフィックを暗号化する方法に関する一般的な情報については、Google Cloud での転送中の暗号化ホワイト ペーパーをご覧ください。

ファイアウォール ルール

内部 HTTP(S) ロードバランサには、次のファイアウォール ルールが必要です。

タイムアウトと再試行

バックエンド サービスのタイムアウトは、HTTP(S) トラフィックのリクエスト / レスポンスのタイムアウトです。これは、ロードバランサがバックエンドから完全なレスポンスが返されるのを待機する時間です。

たとえば、バックエンド サービスのタイムアウトの値がデフォルト値の 30 秒である場合、バックエンドにはリクエストに応答するための時間が 30 秒あります。ロードバランサは、バックエンドが接続を閉じるか、レスポンス ヘッダーをロードバランサに送信する前にタイムアウトになると、HTTP GET リクエストを 1 回再試行します。バックエンドがレスポンス ヘッダーを送信する場合、またはバックエンドに送信されるリクエストが HTTP GET リクエストでない場合、ロードバランサは再試行しません。バックエンドがまったく応答しない場合、ロードバランサは HTTP 5xx レスポンスをクライアントに返します。これらのロードバランサでは、バックエンドがリクエストに応答するまでの時間を増減する場合は、タイムアウト値を変更します。

トラフィック タイプ、スキーム、スコープ

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

内部 HTTP(S) ロードバランサのスコープはグローバルではなくリージョンであるため、クライアントとバックエンドの VM またはエンドポイントはすべて同じリージョン内になければなりません。

共有 VPC のアーキテクチャ

内部 HTTP(S) 負荷分散では、共有 VPC を使用するネットワークがサポートされます。共有 VPC についてまだよく理解していない場合は、共有 VPC の概要のドキュメントをご覧ください。大まかな流れは次のとおりです。

  • ホスト プロジェクトを指定し、1 つ以上の他のサービス プロジェクトをホスト プロジェクトに関連付けます。
  • ホスト プロジェクト管理者が、1 つ以上の共有 VPC ネットワークとサブネットを作成し、これらをサービス プロジェクトと共有します。
  • サービス プロジェクトの適格リソースは共有 VPC ネットワーク内のサブネットを使用できます。

内部 HTTP(S) 負荷分散のコンテキストでは、共有 VPC ネットワーク内で負荷分散を構成する方法が 2 つあります。ロードバランサとそのバックエンド インスタンスは、サービス プロジェクト内でもホスト プロジェクト内でも作成できます。

サービス プロジェクト内でのロードバランサとバックエンド

このモデルでは、サービス プロジェクトでロードバランサとバックエンド インスタンスをデプロイします。次に、共有 VPC ネットワークを使用するようにロードバランサとバックエンド インスタンスを構成します。

このデプロイモデルは、共有 VPC ネットワークのデプロイモデルの一般的なユースケースに厳密に従っています。つまり、ネットワーク管理とサービス開発の責任が分離されています。このデプロイモデルでは、ネットワーク管理者が内部 IP 空間を安全かつ効率的に割り当てることができ、ネットワーク管理者とサービス デベロッパーの責任が明確に分離されます。

共有 VPC ネットワークでの内部 HTTP(S) 負荷分散
共有 VPC ネットワークでの内部 HTTP(S) 負荷分散

ホスト プロジェクト

ホスト プロジェクト管理者は次の作業を行います。

  • ホスト プロジェクト内で共有 VPC ネットワークを設定します。
  • 共有 VPC ネットワークのサブネットをプロビジョニングします。
  • 共有 VPC ネットワークのファイアウォール ルールを構成します。

サービス プロジェクト

  • サービス プロジェクト管理者は、サービス プロジェクト内でロードバランサ(転送ルール、ターゲット HTTP(S) プロキシ、URL マップ、バックエンド サービス)とバックエンド インスタンスを作成します。
  • これらの負荷分散リソースとバックエンド インスタンスで、共有 VPC ホスト プロジェクトの共有ネットワークとサブネットを参照します。

このパターンでは、サービス デベロッパーが独自のサービス プロジェクト内で負荷分散サービスを作成できます。サービス開発チームは、ホスト プロジェクトの管理者を関与させずに、ロードバランサの構成を更新したり、バックエンド インスタンスに変更を加えたりすることもできます。

クライアントがロードバランサと同じ共有 VPC ネットワーク内にある場合は、ホスト プロジェクトとサービス プロジェクトのどちらにでも属すことができます。こうしたクライアントは、ロードバランサのプライベート IP アドレスを使用して負荷分散サービスにアクセスできます。

共有 VPC ネットワークの内部 HTTP(S) ロードバランサを構成する方法については、共有 VPC を使用した内部 HTTP(S) 負荷分散の設定をご覧ください。

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

このネットワーク デプロイモデルでは、ネットワーク、ロードバランサ、バックエンドのすべてがホスト プロジェクトに属します。この設定は有効なものの、ネットワーク管理とサービス開発の責任が分離されないため、一般的な共有 VPC のデプロイには適していません。

それでもホスト プロジェクト内でロードバランサとそのバックエンドを実行する必要がある場合は、内部 HTTP(S) 負荷分散の設定の手順に従ってください。

制限事項

  • 内部 HTTP(S) 負荷分散は、リージョン レベルで動作します。

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

  • 内部 HTTP(S) 負荷分散は、次の機能と互換性がありません。

  • 共有 VPC のホスト プロジェクトまたはサービス プロジェクト内で内部 HTTP(S) ロードバランサを作成する場合:

    • すべての負荷分散コンポーネントとバックエンドは、同じプロジェクト内に存在する必要があります。つまり、すべてがホスト プロジェクトに属するか、すべてがサービス プロジェクトに属する必要があります。たとえば、一方のプロジェクトにロードバランサの転送ルールをデプロイし、他方のプロジェクトにバックエンド インスタンスを作成することはできません。

    • クライアントは、ホスト プロジェクト、接続されたサービス プロジェクト、または任意の接続されたネットワークのいずれかに配置できます。すべてのクライアントは同じ共有 VPC ネットワークを使用し、ロードバランサと同じリージョンに存在する必要があります。

    • サービス プロジェクト内でロードバランサを作成または表示するには、gcloud または API を使用する必要があります。Google Cloud Console を使用してサービス プロジェクト内でロードバランサを作成または表示することはできません。

  • WebSocket プロトコルはサポートされていません。

  • 内部 HTTP(S) ロードバランサは、TLS でのみ HTTP/2 をサポートします。

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

  • 各 VPC ネットワークでは、内部のマネージド転送ルールごとに固有の IP アドレスを設定する必要があります。詳細については、共通の IP アドレスを持つ複数の転送ルールをご覧ください。

  • 内部 HTTP(S) ロードバランサが使用する内部転送ルールには、ポートが 1 つだけ必要です。

次のステップ