負荷分散（コンピューティング）

コンピューティングにおいて、負荷分散とは、一連のタスクを一連のリソース(コンピューティング ユニット)に分散して、全体的な処理の効率を高めるプロセスです。負荷分散により、応答時間を最適化し、一部のコンピューティング ノードが不均等に過負荷になり、他のコンピューティング ノードがアイドル状態になるのを防ぐことができます。

負荷分散は、並列コンピュータの分野で研究されているテーマです。2 つの主なアプローチがあります。1 つは、さまざまなマシンの状態を考慮しない静的アルゴリズム、もう 1 つは、通常、より汎用的で効率的ですが、さまざまなコンピューティング ユニット間での情報交換が必要で、効率が低下するリスクがある動的アルゴリズムです。

負荷分散アルゴリズムは、常に特定の問題に答えようとします。特に、タスクの性質、アルゴリズムの複雑さ、アルゴリズムが実行されるハードウェア アーキテクチャ、必要なエラー許容度を考慮する必要があります。したがって、アプリケーション固有の要件を最もよく満たす妥協点を見つける必要があります。

負荷分散アルゴリズムの効率は、タスクの性質に大きく依存します。したがって、意思決定時に利用できるタスクに関する情報が多いほど、最適化の可能性が高まります。

各タスクの実行時間を完全に把握することで、最適な負荷分散を実現できます（プレフィックス合計のアルゴリズムを参照）。^[1]残念ながら、これは実際には理想的なケースです。各タスクの正確な実行時間を知ることは非常にまれな状況です。

このため、異なる実行時間を把握するための手法はいくつかあります。まず、比較的均一なサイズのタスクがあるという幸運なシナリオでは、各タスクがほぼ平均的な実行時間を必要とすると考えることができます。一方、実行時間が非常に不規則な場合は、より洗練された手法を使用する必要があります。1 つの手法は、各タスクにメタデータを追加することです。同様のメタデータの以前の実行時間に応じて、統計に基づいて将来のタスクを推測することができます。^[2]

場合によっては、タスクは相互に依存します。これらの相互依存性は、有向非巡回グラフで表すことができます。直感的には、一部のタスクは他のタスクが完了するまで開始できません。

各タスクに必要な時間が事前にわかっていると仮定すると、最適な実行順序は合計実行時間の最小化につながるはずです。これはNP 困難な問題であるため、正確に解決するのは難しい場合があります。ジョブ スケジューラのように、メタヒューリスティック手法を使用して最適なタスク配分を計算するアルゴリズムがあります。

負荷分散アルゴリズムの設計に重要なタスクのもう 1 つの特徴は、実行中にサブタスクに分割できることです。後ほど説明する「ツリー型計算」アルゴリズムは、この特異性を最大限に活用しています。

負荷分散アルゴリズムは、タスクの分散にシステムの状態を考慮しない場合、「静的」です。したがって、システムの状態には、特定のプロセッサの負荷レベル(場合によっては過負荷) などの尺度が含まれます。代わりに、着信タスクの到着時間やリソース要件など、システム全体に関する想定が事前に行われます。さらに、プロセッサの数、それぞれの電力と通信速度は既知です。したがって、静的負荷分散は、特定のパフォーマンス関数を最小化するために、既知のタスク セットを利用可能なプロセッサに関連付けることを目的としています。秘訣は、このパフォーマンス関数の概念にあります。

静的負荷分散技術は、通常、負荷を分散してパフォーマンス関数を最適化するルーターまたはマスターを中心に行われます。この最小化では、分散されるタスクに関連する情報を考慮し、予想される実行時間を導き出すことができます。

静的アルゴリズムの利点は、設定が簡単で、かなり定期的なタスク ( Web サイトからのHTTPリクエストの処理など) の場合に非常に効率的であることです。ただし、タスクの割り当てには依然として統計的なばらつきがあり、一部のコンピューティング ユニットに過負荷がかかる可能性があります。

静的負荷分散アルゴリズムとは異なり、動的アルゴリズムは、システム内の各コンピューティング ユニット (ノードとも呼ばれます) の現在の負荷を考慮します。このアプローチでは、タスクを過負荷のノードから負荷の低いノードに動的に移動して、より高速な処理を受けることができます。これらのアルゴリズムの設計ははるかに複雑ですが、特にタスクごとに実行時間が大きく異なる場合に優れた結果を生み出すことができます。

