レイヤー 4 負荷分散では、ネットワークトランスポート層 (レイヤー 4) で定義された情報を基に、クライアント要求をサーバー グループ全体に分散する方法を決定します。 特にインターネット トラフィックの場合、レイヤー 4 ロード バランサは、パケットの内容を考慮せずに、パケット ヘッダーに記録された送信元および宛先の IP アドレスとポートに基づいてロード バランシングの決定を行います。
開放型システム間相互接続 (OSI) 参照モデルによって定義されているネットワーク層は全部で 7 つあります。 詳細については、以下のOSI およびインターネット モデルのレイヤーを参照してください。
負荷分散の詳細については、 「NGINX Plus を使用したアプリケーションの負荷分散」を参照してください。
現在、「レイヤー 4 ロード バランシング」という用語は、ロード バランサーの IP アドレスが Web サイトまたはサービスのクライアントにアドバタイズされる展開 (DNS 経由など) を指すのが最も一般的です。 その結果、クライアントはリクエストの宛先 IP アドレスとしてロード バランサのアドレスを記録します。
レイヤー 4 ロード バランサは、要求を受信して負荷分散の決定を行う際に、要求パケットに対してネットワーク アドレス変換 (NAT) も実行し、記録された宛先 IP アドレスを自身の IP アドレスから内部ネットワーク上で選択したコンテンツ サーバの IP アドレスに変更します。 同様に、ロード バランサは、サーバの応答をクライアントに転送する前に、パケット ヘッダーに記録されている送信元アドレスをサーバの IP アドレスから自身の IP アドレスに変更します。 (パケットに記録される宛先および送信元 TCP ポート番号も同様に変更されることがあります。)
レイヤー 4 ロード バランサは、TCP ストリームの最初の数パケットから抽出されたアドレス情報に基づいてルーティングを決定し、パケットの内容を検査しません。 レイヤー 4 ロード バランサは、多くの場合、ベンダーによって提供される専用のハードウェア デバイスであり、独自のロード バランシング ソフトウェアを実行します。また、NAT 操作はソフトウェアではなく専用のチップによって実行される場合があります。
レイヤー 4 負荷分散は、市販のハードウェアが現在ほど強力ではなく、クライアントとアプリケーション サーバー間のやり取りがそれほど複雑ではなかった時代に、トラフィック処理に対する一般的なアーキテクチャ アプローチでした。 より洗練された負荷分散方法 (レイヤー 7 など) よりも計算量が少なくて済みますが、CPU とメモリが十分に高速かつ安価になったため、ほとんどの状況ではレイヤー 4 負荷分散によるパフォーマンス上の利点は無視できるほど小さく、または無関係になっています。
レイヤー 7 ロード バランサは、OSI モデルの最高レベルであるアプリケーション層で動作します (インターネットでは、この層の主なプロトコルは HTTP です)。 レイヤー 7 ロード バランサは、HTTP ヘッダーのさまざまな特性と、URL、データの種類 (テキスト、ビデオ、グラフィック)、Cookie 内の情報などのメッセージの実際の内容に基づいてルーティングを決定します。
転送される情報の非常に多くの側面を考慮すると、レイヤー 7 の負荷分散は、時間と必要な計算能力の点でレイヤー 4 よりもコストがかかりますが、それでも全体的な効率は向上します。 たとえば、レイヤー 7 ロード バランサはクライアントが要求しているデータの種類 (ビデオ、テキストなど) を判別できるため、負荷分散されるすべてのサーバーで同じデータを複製する必要はありません。
NGINX Plus やオープンソースの NGINX ソフトウェアなどの最新の汎用ロードバランサーは、通常、レイヤー 7 で動作し、完全なリバース プロキシとして機能します。 NAT を使用するレイヤー 4 ロード バランサのようにパケットごとにトラフィックを管理するのではなく、レイヤー 7 ロード バランシング プロキシは要求と応答を全体的に読み取ることができます。 クライアントとアプリケーション サーバー間のトランザクションを完全に理解した上で、トラフィックを管理および操作します。
一部のロード バランサーは、サービスの性質に応じて、レイヤー 4 またはレイヤー 7 のロード バランシングを提供するように構成できます。 前述のように、現代の一般的なハードウェアは一般的に十分に強力であるため、レイヤー 4 の負荷分散による計算コストの節約は、レイヤー 7 の負荷分散による柔軟性と効率性の向上のメリットを上回るほど大きくはありません。
NGINX PlusとNGINX は、 Dropbox、Netflix、Zynga などのトラフィック量の多い Web サイトで使用されているクラス最高の負荷分散ソリューションです。 世界中で3 億 5,000 万を超える Web サイトが、コンテンツを迅速かつ確実に安全に配信するために NGINX Plus と NGINX Open Source を活用しています。
ソフトウェアベースのロードバランサーである NGINX Plus は、同様の機能を備えたハードウェアベースのソリューションよりもはるかに安価です。 NGINX Plus の包括的な負荷分散機能により、高度に最適化されたアプリケーション配信ネットワークを構築できます。
NGINX Plus をサーバー ファームの前にロード バランサーとして挿入すると、Web サイト全体の効率、パフォーマンス、信頼性、スケールが向上します。 NGINX Plus は、顧客満足度と IT 投資収益率の両方を最大化するのに役立ちます。
インターネット トラフィックの場合、「レイヤー 4」および「レイヤー 7」の負荷分散を参照するのは便利な略語ですが、厳密には正確ではありません。 興味があれば、読んでみてください。
7 つのネットワーク層の概念は、開放型システム間相互接続 (OSI) 参照モデルに由来します。 このモデルは、ネットワーク機能を 7 つの抽象化されたレイヤーに分割し、通常は番号 (レイヤー 1 からレイヤー 7) で参照します。 各レイヤーには、データのパッケージ化と転送方法を定義する標準があります。 とりわけ、標準では、要求または応答を構成するビット ストリームを、プロトコル データ ユニット(PDU) と呼ばれる個別のパッケージに分割する方法が定義されています。 標準では、ヘッダーの形式で各 PDU に追加されるメタデータも定義されています。メタデータには、たとえば、送信元ホストと送信先ホストのアドレスが指定されることがあります。
ネットワーク機能のさまざまな側面を異なるレイヤーに割り当てると、各レイヤーでの処理が簡素化されます。これは、プロトコルは自身のレイヤーの PDU の処理方法と、隣接するレイヤーのプロトコルが独自のデータ セグメント化レベルで PDU を再パッケージ化できるようにヘッダーに含めるメタデータのみを知っていればよいためです。
ワールド ワイド ウェブ上のトラフィック用の基本プロトコル (総称してインターネット プロトコル (IP) スイートと呼ばれます) 間のネットワーク機能の分散は、OSI モデルに厳密に準拠しているわけではありません。 これは、1984 年に最終的な OSI モデルが公開される前に、IP スイートが定義され実装されたためです。 それでも、IP スイート内のさまざまなプロトコルは、OSI レイヤーにほぼ対応する個別の機能を実行します。
各レベルでは複数のプロトコルが定義されていますが、Web サイトのトラフィックの負荷分散に関連するプロトコルとレベルは次のとおりです。
このリストから明らかなように、インターネット トラフィックの「レイヤー 4 負荷分散」は便利な略語ですが、より正確な用語は「レイヤー 3/4 負荷分散」です。これは、ロード バランサーが、送信元サーバーおよび送信先サーバーの IP アドレス (レイヤー 3) とアプリケーションの TCP ポート番号 (レイヤー 4) の両方に基づいて決定を行うためです。 HTTP は OSI レイヤー 5、6、7 の機能を組み合わせているため、「レイヤー 7 負荷分散」のより正確な用語は「レイヤー 5 から 7 までの負荷分散」となる可能性があります。