NGINXとNGINX Plusによる負荷分散：第1回

Owen Garrettプロダクトマネジメント担当シニアディレクター

NGINXは、幅広いHTTPベースのアプリケーションに対応する高性能な高速化プロキシです。キャッシュ、HTTP接続処理、オフロードにより、特に高負荷時のアプリケーションパフォーマンスが大幅に向上します。

編集者注：NGINX Plus Release 5以降では、TCPベースのアプリケーションの負荷分散も可能です。Release 6では、ヘルスチェック、動的再構成、SSL終端などが追加され、TCP負荷分散機能が大幅に拡張されました。NGINX Plus Release 7<.htmla>以降では、TCPロードバランサーはHTTPロードバランサーと同等の機能をすべて備えています。UDP負荷分散のサポートはRelease 9で導入されました。

TCPおよびUDPのロードバランシングは、 streamコンテキストで設定します。httpコンテキストではありません。HTTPとTCP/UDPには本質的な違いがあるため、使用できるディレクティブとパラメーターも多少異なります。詳細については、HTTPおよびTCP Upstreamモジュールのドキュメントを参照してください。

NGINX Plusは、NGINXに次の高度な負荷分散機能を追加して、その機能を拡張します：ヘルスチェック、セッション永続化、リアルタイムのアクティビティ監視、および負荷分散サーバーグループの動的構成。

このブログ記事では、一連のWebサーバーへのトラフィックを負荷分散するためのNGINXの設定手順を説明します。また、NGINX Plusの追加機能の一部も紹介します。

さらに詳しく知りたい場合は、NGINX Plus管理ガイドと、この記事の続編である「NGINXおよびNGINX Plusによるロードバランシング：パート2」もご覧ください。

NGINXによるトラフィックのプロキシ

まず、2台のアップストリームWebサーバーにトラフィックをプロキシします。次のNGINX設定により、ポート80へのすべてのHTTPリクエストを終端し、アップストリームグループ内のWebサーバーへラウンドロビン方式で転送できます。

http {    server {
        listen 80;

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

    upstream backend {
        server web-server1:80;
        server web-server2:80;
    }
}

このシンプルな設定により、NGINXはポート80で受信した各リクエストをweb-server1とweb-server2に順番に転送し、その都度新しいHTTP接続を確立します。

負荷分散方式の設定

デフォルトでは、NGINXはラウンドロビン方式を使用し、各サーバーの相対的な処理能力を示すために任意で割り当てられる「weight」を考慮して、サーバー間にトラフィックを均等に分散します。

The IP Hash方式では、送信元IPアドレスのハッシュに基づいてトラフィックを分散します。同じクライアントIPアドレスからのリクエストは、常に同じアップストリームサーバーに送信されます。これは簡易的なセッション永続化方式であり、サーバーで障害が発生した場合やサーバーが復旧した場合、またはアップストリームグループが変更された場合に再計算されます。セッション永続化が必要な場合は、NGINX Plusでより優れたソリューションを利用できます。

The Least Connections方式では、各リクエストがアクティブな接続数が最も少ないアップストリームサーバーにルーティングされます。この方式は、短時間で処理できるリクエストと複雑なリクエストが混在する場合に適しています。

すべての負荷分散方式は、weightディレクティブのオプションパラメーターとしてserverを指定することで調整できます。これは、サーバーごとに処理能力が異なる場合に有効です。次の例では、NGINXはweb-server1の4倍のリクエストをweb-server2に振り分けます。

upstream backend {    zone backend 64k;
    least_conn;

    server web-server1 weight=1;
    server web-server2 weight=4;
}

NGINXでは、重みは各ワーカープロセスによって個別に管理されます。NGINX Plusでは、アップストリームデータに共有メモリセグメント（zoneディレクティブで設定）を使用するため、ワーカー間で重みが共有され、トラフィックがより正確に分散されます。

障害検出

NGINXがサーバーへの接続、リクエストの転送、またはレスポンスヘッダーの読み取りを試みた際にエラーまたはタイムアウトが発生すると、別のサーバーへの接続を再試行します。（リクエストを再試行するその他の条件を定義するには、設定にproxy_next_upstreamディレクティブを含めることができます。）また、NGINXは障害が発生したサーバーを接続先候補から除外し、復旧を検出するために、そのサーバーへのリクエストを定期的に試行できます。max_failsパラメーターとfail_timeoutパラメーターをserverディレクティブに指定することで、この動作を制御できます。

NGINX Plusには、各アップストリームサーバーに対して高度なHTTPテストを実行し、稼働中かどうかを判定する一連のアウトオブバンドヘルスチェックと、復旧したサーバーを負荷分散グループに段階的に再導入するスロースタートメカニズムが追加されています。

server web-server1 slow_start=30s;

よくある「落とし穴」— Hostヘッダーの修正

多くの場合、アップストリームサーバーは、リクエスト内の「Host」ヘッダーを使用して、配信するコンテンツを決定します。サーバーから予期しない「404」エラーが返された場合や、誤ったコンテンツが配信されている可能性を示す事象が発生した場合は、まずこの点を確認してください。そのうえで、ヘッダーに適切な値を設定するため、構成に「proxy_set_header」ディレクティブを追加します。

location / {
    proxy_pass http://backend;

    # Rewrite the 'Host' header to the value in the client request
    # or primary server name
    proxy_set_header Host $host;

    # Alternatively, put the value in the config:
    #proxy_set_header Host www.example.com;
}

NGINX Plusを使用した高度なロードバランシング

NGINX Plusは、さまざまな高度な機能を備えているため、アップストリームサーバー群の前段に配置するロードバランサーとして最適です。

• 負荷分散とセッション維持 – ワーカープロセス間の負荷分散を改善し、アプリケーションセッションを識別して維持するセッション維持方式
• HTTPヘルスチェックとサーバーのスロースタート – 非同期の「合成トランザクション」により各アップストリームサーバーが正常に動作しているかを確認し、サーバーの復旧時には「スロースタート」で段階的に再導入
• リアルタイムのアクティビティ監視 – アクティビティとパフォーマンスを即時にレポート
• 動的に構成されるアップストリームサーバーグループ – サーバーを安全かつ一時的に除外するなど、一般的なアップストリーム管理タスクを容易にするツール

高度なロードバランシングとプロキシの詳細については、この記事の続編である「NGINXおよびNGINX Plusによるロードバランシング：パート2」をご覧ください。

NGINX Plusをお試しいただくには、今すぐ30日間の無料トライアルを開始するか、負荷分散のユースケースについてお問い合わせください。

著者について

Owen Garrettプロダクトマネジメント担当シニアディレクター

Owen Garrettのその他のブログ記事