NGINX Plusの負荷分散方式の選び方

Tony Mauro

Webサイトやアプリの可用性と信頼性を最適化するために、NGINX PlusとNGINX Open Sourceを使用して負荷分散を行う方法について、これまで多くの記事でご紹介してきました。負荷分散は、アプリのパフォーマンス向上、大規模なアプリ配信、およびコンテナとマイクロサービスのデプロイに不可欠なツールです。

これまで、NGINX Plusをデータセンター（従来型のアプリケーションデリバリーコントローラーと併用する場合もあります）、コンテナ、およびAmazon Web Services（AWS）、Google Cloud Platform、Microsoft Azureなどのクラウド環境に導入する方法について説明してきました。

この記事では、NGINX PlusとNGINXの負荷分散手法（負荷分散の「方式」または「アルゴリズム」とも呼ばれます）に焦点を当て、さまざまなユースケースに適した方式を選択するためのポイントをご紹介します。NGINXでは4つの負荷分散手法（ラウンドロビン、ハッシュ、IPハッシュ、最小接続数）を利用でき、NGIN Plusではさらに1つ（最小時間）が追加されます。HTTPトラフィック向けのすべての方式は、IPハッシュを除き、TCPでも利用できます（NGIN Plus Release 9以降ではUDPでも利用できます）。

［編集者注：NGINX Plus R16およびNGINX Open Source 1.15.1では、追加の負荷分散アルゴリズムとしてRandom with Two Choicesが導入されました。詳しくは、F5ブログの「NGINXと「Power of Two Choices」負荷分散アルゴリズム」をご覧ください。］

負荷分散手法の確認

ここでは、ロードバランシングの設定方法の基本を理解していることを前提とします。基本を復習したい場合は、以下のリソースをご覧ください。

• 包括的な概要については、NGINX Plus Admin Guideの記事をご覧ください。
• 高性能なロードバランシングでは、ロードバランシング方式の効率をさらに向上できるNGINX Plusの拡張機能について詳しく説明しています。
• NGINXとNGINX Plusによるロードバランシング、パート1およびパート2では、シンプルなリバースプロキシを、NGINX Plusの拡張機能を活用した包括的なロードバランシングソリューションへと発展させる手順を解説します。
• The ロードバランシングソリューションのページには、eBook、ウェビナー、ホワイトペーパーなど、その他のリソースへのリンクがあります。

説明を簡潔にするため、ここではhttpコンテキストで設定するHTTPロードバランシングに焦点を当てます。TCPロードバランシングは、代わりにstreamコンテキストで設定します（NGINX Plus Release 9以降のUDPロードバランシングも同様です）。HTTPロードバランサーとTCP/UDPロードバランサーの機能は同等ですが、プロトコル固有の違いにより、使用できるディレクティブとパラメーターは多少異なります。詳細については、HTTPおよびTCP/UDPのUpstreamモジュールに関するドキュメントを参照してください。

ロードバランシングは2つの設定ブロックで有効にします。ここでは、オプションのパラメーターや補助機能を含まない基本形式を示します。

• The serverブロックでは、指定した特性を持つトラフィックをリッスンし、名前付きのアップストリームサーバーグループにプロキシする仮想サーバーを定義します。ここで示す例では、仮想サーバーはデフォルトポート（80）でwww.example.com宛てのHTTPトラフィックをリッスンし、backendというアップストリームサーバーグループにプロキシします。このブロックは、すべての例で共通です。

server {    server_name www.example.com;

    location / {
       proxy_pass http://backend;
    }
}

• （NGINX PlusおよびNGINXでは、FastCGI、memcached、SCGI、uwsgiバックエンドサーバーの負荷分散も可能です。proxy_passを、適切なディレクティブ（fastcgi_pass、memcached_pass、scgi_pass、またはuwsgi_pass）に置き換えてください。）
• The upstreamブロックでは、アップストリームグループに名前を付け、そのグループに属するサーバーをホスト名、IPアドレス、またはUNIXドメインソケットのパスで指定して一覧にします。この例では、backendというアップストリームグループに、web1、web2、web3の3台のサーバーが含まれています。upstreamブロックでは負荷分散方式を指定します。以降のセクションでは、この点を重点的に説明します。例として、デフォルト方式であるラウンドロビンのブロックを次に示します。

