NGINX と NGINX Plus による負荷分散、パート 1

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

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

TCP および UDP の負荷分散は、 httpコンテキストではなくストリームコンテキストで構成します。 使用可能なディレクティブとパラメータは、HTTP と TCP/UDP の本質的な違いにより多少異なります。詳細については、 HTTPおよびTCP Upstream モジュールのドキュメントを参照してください。

NGINX Plus は、ヘルスチェック、セッション永続性、ライブ アクティビティ監視、負荷分散サーバー グループの動的構成などのさらなる負荷分散機能を追加することで、NGINX の機能を拡張します。

このブログ記事では、一連の Web サーバーにトラフィックを負荷分散するように NGINX を構成する手順について説明します。 NGINX Plus の追加機能の一部を紹介します。

さらに詳しく知りたい場合は、『 NGINX Plus 管理者ガイド』と、この記事の続編である『NGINX と NGINX Plus を使用した負荷分散、パート 2』もご覧ください。

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

まず、トラフィックを上流の Web サーバーのペアにプロキシします。 次の NGINX 構成は、ポート 80 へのすべての HTTP リクエストを終了し、アップストリーム グループ内の Web サーバー間でラウンドロビン方式で転送するのに十分です。

http { server {
listen 80;

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

アップストリーム バックエンド {
server web-server1:80;
server web-server2:80;
}
}

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

負荷分散方法の設定

デフォルトでは、NGINX はラウンドロビン方式を使用して、各サーバーの相対的な容量を示すために各サーバーに割り当てられたオプションの「重み」に基づいて、サーバー間でトラフィックを均等に分散します。

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

最小接続方式では、各リクエストがアクティブな接続が最も少ないアップストリーム サーバーにルーティングされます。 この方法は、簡単なリクエストと複雑なリクエストが混在する場合に適しています。

すべての負荷分散方法は、サーバーディレクティブのオプションのweightパラメータを使用して調整できます。 これは、サーバーの処理能力が異なる場合に意味を持ちます。 次の例では、NGINX はweb-server1よりも 4 倍多くのリクエストをweb-server2に送信します。

アップストリームバックエンド { ゾーンバックエンド 64k; least_conn; サーバー web-server1 重み = 1; サーバー web-server2重み = 4 ; }

NGINX では、重みは各ワーカー プロセスによって独立して管理されます。 NGINX Plus は、アップストリーム データに共有メモリ セグメント (ゾーンディレクティブで構成) を使用するため、重みはワーカー間で共有され、トラフィックがより正確に分散されます。

障害検出

NGINX がサーバーに接続しようとしたり、サーバーにリクエストを渡したり、レスポンス ヘッダーを読み取ろうとしたりするときにエラーまたはタイムアウトが発生した場合、NGINX は別のサーバーとの接続リクエストを再試行します。 (リクエストを再試行するための他の条件を定義するには、構成にproxy_next_upstreamディレクティブを含めることができます。) さらに、NGINX は障害が発生したサーバーを潜在的なサーバーのセットから取り出し、そのサーバーに対してリクエストを定期的に試行して、サーバーが回復したかどうかを検出することができます。 サーバーディレクティブのmax_failsおよびfail_timeoutパラメータがこの動作を制御します。

NGINX Plus には、各アップストリーム サーバーがアクティブかどうかを判断するための高度な HTTP テストを実行する帯域外ヘルス チェックのセットと、回復したサーバーを負荷分散グループに徐々に再導入するスロー スタートメカニズムが追加されています。

サーバー web-server1 slow_start=30s;

よくある「落とし穴」 –ホストヘッダーの修正

一般的に、アップストリーム サーバーはリクエスト内のHostヘッダーを使用して、提供するコンテンツを決定します。 予期せぬ事態に陥った場合404サーバーからのエラー、または間違ったコンテンツを提供していることを示唆するその他の何かがない場合は、これを最初に確認する必要があります。 次に、構成にproxy_set_headerディレクティブを含めて、ヘッダーに適切な値を設定します。

location / { proxy_pass http://backend; # 'Host' ヘッダーをクライアント リクエストの値またはプライマリ サーバー名に書き換えますproxy_set_header Host $host ; # または、設定に値を入力します: #proxy_set_header Host www.example.com; }

NGINX Plus を使用した高度な負荷分散

NGINX Plus のさまざまな高度な機能により、アップストリーム サーバーのファームの前にある理想的なロード バランサーになります。

• 負荷分散とセッション永続性– ワーカープロセス間の負荷分散とセッション永続性メソッドを改善し、アプリケーションセッションを識別して尊重します。
• HTTP ヘルスチェックとサーバーのスロースタート- 各上流サーバーの正しい動作を調査するための非同期の「合成トランザクション」と、回復時のサーバーの正常な「スロースタート」再導入
• ライブアクティビティモニタリング– アクティビティとパフォーマンスの即時レポート
• 動的に構成されたアップストリームサーバーグループ– サーバーの安全かつ一時的な削除など、一般的なアップストリーム管理タスクを容易にするツール

高度な負荷分散とプロキシの詳細については、この投稿の続編である「NGINX と NGINX Plus を使用した負荷分散、パート 2」を参照してください。

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