動的負荷分散アーキテクチャは、作業の分散専用の特定のノードを持つ必要がないため、よりモジュール化できます。タスクが特定の瞬間の状態に応じてプロセッサに一意に割り当てられている場合、それは一意の割り当てです。一方、タスクがシステムの状態とその進化に応じて永続的に再分散できる場合、これは動的割り当てと呼ばれます。^[3]明らかに、決定に達するために過度の通信を必要とする負荷分散アルゴリズムは、全体的な問題の解決を遅らせるリスクがあります。

並列コンピューティング インフラストラクチャは、多くの場合、異なるコンピューティング能力を持つユニットで構成されており、負荷分散ではこれを考慮する必要があります。

たとえば、低電力ユニットは、より少ない計算量を必要とするリクエストを受信したり、リクエスト サイズが均一または不明な場合は、より大きなユニットよりも少ないリクエストを受信したりすることがあります。

並列コンピュータは、多くの場合、2 つの大きなカテゴリに分けられます。1 つは、すべてのプロセッサが単一の共通メモリを共有し、そのメモリ上で並列に読み取りと書き込みを行うもの ( PRAMモデル)、もう 1 つは、各コンピューティング ユニットが独自のメモリを持ち (分散メモリモデル)、情報がメッセージによって交換されるものです。

共有メモリコンピュータの場合、書き込み競合を管理すると、各コンピューティング ユニットの個々の実行速度が大幅に低下します。ただし、並列処理では問題なく動作します。逆に、メッセージ交換の場合は、各プロセッサがフル スピードで動作できます。一方、集合的なメッセージ交換の場合は、すべてのプロセッサは、最も遅いプロセッサが通信フェーズを開始するまで待機する必要があります。

実際には、これらのカテゴリの 1 つに正確に当てはまるシステムはほとんどありません。一般に、プロセッサにはそれぞれ、次の計算に必要なデータを保存するための内部メモリがあり、連続したクラスターに編成されています。多くの場合、これらの処理要素は、分散メモリとメッセージ パッシングを通じて調整されます。したがって、負荷分散アルゴリズムは、並列アーキテクチャに独自に適合させる必要があります。そうしないと、並列問題解決の効率が大幅に低下するリスクがあります。

上記のハードウェア構造に適応すると、負荷分散アルゴリズムには 2 つの主なカテゴリがあります。1 つは、タスクが「マスター」によって割り当てられ、「ワーカー」によって実行されるもので、ワーカーは作業の進行状況をマスターに通知し、動的アルゴリズムの場合はマスターがワークロードの割り当てまたは再割り当てを担当できます。文献ではこれを「マスター ワーカー」アーキテクチャと呼んでいます。もう 1 つは、制御をさまざまなノードに分散できるものです。負荷分散アルゴリズムは各ノードで実行され、タスクの割り当て (および必要に応じて再割り当てと分割) の責任が共有されます。最後のカテゴリは、動的負荷分散アルゴリズムを想定しています。

各負荷分散アルゴリズムの設計はそれぞれ異なるため、前述の区別は限定的である必要があります。したがって、たとえば、各サブクラスターに「マスター」ノードがあり、それ自体がグローバル「マスター」の影響を受ける中間戦略を持つこともできます。また、マスター スレーブ戦略と分散制御戦略を交互に使用するマルチレベル構成もあります。後者の戦略はすぐに複雑になり、めったに使用されません。設計者は、制御しやすいアルゴリズムを好みます。

非常に長期間にわたって実行されるアルゴリズム（サーバー、クラウドなど）のコンテキストでは、コンピューター アーキテクチャは時間の経過とともに進化します。ただし、毎回新しいアルゴリズムを設計する必要がないことが望ましいです。

したがって、負荷分散アルゴリズムの非常に重要なパラメータは、スケーラブルなハードウェア アーキテクチャに適応する能力です。これは、アルゴリズムのスケーラビリティと呼ばれます。アルゴリズムのパフォーマンスが、そのパラメータのサイズに比較的依存しない場合、そのアルゴリズムは入力パラメータに対してスケーラブルであると呼ばれます。

アルゴリズムが変化する計算ユニット数に適応できるが、実行前に計算ユニット数を固定しなければならない場合、そのアルゴリズムは成形可能と呼ばれます。一方、アルゴリズムが実行中に変動するプロセッサ数に対応できる場合、そのアルゴリズムは柔軟であると言われます。ほとんどの負荷分散アルゴリズムは、少なくとも成形可能です。^[4]

特に大規模なコンピューティングクラスタでは、1つのコンポーネントの障害に耐えられない並列アルゴリズムを実行することは許容されません。そのため、プロセッサの停止を検出して計算を回復できるフォールトトレラントアルゴリズムが開発されています。^[5]

