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

ロード バランサーは、着信ネットワーク トラフィックを複数のバックエンド サーバーに分散するインフラストラクチャ コンポーネントです。スループットが向上し、冗長性が追加され、サーバーの 1 つに障害が発生した場合でもサービスを利用できるようになります。

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

この記事では、ロード バランサーとは何か、どのように機能するか、どのように複雑になる可能性があるかを見ていきます。また、最も一般的な負荷分散アルゴリズムの違いについても説明します。

ロードバランサーは何をしますか

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

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

ロード バランサーは通常、バックエンド サーバー プール内のインスタンスの正常性を監視します。不健全になったサーバー部分は新しいトラフィックの送信を停止するため、サービスの不安定性とダウンタイムが減少します。同様に、通常、ロード バランサーを使用すると、いつでも新しいサーバー インスタンスを追加できるため、ピーク時に余分な電力を使用してサービスをスケーリングできます。

ロード バランサの主な目標は、スループットを最大化し、利用可能なリソースを最も効率的に使用することです。通常、物理サーバー間でスケールアウトする機能は、プロセッサやメモリを追加して単一ノードをスケールアップするよりも効率的です。水平方向のスケーリングにより、容量だけでなく冗長性も向上しますが、負荷分散レベルに関連するオーバーヘッドは通常わずかです。

負荷分散アルゴリズム

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

• スタティックバランス。これらのメソッドは、ハードコーディングされた構成値で動作するため、動作を完全に予測できます。このタイプのアルゴリズムは、転送先の内部サーバーの状態を考慮しないため、すでに過負荷になっているインスタンスに新しいリクエストを送信し続ける可能性があります。
• ダイナミックバランス。動的アルゴリズムは、プール内のトラフィック フローとサーバーの可用性に基づいてリアルタイムで調整されます。これらの戦略により、すでに複数のリクエストを処理しているインスタンスを自動的に回避できます。動的負荷分散では、負荷分散装置が各要求の実行ステータスを追跡する必要があるため、少量のオーバーヘッドが追加される可能性があります。

通常、スタティック バランシング システムは、セットアップ、テスト、検証が簡単です。ダイナミック バランシングははるかに強力であり、通常は実稼働アプリケーションに適しています。これらの各クラス内には、選択できる特定のルーティング戦略がいくつかあります。

• ラウンド ロビンは、要求を各サーバーに順番にルーティングする静的な分散手法です。3 つのサーバー A、B、および C がある場合、最初の着信要求は A に、2 番目は B に、3 番目は C に送信されます。ロード バランサーは、4 番目の要求に対して A から再び開始します。
• 加重ラウンド ロビンは、管理者がプール内の各サーバーの相対的な優先度を決定するラウンド ロビン アルゴリズムの一種です。より高い重みを持つサーバーは、より頻繁に使用され、より高い割合のトラフィックを受信します。この方法では、サーバー プールが異なる特性を持つサーバーで構成されている場合に、ラウンド ロビン方式を使用できます。
• ランダム選択 – 多くのロード バランサーには、代わりの静的選択として真のランダム選択が含まれています。
• ハッシュ – この静的分散戦略では、クライアントの IP アドレスをハッシュして、リクエストを処理するバックエンド サーバーを決定します。これにより、同じインスタンスがそのクライアントから発信されるすべての接続にサービスを提供することが保証されます。
• Least Connections は、開いている接続が最も少ないサーバーに着信要求を常にルーティングする、一般的な動的アルゴリズムです。多くのアプリケーションでは、これが全体的なパフォーマンスを最大化する最も効率的な方法です。
• 利用可能な最大帯域幅 – この方法では、利用可能な帯域幅が最も大きいサーバーに新しいトラフィックが送信されます。これは、リクエストの総数が少ないままであっても、個々のリクエストが帯域幅の大部分を使い果たす可能性がある状況で理想的です。
• カスタマイズ可能なヘルス/負荷エンドポイント。多くのロード バランサーでは、バックエンド サーバーによって提供されるカスタム メトリックに基づいて、トラフィック分散の決定を行うことができます。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 つがダウンした場合の完全な停止を回避できます。

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

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