upstream backend {    server web1;
    server web2;
    server web3;
}

ラウンドロビン

Round Robinは、NGINX PlusとNGINXの両方でデフォルトの負荷分散方式です。ロードバランサーはアップストリームサーバーのリストを順番に処理し、次の接続リクエストを各サーバーに順番に割り当てます。

以下のbackendアップストリームグループのサンプル構成では、ロードバランサーは最初の3つの接続リクエストを順にweb1、web2、web3へ送信し、4つ目をweb1へ、5つ目をweb2へ送信します。以降も同様です。

upstream backend {    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

    location / {
       proxy_pass http://backend;
    }
}

ハッシュ

Hash方式では、リクエストごとに、指定したテキストとNGINX変数の組み合わせに基づいてロードバランサーがハッシュを計算し、いずれかのサーバーに関連付けます。同じハッシュを持つすべてのリクエストがそのサーバーに送信されるため、この方式では基本的なセッション パーシステンスが確立されます。

次の例では、hashディレクティブは、リクエストのスキーム（httpまたはhttps）と完全なURIをハッシュの基準として使用します。

upstream backend {    hash $scheme$request_uri;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

    location / {
       proxy_pass http://backend;
    }
}

IPハッシュ

IP Hash（HTTPでのみ使用可能）は、クライアントのIPアドレスに基づいてハッシュを生成する、Hashメソッドの定義済みバリエーションです。設定にはip_hashディレクティブを使用します。

upstream backend {    ip_hash;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

    location / {
       proxy_pass http://backend;
    }
}

クライアントがIPv6アドレスを使用している場合、アドレス全体に基づいてハッシュが生成されます。IPv4アドレスを使用している場合は、アドレスの先頭3オクテットのみに基づいてハッシュが生成されます。これは、サブネットワーク（/24）の範囲からIPアドレスが動的に割り当てられるISPクライアント向けに最適化することを目的としています。再起動や再接続が発生すると、クライアントのアドレスが同じ/24ネットワーク範囲内の別のアドレスに変わることがよくありますが、接続元は同じクライアントであるため、サーバーへのマッピングを変更する必要はありません。

ただし、サイトへのトラフィックの大半が同じ/24ネットワーク上のクライアントから送信される場合、IP Hashではすべてのクライアントが同じサーバーにマッピングされるため、適していません。その場合（または、別の理由ですべての4オクテットを使用してハッシュを生成する場合）は、代わりに$remote_addr変数を指定したHashメソッドを使用します。

hash $remote_addr;

最小接続数

Least Connections方式では、ロードバランサーが各サーバーへの現在のアクティブ接続数を比較し、接続数が最も少ないサーバーにリクエストを送信します。この方式は、least_connディレクティブで設定します。

upstream backend {
    least_conn;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

    location / {
       proxy_pass http://backend;
    }
}

最短時間

Least Time方式（NGINX Plusでのみ利用可能）では、ロードバランサーが各サーバーについて、現在のアクティブ接続数と過去のリクエストに対する加重平均応答時間という2つの指標を数理的に組み合わせ、値が最も低いサーバーにリクエストを送信します。

Your choice of parameter on the least_timeディレクティブで選択するパラメーターにより、追跡する応答時間が決まります。応答ヘッダーを受信するまでの時間（header）または完全な応答を受信するまでの時間（last_byte）のいずれかです。

upstream backend {    least_time (header | last_byte);

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

    location / {
       proxy_pass http://backend;
    }
}

注記：