タスクが互いに独立しており、それぞれの実行時間とタスクを細分化できる場合は、単純で最適なアルゴリズムが存在します。

各プロセッサに同じ量の計算を与えるようにタスクを分割することで、あとは結果をグループ化するだけです。プレフィックス合計アルゴリズムを使用すると、この分割はプロセッサの数に対して対数時間で計算できます。 ^{[引用が必要]}

しかし、タスクを細分化できない場合（つまり、タスクがアトミックである場合）、タスク割り当ての最適化は難しい問題ではあるものの、各タスクのサイズが各ノードで実行される計算の合計よりもはるかに小さい限り、比較的公平なタスクの配分を近似することは可能です。^[1]

ほとんどの場合、タスクの実行時間は不明であり、大まかな近似値しか利用できません。このアルゴリズムは特に効率的ですが、このようなシナリオには適していません。

実行時間が事前に全く分からない場合でも、静的な負荷分散は常に可能です。

ラウンドロビン アルゴリズムでは、最初のリクエストが最初のサーバーに送信され、次のリクエストが 2 番目のサーバーに送信され、これが最後のサーバーまで続きます。その後、再度開始され、次のリクエストが最初のサーバーに割り当てられ、これが繰り返されます。

このアルゴリズムは、最も強力なユニットが最も多くのリクエストを受信し、最初に受信するように重み付けできます。

ランダム化された静的負荷分散は、単に異なるサーバーにタスクをランダムに割り当てるというものです。この方法は非常にうまく機能します。一方、タスクの数が事前にわかっている場合は、事前にランダムな順列を計算する方がさらに効率的です。これにより、割り当てごとの通信コストを回避できます。すべてのプロセッサが自分に割り当てられたタスクを認識しているため、分散マスターは不要になります。タスクの数が不明な場合でも、すべてのプロセッサに認識されている疑似ランダム割り当て生成により、通信を回避することができます。

この戦略のパフォーマンス (特定の固定タスク セットの合計実行時間で測定) は、タスクの最大サイズとともに低下します。

もちろん、他の割り当て方法もあります。

• ^{作業の削減: [説明が必要]}の実行を減らすことで、サーバーに多くのタスクを割り当てます(この方法には重み付けもできます)。
• ハッシュ:ハッシュ テーブルに従ってクエリを割り当てます。
• 2つの選択肢の力：2つのサーバーをランダムに選び、2つの選択肢のうちより良いものを選ぶ。^{[6] [7]}

マスター ワーカースキームは、最も単純な動的負荷分散アルゴリズムの 1 つです。マスターは、すべてのワーカー (「スレーブ」と呼ばれることもあります) に作業負荷を分散します。最初は、すべてのワーカーがアイドル状態であり、これをマスターに報告します。マスターはワーカーの要求に応答し、タスクをワーカーに分散します。マスターは、割り当てるタスクがなくなると、ワーカーに通知して、タスクの要求を停止します。

このシステムの利点は、負担を非常に公平に分散することです。実際、割り当てに必要な時間を考慮しなければ、実行時間は上記のプレフィックスの合計に匹敵することになります。

このアルゴリズムの問​​題点は、必要な通信量が多いため、多数のプロセッサに適応するのが難しいことです。このスケーラビリティの欠如により、非常に大規模なサーバーや非常に大規模な並列コンピューターではすぐに動作しなくなります。マスターはボトルネックとして機能します。

ただし、マスターをさまざまなプロセッサで使用できるタスク リストに置き換えることで、アルゴリズムの品質を大幅に向上できます。このアルゴリズムは実装が少し難しくなりますが、非常に大規模なコンピューティング センターにはまだ不十分ですが、スケーラビリティが大幅に向上します。

タスクの完了に必要な時間が不明な場合にスケーラビリティの問題を克服するもう 1 つの手法は、ワーク スティーリングです。

このアプローチは、各プロセッサに一定数のタスクをランダムまたは事前定義された方法で割り当て、非アクティブなプロセッサがアクティブなプロセッサまたは過負荷のプロセッサから作業を「奪う」ことを可能にします。この概念の実装はいくつか存在し、タスク分割モデルとプロセッサ間の交換を決定するルールによって定義されます。この手法は特に効果的ですが、通信が問題の解決ではなくプロセッサの主な占有にならないようにする必要があるため、実装は困難です。

