ロードバランシングとは何ですか?

導入

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

A web infrastructure with no load balancing might look something like the following:

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

この単一障害点は、負荷分散器とバックエンドの少なくとも1つの追加のウェブサーバーを導入することで軽減できます。通常、すべてのバックエンドサーバーは同一のコンテンツを提供するため、どのサーバーが応答してもユーザーは一貫したコンテンツを受け取ります。

上記の例では、ユーザーが負荷分散器にアクセスし、それがユーザーのリクエストをバックエンドサーバーに転送し、それが直接ユーザーのリクエストに応答するというプロセスが示されています。このシナリオでは、単一障害点は負荷分散器自体になります。これは2番目の負荷分散器を導入することで軽減できますが、その前に負荷分散器がどのように機能するかを探ってみましょう。

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

ロードバランサーの管理者は、次の4つの主要なタイプのトラフィックに対する転送ルールを作成します:

  • HTTP — 標準のHTTPバランシングは、標準のHTTPメカニズムに基づいてリクエストを処理します。ロードバランサーは、バックエンドに元のリクエストに関する情報を提供するために、X-Forwarded-ForX-Forwarded-Proto、およびX-Forwarded-Portヘッダーを設定します。
  • HTTPS — HTTPSバランシングは、HTTPバランシングと同様に機能しますが、暗号化が追加されます。暗号化は、次の2つの方法で処理されます:まず、SSLパススルー、それは暗号化をバックエンドまで維持します。または、SSL終端、それは復号化の負荷をロードバランサーに置きますが、トラフィックは暗号化されてバックエンドに送信されません。
  • TCP — HTTPまたはHTTPSを使用しないアプリケーションのために、TCPトラフィックもバランスできます。たとえば、データベースクラスターへのトラフィックは、すべてのサーバーに分散される可能性があります。
  • UDP — より最近、一部のロードバランサーは、UDPを使用するDNSやsyslogdなどのコアインターネットプロトコルのロードバランシングのサポートを追加しました。

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

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

ロードバランサーは、2つの要因の組み合わせに基づいて、リクエストをどのサーバーに転送するかを選択します。まず、選択できるすべてのサーバーが適切に応答していることを確認し、その健全なプールから選択するための事前に設定されたルールを使用します。

ヘルスチェック

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

ロードバランシングアルゴリズム

使用されているロードバランシングアルゴリズムは、バックエンドの健全なサーバーから選択されるものを決定します。一般的に使用されるアルゴリズムのいくつかは次のとおりです:

ラウンドロビン — ラウンドロビンは、サーバーが順次選択されることを意味します。ロードバランサーは最初のリクエストに対してリスト上の最初のサーバーを選択し、次にリストを順に下に移動し、最後に到達したときには再びトップから始めます。

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

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

管理者が利用できるアルゴリズムは、使用されている特定のロードバランシング技術によって異なります。

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

一部のアプリケーションでは、ユーザーが引き続き同じバックエンドサーバーに接続する必要があります。ソースアルゴリズムは、クライアントのIP情報に基づいてアフィニティを作成します。ウェブアプリケーションレベルでこれを達成する別の方法は、スティッキーセッションを介してです。ロードバランサーがクッキーを設定し、そのセッションからのすべてのリクエストが同じ物理サーバーに向けられます。

冗長なロードバランサー

単一障害点となるロードバランサーを除去するために、2番目のロードバランサーを最初のロードバランサーに接続してクラスターを形成することができます。各ロードバランサーは、他のロードバランサーの健康状態を監視します。各ロードバランサーは障害の検出と回復が同等に可能です。

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

予約済みIPアドレスを使用した高可用性インフラストラクチャーは次のようになります:

結論

この記事では、ロードバランサーの概念と一般的な動作について概説しました。特定のロードバランシング技術について詳しく学びたい場合は、次を参照してください:

DigitalOceanのロードバランシングサービス

HAProxy

Nginx

Source:
https://www.digitalocean.com/community/tutorials/what-is-load-balancing