• TCPおよびUDPのロードバランシング（stream コンテキスト）では、least_timeディレクティブに次のパラメーターを指定して、3種類の応答時間から選択できます。
  • connect – アップストリームサーバーへの接続にかかる時間
  • first_byte – レスポンスデータの最初のバイトを受信するまでの時間
  • last_byte – レスポンスデータの最後のバイトを受信するまでの時間
• HTTPトラフィックとTCP/UDPトラフィックのいずれについても、NGINX Plus R12以降では、各メトリクスに未完了の接続を含めるためにinflightパラメーターを追加します。以前のリリースでは、このような接続がデフォルトで含まれます。

負荷分散方式の選択

では、Webサイトやアプリに最適な負荷分散手法は、どのように判断すればよいのでしょうか。

トラフィックパターンはサイトごとに大きく異なり、同じサイトでも時間帯によって変化します。そのため、負荷分散手法を、バースト性の高いトラフィックか安定したトラフィックか、短時間接続か長時間接続かといった単一の特性だけに基づいて選ぶことは適切ではありません。ここでは、検討すべき選択肢を絞り込めるよう、各手法の長所と短所を見ていきます。

手法を比較するためのテストの実施

どのロードバランシング方式を候補とする場合でも、実際にテストし、トラフィックに最適な方式を確認することを推奨します。通常、「最適」とはクライアントへの応答時間が最も短いことを意味しますが、別の基準を採用する場合もあります。

アプリケーションパフォーマンス管理ツールは、この種のテストに非常に便利です。アップストリームグループ内の各サーバーのグラフを表示するカスタム画面を作成できるため、テスト中に値が変化する様子をリアルタイムで比較できます。NGINX PlusおよびNGINX向けのカスタムプラグインを提供しているAPMには、AppDynamics、Datadog、Dynatrace、New Relicなどがあります。

すべてのサーバーの処理能力が同じであれば、テストは最も簡単です。異なる場合は、処理能力の高いマシンがより多くのリクエストを受信するように、サーバーの重みを設定する必要があります。以下の「サーバーの性能が同一でない場合の重みの設定」を参照してください。

テスト中に確認する主なメトリクスは次のとおりです。

• CPUとメモリの負荷 – CPUとメモリの両方について、総容量に対する使用率を確認します。すべてのサーバーに負荷が均等にかかっていない場合、トラフィックは効率的に分散されていません。
• サーバーの応答時間 – 一部のサーバーの応答時間が他のサーバーよりも常に長い場合、より多くの計算処理やデータベースなどのサービスへの呼び出しを必要とする「負荷の高い」リクエストが、それらのサーバーに偏って振り分けられている可能性があります。負荷分散手法の問題ではなく、重みの設定が不適切なために偏りが生じている可能性があるため、重みを調整してみてください。
• クライアントへの応答にかかる合計時間 – 同様に、一部のサーバーで一貫して時間が長い場合、処理に時間のかかるリクエストがそれらのサーバーに偏って振り分けられている可能性があります。この場合も、重みを調整して問題が解消されるかどうかを確認できます。
• エラーと失敗したリクエスト – テスト中に発生した失敗したリクエストやその他のエラーの数が、サイトで通常発生する数を超えていないことを確認する必要があります。そうしないと、実際のトラフィックではなく、エラーが発生している状況に基づいて判断することになります。エラーの種類によっては、リクエストが成功した場合よりもサーバーが迅速に応答できることがあります。たとえば、HTTPレスポンスコード404（File Not Found）の場合、実際のファイルが存在して配信する場合よりも、サーバーがはるかに迅速にエラーを返す可能性があります。Least ConnectionsおよびLeast Timeロードバランシングアルゴリズムでは、このため、ロードバランサーが実際には正常に動作していないサーバーを優先することがあります。

メリット、デメリット、ユースケース

それでは、各負荷分散手法のメリットとデメリットを確認し、それぞれが特に適しているユースケースを紹介します。多くのユースケースへの適合性が高い順に説明します。先に結論を述べると、最も幅広いユースケースに適しているのはLeast Connections（NGINX PlusではLeast Timeも含む）だと考えています。