アトミックタスクの場合、2 つの主な戦略を区別できます。1 つは、負荷の低いプロセッサが、負荷の高いプロセッサにコンピューティング能力を提供する戦略、もう 1 つは、負荷の高いユニットが割り当てられたワークロードを軽減しようとする戦略です。ネットワークの負荷が高い場合は、負荷の最も低い^ユニットが可用性を提供する方が効率的であり、ネットワークの負荷が軽い場合は、過負荷のプロセッサが最も非アクティブなプロセッサからのサポートを必要とすることが示されています [8]。この経験則により、交換されるメッセージの数が制限されます。

原子レベルを超えて分割できない単一の大きなタスクから開始する場合、親タスクが作業ツリーに分散される 非常に効率的なアルゴリズム「ツリー型計算」 ^{[9]があります。}

最初は、順番に作業する 1 つのプロセッサを除いて、多くのプロセッサに空のタスクがあります。アイドル状態のプロセッサは、他のプロセッサ (必ずしもアクティブではない) にランダムに要求を発行します。後者が作業中のタスクを細分化できる場合は、作業の一部を要求元のノードに送信することで細分化します。そうでない場合は、空のタスクを返します。これにより、ツリー構造が生成されます。次に、サブタスクが完了したら、親プロセッサに終了信号を送信して、ツリーのルートに到達するまでメッセージを親プロセッサに送信する必要があります。最初のプロセッサ、つまりルートが終了したら、グローバル終了メッセージをブロードキャストできます。最後に、ツリーを遡って結果を組み立てる必要があります。

このようなアルゴリズムの効率は、ジョブのカットと通信時間が、実行する作業量に比べてそれほど高くない場合、プレフィックスの合計に近くなります。通信コストが高くなりすぎないようにするために、共有メモリ上にジョブのリストを置くことが考えられます。したがって、マスター プロセッサの要求に応じて、この共有メモリ上の特定の位置から要求が読み取られるだけです。

並列計算による効率的な問題解決に加えて、負荷分散アルゴリズムは、多数のユーザーがいるサイトで 1 秒あたり多数のリクエストを処理できる必要がある HTTPリクエスト管理で広く使用されています。

負荷分散の最も一般的に使用されるアプリケーションの 1 つは、複数のサーバー(サーバー ファームとも呼ばれる) から単一のインターネット サービスを提供することです。一般的な負荷分散システムには、人気のあるWeb サイト、大規模なインターネット リレー チャットネットワーク、高帯域幅のファイル転送プロトコル(FTP) サイト、ネットワーク ニュース転送プロトコル(NNTP) サーバー、ドメイン ネーム システム(DNS) サーバー、データベースなどがあります。

ラウンドロビン DNS は、専用のソフトウェア ノードまたはハードウェア ノードを必要としない、負荷分散の代替方法です。この手法では、複数のIP アドレスが単一のドメイン名に関連付けられ、クライアントにはラウンドロビン方式で IP が与えられます。クライアントには有効期限の短い IP が割り当てられるため、クライアントは要求されたインターネット サービスに次回アクセスするときに、別の IP を使用する可能性が高くなります。

DNS を使用した負荷分散のもう 1 つのより効果的な手法は、www.example.org をサブドメインとして委任し、そのゾーンを Web サイトを提供している同じ各サーバーで処理することです。この手法は、個々のサーバーがインターネット上で地理的に分散している場合に特に有効です。例:

one.example.org 192.0.2.1

two.example.org 203.0.113.2

www.example.org NS one.example.org

www.example.org NS 2.example.org

しかし、各サーバーのwww.example.orgのゾーンファイルは異なっており、各サーバーは独自のIPアドレスをAレコードとして解決します。^{[10]サーバー}1のwww.example.orgのゾーンファイルは次のように報告します。

192.0.2.1の@

サーバー2の同じゾーン ファイルには次の内容が含まれます。

203.0.113.2の@

この方法では、サーバーがダウンすると、その DNS は応答せず、Web サービスはトラフィックを受信しません。1 つのサーバーへの回線が混雑すると、DNS の信頼性が低いため、そのサーバーに到達する HTTP トラフィックが少なくなります。さらに、リゾルバへの最も速い DNS 応答は、ほとんどの場合、ネットワークの最も近いサーバーからの応答であるため、地理的な負荷分散が保証されます^{[引用が必要] 。A レコードの}TTL を短くすると、サーバーがダウンしたときにトラフィックが迅速に迂回されるようになります。この手法では、セッションの途中で個々のクライアントが個々のサーバー間を切り替える可能性があることを考慮する必要があります。

