内部 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 と呼ぶこともあります)。

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

    • IP アドレスは、バックエンド インスタンス グループと同じサブネットから取得できます(必須ではありません)。
    • IP アドレスは、--purpose フラグが INTERNAL_HTTPS_LOAD_BALANCER に設定されている予約済みプロキシ専用サブネットから取得しないでください。
  • リージョン ターゲット HTTP(S) プロキシは、クライアントからの HTTP(S) 接続を解除します。HTTP(S) プロキシは、URL マップを参照してトラフィックをバックエンドにルーティングする方法を決定します。ターゲット HTTPS プロキシは、SSL 証明書を使用してクライアントに対する認証を行います。

    ロードバランサは、元のクライアント リクエストのホストヘッダーを保持します。また、ロードバランサは 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(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(S) 負荷分散には次の 2 種類のタイムアウトがあります。
  • 構成可能な HTTP バックエンド サービス タイムアウト。ロードバランサがバックエンドから完全な HTTP レスポンスが返されるまで待機する時間です。バックエンド サービス タイムアウトのデフォルト値は 30 秒です。次のいずれかの状況では、タイムアウトを長くすることを検討してください。

    • バックエンドが HTTP レスポンスを返すのに時間がかかることが予想される場合。
    • jsonPayload.statusDetail client_timed_out による HTTP 408 レスポンスが表示される場合。
    • 接続が WebSocket にアップグレードされた場合。

    ロードバランサ経由で送信される WebSocket トラフィックのバックエンド サービスのタイムアウトは、アイドル状態かどうかにかかわらず、WebSocket 接続をオープン状態に保てる最長時間として解釈されます。詳細については、バックエンド サービスの設定をご覧ください。

  • TCP セッション タイムアウト。この値は 10 分(600 秒)に固定されています。このセッション タイムアウトは keep-alive タイムアウトまたはアイドル タイムアウトと呼ばれることもあります。バックエンド サービスの設定の変更では、セッション タイムアウトの値は構成できません。バックエンドによって接続が早期に閉じられないようにするには、バックエンドによって使用されているウェブサーバー ソフトウェアで keep-alive タイムアウトを 600 秒より長い時間に構成する必要があります。このタイムアウトは WebSocket には適用されません

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

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

ロードバランサは、バックエンド サービス タイムアウトに達したときなど、特定の状況で失敗した GET リクエストを再試行します。失敗した POST リクエストは再試行されません。再試行回数は 2 回に制限されています。再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。

詳細については、内部 HTTP(S) 負荷分散のロギングとモニタリングをご覧ください。

WebSocket のサポート

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

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

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

WebSocket 接続のタイムアウトは、ロードバランサの構成可能なバックエンド サービス タイムアウトによって異なります。デフォルトは 30 秒です。このタイムアウトは、WebSocket 接続が使用中かどうかに関係なく WebSocket 接続に適用されます。バックエンド サービス タイムアウトとその構成方法の詳細については、タイムアウトと再試行をご覧ください。

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

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

バックエンド サービスは、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 ネットワークを使用し、ロードバランサと同じリージョンに存在する必要があります。

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

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

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

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

  • 中間ルーター VM(ルーティング アプライアンスなど)から内部 HTTP(S) ロードバランサにリクエストを送信する場合は、次のようにルーティング アプライアンスを構成する必要があります。

    1. リクエスト パケットを内部 HTTP(S) ロードバランサに送信する前に、ソース ネットワーク アドレス変換(SNAT)を行うように、ルーター VM (ルーティング アプライアンス)を構成します。
    2. 内部 HTTP(S) ロードバランサから送信されたレスポンス パケットを配信する際に、宛先ネットワーク アドレス変換(DNAT)を行うようにルーター VM を構成します。

次のステップ