ハッシュとIPハッシュ

HashおよびIP Hashの負荷分散手法では、特定の種類のクライアントリクエスト（ハッシュ値として取得）と特定のサーバーとの間に固定の関連付けを作成します。これはセッション永続化とも呼ばれ、同じハッシュ値を持つすべてのリクエストは常に同じサーバーに送信されます。

これらの方式の最大の欠点は、各サーバーに同数のリクエストが分散される保証がなく、ましてや負荷が均等に分散される保証もないことです。ハッシュアルゴリズムは、取り得るすべてのハッシュ値を、アップストリームグループ内の各サーバーに対応する「バケット」に均等に分割します。しかし、実際に発生するリクエストのハッシュ値が均等に分散するかどうかは予測できません。たとえば、10台のクライアントがサイトにアクセスしており、IP Hashアルゴリズムによって、7つのIPアドレスのハッシュが「web1」に、1つが「web2」に、2つが「web3」に割り当てられたとします。その場合、「web1」サーバーが受信するリクエスト数は、ほかのサーバーが受信するリクエスト数の合計の2倍を超えます。

したがって、セッションを維持するメリットが、負荷の不均衡によって生じ得る悪影響を上回る場合は、HashまたはIP Hashを使用するのが妥当です。これらは、NGINXで利用できる唯一のセッション永続化方式です。NGINX Plusでは、より高度で、実際の負荷分散と組み合わせて機能する、ほかの3つのセッション永続化メカニズムも利用できます（stickyディレクティブで設定します）。ただし、次の場合にはこれら3つのメカニズムが機能しないため、NGINX PlusでもHashまたはIP Hashを選択することがあります。

• ブラウザーまたはクライアントアプリがCookieを受け入れず、アプリケーションにもCookieを使用せずにセッション永続化メカニズムを機能させる方法がない場合。IP Hash方式を使用して、各クライアント（具体的にはそのIPアドレス）を特定のサーバーに関連付けます。
• サーバー自体のキャッシュを活用するため、特定のURLへのリクエストを常に同じサーバーへ送信する場合は、Hash方式で$request_uri変数を使用し、常に同じサーバーからファイルを取得します。たとえば、ある.phpファイルの配信には時間のかかるデータベース呼び出しが複数必要である一方、取得するデータは頻繁には変更されず、キャッシュ可能であるとします。このファイルへのすべてのリクエストを同じサーバーに送信すると、データベース呼び出しによる長い遅延が発生するのは最初のクライアントだけです。それ以降のクライアントでは、キャッシュからデータをすばやく取得できます。また、その特定のデータセットをキャッシュする必要があるのは1台のサーバーだけです。すべてのサーバーで同じデータを重複してキャッシュする必要がないため、キャッシュ容量を小さくできます。

IP Hash、およびクライアントIPアドレスをキーに含めるHashが機能しないケースが2つあります。

• セッション中にクライアントのIPアドレスが変わる可能性がある場合。たとえば、モバイルクライアントがWiFiネットワークからモバイルネットワークに切り替わる場合です。
• 多数のクライアントからのリクエストがフォワードプロキシを経由し、すべてのリクエストにプロキシのIPアドレスが使用される場合。

ハッシュは決定論的です（ハッシュアルゴリズムは毎回同じ結果を生成します）。これには、いくつかの好ましい副次的効果があります。デプロイ内のすべてのNGINX PlusまたはNGINXインスタンスがまったく同じ方法でリクエストを負荷分散し、ロードバランサーを再起動してもハッシュとサーバーのマッピングが維持されます。（実際には再起動後に再計算されますが、結果は常に同じになるため、実質的に維持されます。）

一方、アップストリームサーバーの構成を変更すると、通常は少なくとも一部のマッピングが再計算され、セッションの永続性が失われます。再計算されるマッピングの数は、ある程度減らすことができます。