負荷分散のもう 1 つのアプローチは、サーバーの IP アドレスのリストをクライアントに配信し、各接続でクライアントにリストから IP アドレスをランダムに選択させることです。^{[11] [12]}これは基本的に、すべてのクライアントが同様の負荷を生成し、大数の法則^[12]によってサーバー間で適度に均一な負荷分散を実現することに依存しています。クライアント側のランダム負荷分散は、ラウンドロビン DNS よりも負荷分散が優れている傾向があると言われています。これは、ラウンドロビン DNS のキャッシュの問題によるもので、大規模な DNS キャッシュ サーバーの場合、ラウンドロビン DNS の分散がゆがむ傾向がありますが、クライアント側のランダム選択は DNS キャッシュに関係なく影響を受けません。^[12]

このアプローチでは、IP リストをクライアントに配信する方法はさまざまで、DNS リスト (ラウンドロビンなしですべてのクライアントに配信) として実装することも、リストにハードコーディングして実装することもできます。「スマート クライアント」を使用すると、ランダムに選択されたサーバーがダウンしていることを検出し、ランダムに再接続するため、フォールト トレランスも提供されます。

インターネット サービスの場合、サーバー側のロード バランサは通常、外部クライアントがサービスにアクセスするために接続しているポートをリッスンしているソフトウェア プログラムです。ロード バランサは、リクエストを「バックエンド」サーバーの 1 つに転送します。通常、バックエンド サーバーはロード バランサに応答します。これにより、クライアントが内部の機能分離について知ることなく、ロード バランサがクライアントに応答できます。また、クライアントがバックエンド サーバーに直接接続するのを防ぐため、内部ネットワークの構造が隠され、カーネルのネットワーク スタックや他のポートで実行されている無関係なサービスへの攻撃を防ぐことができるため、セキュリティ上の利点があります。

一部のロード バランサは、すべてのバックエンド サーバーが利用できない場合に特別な処理を実行するためのメカニズムを提供します。これには、バックアップ ロード バランサへの転送や、停止に関するメッセージの表示などが含まれます。

また、ロードバランサ自体が単一障害点にならないことも重要です。通常、ロードバランサは高可用性ペアで実装され、特定のアプリケーションで必要な場合はセッション永続性データを複製することもできます。^[13]一部のアプリケーションは、定義されたネットワークを超えて差分共有プラットフォームにロードバランシングポイントをオフセットすることで、この問題の影響を受けないようにプログラムされています。これらの機能とペアになっているシーケンシャルアルゴリズムは、特定のデータベースに固有の柔軟なパラメータによって定義されます。^[14]

ロードバランサーは、リクエストをどのバックエンドサーバーに送信するかを決定するために、負荷分散方式とも呼ばれる多数のスケジューリングアルゴリズムを使用します。単純なアルゴリズムには、ランダム選択、ラウンドロビン、最小接続などがあります。^[15]より高度なロードバランサーでは、サーバーの報告された負荷、最小応答時間、稼働/停止ステータス（何らかの監視ポーリングによって決定）、アクティブな接続の数、地理的な場所、機能、最近割り当てられたトラフィック量などの追加の要素が考慮される場合があります。

負荷分散サービスを運用する際の重要な問題は、ユーザーのセッション内の複数のリクエストにわたって保持する必要がある情報をどのように処理するかです。この情報が 1 つのバックエンド サーバーにローカルに保存されている場合、その後の異なるバックエンド サーバーへのリクエストではその情報を見つけることができません。これは再計算可能なキャッシュされた情報である可能性があり、その場合、リクエストを別のバックエンド サーバーに負荷分散すると、パフォーマンスの問題が発生するだけです。^[15]

理想的には、ロード バランサーの背後にあるサーバーのクラスターはセッションを認識しないようにする必要があります。これにより、クライアントがいつでも任意のバックエンド サーバーに接続しても、ユーザー エクスペリエンスは影響を受けません。これは通常、共有データベースまたはMemcachedなどのメモリ内セッション データベースによって実現されます。

セッション データの問題に対する基本的な解決策の 1 つは、ユーザー セッション内のすべての要求を一貫して同じバックエンド サーバーに送信することです。これは、「永続性」または「スティッキネス」と呼ばれます。この手法の大きな欠点は、自動フェイルオーバーがないことです。バックエンド サーバーがダウンすると、そのセッションごとの情報にアクセスできなくなり、それに依存するセッションはすべて失われます。同じ問題は通常、中央データベース サーバーに関連します。Web サーバーが「ステートレス」で「スティッキ」ではない場合でも、中央データベースはステートレスです (以下を参照)。

