Trusted Cloud by S3NS 内部プロキシ ネットワーク ロードバランサは、オープンソースの Envoy プロキシ ソフトウェアと Andromeda ネットワークの仮想化スタックを活用したプロキシベースのロードバランサです。
内部プロキシ ネットワーク ロードバランサはレイヤ 4 ロードバランサで、同じ VPC ネットワーク内のクライアントまたは VPC ネットワークに接続されているクライアントのみがアクセスできるリージョン内部 IP アドレスの背後で TCP サービス トラフィックを実行し、スケーリングできます。ロードバランサは、まず Envoy プロキシでクライアントとロードバランサ間の TCP 接続を終端します。プロキシは Trusted Cloud by S3NS、オンプレミス、その他のクラウド環境でホストされているバックエンドへの 2 番目の TCP 接続を開きます。その他のユースケースについては、プロキシ ネットワーク ロードバランサの概要をご覧ください。
運用モード
このロードバランサはリージョン モードで使用できます。以降は、リージョン内部プロキシ ネットワーク ロードバランサと呼びます。このロードバランサは、オープンソースの Envoy プロキシをベースにマネージド サービスとして実装されています。リージョン モードでは、すべてのクライアントとバックエンドが指定されたリージョンに配置されます。このロードバランサは、1 つの位置情報のみからコンテンツを配信する場合に使用します（コンプライアンスで規制されている場合など）。
アーキテクチャ
次の図は、内部プロキシ ネットワーク ロードバランサに必要な Trusted Cloud リソースを示しています。
リージョン
この図は、プレミアム ティアにリージョン内部プロキシ ネットワーク ロードバランサをデプロイした場合のコンポーネントを示しています。
プロキシ専用サブネット
前の図では、プロキシ専用サブネットには、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。Envoy ベースの内部プロキシ ネットワーク ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを作成する必要があります。
次の表に、内部プロキシ ネットワーク ロードバランサのプロキシ専用サブネットの要件を示します。
| ロードバランサ モード | プロキシ専用サブネットの --purpose フラグの値 |
|---|---|
| リージョン内部プロキシ ネットワーク ロードバランサ |
リージョン ロードバランサとクロスリージョン ロードバランサで同じサブネットを共有することはできません リージョンと VPC ネットワーク内のすべてのリージョン Envoy ベースのロードバランサは、同じプロキシ専用サブネットを共有します。 |
さらに、
- プロキシ専用サブネットは Envoy プロキシにのみ使用され、バックエンドには使用されません。
- リージョンと VPC ネットワーク内のすべての内部プロキシ ネットワーク ロードバランサのバックエンド仮想マシン（VM）インスタンスまたはエンドポイントは、プロキシ専用サブネットからの接続を受信します。
- 内部プロキシ ネットワーク ロードバランサの IP アドレスは、プロキシ専用サブネットにはありません。ロードバランサの IP アドレスは内部マネージド転送ルールによって定義されます。
転送ルールと IP アドレス
転送ルールは、IP アドレス、ポート、プロトコルに基づいて、ターゲット プロキシとバックエンド サービスからなるロード バランシング構成にトラフィックをルーティングします。
IP アドレスの指定。各転送ルールは、アプリケーションの DNS レコードで使用できる単一のリージョン IP アドレスを参照します。使用できる静的 IP アドレスを予約するか、Cloud Load Balancing から割り当てます。推奨されているのは静的 IP アドレスの予約です。静的アドレスを予約しない場合、転送ルールを削除して新しく作り直すたびに DNS レコードを編集して、新しく割り当てられたエフェメラル IP アドレスに直す必要があるからです。
クライアントは IP アドレスとポートを使用してロードバランサの Envoy プロキシに接続します。転送ルールの IP アドレスはロードバランサの IP アドレスです（仮想 IP アドレスまたは VIP と呼ぶこともあります）。ロードバランサに接続するクライアントは TCP を使用する必要があります。サポートされているプロトコルの一覧については、ロードバランサの機能の比較をご覧ください。
転送ルールに関連付けられた内部 IP アドレスは、バックエンドと同じネットワークとリージョンにあるサブネットから取得できます。
ポートの指定。内部プロキシ ネットワーク ロードバランサで使用する各転送ルールは、1～65535 の単一ポートを参照できます。複数のポートをサポートするには、複数の転送ルールを構成する必要があります。
次の表に、内部プロキシ ネットワーク ロードバランサの転送ルールの要件を示します。
| ロードバランサ モード | 転送ルール、IP アドレス、プロキシ専用サブネット --purpose |
クライアントからロードバランサのフロントエンドへのルーティング |
|---|---|---|
| リージョン内部プロキシ ネットワーク ロードバランサ |
ロード バランシング スキーム:
プロキシ専用サブネット
IP アドレス
|
また、バックエンドもロードバランサと同じリージョンに存在する必要があります。 |
転送ルールと VPC ネットワーク
このセクションでは、外部アプリケーション ロードバランサで使用される転送ルールを VPC ネットワークに関連付ける方法について説明します。
| ロードバランサ モード | VPC ネットワークの関連付け |
|---|---|
| クロスリージョン内部プロキシ ネットワーク ロードバランサ リージョン内部プロキシ ネットワーク ロードバランサ |
リージョン内部 IPv4 アドレスは常に VPC ネットワーク内に存在します。転送ルールを作成するときに、内部 IP アドレスを取得するサブネットを指定する必要があります。このサブネットは、作成したプロキシ専用サブネットと同じリージョンおよび VPC ネットワークに存在している必要があります。このため、暗黙的なネットワークの関連付けが存在します。 |
ターゲット プロキシ
内部プロキシ ネットワーク ロードバランサは、クライアントからの TCP 接続を終端し、バックエンドへの新しい接続を作成します。デフォルトでは、元のクライアントの IP アドレスとポート情報は保持されません。PROXY プロトコルを使用してこの情報を保持できます。ターゲット プロキシは、受信リクエストを直接ロードバランサのバックエンド サービスにルーティングします。
次の表に、内部プロキシ ネットワーク ロードバランサに必要なターゲット プロキシ API を示します。
| ロードバランサ モード | ターゲット プロキシ |
|---|---|
| リージョン内部プロキシ ネットワーク ロードバランサ | リージョン regionTargetTcpProxies |
バックエンド サービス
バックエンド サービスによって、受信トラフィックが 1 つ以上の関連バックエンドに振り向けられます。バックエンドは、インスタンス グループまたはネットワーク エンドポイント グループのいずれかになります。バックエンドには、接続に基づいて完全性を定義するためのバランシング モード情報が含まれています（たとえば、グループ バックエンドのみの場合は使用率）。
各内部プロキシ ネットワーク ロードバランサには、単一のバックエンド サービス リソースが含まれます。
次の表に、内部プロキシ ネットワーク ロードバランサのバックエンド サービスの要件を示します。
| ロードバランサ モード | バックエンド サービスのタイプ |
|---|---|
| リージョン内部プロキシ ネットワーク ロードバランサ | リージョン regionBackendServices |
サポートされているバックエンド
バックエンド サービスは、次のタイプのバックエンドをサポートします。
| ロードバランサ モード | バックエンド サービスでサポートされるバックエンド | ||||||
|---|---|---|---|---|---|---|---|
| インスタンス グループ | ゾーン NEG | インターネット NEG | サーバーレス NEG | ハイブリッド NEG | GKE | ||
| リージョン内部プロキシ ネットワーク ロードバランサ |
GCE_VM_IP_PORT タイプのエンドポイント |
リージョン NEG のみ | |||||
すべてのバックエンドは同じ種類（インスタンス グループまたは NEG）である必要があります。異なるタイプのインスタンス グループ バックエンドを同時に使用することも、異なるタイプの NEG バックエンドを同時に使用することもできますが、同じバックエンド サービスでインスタンス グループと NEG バックエンドを併用することはできません。
同じバックエンド サービス内にゾーン NEG とハイブリッド NEG を混在させることはできます。
ユーザーへのサービスの中断を最小限に抑えるためには、バックエンド サービスでコネクション ドレインを有効にします。このような中断は、バックエンドの停止、手動による削除、オートスケーラーによる削除によって発生することがあります。コネクション ドレインを使用してサービスの中断を最小限に抑える方法については、コネクション ドレインを有効にするをご覧ください。
バックエンドと VPC ネットワーク
インスタンス グループ、ゾーン NEG、ハイブリッド接続 NEG の場合、すべてのバックエンドはバックエンド サービスと同じプロジェクトとリージョンに配置する必要があります。ただし、ロードバランサは、バックエンド サービスと同じプロジェクトで別の VPC ネットワークを使用するバックエンドを参照できます。 ロードバランサの VPC ネットワークとバックエンド VPC ネットワーク間の接続は、VPC ネットワーク ピアリング、Cloud VPN トンネル、Cloud Interconnect VLAN アタッチメントのいずれかを使用して構成できます。
バックエンド ネットワークの定義
- ゾーン NEG とハイブリッド NEG の場合、NEG の作成時に VPC ネットワークを明示的に指定します。
- マネージド インスタンス グループの場合、VPC ネットワークはインスタンス テンプレートで定義されます。
- 非マネージド インスタンス グループの場合、インスタンス グループの VPC ネットワークは、インスタンス グループに追加された最初の VM の
nic0インターフェースの VPC ネットワークと一致するように設定されます。
バックエンド ネットワークの要件
バックエンド ネットワークは、次のいずれかのネットワーク要件を満たしている必要があります。
バックエンドの VPC ネットワークは、転送ルールの VPC ネットワークと完全に一致する必要があります。
バックエンドの VPC ネットワークは、VPC ネットワーク ピアリングを使用して転送ルールの VPC ネットワークに接続する必要があります。転送ルールの VPC ネットワークのプロキシ専用サブネットと、バックエンド インスタンスまたはエンドポイントで使用されるサブネットとの通信を許可するには、サブネット ルート交換を構成する必要があります。
他のすべてのバックエンド タイプの場合、すべてのバックエンドを同じ VPC ネットワークとリージョンに配置する必要があります。
バックエンドとネットワーク インターフェース
インスタンス グループのバックエンドを使用する場合、パケットは常に nic0 に配信されます。nic0 以外のインターフェース（vNIC または Dynamic Network Interface）にパケットを送信するには、NEG バックエンドを使用します。
ゾーン NEG バックエンドを使用する場合、パケットは NEG のエンドポイントで表されるネットワーク インターフェースに送信されます。NEG エンドポイントは、NEG に明示的に定義された VPC ネットワークと同じ VPC ネットワークに存在する必要があります。
バックエンドと通信するためのプロトコル
内部プロキシ ネットワーク ロードバランサのバックエンド サービスを構成するときに、バックエンド サービスがバックエンドとの通信に使用するプロトコルを設定します。ロードバランサは指定したプロトコルのみを使用し、他のプロトコルとの接続をネゴシエートしません。内部プロキシ ネットワーク ロードバランサは、バックエンドとの通信に TCP のみをサポートしています。
ヘルスチェック
各バックエンド サービスは、ロードバランサからの接続を受信するバックエンドの稼働状況を定期的に監視するヘルスチェックを指定します。これにより、処理不能なバックエンドにリクエストが送信されるリスクを軽減できます。ヘルスチェックでは、アプリケーション自体が動作するかどうかはチェックされません。
ヘルスチェック プロトコル
必須ではなく、常に可能というわけでもありませんが、バックエンド サービスのプロトコルに一致するプロトコルでヘルスチェックを使用することをおすすめします。たとえば、TCP ヘルスチェックはバックエンドへの TCP 接続を最も正確にテストできます。サポートされているヘルスチェック プロトコルの一覧については、ロードバランサの機能の比較ページにあるヘルスチェック セクションをご覧ください。
次の表では、各モードの内部プロキシ ネットワーク ロードバランサでサポートされているヘルスチェックのスコープをまとめています。
| ロードバランサ モード | ヘルスチェックのタイプ |
|---|---|
| リージョン内部プロキシ ネットワーク ロードバランサ | リージョン regionHealthChecks |
ヘルスチェックの詳細については、以下をご覧ください。
ファイアウォール ルール
内部プロキシ ネットワーク ロードバランサには、次のファイアウォール ルールが必要です。
- Google ヘルスチェック プローブからのトラフィックを許可する上り（内向き）許可ルール。特定のヘルスチェック プローブの IP アドレス範囲と、プローブからのトラフィックを許可する必要がある理由については、プローブの IP 範囲とファイアウォール ルールをご覧ください。
- プロキシ専用サブネットからのトラフィックを許可するための上り（内向き）許可ルール
これらのファイアウォール ルールのポートは、次のように構成する必要があります。
各バックエンド サービスのヘルスチェックのための宛先ポートへのトラフィックを許可します。
インスタンス グループのバックエンドの場合: バックエンド サービスの名前付きポートと、各インスタンス グループの名前付きポートに関連付けられたポート番号とのマッピングによって、構成するポートを決定します。同じバックエンド サービスに割り当てられたインスタンス グループ間でポート番号が異なる可能性があります。
GCE_VM_IP_PORTNEG バックエンドの場合: エンドポイントのポート番号へのトラフィックを許可します。
これらのロードバランサのファイアウォール ルール要件には、いくつかの例外があります。
- ハイブリッド NEG では、Google のヘルスチェック プローブ範囲からのトラフィックを許可する必要はありません。ただし、1 つのバックエンド サービスでハイブリッド NEG とゾーン NEG の組み合わせを使用している場合は、ゾーン NEG の Google ヘルスチェック プローブ範囲からのトラフィックを許可する必要があります。
- リージョン インターネット NEG の場合、ヘルスチェックは省略可能です。リージョン インターネット NEG を使用するロードバランサからのトラフィックは、プロキシ専用サブネットから発信されます。このトラフィックは、Cloud NAT により、手動または自動的に割り振られた NAT IP アドレスに NAT 変換されます。このトラフィックには、ヘルスチェック プローブと、ロードバランサからバックエンドへのユーザー リクエストの両方が含まれます。詳細については、リージョン NEG: Cloud NAT ゲートウェイを使用するをご覧ください。
クライアント アクセス
クライアントは、同じネットワークまたは、VPC ネットワーク ピアリングを使用して接続された VPC ネットワークに配置できます。
リージョン内部プロキシ ネットワーク ロードバランサの場合、クライアントは、デフォルトでロードバランサと同じリージョンに存在しなければなりません。また、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。
オンプレミス クライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを使用してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、ロードバランサと同じリージョンになければなりません。
共有 VPC アーキテクチャ
内部プロキシ ネットワーク ロードバランサは、共有 VPC を使用するネットワークをサポートしています。共有 VPC を使用すると、ネットワーク管理者とサービス デベロッパーの責任を明確に分離できます。開発チームはサービス プロジェクトでのサービスの構築に集中し、ネットワーク インフラストラクチャ チームはロード バランシングのプロビジョニングと管理を行うことができます。共有 VPC についてまだよく理解していない場合は、共有 VPC の概要のドキュメントをご覧ください。
| IP アドレス | 転送ルール | ターゲット プロキシ | バックエンド コンポーネント |
|---|---|---|---|
内部 IP アドレスは、バックエンドと同じプロジェクトで定義する必要があります。 共有 VPC ネットワークでロードバランサを使用できるようにするには、内部 IP アドレスは、バックエンド VM が配置されている同じサービス プロジェクト内で定義する必要があります。さらに、ホスト プロジェクト内の目的の共有 VPC ネットワーク内のサブネットを参照する必要があります。アドレス自体は、参照先サブネットのプライマリ IP 範囲から取得します。 |
内部転送ルールは、バックエンドと同じプロジェクトで定義する必要があります。 共有 VPC ネットワークでロードバランサを使用できるようにするには、内部転送ルールは、バックエンド VM が配置されている同じサービス プロジェクト内で定義する必要があります。さらに、関連付けられている内部 IP アドレスが参照する同じサブネット（共有 VPC ネットワーク内）を参照する必要があります。 |
ターゲット プロキシは、バックエンドと同じプロジェクトで定義する必要があります。 | 共有 VPC のシナリオでは、バックエンド VM は通常、サービス プロジェクトに配置されます。そのサービス プロジェクトでは、リージョン内部のバックエンド サービスとヘルスチェックを定義する必要があります。 |
トラフィック分散
内部プロキシ ネットワーク ロードバランサは、次のようにバックエンドにトラフィックを分散します。
- 1 つのクライアントから発信された接続は、そのゾーン内の正常なバックエンド（インスタンス グループまたは NEG）が使用可能であり、容量があれば（バランシング モードによって判別されます）、同じゾーンに送信されます。リージョン内部プロキシ ネットワーク ロードバランサの場合、バランシング モードは
CONNECTION（インスタンス グループまたは NEG バックエンド）またはUTILIZATION（インスタンス グループ バックエンドのみ）になります。 - セッション アフィニティを構成している場合は、クライアントからの接続は同じバックエンドに送信されます。
- バックエンドが選択されると、ロード バランシング ポリシーに従ってインスタンス（インスタンス グループ）またはエンドポイント（NEG）間でトラフィックが分散されます。サポートされているロード バランシング ポリシー アルゴリズムについては、リージョン バックエンド サービス API ドキュメントの
localityLbPolicy設定をご覧ください。
セッション アフィニティ
セッション アフィニティでは、バックエンドが良好な状態で容量があれば、同じクライアントからのすべてのリクエストを同じバックエンドに送信するように、ロードバランサのバックエンド サービスを構成できます。
内部ネットワーク ロードバランサはクライアント IP アフィニティを提供します。これにより、バックエンドに容量があり、正常な状態を維持している限り、同じクライアント IP アドレスからのすべてのリクエストが同じバックエンドに転送されます。
フェイルオーバー
バックエンドが異常な状態になると、トラフィックは正常なバックエンドに自動的にリダイレクトされます。
次の表に、内部プロキシ ネットワーク ロードバランサのフェイルオーバー動作を示します。
| ロードバランサ モード | フェイルオーバーの動作 | すべてのバックエンドが異常な場合の動作 |
|---|---|---|
| リージョン内部プロキシ ネットワーク ロードバランサ | ロードバランサはゾーンごとの段階的なフェイルオーバー アルゴリズムを実装しています。ゾーン内のすべてのバックエンドが異常になるのを待つことなく、いずれかのゾーンで正常なバックエンドと異常なバックエンドの比率が一定のしきい値（70%、このしきい値は構成不可）より低くなったときに、ロードバランサは別のゾーンへのトラフィックのリダイレクトを開始します。すべてのゾーンのすべてのバックエンドが異常な状態になると、ロードバランサは直ちにクライアント接続を終端します。 Envoy プロキシは、構成されたトラフィック分散に基づいて、リージョン内の正常なバックエンドにトラフィックを送信します。 |
接続を終端する |
GKE アプリケーションのロード バランシング
Google Kubernetes Engine（GKE）でアプリケーションを構築する場合は、スタンドアロン NEG を使用してトラフィックを直接コンテナにロード バランシングできます。スタンドアロン NEG では、ゾーン NEG を作成する Service オブジェクトを作成し、NEG をバックエンド サービスに関連付ける必要があります。これにより、ロードバランサが Pod に接続できるようになります。
関連する GKE のドキュメント:
割り当てと上限
割り当てと上限については、割り当てと上限をご覧ください。
制限事項
- 内部プロキシ ネットワーク ロードバランサは、IPv6 トラフィックをサポートしていません。
- 内部プロキシ ネットワーク ロードバランサは、ロードバランサのフロントエンドが 1 つのホストまたはサービス プロジェクトにあるため、バックエンド サービスとバックエンドが別のサービス プロジェクトにある共有 VPC デプロイ（クロス プロジェクト サービス参照とも呼ばれます）をサポートしていません。