ロードバランサを選択する

このドキュメントは、どの Google Cloud ロードバランサがニーズに最適であるかを確認する際に利用できます。利用可能なすべての Cloud Load Balancing プロダクトの概要については、Cloud Load Balancing の概要をご覧ください。

使用する Cloud Load Balancing プロダクトを決定するには、まず、ロードバランサが処理するトラフィック タイプを決定する必要があります。原則として、HTTP(S) トラフィックを使用するアプリケーションに柔軟な機能セットが必要な場合は、アプリケーション ロードバランサを選択します。1 つ以上のリージョンのバックエンドに TCP プロキシ ロード バランシングを実装するには、プロキシ ネットワーク ロードバランサを選択します。クライアント ソース IP アドレスを保持し、プロキシのオーバーヘッドを回避して、UDP、ESP、ICMP などの追加のプロトコルをサポートするには、パススルー ネットワーク ロードバランサを選択します。

アプリケーションが外部（インターネット接続）または内部のどちらであるか、バックエンドをグローバルまたはリージョンのどちらでデプロイする必要があるのかなど、アプリケーションの要件に応じて、選択肢をさらに絞り込むことができます。

次の図は、Cloud Load Balancing で利用可能なすべてのデプロイモードをまとめたものです。

ロードバランサの選択（クリックして拡大）

¹ グローバル外部アプリケーション ロードバランサは、グローバルと従来の 2 つの運用モードをサポートしています。

² グローバル外部プロキシ ネットワーク ロードバランサは、グローバルと従来の 2 つの運用モードをサポートしています。

³ パススルー ネットワーク ロードバランサは、クライアントの送信元 IP アドレスを保持します。パススルー ネットワーク ロードバランサは、UDP、ESP、ICMP などの追加のプロトコルもサポートしています。

ロード バランシングのアスペクト

Google Cloud の実装に最適なロードバランサを決定するには、Cloud Load Balancing の以下の事項について検討します。

• トラフィックの種類
• 外部ロード バランシングと内部ロード バランシング
• グローバル ロード バランシングとリージョン ロード バランシングの比較
• プレミアムとスタンダードの Network Service Tiers
• プロキシ ロード バランシングとパススルー ロード バランシング

トラフィックの種類

ロードバランサで処理する必要があるトラフィックの種類も、どのロードバランサを使用するのかを決める際の判断基準となります。

ロードバランサの種類	トラフィックの種類
アプリケーション ロードバランサ	HTTP または HTTPS
パススルー ネットワーク ロードバランサ	TCP または UDP これらのロードバランサは、ESP、GRE、ICMP、ICMPv6 などの他の IP プロトコル トラフィックもサポートしています。
プロキシ ネットワーク ロードバランサ	TCP とオプションの SSL オフロード

外部ロード バランシングと内部ロード バランシング

Google Cloud ロードバランサは、外部ロードバランサまたは内部ロードバランサとしてデプロイできます。

• 外部ロードバランサは、インターネットからのトラフィックを Google Cloud Virtual Private Cloud（VPC）ネットワークに分散します。

• 内部ロードバランサは、ロードバランサと同じ VPC ネットワーク内のクライアント、または VPC ネットワーク ピアリング、Cloud VPN、または Cloud Interconnect を使用して VPC ネットワークに接続されたクライアントからのトラフィックを分散します。

アプリケーションで機能するロードバランサを確認するには、概要の表をご覧ください。

グローバル ロード バランシングとリージョン ロード バランシング

ロードバランサで処理する必要のあるトラフィックの種類と、クライアントが内部か外部かにより、グローバル ロードバランサとリージョン ロードバランサのどちらを選択するのかが決まります。

• ロードバランサをグローバルに分散する場合や、複数のリージョンにまたがるようにする場合は、グローバル ロードバランサまたはクロスリージョン ロードバランサを選択します。このようなロードバランサは、複数のリージョンにまたがってトラフィックを分散できるため、アプリケーションやコンテンツが複数のリージョンに分散している場合や、新しい地域にアプリケーションを拡大する際にマルチリージョン バックエンドを柔軟に追加したい場合に適しています。

  グローバル ロードバランサとして使用できるのは、外部ロードバランサのみです。バックエンドが複数のリージョンにある内部ロードバランサの場合は、クロスリージョン ロードバランサを選択します。クロスリージョン ロードバランサには、VPC ネットワーク内のリージョン サブネットから取得したリージョン内部 IP アドレスを使用してアクセスできます。これは、単一のエニーキャスト IP アドレスを使用してロードバランサで IPv6 を終端することでアクセスを提供するグローバル ロードバランサとは異なります。詳しくは、次の表をご覧ください。