特定のサーバーへの割り当ては、ユーザー名、クライアント IP アドレス、またはランダムに基づいて行われます。DHCP 、ネットワークアドレス変換、Web プロキシによってクライアントの認識アドレスが変化するため、この方法は信頼できない場合があります。ランダム割り当てはロード バランサーで記憶する必要があるため、ストレージに負担がかかります。ロード バランサーが交換されるか故障すると、この情報が失われる可能性があり、割り当てテーブルに使用可能なスペースを超えないように、タイムアウト期間後または高負荷期間中に割り当てを削除する必要がある場合があります。ランダム割り当て方法では、クライアントが何らかの状態を維持する必要があり、たとえば Web ブラウザーが Cookie の保存を無効にした場合などに問題が発生する可能性があります。高度なロード バランサーは、複数の永続化手法を使用して、1 つの方法の欠点の一部を回避します。

もう 1 つの解決策は、セッションごとのデータをデータベースに保存することです。これは通常、データベースの負荷が増加するため、パフォーマンスに悪影響を及ぼします。データベースは、セッションごとのデータよりも一時的ではない情報を保存するのに最適です。データベースが単一障害点になるのを防ぎ、スケーラビリティを向上させるために、データベースは複数のマシンに複製されることが多く、負荷分散を使用してクエリ負荷をそれらのレプリカに分散します。Microsoft のASP.net State Server テクノロジは、セッション データベースの例です。Web ファーム内のすべてのサーバーは、State Server にセッション データを保存し、ファーム内のどのサーバーでもデータを取得できます。

クライアントが Web ブラウザである非常に一般的なケースでは、ブラウザ自体にセッションごとのデータを保存するのがシンプルですが効率的な方法です。これを実現する方法の 1 つは、適切にタイムスタンプが付けられ暗号化されたブラウザ Cookie を使用することです。もう 1 つはURL 書き換えです。セッション データをクライアントに保存することが、一般的に推奨されるソリューションです。そうすれば、ロード バランサは、リクエストを処理するバックエンド サーバを自由に選択できます。ただし、この状態データ処理方法は、セッション状態ペイロードが大きく、サーバ上のリクエストごとにそれを再計算することが不可能な、一部の複雑なビジネス ロジック シナリオには適していません。URL 書き換えには、エンド ユーザーが送信された URL を簡単に変更してセッション ストリームを変更できるため、セキュリティ上の大きな問題があります。

永続的なデータを保存するためのもう 1 つのソリューションは、各データ ブロックに名前を関連付け、分散ハッシュ テーブルを使用してその名前を使用可能なサーバーの 1 つに疑似ランダムに割り当て、そのデータ ブロックを割り当てられたサーバーに保存することです。

ハードウェアおよびソフトウェア ロード バランサには、さまざまな特別な機能があります。ロード バランサの基本的な機能は、スケジューリング アルゴリズムに従って、受信リクエストをクラスター内の複数のバックエンド サーバーに分散できることです。次の機能のほとんどはベンダー固有です。

非対称負荷

一部のバックエンド サーバーが他のサーバーよりも多くのワークロードを共有するように、手動で比率を割り当てることができます。これは、一部のサーバーの容量が他のサーバーよりも大きいことを考慮するための大まかな方法​​として使用される場合があり、必ずしも期待どおりに機能するとは限りません。

優先アクティベーション

利用可能なサーバーの数が一定数を下回ったり、負荷が高くなりすぎたりすると、スタンバイ サーバーをオンラインにすることができます。

TLS オフロードと高速化

TLS (またはその前身である SSL) アクセラレーションは、暗号化プロトコルの計算を専用のハードウェアにオフロードする手法です。ワークロードによっては、TLS要求の暗号化と認証の要件の処理が Web サーバーの CPU の需要の大部分を占めることがあります。需要が増加すると、TLS のオーバーヘッドが Web サーバー間で分散されるため、ユーザーは応答時間が遅くなることに気付くでしょう。Web サーバーのこの需要を取り除くために、バランサーは TLS 接続を終了し、HTTPS 要求を HTTP 要求として Web サーバーに渡すことができます。バランサー自体が過負荷になっていなければ、エンドユーザーが感じるパフォーマンスが著しく低下することはありません。このアプローチの欠点は、すべての TLS 処理が単一のデバイス (バランサー) に集中し、それが新しいボトルネックになる可能性があることです。一部のロード バランサー アプライアンスには、TLS を処理するための専用のハードウェアが含まれています。非常に高価な専用ハードウェアであるロード バランサーをアップグレードする代わりに、TLS オフロードを放棄して Web サーバーをいくつか追加する方が安上がりな場合があります。また、Oracle/Sun などの一部のサーバー ベンダーは、T2000 などの CPU に暗号化アクセラレーション ハードウェアを組み込んでいます。F5 Networks は、TLS トラフィックの暗号化と復号化に使用されるローカル トラフィック マネージャー (LTM) に専用の TLS アクセラレーション ハードウェア カードを組み込んでいます。バランサーでの TLS オフロードの明らかな利点の 1 つは、HTTPS 要求のデータに基づいてバランシングやコンテンツ スイッチングを行えることです。