• Hash方式では、consistentパラメーターをhashディレクティブに指定します。NGINX Plusはketamaハッシュアルゴリズムを使用するため、再マッピングが少なくなります。
• IP Hash方式でサーバーをアップストリームグループから一時的に削除する場合は、削除する前に、次の例のdownパラメーターをそのserverディレクティブに追加します。web2がその例です。サーバーがまもなくサービスに復帰することを前提として、マッピングは再計算されません。

upstream backend {    ip_hash;

    server web1;
    server web2 down;
    server web3;
}

ラウンドロビン

前述のとおり、ラウンドロビンはNGINX PlusおよびNGINXのデフォルトの負荷分散方式です。そのため、最も簡単に選択できる方式であり、アップストリームグループ自体以外に設定する必要はありません。

一般に、サーバーとリクエストの特性上、一部のサーバーに他のサーバーよりも負荷が集中する可能性が低い場合に、Round Robinが最も効果的に機能すると考えられています。その条件には、次のようなものがあります。

• すべてのサーバーの処理能力がほぼ同じであること。サーバー間の差異がサーバーの重みに正確に反映されている場合、この要件の重要性は低くなります。
• すべてのサーバーが同じコンテンツをホストしている。
• 各リクエストに必要な時間や処理能力は、ほぼ同程度です。リクエストの負荷に大きなばらつきがあると、ロードバランサーが負荷の高いリクエストを偶然立て続けに同じサーバーへ送信し、そのサーバーが過負荷になる可能性があります。
• トラフィック量がそれほど多くなく、サーバーが最大容量近くに達することがほとんどない場合。サーバーにすでに高い負荷がかかっていると、ラウンドロビンによる機械的なリクエスト分散によって、前の項目で説明したように、一部のサーバーが限界を超えて過負荷に陥る可能性が高くなります。

Round Robinは、すべてのサーバーに同数（または適切に重み付けされた比率）のリクエストを確実に分散するため、テストシナリオに特に適しています。他の一部の方式では、トラフィック量が少ない場合にトラフィックが常に均等に分散されるとは限らず、テスト結果に偏りが生じる可能性があります。

均等に分散されるため、キャッシュが正常かつ最大容量で動作しているかどうかも確認できます。Round Robinでは、特定のファイルに対するリクエストを同じサーバーに送信することができないため、各サーバーが幅広いファイルを配信してキャッシュすることになりやすく（通常は他のサーバーと同じファイルも多数含まれます）、キャッシュがいっぱいになる可能性が高まります。

最後に、初期分散が均等であるため、NGINX Plusのセッション永続化（stickyディレクティブで設定）に関する問題を特定しやすくなります。

最小接続数と最小時間

前述のとおり、Least Connectionsは幅広いユースケース、特に本番トラフィックに最適な負荷分散手法です。これは、お客さまから寄せられた事例からも裏付けられています。安定した予測可能なパフォーマンスを実現します。

Least Connectionsは、各サーバーの処理能力に応じてワークロードを効果的に分散します。高性能なサーバーほどリクエストを迅速に処理するため、処理中（または処理開始待ち）の接続数は、どの時点でも処理能力の低いサーバーより少ない傾向があります。Least Connectionsは、現在の接続数が最も少ないサーバーに各リクエストを送信するため、高性能なサーバーにリクエストが送信される可能性が高くなります。（ただし、以下の「サーバーの性能が同一でない場合の重みの設定」で説明するように、重みを設定すると、リクエストをさらに効率よく分散できます。）

Least Time（NGINX Plusのみ）は、Least Connectionsをより高感度にした方式と考えることができます。平均応答時間を含めることで、サーバーの直近のパフォーマンス履歴が考慮されます（実際には指数加重移動平均が使用されるため、古い応答時間が平均値に与える影響は、最近の応答時間よりも小さくなります）。

