Loading article…
コンピューティングにおいて、負荷分散とは、一連のタスクを複数のリソース（計算ユニット）に分散させることで、全体の処理効率を向上させるプロセスです。負荷分散によって応答時間を最適化し、一部の計算ノードに過負荷がかかる一方で、他の計算ノードがアイドル状態になるといった不均衡な状況を回避することができます。
負荷分散は、並列コンピュータ分野における研究テーマの一つです。主なアプローチは2つあります。1つは、異なるマシンの状態を考慮しない静的アルゴリズム、もう1つは、通常はより汎用的で効率的ですが、異なる計算ユニット間での情報交換が必要となるため、効率が低下するリスクがある動的アルゴリズムです。
負荷分散アルゴリズムは常に特定の課題に対応しようとします。タスクの性質、アルゴリズムの複雑さ、アルゴリズムが実行されるハードウェアアーキテクチャ、必要なエラー許容度など、考慮すべき要素は多岐にわたります。そのため、アプリケーション固有の要件を最適に満たすためには、妥協点を見つける必要があります。
負荷分散アルゴリズムの効率は、タスクの性質に大きく依存します。したがって、意思決定時にタスクに関する情報が多ければ多いほど、最適化の可能性は高まります。
各タスクの実行時間を完全に把握できれば、最適な負荷分散を実現できます（プレフィックス和アルゴリズムを参照）。[ 1 ]残念ながら、これは実際には理想的なケースです。各タスクの正確な実行時間を把握できる状況は極めてまれです。
このため、さまざまな実行時間を把握するための手法がいくつかあります。まず、タスクのサイズが比較的均一な場合は、それぞれのタスクが平均実行時間を要していると考えることができます。一方、実行時間が著しく不規則な場合は、他の手法を用いることができます。1つの手法は、各タスクにメタデータを追加することです。同様のメタデータの過去の実行時間に基づいて、統計情報に基づいて将来のタスクについて推論を行うことができます。[ 2 ]
場合によっては、タスク同士が相互に依存していることがあります。こうした相互依存関係は、有向非巡回グラフで表すことができます。直感的に言えば、あるタスクは他のタスクが完了するまで開始できないということです。
各タスクに必要な時間が事前に分かっていると仮定すると、最適な実行順序は総実行時間を最小化するものでなければなりません。しかし、これはNP困難問題であるため、厳密に解くのは困難です。ジョブスケジューラなどのアルゴリズムは、メタヒューリスティック手法を用いて最適なタスク配分を計算します。
負荷分散アルゴリズムの設計において重要なタスクのもう一つの特徴は、実行中にサブタスクに分割できることである。後述するツリー構造の計算アルゴリズムは、この特性を最大限に活用している。
負荷分散アルゴリズムは、タスクの分散においてシステムの状態を考慮しない場合、「静的」であると言えます。ここでいうシステムの状態とは、特定のプロセッサの負荷レベル（場合によっては過負荷状態）などの指標を指します。その代わりに、到着予定時刻や必要なリソースなど、システム全体に関する前提条件が事前に設定されます。さらに、プロセッサの数、それぞれの消費電力、通信速度も既知です。したがって、静的負荷分散は、特定のパフォーマンス関数を最小化するために、既知のタスクセットを利用可能なプロセッサに割り当てることを目的としています。設計上の重要な選択は、このパフォーマンス関数です。
静的負荷分散技術は、一般的にルーター（マスター）を中心に構成され、負荷を分散してパフォーマンス関数を最適化します。この最適化では、分散対象となるタスクに関する情報を考慮し、期待される実行時間を算出します。
静的アルゴリズムの利点は、設定が容易で、比較的規則的なタスク（ウェブサイトからのHTTPリクエストの処理など）においては効率的であることです。しかし、タスクの割り当てには統計的なばらつきが依然として存在するため、一部の計算ユニットに過負荷がかかる可能性があります。
静的な負荷分散アルゴリズムとは異なり、動的アルゴリズムはシステム内の各計算ユニット（ノードとも呼ばれる）の現在の負荷を考慮します。このアプローチでは、処理速度を向上させるために、タスクを過負荷状態のノードから負荷の低いノードへ動的に移動させることができます。これらのアルゴリズムは設計がはるかに複雑ですが、特にタスクごとに実行時間が大きく異なる場合に、パフォーマンスを向上させることができます。
動的負荷分散アーキテクチャは、作業の分散専用の特定のノードを用意する必要がないため、よりモジュール化できます。タスクが特定の時点での状態に応じてプロセッサに一意に割り当てられる場合、それは一意の割り当てです。一方、タスクがシステムの状態とその変化に応じて恒久的に再分配される場合、これは動的割り当てと呼ばれます。[ 3 ]決定を下すために通信が多すぎる負荷分散アルゴリズムは、全体的な問題の解決を遅らせるリスクがあります。
並列コンピューティングインフラストラクチャは、多くの場合、異なる計算能力を持つユニットで構成されており、負荷分散を行う際には、これらの点を考慮に入れる必要がある。
例えば、低出力のユニットは、より少ない計算量を必要とする要求を受け取る可能性があり、また、要求のサイズが均一または不明な場合は、より出力の高いユニットよりも少ない要求を受け取る可能性があります。
並列コンピュータは大きく2つのカテゴリに分けられることが多い。1つは、すべてのプロセッサが単一の共通メモリを共有し、並列に読み書きを行うもの（PRAMモデル）、もう1つは、各演算ユニットが独自のメモリを持ち、メッセージによって情報が交換されるもの（分散メモリモデル）である。
共有メモリ型コンピュータでは、書き込み競合の処理によって各演算ユニットの個々の実行速度が大幅に低下します。しかし、並列処理は問題なく行えます。一方、メッセージ交換の場合は、各プロセッサがフルスピードで動作できます。しかし、集団的なメッセージ交換の場合、すべてのプロセッサは最も処理速度の遅いプロセッサが通信フェーズを開始するまで待機せざるを得ません。
実際には、いずれか1つのカテゴリに完全に該当するシステムはほとんどありません。一般的に、プロセッサはそれぞれ次の計算に必要なデータを格納するための内部メモリを持ち、連続するクラスタに編成されています。多くの場合、これらの処理要素は分散メモリとメッセージパッシングによって連携されます。したがって、負荷分散アルゴリズムは並列アーキテクチャに特化して設計する必要があります。そうしないと、並列問題解決の効率が大幅に低下するリスクがあります。
上述のハードウェア構造に適合する負荷分散アルゴリズムには、大きく分けて2つのカテゴリがあります。1つは、「マスター」がタスクを割り当て、「ワーカー」が実行し、ワーカーが作業の進捗状況をマスターに報告する方式です。動的アルゴリズムの場合、マスターはワークロードの割り当てや再割り当てを担当できます。文献では、これをマスターワーカーアーキテクチャと呼んでいます。もう1つは、制御を複数のノードに分散させる方式です。この場合、負荷分散アルゴリズムは各ノードで実行され、タスクの割り当て（および必要に応じて再割り当てや分割）の責任が共有されます。最後のカテゴリは、動的負荷分散アルゴリズムを前提としています。
各負荷分散アルゴリズムの設計はそれぞれ異なるため、前述の区別には補足が必要です。例えば、各サブクラスタに「マスター」ノードを配置し、それらがグローバルな「マスター」ノードの支配下に置かれるといった中間的な戦略も可能です。また、マスタースレーブ型と分散制御型を交互に用いる多層構造も存在します。しかし、後者の戦略はすぐに複雑化するため、あまり一般的ではありません。設計者は、制御しやすいアルゴリズムを好みます。
非常に長期間にわたって実行されるアルゴリズム（サーバー、クラウドなど）においては、コンピュータアーキテクチャは時間とともに進化します。しかし、その都度新しいアルゴリズムを設計する必要がない方が望ましいでしょう。
したがって、負荷分散アルゴリズムのパラメータの一つは、スケーラブルなハードウェアアーキテクチャに適応できる能力である。これはアルゴリズムのスケーラビリティと呼ばれる。アルゴリズムのパフォーマンスが入力パラメータのサイズに比較的依存しない場合、そのアルゴリズムは入力パラメータに対してスケーラブルであると言われる。
アルゴリズムが計算ユニット数の変動に適応できるが、実行前に計算ユニット数を固定する必要がある場合、それは「成形可能」と呼ばれる。一方、アルゴリズムが実行中にプロセッサ数の変動に対応できる場合、そのアルゴリズムは「可撓性」であると言われる。ほとんどの負荷分散アルゴリズムは少なくとも「成形可能」である。[ 4 ]
特に大規模なコンピューティングクラスタでは、単一のコンポーネントの障害に耐えられない並列アルゴリズムを実行することは許容できません。そのため、プロセッサの停止を検出して計算を回復できるフォールトトレラントアルゴリズムが開発されています。[ 5 ]
タスクが互いに独立しており、それぞれの実行時間とタスクを細分化できる場合、これらの仮定の下で最適なアルゴリズムが利用可能となる。
各プロセッサに均等な計算量を割り当てるようにタスクを分割することで、あとは結果をまとめるだけで済む。プレフィックス和アルゴリズムを使用すれば、この分割はプロセッサ数に対して対数時間で計算できる。
しかし、タスクを細分化できない場合（つまり、タスクがアトミックである場合）、タスク割り当ての最適化は難しい問題ではあるものの、各タスクのサイズが各ノードによって実行される計算の総量よりもはるかに小さい限り、比較的公平なタスクの分配を近似することは依然として可能である。[ 1 ]
多くの場合、タスクの実行時間は不明であり、おおよその概算値しか得られません。このアルゴリズムは、このような前提の下では効率的かもしれませんが、タスクの実行時間が不明な場合には適用性が低くなります。
実行時間が全く事前にわからない場合でも、静的負荷分散は常に可能である。
ラウンドロビンアルゴリズムでは、最初のリクエストは最初のサーバーに送信され、次に2番目のリクエストは2番目のサーバーに送信され、以下同様に最後のサーバーまで送信されます。その後、再び最初のリクエストが最初のサーバーに割り当てられ、同様に処理が繰り返されます。
このアルゴリズムは、最も処理能力の高いユニットがより多くのリクエストを優先的に受け取るように重み付けすることができる。
ランダム化静的負荷分散は、タスクを異なるサーバーにランダムに割り当てるだけの単純な方法です。この方法は非常に効果的です。一方、タスク数が事前にわかっている場合は、ランダムな順列を事前に計算しておく方がさらに効率的です。これにより、割り当てごとに発生する通信コストを削減できます。各プロセッサがどのタスクが割り当てられているかを把握しているため、分散マスターは不要になります。タスク数が不明な場合でも、すべてのプロセッサが認識できる擬似乱数生成器を使用することで、通信を回避することが可能です。
この戦略のパフォーマンス（特定の固定タスクセットに対する総実行時間で測定）は、タスクの最大サイズが大きくなるにつれて低下します。
他にも割り当て方法があります。
マスターワーカー方式は、最もシンプルな動的負荷分散アルゴリズムの一つです。マスターは、すべてのワーカー（「スレーブ」とも呼ばれます）にワークロードを分散します。最初はすべてのワーカーがアイドル状態であり、そのことをマスターに報告します。マスターはワーカーからの要求に応答し、タスクを割り当てます。割り当てるタスクがなくなると、ワーカーにその旨を通知し、タスクの要求を停止させます。
この方式は、割り当てのオーバーヘッドが低い場合に作業を均等に分散できる。割り当てに必要な時間を考慮しない場合、実行時間は上記のプレフィックス和と同程度になる。
このアルゴリズムの問題点は、必要な通信量が多いため、多数のプロセッサへの適応が難しいことです。この拡張性の欠如により、非常に大規模なサーバーや並列コンピュータではすぐに動作しなくなります。マスターがボトルネックとして機能します。
しかし、マスターを複数のプロセッサで使用可能なタスクリストに置き換えることで、アルゴリズムの品質を大幅に向上させることができる。このアルゴリズムは実装がやや困難になるものの、スケーラビリティを向上させることができる。ただし、非常に大規模な計算センターにはまだ不十分である。
タスク完了に必要な時間が不明な場合にスケーラビリティの問題を克服するもう1つの手法は、ワークスティーリングです。
この手法は、各プロセッサに一定数のタスクをランダムまたは事前に定義された方法で割り当て、非アクティブなプロセッサがアクティブなプロセッサや過負荷状態のプロセッサからタスクを「奪う」ことを可能にするというものです。この概念には、タスク分割モデルとプロセッサ間のタスク交換を決定するルールによって定義される、いくつかの実装が存在します。この手法は特に効果的である一方、プロセッサが問題を解決するのではなく、通信を主な作業として行わないようにする必要があるため、実装は困難です。
アトミックタスクの場合、2 つの主要な戦略を区別できます。1 つは負荷の低いプロセッサが負荷の高いプロセッサに計算能力を提供する戦略、もう 1 つは負荷の高いユニットが割り当てられたワークロードを軽減したいという戦略です。[ 9 ]では、ネットワークの負荷が高い場合、負荷の低いユニットが可用性を提供する方が効率的であり、ネットワークの負荷が低い場合は、過負荷のプロセッサが最も非アクティブなプロセッサからのサポートを必要とすることが示されています。この経験則により、交換されるメッセージの数が制限されます。
原子レベルを超えて分割できない単一の大きなタスクから開始する場合、「ツリー型計算」アルゴリズムを使用できます[ 10 ]。この場合、親タスクはワークツリーに分散されます。
最初は、多くのプロセッサが空のタスクを持っていますが、1つのプロセッサだけはタスクを順次処理します。アイドル状態のプロセッサは、他のプロセッサ（必ずしもアクティブである必要はありません）にランダムに要求を発行します。要求されたプロセッサは、処理中のタスクを分割できる場合、要求元のノードに処理の一部を送信します。そうでない場合は、空のタスクを返します。これにより、ツリー構造が形成されます。サブタスクが完了したら、親プロセッサに終了信号を送信する必要があります。親プロセッサは、そのメッセージをさらに親プロセッサに送信し、ツリーのルートに到達するまで処理を続けます。最初のプロセッサ、つまりルートの処理が完了すると、グローバルな終了メッセージがブロードキャストされます。最後に、ツリーを遡って結果を組み立てる必要があります。
このようなアルゴリズムの効率は、ジョブの分割時間と通信時間が処理すべき作業量に比べてそれほど高くない場合、プレフィックス和法に匹敵する。通信コストが高くなりすぎないようにするために、共有メモリ上にジョブのリストを作成することが考えられる。そうすれば、マスタープロセッサの要求に応じて、この共有メモリ上の特定の位置から読み取るだけで済む。
並列計算による効率的な問題解決に加え、負荷分散アルゴリズムは、アクセス数の多いサイトが毎秒大量のリクエストを処理できる必要があるHTTPリクエスト管理において広く利用されている。
ロードバランシングの最も一般的な用途の1つは、複数のサーバー（サーバーファームとも呼ばれる）から単一のインターネットサービスを提供することです。ロードバランシングが一般的に用いられるシステムには、人気のあるWebサイト、大規模なインターネットリレーチャットネットワーク、高帯域幅のファイル転送プロトコル（FTP）サイト、ネットワークニュース転送プロトコル（NNTP）サーバー、ドメインネームシステム（DNS）サーバー、およびデータベースなどがあります。
ラウンドロビンDNSは、専用のソフトウェアノードやハードウェアノードを必要としない、負荷分散の代替手段です。この方式では、1つのドメイン名に複数のIPアドレスが割り当てられ、クライアントにはラウンドロビン方式でIPアドレスが割り当てられます。クライアントには有効期限の短いIPアドレスが割り当てられるため、次回インターネットサービスにアクセスする際に、別のIPアドレスが使用される可能性が高くなります。
DNS を使用した負荷分散のより効果的な手法として、www.example.org をサブドメインとして委任し、そのゾーンを Web サイトを配信しているサーバーと同じサーバーが担当するという方法があります。この手法は、個々のサーバーがインターネット上で地理的に分散している場合に特に効果的です。例:
しかし、各サーバー上のwww.example.orgのゾーンファイルは異なっており、各サーバーはAレコードとして自身のIPアドレスを解決します。[ 11 ]サーバー1上のwww.example.orgのゾーンファイルには、次のように記載されています。
サーバー2では、同じゾーンファイルに以下の内容が含まれています。
この方法により、サーバーがダウンすると、そのDNSは応答せず、Webサービスはトラフィックを受信しません。あるサーバーへの回線が混雑している場合、DNSの信頼性の低さによって、そのサーバーに到達するHTTPトラフィックが減少します。さらに、リゾルバへのDNS応答は、ほぼ常にネットワーク内で最も近いサーバーからの応答となるため、地理的に配慮した負荷分散が実現されます。AレコードのTTLを短く設定することで、サーバーがダウンした際にトラフィックが迅速に振り分けられるようになります。ただし、この手法では、セッション中に個々のクライアントが個々のサーバー間を切り替える可能性があることを考慮する必要があります。
負荷分散のもう 1 つのアプローチは、サーバー IP のリストをクライアントに提供し、クライアントが接続ごとにリストから IP をランダムに選択することです。[ 12 ] [ 13 ]これは基本的に、すべてのクライアントが同様の負荷を生成することと、大数の法則[ 13 ]によってサーバー間で比較的フラットな負荷分散を実現することに依存しています。クライアント側のランダム負荷分散は、ラウンドロビン DNS よりも優れた負荷分散を提供する傾向があると主張されています。これは、ラウンドロビン DNS のキャッシュの問題に起因するとされています。大規模な DNS キャッシュ サーバーの場合、ラウンドロビン DNS の分布が偏る傾向がありますが、クライアント側のランダム選択は DNS キャッシュに関係なく影響を受けません。[ 13 ]
このアプローチでは、クライアントへのIPアドレスリストの配信方法は様々で、DNSリスト（ラウンドロビン方式ではなく、すべてのクライアントに配信）として実装することも、リストにハードコーディングすることも可能です。ランダムに選択されたサーバーがダウンしていることを検出し、ランダムに再接続する「スマートクライアント」を使用すれば、フォールトトレランスも実現できます。
インターネットサービスの場合、サーバーサイドロードバランサーは通常、外部クライアントがサービスにアクセスするために接続するポートで待機するソフトウェアプログラムです。ロードバランサーはリクエストを「バックエンド」サーバーのいずれかに転送し、バックエンドサーバーは通常、ロードバランサーに応答します。これにより、クライアントは内部的な機能分離を意識することなく、ロードバランサーからクライアントに応答できます。また、クライアントがバックエンドサーバーに直接接続することを防ぐため、内部ネットワークの構造を隠蔽し、カーネルのネットワークスタックや他のポートで実行されている無関係なサービスへの攻撃を防ぐことで、セキュリティ上のメリットが得られます。
一部のロードバランサーは、すべてのバックエンドサーバーが利用不能になった場合に特別な処理を行うための仕組みを備えています。これには、バックアップのロードバランサーへの転送や、障害に関するメッセージの表示などが含まれます。
ロードバランサー自体が単一障害点にならないことも重要です。通常、ロードバランサーは高可用性ペアで実装され、特定のアプリケーションで必要とされる場合はセッション永続性データを複製することもできます。 [ 14 ]特定のアプリケーションは、定義されたネットワークを超えて差分共有プラットフォームにロードバランシングポイントをオフセットすることで、この問題に対する耐性を持つようにプログラムされています。これらの機能とペアになっているシーケンシャルアルゴリズムは、特定のデータベースに固有の柔軟なパラメータによって定義されます。[ 15 ]
ロードバランサーは、リクエストをどのバックエンドサーバーに送信するかを決定するために、ロードバランシング方式とも呼ばれる多数のスケジューリングアルゴリズムを使用します。単純なアルゴリズムには、ランダム選択、ラウンドロビン、最小接続などがあります。[ 16 ]より高度なロードバランサーは、サーバーの報告された負荷、最小応答時間、アップ/ダウン状態（何らかの監視ポーリングによって決定）、アクティブな接続数、地理的位置、機能、または最近割り当てられたトラフィック量など、追加の要素を考慮に入れる場合があります。
負荷分散サービスを運用する際の重要な課題は、ユーザーセッション内の複数のリクエスト間で保持する必要のある情報をどのように処理するかです。この情報が1つのバックエンドサーバーにローカルに保存されている場合、異なるバックエンドサーバーへの後続のリクエストではそれを見つけることができません。これは再計算可能なキャッシュ情報である可能性があり、その場合、リクエストを別のバックエンドサーバーに負荷分散するとパフォーマンスの問題が発生するだけです。[ 16 ]
理想的には、ロードバランサーの背後にあるサーバー群はセッションを認識しないことが望ましい。そうすることで、クライアントがどのバックエンドサーバーに接続しても、ユーザーエクスペリエンスに影響が出ないようにできる。これは通常、共有データベースまたはMemcachedのようなインメモリセッションデータベースを使用することで実現できる。
セッションデータの問題に対する基本的な解決策の一つは、ユーザーセッション内のすべてのリクエストを常に同じバックエンドサーバーに送信することです。これは「永続性」または「スティッキネス」と呼ばれます。この手法の大きな欠点は、自動フェイルオーバーがないことです。バックエンドサーバーがダウンすると、セッションごとの情報にアクセスできなくなり、それに依存するセッションはすべて失われます。同じ問題は通常、中央データベースサーバーにも当てはまります。Webサーバーが「ステートレス」で「スティッキネス」ではない場合でも、中央データベースはそうであるからです（下記参照）。
特定のサーバーへの割り当ては、ユーザー名、クライアントのIPアドレス、またはランダムに基づいて行われる場合があります。DHCP 、ネットワークアドレス変換、およびWebプロキシによってクライアントの認識アドレスが変化するため、この方法は信頼性に欠ける可能性があります。ランダム割り当てはロードバランサーによって記憶される必要があり、ストレージに負担がかかります。ロードバランサーが交換または故障した場合、この情報が失われる可能性があり、割り当てテーブルに使用できるスペースを超えないように、タイムアウト期間後または高負荷期間中に割り当てを削除する必要がある場合があります。ランダム割り当て方式では、クライアントが何らかの状態を維持する必要もありますが、WebブラウザがCookieの保存を無効にしている場合など、問題となる可能性があります。高度なロードバランサーは、複数の永続化技術を使用して、いずれか1つの方法の欠点のいくつかを回避します。
別の解決策として、セッションごとのデータをデータベースに保持する方法があります。ただし、この方法ではデータベースへの負荷が増加するため、パフォーマンスが低下する可能性があります。データベースは、セッションごとのデータよりも長期にわたる情報を保存するのに最適です。データベースが単一障害点となるのを防ぎ、スケーラビリティを向上させるために、データベースは複数のマシンに複製され、負荷分散によってクエリ負荷がこれらの複製に分散されることがよくあります。Microsoft のASP.NET State Server テクノロジーは、セッションデータベースの一例です。Web ファーム内のすべてのサーバーは、セッションデータを State Server に保存し、ファーム内のどのサーバーからでもデータを取得できます。
クライアントがウェブブラウザの場合、セッションごとのデータをブラウザ自体に保存するという方法があります。これを実現する方法の1つは、適切なタイムスタンプと暗号化を施したブラウザのクッキーを使用することです。もう1つはURL書き換えです。セッションデータをクライアントに保存するのが一般的に推奨される解決策です。そうすれば、ロードバランサーはリクエストを処理するバックエンドサーバーを自由に選択できます。ただし、この状態データ処理方法は、セッション状態のペイロードが大きく、サーバー上でリクエストごとにそれを再計算することが現実的ではないような、複雑なビジネスロジックのシナリオには適さない場合があります。URL書き換えには、エンドユーザーが送信されたURLを簡単に変更してセッションストリームを変更できるため、重大なセキュリティ上の問題があります。
永続的なデータを保存するためのもう一つの解決策は、各データブロックに名前を関連付け、分散ハッシュテーブルを使用してその名前を利用可能なサーバーのいずれかに擬似乱数的に割り当て、割り当てられたサーバーにそのデータブロックを保存することです。
ハードウェアおよびソフトウェアのロードバランサーには、さまざまな特殊機能があります。ロードバランサーの基本的な機能は、スケジューリングアルゴリズムに従って、クラスタ内の複数のバックエンドサーバーに受信リクエストを分散できることです。以下の機能のほとんどはベンダー固有です。
ロードバランシングは、冗長な通信リンクを持つアプリケーションで役立ちます。例えば、企業が複数のインターネット接続を用意し、いずれかの接続が故障した場合でもネットワークアクセスを確保している場合などが挙げられます。フェイルオーバー構成では、一方のリンクを通常使用用に指定し、もう一方のリンクはプライマリリンクが故障した場合にのみ使用するようにします。
ロードバランシングを使用することで、両方のリンクを常時使用可能にできます。デバイスまたはプログラムがすべてのリンクの可用性を監視し、パケット送信の経路を選択します。複数のリンクを同時に使用することで、利用可能な帯域幅が増加します。
TRILL (Transparent Interconnection of Lots of Links) は、イーサネットが任意のトポロジーを持つことを可能にし、構成やユーザーの介入なしに、ダイクストラ法によるフローごとのペアワイズ負荷分割を可能にします。 TRILL のきっかけとなったのは、2002 年 11 月 13 日に始まったベス・イスラエル・ディーコネス医療センターでのイベントでした。 [ 17 ] [ 18 ] Rbridges [ 19 ] [sic] の概念は、2004 年に電気電子学会に初めて提案されましたが、 [ 20 ] 2005 年に[ 21 ]後にTRILL として知られるようになったものを却下し、2006 年から 2012 年にかけて[ 22 ]最短経路ブリッジングとして知られる互換性のないバリエーションを考案しました。
IEEE は2012 年 5 月にIEEE 802.1aq規格を承認しました[ 23 ]。これは最短経路ブリッジング (SPB) としても知られています。SPB は、すべてのリンクを複数の等コスト経路でアクティブにすることができ、ダウンタイムを削減するために収束時間を短縮し、ネットワークのすべての経路でトラフィックの負荷分散を可能にすることで、メッシュ ネットワーク トポロジ(部分的に接続された、または完全に接続された) での負荷分散の使用を簡素化します。[ 24 ] [ 25 ] SPB は、構成エラーを減らし、レイヤ 2 でイーサネットを事実上のプロトコルとして確立したプラグアンドプレイの性質を維持するように設計されています。[ 26 ]
多くの通信会社は、自社ネットワーク内または外部ネットワークへの複数の経路を持っています。高度な負荷分散技術を用いてトラフィックをある経路から別の経路に振り分けることで、特定のリンクにおけるネットワークの混雑を回避し、場合によっては外部ネットワークを経由する伝送コストを最小限に抑えたり、ネットワークの信頼性を向上させたりしています。
負荷分散のもう 1 つの使用方法は、ネットワーク監視活動です。負荷バランサーを使用すると、巨大なデータフローを複数のサブフローに分割し、それぞれが元のデータの一部を読み取る複数のネットワークアナライザーを使用できます。これは、10GbEや STM64 などの高速ネットワークを監視するために使用できます。これらのネットワークでは、データの複雑な処理がワイヤースピードでは不可能な場合があります。[ 27 ]
ロードバランシングは、データセンターネットワークで広く使用されており、任意の 2 つのサーバー間の既存の多数のパスにトラフィックを分散します。[ 28 ]これにより、ネットワーク帯域幅をより効率的に使用でき、プロビジョニング コストを削減できます。一般的に、データセンターネットワークのロードバランシングは、静的または動的に分類できます。
静的負荷分散は、トラフィックフローの送信元アドレスと宛先アドレス、ポート番号のハッシュを計算し、それを使用してフローを既存のパスのいずれかに割り当てる方法を決定することでトラフィックを分散します。動的負荷分散は、異なるパスの帯域幅の使用状況を監視することでトラフィックフローをパスに割り当てます。動的割り当ては、プロアクティブまたはリアクティブにすることもできます。前者の場合、割り当ては一度行われると固定されますが、後者の場合、ネットワークロジックは利用可能なパスを継続的に監視し、ネットワークの使用状況の変化（新しいフローの到着または既存のフローの完了）に応じてフローをパス間で移動します。データセンターネットワークにおける負荷分散の包括的な概要が公開されています。[ 28 ]
ロードバランシングは、フェイルオーバー（1 つ以上のコンポーネントの障害発生後もサービスを継続する仕組み）を実装するためによく使用されます。コンポーネントは継続的に監視され（たとえば、Web サーバーは既知のページを取得することで監視されます）、いずれかのコンポーネントが応答しなくなると、ロードバランサーに通知され、そのコンポーネントへのトラフィック送信が停止されます。コンポーネントがオンラインに戻ると、ロードバランサーはトラフィックをそのコンポーネントに再ルーティングし始めます。この仕組みが機能するためには、サービスの容量を超えるコンポーネントが少なくとも 1 つ必要です（N+1 冗長）。これは、稼働中のコンポーネントすべてに、障害発生時に引き継ぐ単一のバックアップ コンポーネントをペアにするフェイルオーバー方式（デュアル モジュラー冗長）よりもはるかに低コストで柔軟性があります。一部のRAIDシステムでは、同様の効果を得るためにホット スペアを使用することもできます。[ 29 ]
この手法は、システムの中で最も複雑で故障しやすい部分を迅速に代替できるようにすることで、耐障害性を向上させることができます。しかし、ロードバランサー自体が単一障害点となる可能性もあります。
人工知能のトレーニングおよび推論システム（「AIファクトリー」と呼ばれることもある）にデータを供給する大容量データ取り込みパイプラインを管理するために、ロードバランシング技術がますます使用されるようになっている。これらのAI駆動環境では、膨大な量の構造化データと非構造化データを継続的に処理する必要があり、ネットワーク、ストレージ、および計算リソースに大きな負荷がかかる。[ 30 ]必要な高スループットと低遅延を維持するために、組織は一般的に、高度なTCP最適化、接続プーリング、および適応型スケジューリングが可能なロードバランシングツールを導入する。このような機能は、受信データ要求をサーバーまたはノード全体に均等に分散し、輻輳を防ぎ、計算リソースが効率的に利用され続けることを保証するのに役立つ。[ 31 ]
大規模または高性能なAI環境にロードバランサーを導入すると、帯域幅の制約が緩和され、さまざまなデータガバナンス要件に対応できます。特に、機密性の高いトレーニングデータをサードパーティのクラウドサービスに送信できない場合に有効です。ロードバランサーは、データをローカル（オンプレミス）またはプライベートクラウド間でルーティングすることで、AIワークフローがパブリッククラウドの帯域幅制限を回避し、転送コストを削減し、規制基準への準拠を維持できるようにします。AIモデルのサイズが拡大するにつれて（多くの場合、数十億または数兆のパラメータで測定されます）、データ取り込みのためのロードバランシングは、AIファクトリーの信頼性、拡張性、およびコスト効率を維持するために重要性を増しています。
最短経路ブリッジングがイーサネットファブリックのスパニングツリーに取って代わる。