nginx を HTTP ロードバランサとして使用

ロードバランシングの方法
デフォルトのロードバランシング設定
Least Connected ロードバランシング
セッションの永続化
重み付けされたロードバランシング
ヘルスチェック
参考資料

はじめに

複数のアプリケーションインスタンスにわたるロードバランシングは、リソース利用率の最適化、スループットの最大化、レイテンシの削減、フォールトトレラントな構成の確保のために一般的に使用される手法です。

nginx を非常に効率的な HTTP ロードバランサとして使用し、トラフィックを複数のアプリケーションサーバに分散することで、nginx を使用した Web アプリケーションのパフォーマンス、スケーラビリティ、信頼性を向上させることができます。

ロードバランシングの方法

nginx では、次のロードバランシングメカニズム（または方法）がサポートされています。

デフォルトのロードバランシング設定

nginx を使用したロードバランシングの最も単純な設定は、次のようになります。

http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

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

上記の例では、srv1〜srv3 で実行されている同じアプリケーションのインスタンスが 3 つあります。ロードバランシング方法が具体的に設定されていない場合、デフォルトはラウンドロビンになります。すべてのリクエストはサーバグループ myapp1 にプロキシされ、nginx は HTTP ロードバランシングを適用してリクエストを分散します。

nginx のリバースプロキシ実装には、HTTP、HTTPS、FastCGI、uwsgi、SCGI、memcached、および gRPC のロードバランシングが含まれています。

HTTP の代わりに HTTPS のロードバランシングを設定するには、「https」をプロトコルとして使用します。

FastCGI、uwsgi、SCGI、memcached、または gRPC のロードバランシングを設定する場合は、それぞれfastcgi_pass、uwsgi_pass、scgi_pass、memcached_pass、およびgrpc_pass ディレクティブを使用します。

Least Connected ロードバランシング

もう 1 つのロードバランシング方式は Least Connected です。Least Connected を使用すると、一部のリクエストの完了に時間がかかる状況で、アプリケーションインスタンスへの負荷をより公平に制御できます。

Least Connected ロードバランシングを使用すると、nginx は過剰なリクエストでビジーなアプリケーションサーバを過負荷にしないようにし、代わりにビジーでないサーバに新しいリクエストを分散しようとします。

nginx の Least Connected ロードバランシングは、サーバグループ設定の一部としてleast_conn ディレクティブが使用されている場合に有効になります。

    upstream myapp1 {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

セッションの永続化

ラウンドロビンまたは Least Connected ロードバランシングでは、後続のクライアントのリクエストは、別のサーバに分散される可能性があることに注意してください。同じクライアントが常に同じサーバに転送される保証はありません。

クライアントを特定のアプリケーションサーバにバインドする必要がある場合（つまり、常に特定のサーバを選択しようとするときに、クライアントのセッションを「スティッキー」または「永続的」にする場合）、IP ハッシュロードバランシングメカニズムを使用できます。

IP ハッシュを使用すると、クライアントの IP アドレスがハッシュキーとして使用され、サーバグループ内のどのサーバをクライアントのリクエストに選択するかを決定します。この方法により、そのサーバが使用できない場合を除き、同じクライアントからのリクエストは常に同じサーバに転送されます。

IP ハッシュロードバランシングを設定するには、サーバ（アップストリーム）グループ設定にip_hash ディレクティブを追加します。

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

重み付けされたロードバランシング

サーバの重みを使用することで、nginx ロードバランシングアルゴリズムにさらに影響を与えることも可能です。

上記の例では、サーバの重みは設定されていません。つまり、指定されたすべてのサーバは、特定のロードバランシング方法に対して同等の資格があると見なされます。

特にラウンドロビンでは、リクエストが十分にある場合、およびリクエストが均一に処理され、十分に高速に完了する場合、サーバ間でほぼ均等にリクエストが分散されることを意味します。

weight パラメータがサーバに対して指定されている場合、重みはロードバランシングの決定の一部として考慮されます。

    upstream myapp1 {
        server srv1.example.com weight=3;
        server srv2.example.com;
        server srv3.example.com;
    }

この設定では、新しいリクエスト 5 件ごとに、アプリケーションインスタンスに次のように分散されます。3 件のリクエストは srv1 に、1 件のリクエストは srv2 に、もう 1 件は srv3 に送信されます。

最近のバージョンの nginx では、Least Connected および IP ハッシュロードバランシングでも同様に重みを使用できます。

ヘルスチェック

nginx のリバースプロキシ実装には、インバンド（またはパッシブ）サーバのヘルスチェックが含まれています。特定のサーバからの応答がエラーで失敗した場合、nginx はこのサーバを失敗としてマークし、しばらくの間、後続の着信リクエストでこのサーバを選択しないようにしようとします。

max_fails ディレクティブは、fail_timeout の間に発生する、サーバとの通信を試行する連続した失敗回数を設定します。max_fails はデフォルトで 1 に設定されています。0 に設定されている場合、このサーバのヘルスチェックは無効になります。fail_timeout パラメータは、サーバが失敗としてマークされる期間も定義します。fail_timeout 間隔がサーバの失敗後に経過すると、nginx はライブクライアントのリクエストでサーバを正常にプローブし始めます。プローブが成功すると、サーバはライブとしてマークされます。

参考資料

さらに、nginx のサーバロードバランシングを制御するディレクティブとパラメータが他にもあります。例：proxy_next_upstream、backup、down、およびkeepalive。詳細については、リファレンスドキュメントをご覧ください。

最後に、アプリケーションロードバランシング、アプリケーションヘルスチェック、アクティビティ監視、およびサーバグループのオンザフライ再構成は、有料の NGINX Plus サブスクリプションの一部として利用できます。