ロードバランサは、相互作用する複数のコンポーネントで構成されるシステムです。ロードバランサを表す単一の API リソースはありません。代わりに、複数のコンポーネントが連携して、受信トラフィックを複数のバックエンドに分散します。
次の図は、アプリケーション ロードバランサ、プロキシ ネットワーク ロードバランサ、パススルー ネットワーク ロードバランサのコア コンポーネントを示しています。
アプリケーション ロードバランサ
プロキシ ネットワーク ロードバランサ
パススルー ネットワーク ロードバランサ
このセクションでは、トラフィックがロードバランサに到達してからバックエンド リソースにルーティングされるまでの段階に沿って、ロードバランサの主なコンポーネントの概要を示します。各ロードバランサ コンポーネントの詳細については、各セクションにリンクされているページをご覧ください。
転送ルール
転送ルールには、IP アドレス、IP プロトコル、ロードバランサがトラフィックを受け入れる 1 つ以上のポートを指定します。転送ルールとそれに接続された IP アドレスは、 Trusted Cloud by S3NS ロードバランサのフロントエンドを表します。
詳細については、転送ルールの概要をご覧ください。
ターゲット プロキシ
ターゲット プロキシは、クライアントからの受信接続を終端し、ロードバランサからバックエンドへの新しい接続を作成します。
最初の接続はクライアントから開始され、ロードバランサのターゲット プロキシで終端されます。
2 番目の接続はターゲット プロキシから始まり、クライアント リクエストを処理するバックエンド インスタンスで終了します。
最初の接続は、Google Front End（GFE）またはプロキシ専用サブネットと呼ばれる特別に指定されたサブネットで終端されます。このサブネットは、Envoy プロキシ専用に予約されています。ロードバランサが GFE ベースか Envoy ベースかを判断するには、 Trusted Cloud by S3NS ロードバランサの基盤となるテクノロジーをご覧ください。
ターゲット プロキシは、アプリケーション ロードバランサやプロキシ ネットワーク ロードバランサなどのプロキシベースのロードバランサでのみ使用されます。このようなタイプのロードバランサの場合、バックエンド インスタンスからのレスポンスは、クライアントに直接ではなく、ターゲット プロキシに返されます。
詳細については、ターゲット プロキシをご覧ください。
プロキシ専用サブネット
プロキシ専用サブネットは、 Trusted Cloud by S3NS ロードバランサが使用する Envoy プロキシ専用として予約された IP アドレスのプールを提供します。プロキシは受信接続を終端し、バックエンドへの新しい接続を作成します。
詳細については、Envoy ベースのロードバランサのプロキシ専用サブネットをご覧ください。
SSL 証明書
SSL 証明書は、Transport Layer Security（TLS）証明書とも呼ばれ、クライアントとロードバランサの間の安全な通信を容易にします。転送ルールでターゲット HTTPS プロキシまたはターゲット SSL プロキシを参照する プロキシベースのロードバランサには、ロードバランサのターゲット プロキシ構成の一部として秘密鍵と SSL 証明書が必要になります。
詳しくは、SSL 証明書をご覧ください。
URL マップ
接続を終了すると、ターゲット HTTP(S) プロキシは URL マップを使用して、新しいリクエスト（ターゲット プロキシセクションで説明されている 2 番目の接続）を転送する場所を決定します。URL マップは、リクエストをバックエンド サービスまたはバックエンド バケットのいずれかに転送します。URL マップは、アプリケーション ロードバランサでのみ使用されます。アプリケーション ロードバランサは OSI モデルのレイヤ 7 で動作するため、ドメイン名、リクエストパス、クエリ パラメータなどの HTTP 属性に基づいてルーティングを決定できます。
詳細については、URL マップをご覧ください。
バックエンド サービス
バックエンド サービスは、ロードバランサがトラフィックを分散する方法を定義します。バックエンド サービスの構成には、バックエンドへの接続に使用されるプロトコル、さまざまな配信とセッションの設定、ヘルスチェック、タイムアウトなどの値が含まれます。
これらの設定により、ロードバランサの動作を細かく制御し、トラフィックを正しいバックエンド（VM インスタンス グループまたはネットワーク エンドポイント グループ（NEG））に転送できます。
詳細については、バックエンド サービスの概要をご覧ください。
ヘルスチェック
ロードバランサのバックエンド サービスを構成する場合は、バックエンドに 1 つ以上のヘルスチェックを指定する必要があります。ヘルスチェックは、その名前が示すように、ロードバランサのバックエンド インスタンスが正常かどうかを判断します。この判断は、バックエンドが受信トラフィックに応答する能力に基づいています。バックエンドが応答する必要があるトラフィックは、ロードバランサの種類によって異なります。レイヤ 7 プロトコルとレイヤ 4 プロトコルの両方を使用してヘルスチェックを作成し、ロード バランシング インスタンスをモニタリングできます。
ファイアウォール ルール
ヘルスチェックを機能させるには、ヘルスチェック プローブがバックエンドに到達できるように、上り（内向き）allow ファイアウォール ルールを作成する必要があります。
Google Front End ベースのロードバランサには、Google Front End の CIDR からのトラフィックがバックエンドに接続することを許可する上り（内向き）許可ファイアウォール ルールが必要です。オープンソースの Envoy プロキシに基づくロードバランサには、プロキシ専用サブネットからのトラフィックがバックエンド インスタンスに到達できるように上り（内向き）allow ファイアウォール ルールを作成する必要があります。
詳細については、ファイアウォール ルールをご覧ください。
バックエンド
バックエンドは、ロードバランスされたトラフィックの最終的な宛先です。
ロードバランサによって、サポートされるバックエンドのタイプが異なります。バックエンド サービスにバックエンドを追加する場合は、バランシング モードを指定します。このモードでは、新しいリクエストを処理するバックエンドの容量を評価し、バックエンド間でトラフィックを分散する方法を決定します。
詳細については、バックエンドをご覧ください。
次のステップ
- ニーズに最も適している Trusted Cloud ロードバランサを判断するには、ロードバランサを選択するをご覧ください。
- Cloud Load Balancing が提供するロード バランシング機能の比較については、ロードバランサの機能の比較をご覧ください。