分散型サービス拒否(DDoS) 攻撃からの保護

ロード バランサは、 SYN フラッド攻撃を軽減し、一般的にサーバからより効率的なプラットフォームに作業をオフロードするために、 SYN クッキーや遅延バインディング (バックエンド サーバは TCP ハンドシェイクが完了するまでクライアントを認識しない) などの機能を提供できます。

HTTP 圧縮

HTTP 圧縮は、すべての最新の Web ブラウザーで利用可能な gzip 圧縮を利用して、HTTP オブジェクトに転送されるデータの量を削減します。応答が大きいほど、またクライアントが遠いほど、この機能によって応答時間が改善されます。ただし、この機能はロード バランサーに追加の CPU 要求をかけるため、代わりに Web サーバーで実行できます。

TCP オフロード

ベンダーによって用語は異なりますが、通常、各クライアントからの各 HTTP リクエストは異なる TCP 接続であるという考え方です。この機能は、HTTP/1.1 を利用して、複数のクライアントからの複数の HTTP リクエストをバックエンド サーバーへの単一の TCP ソケットに統合します。

TCPバッファリング

ロード バランサは、サーバーからの応答をバッファリングし、そのデータを低速クライアントに少しずつ提供することで、Web サーバーが、リクエスト全体をクライアントに直接送信する場合よりも速く、他のタスクのためにスレッドを解放できるようにします。

直接サーバーリターン

要求と応答が異なるネットワーク パスを持つ非対称負荷分散のオプション。

健康チェック

バランサは、アプリケーション層の健全性についてサーバーをポーリングし、障害のあるサーバーをプールから削除します。

HTTP キャッシュ

バランサーは静的コンテンツを保存するため、一部のリクエストはサーバーに接続せずに処理できます。

コンテンツフィルタリング

一部のバランサーは、通過中にトラフィックを任意に変更することができます。

HTTP セキュリティ

一部のバランサーは、HTTP エラー ページを非表示にしたり、HTTP 応答からサーバー識別ヘッダーを削除したり、Cookie を暗号化してエンド ユーザーが操作できないようにしたりできます。

優先キューイング

レート シェーピングとも呼ばれ、異なるトラフィックに異なる優先順位を付ける機能です。

コンテンツ認識スイッチング

ほとんどのロード バランサは、要求が暗号化されていない (HTTP) か、暗号化されている (HTTPS 経由) 場合は HTTPS 要求がロード バランサで終了 (復号化) されることを前提として、要求されている URL に基づいて異なるサーバーに要求を送信できます。

クライアント認証

ウェブサイトへのアクセスを許可する前に、さまざまな認証ソースに対してユーザーを認証します。

プログラムによるトラフィック操作

少なくとも 1 つのバランサーでは、スクリプト言語を使用して、カスタム バランシング メソッド、任意のトラフィック操作などが可能になります。

ファイアウォール

ファイアウォールは、ネットワーク セキュリティ上の理由から、バックエンド サーバーへの直接接続をブロックする場合があります。

侵入防止システム

侵入防止システムは、ファイアウォール セキュリティによって提供されるネットワーク/トランスポート層に加えて、アプリケーション層のセキュリティも提供します。

負荷分散は、冗長通信リンクを備えたアプリケーションで役立ちます。たとえば、企業では複数のインターネット接続があり、接続の 1 つに障害が発生した場合でもネットワーク アクセスが確保されます。フェイルオーバー構成では、1 つのリンクが通常の使用に指定され、2 番目のリンクはプライマリ リンクに障害が発生した場合にのみ使用されます。

負荷分散を使用すると、両方のリンクを常に使用できます。デバイスまたはプログラムは、すべてのリンクの可用性を監視し、パケットを送信するためのパスを選択します。複数のリンクを同時に使用すると、使用可能な帯域幅が増加します。

