負荷分散_システム設計ノート 5

零.水平拡張から始める

単一マシンから複数マシンへの拡張において、最初に直面する問題は、これらのマシンがどのように協調して作業するか、つまりどのようにリクエストをスケジューリングするかです：

[caption id="attachment_2103" align="alignnone" width="625"] load balancer dispatcher[/caption]

P.S. 水平拡張と垂直拡張の詳細情報については、Scalability_システム設計ノート 1 を参照

一.負荷分散装置

複数サーバー下でのリクエストスケジューリングメカニズムを負荷分散（Load balancing）と呼び、スケジューラ（Dispatcher）は負荷分散装置（Load balancer）です：

その主な役割は既定の戦略（ランダム、ラウンドロビンなど）に従ってクライアントリクエストを各サーバーに配信することです：

The fundamental feature of a load balancer is to be able to distribute incoming requests over a number of backend servers in the cluster according to a scheduling algorithm.

以下のことに役立ちます：

リクエストが利用できないサーバーに到達するのを防ぐ
リソースの過負荷を防ぐ
単一障害点を排除し、可用性を向上させる

さらに、以下にも使用できます：

SSL termination：SSL 接続を処理し、暗号化/復号の作業をスケジューリング層に前置
セッション維持（Session persistence）：セッションを集中処理し、サーバー切り替えによるセッション状態の損失を回避

つまり、複数マシンシーンでは、リクエストの配信/スケジューリングを担当する負荷分散装置が必ず必要です。では、次の問題は負荷分散メカニズムをどの層で実装すべきかです

二.実装思路

HTTP リクエストがクライアントからサーバーへの通信プロセスを考慮すると、簡単に 3 つの段階に分割できます：

出発：クライアントがリクエストを送信
途中：リクエストがネットワーク伝送を経由
到達：サーバーがリクエストを受信

リクエストの配信/スケジューリングとは、（既定の戦略に従って）リクエストの目的地を変更する方法を考えること です。したがって、少なくとも 3 つの思路があります：

出発前：リクエストがネットワーク伝送される前に、最終目的地を決定する。例えば DNS 負荷分散、クライアント側負荷分散
伝送中：ネットワーク伝送のいくつかの环节で目的地を変更する。例えば 4 層負荷分散
到達後：リクエストがサーバーに到達した後、二次配信を行う。例えば 7 層負荷分散

三.DNS 負荷分散

クライアントがサーバーにリクエストを開始するには、まずサーバーの IP アドレスを知る必要があり、DNS を通じて照会します：

DNS はドメイン名と IP アドレスの間のマッピング関係を維持しているため、ここで負荷分散戦略を実装し、リクエストをターゲットサーバー（の IP アドレス）に向けることができます。例えば：

ラウンドロビン配信：一連の A レコードを追加し、同一ドメイン名を複数の異なる IP アドレスに向ける。round-robin DNS と呼ぶ
ランダム配信：多値応答路由戦略をサポートする DNS サービスを採用

簡単で使いやすいですが、欠陥も明らか です：

信頼性が保証されない：DNS はサーバーの可用性をチェックせず、ターゲットサーバーがダウンしたりアクセスできなくなったりしても、その IP アドレスを返す
更新がタイムリーでない：DNS の解決結果はしばしば层层にキャッシュされ、レコードの更新が直ちに生效しない

P.S. DNS 負荷分散の詳細情報については、What Is DNS Load Balancing? を参照

四.クライアント側負荷分散

同様に、サーバー IP アドレス選択メカニズムをクライアント側で実装することを、クライアント側負荷分散と呼びます

クライアントが自分でターゲットサーバーの IP アドレスを選択します（DNS 照会を通じない）：

[caption id="attachment_2105" align="alignnone" width="445"] client-side load balancing[/caption]

例えば、クライアントにサーバー IP リストを提供し、クライアントがリクエストを開始する前にランダムに 1 つの IP を選択すれば、ランダム配信の目的を達成できます

DNS 負荷分散と比較して、クライアント側にはキャッシュの問題がなく、より精細な制御が可能 です。例えばサービスの可用性をチェックし、その中から利用可能な IP アドレスを選択できます

五.OSI 七層モデル

リクエストがクライアントから送信された後、ネットワークを通じて伝送されます

OSI（Open System Interconnect）参照モデルはネットワーク通信を 7 つの抽象層に分割します：

下から上へ、順に：

