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

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

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

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

内部クライアントがロードバランサの内部 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) ロードバランサに必要な Google Cloud リソースを示しています。

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

内部 HTTP(S) ロードバランサを定義するリソースは次のとおりです。

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

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

  • 内部 HTTP(S) 負荷分散を使用している場合、HTTP(S) プロキシはリージョン SSL 証明書を使用して、クライアントに ID を提供します。ターゲット HTTP(S) プロキシは、ドキュメント番号までの SSL 証明書をサポートします。

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

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

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

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

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

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

  • プロキシ専用サブネット。この IP アドレスが、ロードバランサ プロキシからバックエンドにトラフィックを送信する際の送信元になります。内部 HTTP(S) ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを 1 つ作成する必要があります。Google では、このサブネットだけでなく、リージョン内で共有されるすべての内部 HTTP(S) ロードバランサも管理しています。このサブネットを使用してバックエンドをホストすることはできません。

ファイアウォール ルール

内部 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 またはエンドポイントはすべて同じリージョン内になければなりません。

制限事項

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

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

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

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

    • クライアント VM は、ホスト プロジェクトまたは接続されたサービス プロジェクトのいずれかに配置できます。クライアント VM は、ロードバランサと同じ共有 VPC ネットワークと同じリージョンを使用する必要があります。
    • ロードバランサのコンポーネントとバックエンドは、すべてホスト プロジェクト内にある必要があります。ロードバランサが共有 VPC ネットワークを使用するときに、サービス プロジェクトに内部 HTTP(S) ロードバランサのコンポーネントがありません。この点で、これは他の Google Cloud ロードバランサと異なります。
    • 共有 VPC ネットワーク内のホスト プロジェクトがプロキシ専用サブネットのオーナーになり、サブネットの作成を行います(purpose=INTERNAL_HTTPS_LOAD_BALANCER)。
  • WebSocket プロトコルはサポートされていません。

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

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

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

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

次のステップ