• 1 つのリージョンにのみバックエンドが必要な場合や IPv4 終端のみが必要な場合（IPv6 ではない）、あるいは、トラフィックを特定のリージョン内に維持することが法令で義務付けられている場合は、リージョン ロードバランサを選択します。

  コンプライアンス上の理由でリージョン リソースを必要とするワークロードの場合は、特定のリソースを特定のリージョンに残すか、特定のリージョンでトラフィックを終端する必要があります。TLS の終端を地理的に制御する必要がある場合は、リージョン ロードバランサを使用する必要があります。リージョン ロードバランサは、選択した特定のリージョンにデプロイされ、同じリージョン内のバックエンドにのみ接続できます。したがって、リージョン ロードバランサでは、ロードバランサとそのバックエンドをデプロイしたリージョンでのみ TLS を終端することが保証されます。グローバル ロードバランサは、クライアントとロードバランサ間のレイテンシを最小限に抑えるため、グローバルに分散するロケーションで Transport Layer Security（TLS）を終端します。

ロードバランサは、高可用性を備えたアプリケーションを構築する際に重要な要素となります。アプリケーション全体の復元力は、選択したロードバランサのスコープ（グローバルまたはリージョン）だけでなく、バックエンド サービスの冗長性にも依存する点に注意する必要があります。

次の表は、ロードバランサの分散またはスコープに基づいてロードバランサの復元力をまとめたものです。

ロードバランサのスコープ	アーキテクチャ	ゾーンの停止に対する耐障害性	リージョンの停止に対する耐障害性
グローバル	各ロードバランサはすべてのリージョンに分散されます。
クロスリージョン	各ロードバランサは複数のリージョンに分散されます。
リージョン	各ロードバランサは、リージョン内の複数のゾーンに分散されます。		特定のリージョンが停止すると、そのリージョン内のリージョン ロードバランサに影響します。

アプリケーションで機能するロードバランサを確認するには、概要の表をご覧ください。

プロキシ ロード バランシングとパススルー ロード バランシング

ロードバランサで処理する必要のあるトラフィックの種類と、クライアントが内部か外部かにより、プロキシ ロードバランサとパススルー ロードバランサのどちらを選択するのかが決まります。

プロキシ ロードバランサは、ロードバランサで受信クライアント接続を終端し、ロードバランサからバックエンドへの新しい接続を開きます。すべてのアプリケーション ロードバランサとプロキシ ネットワーク ロードバランサは、このように動作します。クライアント接続は、Google Front End（GFE）または Envoy プロキシを使用して終端されます。

パススルー ロードバランサはクライアント接続を終端しません。ロード バランシングされたパケットは、パケットの送信元、宛先、ポート情報（該当する場合）が変更されずにバックエンド VM によって受信されます。接続は、バックエンド VM によって終端されます。バックエンド VM からのレスポンスは、ロードバランサを経由せず、クライアントに直接送信されます。これを Direct Server Return といいます。クライアント パケットの情報を保持する必要がある場合は、パススルー ロードバランサを使用します。名前が示すように、パススルー ネットワーク ロードバランサはこのカテゴリに分類されます。

アプリケーションで機能するロードバランサを確認するには、概要の表をご覧ください。

注: プロキシベースのロードバランサは、別の GFE または Envoy IP アドレスからバックエンドに接続します。最初の接続を開いた IP アドレスを追跡し、その同じ IP アドレスで 2 番目の接続を開くことを前提としている認証方法を使用している場合は、プロキシ ロードバランサでないほうが良いかもしれません。プロキシ ロードバランサは、デフォルトではクライアント IP アドレスを保持しません。このタイプの認証の場合、パススルー ロードバランサのほうが適しています。 内部および外部のアプリケーション ロードバランサなどのプロキシ ロードバランサの場合は、代わりに Identity-Aware Proxy（IAP）を認証方法として使用することをおすすめします。

プレミアムとスタンダードの Network Service Tiers

Network Service Tiers を使用すると、インターネット上のシステムと Google Cloud インスタンス間の接続を最適化できます。プレミアム ティアは Google のプレミアム バックボーンでトラフィックを配信し、スタンダード ティアは通常の ISP ネットワークを使用します。一般に、高パフォーマンスと低レイテンシを実現するには、プレミアム ティアを選択します。レイテンシやパフォーマンスに関する厳格な要件がないアプリケーションの場合は、低コストの代替手段としてスタンダード ティアを使用できます。

プレミアム ティア。ロードバランサの IP アドレスがプレミアム ティアにある場合、トラフィックは Google の高品質グローバル バックボーンを通過し、パケットはクライアントに可能な限り近い Google エッジ ピアリング ポイントを通過します。ネットワーク ティアを指定しない場合、ロードバランサはデフォルトのプレミアム ティアを使用します。すべての内部ロードバランサは常にプレミアム ティアです。また、グローバル外部アプリケーション ロードバランサは、プレミアム ティアでのみ構成できます。

スタンダード ティア。ロードバランサの IP アドレスがスタンダード ティアにある場合、トラフィックは、ロードバランサが構成されている Google Cloud リージョンに最も近いピアリング ポイントで Google ネットワークに出入りします。概要の表に示されているように、すべてのロードバランサをスタンダード ティアにデプロイできるわけではないため、それに応じて予算を計画してください。

