ロードバランサとは何ですか?受信トラフィックを効果的に分散する方法

ロードバランサーは、受信ネットワークトラフィックを複数のバックエンドサーバー間で分散するインフラストラクチャコンポーネントです。これらは、サーバーの 1 つに障害が発生した場合でもサービスへのアクセスを維持することで、容量を向上させ、冗長性を追加します。

ロードバランサーは、アプリケーションへのパブリックゲートウェイとして機能します。これらはその役割に特化しているため、トラフィックスループットを最大化するために高度に最適化できます。ロードバランサーは通常、アプリケーションの要件に合わせて数種類のルーティングアルゴリズムを使用して構成できます。

この記事では、ロードバランサーとは何か、その仕組み、およびロードバランサーが引き起こす可能性のあるいくつかの複雑さについて説明します。最も一般的な負荷分散アルゴリズムの違いについても説明します。

ロードバランサの機能

ロードバランサーは、アプリケーションのサーバーの前にリバースプロキシを提供する役割を果たします。すべてのクライアントは、個々のバックエンドインスタンスではなく、この単一のプロキシに接続します。ロードバランサーは、各リクエストを処理するサーバーを選択する責任があります。これは外部クライアントには目に見えずに行われます。

ハードウェアベースとソフトウェアベースの両方のロードバランサ実装が利用可能です。ソフトウェア側では、 Apache や NGINX などのほとんどの Web サーバーがその役割を果たすことができます。ハードウェアタイプのロードバランサーは、ホスティングプロバイダーからスタンドアロンインフラストラクチャコンポーネントとして展開されます。

ロードバランサーは通常、バックエンドサーバープール内のインスタンスの健全性を監視します。異常な状態になったバックエンドは新しいトラフィックの送信を停止し、サービスの不安定性とダウンタイムを削減します。同様に、ロードバランサーを使用すると、通常、新しいバックエンドインスタンスをいつでも追加できるため、ピーク時に追加容量を使用してサービスを拡張できます。

ロードバランサーの主な目的は、スループットを最大化し、利用可能なリソースを最も効率的に使用することです。通常、物理サーバー間で水平方向に拡張できることは、CPU やメモリを追加して単一ノードを垂直方向に拡張するよりも効果的です。水平スケーリングにより、容量だけでなく冗長性も向上しますが、ロードバランサ層によって発生するオーバーヘッドは一般にわずかです。

負荷分散アルゴリズム

負荷分散の目的は常に複数のサーバー間でトラフィックを分散することですが、これを実現する方法はいくつかあります。具体的な戦略を検討する前に、選択できるアルゴリズムの 2 つの基本的なタイプを特定することが重要です。

静的バランシング – これらの方法は、ハードコードされた設定値に基づいて動作するため、動作が完全に予測可能になります。この種のアルゴリズムでは、転送先のバックエンドサーバーの状態が考慮されていないため、すでに混雑しているインスタンスに新しいリクエストを送信し続ける可能性があります。
動的バランシング – 動的アルゴリズムは、トラフィックフローとプール内のサーバーの可用性に基づいてリアルタイムで調整します。これらの戦略により、すでに複数のリクエストを処理しているインスタンスを自動的に回避できます。動的ロードバランシングでは、ロードバランサーが各リクエストの完了ステータスを追跡する必要があるため、オーバーヘッドがわずかに増加する可能性があります。

通常、静的バランシングシステムの方が構成、テスト、検査が簡単です。動的バランシングははるかに強力であり、通常は実稼働アプリケーションで推奨される選択肢です。これらの各クラス内では、選択できる特定のルーティング戦略がいくつかあります。

ラウンドロビン – ラウンドロビンは、リクエストを各サーバーに順番に送信する静的なバランシング方法です。 3 つのサーバー A、B、C がある場合、最初の受信リクエストは A に送信され、2 番目のリクエストは B に送信され、3 番目のリクエストは C に送信されます。ロードバランサーは 4 番目のリクエストに対して A で再び開始されます。
加重ラウンドロビン – 管理者がプール内の各サーバーの相対的な優先順位を定義するラウンドロビンアルゴリズムのバリエーション。重みの高いサーバーはより頻繁に使用され、トラフィックのより高いシェアを受け取ります。この方法では、サーバープールが異なる仕様のサーバーで構成されている場合に、ラウンドロビン戦略を使用できます。
ランダム – 多くのロードバランサーには、代替静的選択肢として真のランダムオプションが含まれています。
ハッシュ – この静的バランシング戦略は、クライアントの IP アドレスをハッシュして、どのバックエンドサーバーがリクエストを処理するかを決定します。これにより、同じインスタンスがそのクライアントから発信されるすべての接続に対応することが保証されます。
最も少ない接続数 – これは、オープン接続数が最も少ないサーバーに受信リクエストを常に送信する、一般的な動的アルゴリズムです。多くのアプリケーションでは、これが全体的なパフォーマンスを最大化する最も効果的な方法です。
最も高い帯域幅の利用可能性 – この方法は、最も利用可能な帯域幅を備えたサーバーに新しいトラフィックを送信します。これは、総リクエスト数が少ないままであっても、個々のリクエストが大量の帯域幅を使用する可能性がある状況に最適です。
カスタムの健全性/負荷エンドポイント – 多くのロードバランサーには、バックエンドサーバーによって公開されるカスタムメトリックに基づいてトラフィック分散を決定する方法が含まれています。 SNMP などのメカニズムを使用して、CPU 使用率、メモリ消費量、その他の重要な測定値に対してクエリを実行できます。