TRILL (Transparent Interconnection of Lots of Links)は、イーサネットが任意のトポロジを持つことを容易にし、ダイクストラのアルゴリズムによって、構成やユーザーの介入なしに、フローごとにペアワイズ負荷分割を可能にします。TRILL のきっかけは、2002 年 11 月 13 日に始まったベス・イスラエル・ディーコネス医療センターでのイベントでした^{。[16] [17]} Rbridge の概念^[18] [sic] は、2004 年に電気電子技術者協会に初めて提案されましたが、 ^[19]同協会は 2005 年に^[20] TRILL として知られるようになった概念を拒否し、2006 年から 2012 年にかけて^[21]最短パス ブリッジングとして知られる互換性のないバリエーションを考案しました。

IEEEは2012年5月にIEEE 802.1aq規格を承認しました。 ^[22]これは最短パスブリッジング（SPB）としても知られています。SPBは、すべてのリンクを複数の等コストパスを介してアクティブにし、ダウンタイムを削減するためにより速い収束時間を提供し、トラフィックがネットワークのすべてのパスにわたって負荷分散できるようにすることで、メッシュネットワークトポロジ（部分的に接続または完全に接続）での負荷分散の使用を簡素化します。^{[23] [24]} SPBは、構成中の人為的エラーを事実上排除するように設計されており、イーサネットをレイヤー2の事実上のプロトコルとして確立したプラグアンドプレイの性質を維持しています。^[25]

多くの通信会社は、自社のネットワークまたは外部ネットワークへの複数のルートを持っています。これらの会社は、高度な負荷分散を使用してトラフィックをあるパスから別のパスに移行し、特定のリンクでのネットワーク輻輳を回避します。また、外部ネットワーク間の転送コストを最小限に抑えたり、ネットワークの信頼性を向上させたりすることもあります。

負荷分散のもう一つの用途は、ネットワーク監視活動です。負荷分散装置を使用すると、膨大なデータフローを複数のサブフローに分割し、複数のネットワークアナライザを使用して、それぞれが元のデータの一部を読み取ることができます。これは、ワイヤスピードではデータの複雑な処理が不可能な10GbEやSTM64などの高速ネットワークを監視するのに非常に便利です。^[26]

負荷分散は、データセンターネットワークで、任意の2つのサーバー間の多数の既存パスにトラフィックを分散するために広く使用されています。 ^[27]これにより、ネットワーク帯域幅をより効率的に使用し、プロビジョニングコストを削減できます。一般に、データセンターネットワークの負荷分散は、静的または動的に分類できます。

静的負荷分散は、トラフィックフローの送信元と宛先のアドレスとポート番号のハッシュを計算し、それを使用してフローが既存のパスの 1 つに割り当てられる方法を決定することによってトラフィックを分散します。動的負荷分散は、さまざまなパスの帯域幅の使用状況を監視することによって、トラフィックフローをパスに割り当てます。動的割り当ては、プロアクティブまたはリアクティブにすることもできます。前者の場合、割り当ては一度行われると固定されますが、後者の場合、ネットワークロジックは利用可能なパスを監視し続け、ネットワーク使用率が変化すると (新しいフローの到着または既存のフローの完了)、それらのパス間でフローをシフトします。データセンターネットワークの負荷分散の包括的な概要が公開されています。^[27]

負荷分散は、フェイルオーバー (1 つ以上のコンポーネントに障害が発生した後もサービスを継続する) を実装するためによく使用されます。コンポーネントは継続的に監視され (たとえば、Web サーバーは既知のページを取得することで監視されます)、コンポーネントの 1 つが応答しなくなると、ロード バランサーに通知され、そのコンポーネントにトラフィックが送信されなくなります。コンポーネントがオンラインに戻ると、ロード バランサーはそのコンポーネントにトラフィックを再ルーティングし始めます。これが機能するには、サービスの容量を超えるコンポーネントが少なくとも 1 つ必要です ( N+1 冗長性)。これは、すべてのライブ コンポーネントが、障害発生時に引き継ぐ単一のバックアップ コンポーネントとペアになっているフェイルオーバー アプローチ (デュアル モジュラー冗長性)よりもはるかに安価で柔軟性があります。一部のRAIDシステムでは、同様の効果を得るためにホット スペアを利用することもできます。^[28]

ウィキメディア・コモンズには、負荷分散 (コンピューティング)に関連するメディアがあります。

• 完全な自動障害回復機能を備えた負荷分散用のサーバールーティング