リソースレベルで階層を選択するため（ロードバランサまたは VM 用の外部 IP アドレスなど）、一部のリソースにスタンダード ティアを使用し、別のリソースにはプレミアム ティアを割り当てるといったことが可能です。ディシジョン ツリーを Network Service Tiers のドキュメントで確認して、決定に役立てることができます。

Google Cloud Armor による外部ロードバランサの保護

Google Cloud Armor は、すべての外部ロードバランサに対して常時保護の DDoS 対策とユーザーが構成可能な DDoS 対策の両方を提供します。また、ロードバランサのタイプに応じてユーザーが構成可能なセキュリティ ポリシー ルールも提供します。

ロードバランサのタイプまたはモード	Google Cloud Armor セキュリティ ポリシー	サポートされているセキュリティ ポリシーの種類
グローバル外部アプリケーション ロードバランサ		バックエンド セキュリティ ポリシー Edge のセキュリティ ポリシー
従来のアプリケーション ロードバランサ		バックエンド セキュリティ ポリシー Edge のセキュリティ ポリシー
リージョン外部アプリケーション ロードバランサ		リージョン バックエンド セキュリティ ポリシー
グローバル外部プロキシ ネットワーク ロードバランサ		バックエンド セキュリティ ポリシー
従来のプロキシ ネットワーク ロードバランサ		バックエンド セキュリティ ポリシー
外部パススルー ネットワーク ロードバランサ		ネットワーク エッジのセキュリティ ポリシー

外部パススルー ネットワーク ロードバランサ、プロトコル転送、パブリック IP アドレスを持つ VM に対して高度なネットワーク DDoS 対策を構成することもできます。高度なネットワーク DDoS 対策の詳細については、高度なネットワーク DDoS 対策の構成をご覧ください。

Google Cloud ロードバランサの概要

次の表は、各ロードバランサに固有の情報を示しています。

ロードバランサ	デプロイモード	トラフィックの種類	ネットワーク サービス ティア	ロード バランシング スキーム*
アプリケーション ロードバランサ	グローバル外部	HTTP または HTTPS	プレミアム ティア	EXTERNAL_MANAGED
	リージョン外部	HTTP または HTTPS	プレミアムまたはスタンダード ティア	EXTERNAL_MANAGED
	従来	HTTP または HTTPS	グローバル（プレミアム ティア） リージョン（スタンダード ティア）	EXTERNAL^†
	リージョン内部	HTTP または HTTPS	プレミアム ティア	INTERNAL_MANAGED
	クロスリージョン内部	HTTP または HTTPS	プレミアム ティア	INTERNAL_MANAGED
プロキシ ネットワーク ロードバランサ	グローバル外部	TCP とオプションの SSL オフロード	プレミアム ティア	EXTERNAL_MANAGED
	リージョン外部	TCP	プレミアムまたはスタンダード ティア	EXTERNAL_MANAGED
	従来	TCP とオプションの SSL オフロード	グローバル（プレミアム ティア） リージョン（スタンダード ティア）	EXTERNAL
	リージョン内部	TCP、SSL オフロードなし	プレミアム ティア	INTERNAL_MANAGED
	クロスリージョン内部	TCP、SSL オフロードなし	プレミアム ティア	INTERNAL_MANAGED
パススルー ネットワーク ロードバランサ	外部 常にリージョン	TCP、UDP、ESP、GRE、ICMP、ICMPv6	プレミアムまたはスタンダード ティア	EXTERNAL
	内部 常にリージョン	TCP、UDP、ICMP、ICMPv6、SCTP、ESP、AH、GRE	プレミアム ティア	INTERNAL

^* ロード バランシング スキームは、ロードバランサに関する転送ルールとバックエンド サービスの属性であり、ロードバランサを内部トラフィックと外部トラフィックのどちらで使用できるかを示します。

ロード バランシング スキームにおける用語 *_MANAGED は、ロードバランサが Google Front End（GFE）またはオープンソースの Envoy プロキシのいずれかのマネージド サービスとして実装されていることを示します。*_MANAGED のロード バランシング スキームでは、GFE または Envoy プロキシにリクエストがルーティングされます。

^† EXTERNAL_MANAGED バックエンド サービスに EXTERNAL 転送ルールを適用できます。ただし、EXTERNAL バックエンド サービスに EXTERNAL_MANAGED 転送ルールを適用することはできません。グローバル外部アプリケーション ロードバランサでのみ利用可能な新機能を活用するには、従来のアプリケーション ロードバランサからグローバル外部アプリケーション ロードバランサにリソースを移行するで説明されている移行プロセスに従って、既存の EXTERNAL リソースを EXTERNAL_MANAGED に移行することをおすすめします。

次のステップ

• Cloud Load Balancing が提供するロード バランシング機能の比較については、ロードバランサの機能の比較をご覧ください。