GCPのネットワークロードバランサーとHTTP（s）ロードバランサーの違いは何ですか
GCPは、2つのロードバランサー、つまりNetworkとHTTP（s）を提供します。前者はlayer 4で機能し、後者はlayer）で機能します。 7。
HTTPトラフィックでさえネットワークロードバランサーによって負荷分散できると述べているドキュメントもあります。これにより、GCPのウェブアプリにどのロードバランサーを選択するかが少し混乱します。プロジェクトに1つを選択する前に、違いを理解することをお勧めします。
ワークフロー、セットアップ、リージョン/ゾーンベース、セッションアフィニティのオプションに基づくそれらの違いは何ですか？ 、およびその他の設定？
ネットワークロードバランサーとHTTP（s）ロードバランサー
+---------------------+------------------------------------------+------------------------------------------------------+
| Category | Network Load Balancing (NLB) | HTTP(S) Load Balancing (HLB) |
+---------------------+------------------------------------------+------------------------------------------------------+
| 1. Region / | NLB supports only within a region. | HLB supports both within cross-region |
| Cross-Region | Does not support cross-region | load balancing. |
| | load balancing | |
+---------------------+------------------------------------------+------------------------------------------------------+
| 2. Load balancing | NLB is based on IP address, port | HLB is based only on HTTP and HTTPS |
| based on | and protocol type. Any TCP/UDP | protocols. |
| | traffic, even SMTP can be | |
| | load balanced. | |
+---------------------+------------------------------------------+------------------------------------------------------+
| 3. Packet | Packet inspection is possible and | HLB cannot inspect packets. |
| inspection | load balance based on packets | |
+---------------------+------------------------------------------+------------------------------------------------------+
| 4. Instance | No need of creating instance group. | Managed / UnManaged Instance group |
| Group | Target pools need to be created. | is necessary for creating HTTP / HTTPS |
| | Instance can be just tagged to the pool. | load balancer. |
| | Ideal for unmanaged instance group | |
| | where instances are non homogeneous. | |
+---------------------+------------------------------------------+------------------------------------------------------+
| 5. Workflow | Forwarding rules is the starting point. | This is quite complex in HTTP(s) load balancer. |
| | It directs the request to the | Global forwarding rulesroutes direct the request |
| | target pools from which compute | to target HTTP proxy, which in turn checks the |
| | engines will pick the request. | URL map to determine appropriate backend |
| | | services. These services in turn direct the request |
| | Forwarding rules -> target pool | to the instance group. |
| | -> instances | |
| | | |
| | | Global forwarding rules -> Target HTTP proxy -> |
| | | URL map -> Backend Sevices -> instance group |
+---------------------+------------------------------------------+------------------------------------------------------+
| 6. Types of | Basic network load balancer which | 1. Cross-region load balancer uses only one |
| load balancer | directs the request based on IP address, | global IP address and routes the request |
| | port and the protocol within the region. | to the nearest region. |
| | | |
| | | 2. Content-based load balancer is based |
| | | on the URL path. Different path rules need |
| | | different backend services. for eg: /video |
| | | and /static require two separate backend services. |
+---------------------+------------------------------------------+------------------------------------------------------+
| 7. Session affinity | Session affinity can be set, but only | 1. Client IP Affinity: This directs the same |
| | during the creation of target pool. | client ip to same backend instance by |
| | Once it is set, the value | computing hash of the IP. |
| | cannot be changed. | 2. Generated Cookie Affinity: Load balancer stores |
| | | cookie in clients and directs the same client to |
| | | same instance with the help of retrieved cookie. |
+---------------------+------------------------------------------+------------------------------------------------------+
| 8. Health check | Health check is optional, but network | Health can be verified by either using HTTP |
| | load balancing relies on HTTP Health | heath check or HTTPS health check. |
| | checks for determining instance health. | |
+---------------------+------------------------------------------+------------------------------------------------------+
上記の表は私の見解に基づいています。何かが間違っている場合、または何かを見逃した場合は、コメントしてください。テーブルに追加します。
GCP。でHTTPロードバランサーを設定する手順については、 リンク をご覧ください。
一般に、以下はネットワークロードバランサーとHttpロードバランサーの違いです。
ネットワークロードバランサー（レイヤー4）：これは、IPアドレスや宛先ポートなどのネットワーク変数に基づくトラフィックの分散です。これはレイヤー4（TCP）以下であり、コンテンツタイプ、Cookieデータ、カスタムヘッダー、ユーザーの場所、アプリケーションの動作など、アプリケーションレイヤーで何も考慮しないように設計されています。それはコンテキストレスであり、それがこのようにそしてそれを向けているパケットに含まれるネットワーク層情報だけを気にします。
アプリケーションロードバランサー（レイヤー7）これは、ネットワークレイヤーからアプリケーションレイヤーへの複数の変数に基づくリクエストの分散です。コンテキストを認識し、変数の組み合わせと同じくらい簡単に、単一の変数に基づいてリクエストを送信できます。アプリケーションは、サーバー（オペレーティングシステムまたは仮想化レイヤー）情報だけでなく、固有の動作に基づいて負荷分散されます。ルール、ホストベース、またはパスベースに基づいてHTTPおよびHTTPSトラフィックをルーティングする機能を提供します。 NLBと同様に、各ターゲットは異なるポートに配置できます。
ネットワーク負荷分散ではアプリケーションの可用性を保証できないため、この2つの違いは重要です。これは、ネットワークとTCP層の変数のみに基づいて決定を下し、アプリケーションをまったく認識していないためです。一般に、ネットワークロードバランサーは、サーバーがICMP pingに応答する能力、またはスリーウェイTCPハンドシェイクを正しく完了する能力）に基づいて「可用性」を決定します。アプリケーションロードバランサーはさらに深くなります。 、および特定のページの成功したHTTP GETだけでなく、入力パラメータに基づいてコンテンツが期待どおりであるかどうかの検証に基づいて可用性を判断することができます。