ロードバランサのその他の特性

ロードバランサーにより、アプリケーションがいくつか複雑になる可能性があります。最も一般的なものの 1 つは、スティッキーなバックエンドセッションを実現するという課題です。システムがサーバー上で状態を維持し、クライアント接続間で状態を保持する必要があるのは一般的です。

ハッシュ化バランシングアルゴリズムまたは同様のクライアントベースのオプションを使用して、これを軽減できます。これにより、同じ IP アドレスからの接続が特定のサーバーで終了することが保証されます。ほとんどのロードバランサーは、HTTP リクエスト内の指定されたヘッダーまたは Cookie を検索する明示的なスティッキーセッションオプションも提供します。この値を使用すると、クライアントの最初の接続後、リクエストを一貫して同じサーバーに送信できます。

ロードバランサーも SSL 周りの複雑さを生み出す可能性があります。多くの組織は、ロードバランサーで終了するように SSL を構成しています。ロードバランサーとバックエンドサーバー間の接続は、通常の HTTP 経由で行われます。これにより、通常はセットアップが簡素化され、メンテナンスの必要性が軽減されます。

HTTP のみの接続を順方向に使用することは、セキュリティクリティカルなワークロードでは必ずしも受け入れられるとは限りません。 SSL パススルーを実行できるロードバランサーは、最初にデータを復号化することなく、トラフィックをバックエンドサーバーに直接配信できます。ただし、これにより使用できるルーティング機能が制限されます。ロードバランサーは受信リクエストを復号化できないため、ヘッダーや Cookie などの属性に基づいて照合を実行できなくなります。

レイヤ 4 およびレイヤ 7 ロードバランサ

負荷分散は、レイヤー 4 (L4) およびレイヤー 7 (L7) ネットワークの文脈で議論されることがよくあります。これらの用語は、ロードバランサーがネットワークリクエストのライフサイクル内でトラフィックをルーティングする時点を説明します。

レイヤ 4 リソースは、ネットワークトランスポートレベルで動作します。これらのロードバランサーは、使用された TCP ポートや UDP ポートなど、リクエストのトランスポートの特性に基づいてルーティングを決定します。リクエスト固有のデータは考慮されません。

レイヤ 7 ロードバランサは、アプリケーションレイヤに隣接して配置されます。これらのロードバランサーは、リクエスト内の複雑なデータにアクセスし、それを使用してワークロード固有のルーティングルールを通知できます。ここで、HTTP ヘッダーまたは Cookie 内のセッション ID を考慮した負荷分散が行われます。

レイヤ 7 負荷分散は強力ですが、比較的リソースを大量に消費します。バックエンドに渡す前に、各リクエストの内容を解析して検査する必要があります。レイヤ 4 ロードバランサのパケットベースの性質により、制御性は低下しますが、それに応じてスループットへの影響も軽減されます。レイヤ 4 はトラフィックを復号化しないため、この段階でロードバランサが侵害されてもリクエストデータが公開されることはありません。

結論

ロードバランサーを使用すると、サーバー間で受信トラフィックをルーティングできます。これらは、複数のバックエンドインスタンスを透過的に実行できる高可用性ネットワークアーキテクチャの重要なコンポーネントです。これにより、サービス容量が増加し、1 台のサーバーがオフラインになった場合の全体的な停止が回避されます。

ほとんどのロードバランサーの実装では、静的オプションと動的オプションの両方を含む、いくつかの異なるアルゴリズムを選択できます。多くのアプリケーションは、「最小接続」や「ラウンドロビン」などの単純な選択で十分に機能しますが、特定の状況ではより複雑なオプションが役立ちます。

すべての実稼働アプリケーションをロードバランサーの背後で実行することをお勧めします。これにより、オンデマンドで拡張し、異常なサーバーに対応する柔軟性が得られます。負荷分散は通常、ホスティングスタックまたはクラウドプロバイダーのネットワークインフラストラクチャ内で簡単に設定できます。