物理層（第 1 層）：物理媒体を通じて原始ビットストリーム、つまり物理信号（Symbol）を伝送
データリンク層（第 2 層）：信頼できるノード間データフレーム（Frame）伝送メカニズムを提供。具体的な作業には MAC 住所指定を含む
ネットワーク層（第 3 層）：データパケット（Packet）伝送が採用する物理経路を決定。IP、ARP などのプロトコルをサポート。具体的な作業には IP 住所指定、ルーティング、フロー制御を含む
トランスポート層（第 4 層）：信頼できる报文（Datagram）伝送メカニズムを提供。TCP、UDP などの伝送プロトコルをサポート。具体的な作業には
セッション層（第 5 層）：セッションの管理を担当。複数回の伝送を通じた連続的な情報交換をサポート
プレゼンテーション層（第 6 層）：ネットワークサービスからのデータをアプリケーション層で利用可能な形式に翻訳。具体的な作業には文字エンコーディング変換、データ圧縮、暗号化/復号などを含む
アプリケーション層（第 7 層）：高度な API の人間 - 機械インタラクション層を提供。アプリケーションはこの層を通じてネットワークサービスにアクセス可能。リソース共有、リモートファイルアクセスなど

その中で、第 1 層は原始データ、第 2 層はターゲットマシンの MAC アドレスを決定、第 3 層は終点の IP アドレス、および経由する具体的な経路を決定。第 4 層まで到達すると、伝送プロトコルに従ってターゲットポート番号を決定。第 5〜7 層は終点を気にしない。IP アドレス + MAC アドレス + ポート番号がすでにターゲットアプリケーションを一意に決定しているため

つまり、HTTP リクエストはこれらの層を経由して初めてターゲットサーバーに到達できます。したがって、理論上、第 2〜7 層の任意の層で終点を変更し、負荷分散を実装する機会があります

一般的な負荷分散メカニズムが主に第 4 層と第 7 層で実装されるのは、なぜでしょうか？

六.2 層、3 層負荷分散

2 層負荷分散：送信元/宛先 MAC アドレスに従って配信。例えば仮想 MAC アドレスを既定の戦略に従って実際の MAC アドレスにマッピング
3 層負荷分散：送信元/宛先 IP アドレス、および第 2 層情報に従って配信。例えば仮想 IP（Virtual IP address）の解決

底层に近づくほど、配信決定に使用できる情報が少なくなります。したがって 2 層負荷分散の実際の用途は限られており、一般的なのは冗長ゲートウェイプロトコル（GLBP、VRRP など）とリンクアグリゲーション（Link aggregation、etherchannel とも呼ぶ）など。詳細は How is load balancing achieved with layer 2 devices? を参照

七.4 層負荷分散

4 層負荷分散はトランスポート層（第 4 層）情報に基づいてリクエストを配信。送信元/宛先 IP アドレス、およびデータパケットヘッダーのポート番号を含む。ただしデータパケットの内容は考慮しない：

Layer 4 load balancing uses information defined at the networking transport layer (Layer 4) as the basis for deciding how to distribute client requests across a group of servers. For Internet traffic specifically, a Layer 4 load balancer bases the load-balancing decision on the source and destination IP addresses and ports recorded in the packet header, without considering the contents of the packet.

クライアントは負荷分散装置の IP アドレスをターゲット IP アドレスとしてリクエストを開始。4 層負荷分散装置はリクエストを受信後、データパケットに NAT 変換を実行。ターゲット IP アドレスを実際サーバーのアドレスに変更。サーバー応答をクライアントに転送する前に、負荷分散装置は送信元 IP アドレスを自身の IP アドレスに変更。同様に、データパケット内の送信元/宛先ポート番号もこの方式で変更

P.S. 第 4 層負荷分散装置は通常専用のハードウェア装置。NAT 操作は専用チップによって完了される場合がある

より複雑な 7 層負荷分散と比較して、4 層負荷分散に必要な計算は少ない。しかし現在のハードウェア条件下では、これによってもたらされるパフォーマンス優位性はすでに重要ではなくなりました

P.S.厳密に言えば、4 層負荷分散は 3/4 層負荷分散と呼ぶべき。第 3 層の IP アドレスと第 4 層のポート番号情報を組み合わせているため

八.7 層負荷分散

7 層負荷分散はアプリケーション層プロトコル情報（HTTP ヘッダーなど）およびデータパケット内容情報に基づいて配信。URL、データタイプ、Cookie 情報などを含む：

Layer 7 load balancers base their routing decisions on various characteristics of the HTTP header and on the actual contents of the message, such as the URL, the type of data (text, video, graphics), or information in a cookie.

4 層負荷分散と比較して、7 層負荷分散はリクエストと応答内容を読み取れる。必要な計算は多いが、必ずしも 4 層負荷分散よりパフォーマンスが悪いわけではない。より包括的なコンテキスト情報を拥有しているため、これを基にさらに賢いグローバル決定を下せる（低速接続の排除、タイムアウトリクエストのリダイレクトなど）。さらに内容の最適化（圧縮など）も可能。从而パフォーマンスを向上

P.S.厳密に言えば、7 層負荷分散は 5〜7 層負荷分散と呼ぶべき。OSI モデルの 5〜7 層の関連情報を組み合わせているため：

[caption id="attachment_2110" align="alignnone" width="800"] TCP/IP model and OSI model[/caption]