ロードバランシングとは

前書き

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

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

画像:https://assets.digitalocean.com/articles/HAProxy/web_server.png [web_server]

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

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

画像:https://assets.digitalocean.com/articles/high-availability/Diagram_2.png [図01:ロードバランサー/上から下]

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

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

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

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

  • * HTTPS -HTTPSバランシングは、暗号化が追加されたHTTPバランシングと同じように機能します。 暗号化は、バックエンドまで暗号化を維持する SSLパススルー*またはロードバランサーに復号化の負荷をかけるがバックエンドに暗号化されていないトラフィックを送信する* SSL終了*のいずれかの方法で処理されます。

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

  • * UDP *-最近、一部のロードバランサーは、UDPを使用するDNSやsyslogdなどのコアコアプロトコルのロードバランシングのサポートを追加しました。

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

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

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

ヘルスチェック

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

負荷分散アルゴリズム

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

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

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

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

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

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

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

冗長ロードバランサー

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

image:https://assets.digitalocean.com/articles/high-availability/Diagram_1.png [図02:クラスター/分散]

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

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

画像:https://assets.digitalocean.com/articles/high_availability/ha-diagram-animated.gif [図03:フローティングIP]

結論

この記事では、ロードバランサーの概念の概要と、それらが一般的にどのように機能するかを説明しました。 特定の負荷分散テクノロジーの詳細については、以下をご覧ください。

DigitalOceanの負荷分散サービス