ロードバランシングとは

前書き

負荷分散は、複数のサーバーにワークロードを分散することにより、Webサイト、アプリケーション、データベース、その他のサービスのパフォーマンスと信頼性を向上させるために一般的に使用される高可用性インフラストラクチャの重要なコンポーネントです。

負荷分散のないWebインフラストラクチャは、次のようになります。

web_server

この例では、ユーザーはyourdomain.comでWebサーバーに直接接続します。 この単一のWebサーバーがダウンすると、ユーザーはWebサイトにアクセスできなくなります。 さらに、多くのユーザーが同時にサーバーにアクセスしようとして、負荷を処理できない場合、読み込み時間が遅くなるか、まったく接続できないことがあります。

この単一障害点は、バックエンドにロードバランサーと少なくとも1つの追加Webサーバーを導入することで軽減できます。 通常、すべてのバックエンドサーバーは同一のコンテンツを提供するため、ユーザーはどのサーバーが応答しても一貫したコンテンツを受信できます。

Diagram 01: Load Balancers / Top-to-bottom

上記の例では、ユーザーはロードバランサーにアクセスし、ロードバランサーはユーザーのリクエストをバックエンドサーバーに転送し、バックエンドサーバーはユーザーのリクエストに直接応答します。 このシナリオでは、単一障害点はロードバランサー自体です。 これは、2番目のロードバランサーを導入することで軽減できますが、それについて説明する前に、ロードバランサーの仕組みを見てみましょう。

ロードバランサーはどのようなトラフィックを処理できますか?

ロードバランサーの管理者は、4つの主要な種類のトラフィックの転送ルールを作成します。

  • HTTP —標準のHTTPバランシングは、標準のHTTPメカニズムに基づいてリクエストを送信します。 ロードバランサーは、X-Forwarded-ForX-Forwarded-Proto、およびX-Forwarded-Portヘッダーを設定して、元のリクエストに関する情報をバックエンドに提供します。

  • HTTPS — HTTPSバランシングは、暗号化が追加されていることを除いて、HTTPバランシングと同じように機能します。 暗号化は、2つの方法のいずれかで処理されます。バックエンドまで暗号化を維持するSSL passthroughを使用するか、ロードバランサーに復号化の負担をかけながらトラフィックを暗号化せずにバックエンドに送信するSSL terminationを使用します。 。

  • TCP — HTTPまたはHTTPSを使用しないアプリケーションの場合、TCPトラフィックのバランスを取ることもできます。 たとえば、データベースクラスターへのトラフィックをすべてのサーバーに分散できます。

  • UDP —最近、一部のロードバランサーは、UDPを使用するDNSやsyslogdなどのコアインターネットプロトコルの負荷分散のサポートを追加しました。

これらの転送ルールは、ロードバランサー自体のプロトコルとポートを定義し、ロードバランサーがトラフィックをバックエンドにルーティングするために使用するプロトコルとポートにマップします。

ロードバランサーはどのようにバックエンドサーバーを選択しますか?

ロードバランサーは、2つの要素の組み合わせに基づいて、要求を転送するサーバーを選択します。 最初に、選択できるサーバーが実際に要求に適切に応答していることを確認してから、事前に構成されたルールを使用してその健全なプールの中から選択します。

ヘルスチェック

ロードバランサーは、トラフィックを「正常な」バックエンドサーバーにのみ転送する必要があります。 バックエンドサーバーのヘルスを監視するために、ヘルスチェックは、転送ルールで定義されたプロトコルとポートを使用してバックエンドサーバーへの接続を定期的に試行し、サーバーがリッスンしていることを確認します。 サーバーがヘルスチェックに失敗し、リクエストを処理できない場合、サーバーは自動的にプールから削除され、トラフィックはヘルスチェックに再度応答するまで転送されません。

負荷分散アルゴリズム

使用される負荷分散アルゴリズムにより、バックエンド上の正常なサーバーのどれが選択されるかが決まります。 一般的に使用されるアルゴリズムのいくつかは次のとおりです。

Round Robin —ラウンドロビンは、サーバーが順番に選択されることを意味します。 ロードバランサーは、最初の要求に対してリストの最初のサーバーを選択し、リストの順番を下に移動し、最後に到達したときに先頭からやり直します。

Least Connections —最小接続数は、ロードバランサーが接続数が最も少ないサーバーを選択することを意味し、トラフィックによってセッションが長くなる場合に推奨されます。

Source —ソースアルゴリズムを使用すると、ロードバランサーは、訪問者のIPアドレスなど、リクエストのソースIPのハッシュに基づいて使用するサーバーを選択します。 この方法により、特定のユーザーが常に同じサーバーに接続することが保証されます。

管理者が利用できるアルゴリズムは、使用中の特定の負荷分散技術によって異なります。

ロードバランサーはどのように状態を処理しますか?

一部のアプリケーションでは、ユーザーが同じバックエンドサーバーに接続し続ける必要があります。 ソースアルゴリズムは、クライアントIP情報に基づいてアフィニティを作成します。 Webアプリケーションレベルでこれを実現するもう1つの方法は、sticky sessionsを使用することです。この場合、ロードバランサーはCookieを設定し、そのセッションからのすべての要求は同じ物理サーバーに送信されます。

冗長ロードバランサー

単一障害点としてロードバランサーを削除するには、2番目のロードバランサーを最初のロードバランサーに接続してクラスターを形成し、各クラスターが他のロードバランサーが他の状態を監視できるようにします。 それぞれが等しく障害の検出と回復が可能です。

Diagram 02: Cluster / Distributed

メインロードバランサーに障害が発生した場合、DNSはユーザーを2番目のロードバランサーに移動させる必要があります。 DNSの変更がインターネット上に伝播され、このフェイルオーバーが自動化されるまでにはかなりの時間がかかる可能性があるため、多くの管理者は、floating IPsなどの柔軟なIPアドレスの再マッピングを可能にするシステムを使用します。 オンデマンドIPアドレスの再マッピングは、必要なときに簡単に再マッピングできる静的IPアドレスを提供することにより、DNSの変更に固有の伝播とキャッシュの問題を排除します。 ドメイン名は同じIPアドレスに関連付けられたままにできますが、IPアドレス自体はサーバー間で移動されます。

これは、フローティングIPを使用した高可用性インフラストラクチャの外観です。

Diagram 03: Floating IPs

Related