Least Timeは、アップストリームサーバー間で平均応答時間が大きく異なる場合に特に適しています。たとえば、災害復旧を目的として異なるデータセンターにサーバーを配置している場合、ローカルサーバーの方が応答が速いため、Least Timeではローカルサーバーにより多くのリクエストが送信される傾向があります。サーバーのパフォーマンスが予測しにくいことの多いクラウド環境も、ユースケースの1つです。

サーバーの性能が異なる場合の重みの設定

アップストリームグループ内のサーバーごとに処理能力が異なる場合は、サーバーの重みを設定することが重要です。これまでにも何度か説明してきました。特にラウンドロビン方式のロードバランサーでは、重みを設定しないと各サーバーに同数のリクエストが送信されます。その結果、処理能力の低いサーバーに過剰な負荷がかかる一方で、処理能力の高いサーバーのリソースが十分に活用されない可能性があります。

重みを設定するには、weightパラメーターを、upstreamブロック内の1つ以上のserverディレクティブに指定します。デフォルト値は1です。

各種の負荷分散方式で重みを設定した場合の効果は、次のように考えることができます。以下の説明は概念的には正しいものの、NGINX Plusのコード実装で、示されている数学的演算が必ずしも使用されているわけではない点にご留意ください。例で使用するアップストリームグループは次のとおりです。

upstream backend {    server web1 weight=6;
    server web2 weight=3;
    server web3;
}

• ラウンドロビン：各サーバーには、その重みを重みの合計で割った割合に応じて、受信リクエストが振り分けられます。この例では、10件のリクエストごとに、web1には6件（60%）、web2には3件（30%）、web3には1件（10%）が振り分けられます。
• ハッシュとIPハッシュ – 重みを設定しない場合、ハッシュアルゴリズムは、取り得るすべてのハッシュ値をアップストリームグループ内の各サーバーに対応する「バケット」に均等に分割します。重みを設定した場合は、重みの合計数と同じ数のバケットに取り得るハッシュ値を分割し、各サーバーをその重みに相当する数のバケットに関連付けます。この例では、10個のバケットがあり、それぞれに取り得るハッシュ値の10%が含まれます。6個のバケット（取り得るハッシュ値の60%）がweb1に、3個のバケット（30%）がweb2に、1個のバケット（10%）がweb3に関連付けられます。
• 最小接続数と最小時間 — 前述のとおり、これらのアルゴリズムは重みを設定しなくても、各サーバーの処理能力に応じてワークロードを分散するうえで非常に効果的です。重みを設定すると、この点でのパフォーマンスがさらに向上します。最小接続数と最小時間では、各リクエストが「スコア」の最も低いサーバーに送信されます。スコアは、それぞれ接続数、または接続数と時間を数式で組み合わせた値です。重みを割り当てると、ロードバランサーは各サーバーのスコアをその重みで除算し、最も低い値のサーバーにリクエストを送信します。以下は、サンプルの重みと指定されたアクティブ接続数を使用した最小接続数の例です。web1のスコア100が最も低いため、接続数600がweb2の1.5倍、web3の4倍を超えていても、リクエストはweb1に送信されます。
  • web1 – 600件のアクティブな接続 ÷ 6 = 100
  • web2 – 400アクティブ接続÷3 = 133
  • web3 – 125件のアクティブな接続 ÷ 1 = 125

まとめ

NGINX PlusとNGINXで利用できる負荷分散手法の長所と短所を検討した結果、最も幅広いユースケースに適しているのはLeast Connections（NGINX PlusではLeast Timeも含む）であると考えられます。ただし、トラフィックとサーバーの特性の組み合わせは導入環境ごとに異なり、別の手法の方が適している場合もあるため、複数の手法をテストすることが重要です。

NGINX Plusのロードバランシングを実際にお試しいただくには、今すぐ30日間の無料トライアルを開始するか、お問い合わせのうえ、ユースケースについてご相談ください。

さまざまなユースケースでロードバランシングを活用したご経験を、ぜひお聞かせください。下のコメント欄にご投稿ください。

著者について

Tony Mauro

Tony Mauroのその他のブログ記事