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

NGINX と NGINX Plus を使用した負荷分散、パート 1では、複数の Web サーバー間でトラフィックを負荷分散するためのシンプルな HTTP プロキシを設定しました。 この記事では、 NGINX Plusで利用できる追加機能（キープアライブによるパフォーマンス最適化、ヘルスチェック、セッション永続性、リダイレクト、コンテンツ書き換え）について説明します。

NGINX および NGINX Plus の負荷分散機能の詳細については、 NGINX Plus 管理者ガイドを参照してください。

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

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

簡単なレビュー

確認すると、これは前回の記事で構築した構成です。

server { listen 80;

location / {
proxy_pass http://backend;

# 'Host' ヘッダーをクライアント リクエストの値、またはプライマリ サーバー名に書き換えます
    # proxy_set_header Host $host;

# または、値を構成に入力します:
# proxy_set_header Host www.example.com;
} 
}

upstream backend {
zone backend 64k; # NGINX Plus の共有メモリを使用します
least_conn;

server webserver1 weight=1;
server webserver2 weight=4;
}

この記事では、負荷分散の有効性を向上させる NGINX と NGINX Plus を構成するための簡単な方法をいくつか紹介します。

HTTP キープアライブ

NGINX または NGINX Plus とアップストリーム サーバー間の HTTP キープアライブを有効にすると、パフォーマンスが向上し (レイテンシが短縮されるため)、NGINX の一時ポートが不足する可能性が低くなります。

HTTP プロトコルは、基盤となる TCP 接続を使用して HTTP 要求を送信し、HTTP 応答を受信します。 HTTP キープアライブ接続により、これらの TCP 接続を再利用できるため、リクエストごとに接続を作成および破棄するオーバーヘッドを回避できます。

NGINX は完全なプロキシであり、クライアントからの接続 (フロントエンド キープアライブ接続) とサーバーへの接続 (アップストリーム キープアライブ接続) を個別に管理します。

NGINX は、キープアライブ接続の「キャッシュ」（上流サーバーへのアイドル状態のキープアライブ接続のセット）を維持し、上流にリクエストを転送する必要がある場合は、新しい TCP 接続を作成するのではなく、キャッシュから既に確立されているキープアライブ接続を使用します。 これにより、NGINX とアップストリーム サーバー間のトランザクションの待ち時間が短縮され、一時ポートの使用率が下がるため、NGINX は大量のトラフィックを吸収して負荷分散できるようになります。 トラフィックが急増すると、キャッシュが空になる可能性があり、その場合、NGINX はアップストリーム サーバーへの新しい HTTP 接続を確立します。

他の負荷分散ツールでは、この手法は多重化、接続プール、接続再利用、またはOneConnectと呼ばれることもあります。

キープアライブ接続キャッシュを構成するには、構成にproxy_http_version 、 proxy_set_header 、およびkeepaliveディレクティブを含めます。

server { listen 80; location / { proxy_pass http://backend; proxy_http_version 1.1 ; proxy_set_header Connection "" ; } } アップストリーム バックエンド { server webserver1; server webserver2; # アップストリーム サーバーのグループへの最大 20 個のアイドル接続を維持しますkeepalive 20 ; }

健康診断

ヘルスチェックを有効にすると、負荷分散されたサービスの信頼性が向上し、エンドユーザーがエラー メッセージを見る可能性が低くなり、一般的なメンテナンス操作も容易になります。

NGINX Plus のヘルス チェック機能を使用すると、アップストリーム サーバーの障害を検出できます。 NGINX Plus は「合成トランザクション」を使用して各サーバーをプローブし、 health_checkディレクティブで設定したパラメータ ( matchパラメータを含める場合は、関連するmatch設定ブロック) と照らし合わせて応答をチェックします。

server { listen 80; location / { proxy_pass http://backend; health_check interval=2s fails=1 passing=5 uri=/test.php match=statusok ; # ヘルスチェックは他のプロキシ設定を継承します proxy_set_header Host www.foo.com; } } match statusok { # /test.php ヘルスチェックに使用されますstatus 200 ; header Content-Type = text/html ; body ~ "Server[0-9]+ is alive" ; }

ヘルス チェックは、親のロケーションブロックからいくつかのパラメータを継承します。 構成でランタイム変数を使用すると、問題が発生する可能性があります。 たとえば、次の構成は、クライアント要求からHostヘッダーの値を抽出するため、実際の HTTP トラフィックに対して機能します。 ヘルス チェックが使用する合成トランザクションでは、 Hostヘッダーが設定されていない (つまり合成トランザクションでHostヘッダーが使用されていない) ため、おそらく機能しません。

location / { proxy_pass http://backend;

# このヘルスチェックは機能しない可能性があります...
health_check interval=2s fails=1 passing=5 uri=/test.php match=statusok;

# リクエストから「Host」ヘッダーを抽出
proxy_set_header Host $host;
}

1 つの良い解決策は、ヘルス チェック トランザクションで使用されるすべてのパラメーターを静的に定義するダミーのロケーションブロックを作成することです。

location /internal-health-check1 { internal; # 外部リクエストがこのロケーション ブロックに一致しないようにします

proxy_pass http://backend;

health_check interval=2s fails=1 passing=5 uri=/test.php match=statusok;

# リクエスト パラメータを明示的に設定します。ランタイム変数は使用しないでください
proxy_set_header Host www.example.com;
}

詳細については、 NGINX Plus 管理者ガイドをご覧ください。

セッションの永続性

セッション永続性により、クラスターにデプロイできないアプリケーションでも、確実に負荷分散およびスケーリングが可能になります。 セッション状態を保存および複製するアプリケーションはより効率的に動作し、エンドユーザーのパフォーマンスが向上します。

特定のアプリケーションでは、たとえばユーザーが仮想ショッピング カートにアイテムを入れたり、アップロードした画像を編集したりするときに、アップストリーム サーバーに状態情報を保存することがあります。 このような場合、そのユーザーからの後続のすべてのリクエストを同じサーバーに送信する必要がある場合があります。

セッション永続性はリクエストをルーティングする場所を指定しますが、負荷分散により、NGINX は最適なアップストリーム サーバーを自由に選択できるようになります。 NGINX Plus のセッション永続性機能を使用すると、2 つのプロセスが共存できます。

   リクエストがセッション持続ルールに一致する場合
ターゲットのアップストリームサーバーを使用する
それ以外の場合は、負荷分散アルゴリズムを適用して上流サーバーを選択します。

ターゲット サーバーが利用できないためにセッション永続性の決定が失敗した場合、NGINX Plus は負荷分散の決定を行います。

最も単純なセッション永続化方法は「スティッキー クッキー」アプローチです。NGINX Plus は、スティッキーなアップストリーム サーバーを識別するクッキーを最初の応答に挿入します。

スティッキークッキー srv_id 有効期限=1時間 ドメイン=.example.com パス=/;

代替の「スティッキー ルート」方式では、NGINX は JSESSIONID クッキーなどのリクエスト パラメータに基づいてアップストリーム サーバーを選択します。

アップストリーム バックエンド { server backend1.example.com route=a ; server backend2.example.com route=b ; # 最初の空でない変数を選択します。これには 'a' または 'b' のいずれかが含まれている必要がありますスティッキー ルート $route_cookie $route_uri ; }

詳細については、 NGINX Plus 管理者ガイドをご覧ください。

HTTP リダイレクトの書き換え

一部のリダイレクトが壊れている場合、特にプロキシから実際のアップストリーム サーバーにリダイレクトされていることがわかった場合は、HTTP リダイレクトを書き換えます。

アップストリーム サーバーにプロキシすると、サーバーはローカル アドレスでアプリケーションを公開しますが、ユーザーは別のアドレス (プロキシのアドレス) を介してアプリケーションにアクセスします。 これらのアドレスは通常ドメイン名に解決されますが、サーバーとプロキシのドメインが異なる場合は問題が発生する可能性があります。

たとえば、テスト環境では、プロキシを直接 (IP アドレスで) 指定したり、 localhostとして指定したりすることがあります。 ただし、アップストリーム サーバーは実際のドメイン名 ( www.nginx.comなど) をリッスンする場合があります。 アップストリーム サーバーがリダイレクト メッセージ ( 3xxステータスとLocationヘッダーを使用するか、 Refreshヘッダーを使用する) を発行すると、メッセージにサーバーの実際のドメインが含まれる場合があります。

NGINX は、この問題の最も一般的なインスタンスを傍受して修正しようとします。 特定の書き換えを強制するために完全な制御が必要な場合は、次のようにproxy_redirectディレクティブを使用します。

proxy_redirect http://staging.mysite.com/ http://$host/;

HTTP レスポンスの書き換え

場合によっては、HTTP 応答のコンテンツを書き換える必要があります。 おそらく、上記の例のように、応答にはプロキシ以外のサーバーを参照する絶対リンクが含まれています。

sub_filterディレクティブを使用して、適用する書き換えを定義できます。

sub_filter /blog/ /blog-staging/;
sub_filter_once off;

非常によくある落とし穴の 1 つは、HTTP 圧縮の使用です。 クライアントが圧縮されたデータを受け入れることができることを通知し、サーバーが応答を圧縮した場合、NGINX は応答を検査および変更できません。 最も簡単な対策は、クライアントのリクエストからAccept-Encodingヘッダーを空の文字列 ( "" ) に設定して削除することです。

proxy_set_header Accept-Encoding "";

完全な例

この記事で説明したすべての手法を採用した負荷分散構成のテンプレートを次に示します。 NGINX Plus で利用できる高度な機能はオレンジ色で強調表示されています。

[編集者 – 次の構成は、元々使用されていた個別のモジュールを置き換えて、ライブ アクティビティの監視とアップストリーム グループの動的構成にNGINX Plus API を使用するように更新されました。]

server { listen 80; location / { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_set_header Accept-Encoding ""; proxy_redirect http://staging.example.com/ http://$host/; # Host ヘッダーをクライアント要求の値に書き換えます proxy_set_header Host $host; # インラインのすべての参照を staging.example.com に置き換えます sub_filter http://staging.example.com/ /; sub_filter_once off; } location /internal-health-check1 { internal; # 外部要求がこの場所と一致しないようにします block proxy_pass http://backend; health_check interval=2s fails=1 passing=5 uri=/test.php match=statusok ; # 要求パラメータを明示的に設定します。実行時変数は使用しません proxy_set_header Host www.example.com; } upstream backend { zone backend 64k ; # NGINX Plus の共有メモリを使用します least_conn; keepalive 20; # このアップストリーム グループのスティッキー クッキーにセッション永続性を適用します srv_id expires=1h domain=.example.com path=/servlet ; server webserver1 weight=1; server webserver2 weight=4; } match statusok { # /test.php のヘルス チェックに使用しますstatus 200 ; header Content-Type = text/html ; body ~ "Server[0-9]+ is alive" ; } server { listen 8080; root /usr/share/nginx/html; location = /api { api write=on ; #ライブ アクティビティの監視とアップストリーム グループの動的構成allow 127.0.0.1; # localhost からのアクセスを許可 deny all; # その他すべての場所からのアクセスを拒否 } }

NGINX Plus の優れた負荷分散機能をすべてお試しください。今すぐ30 日間の無料トライアルを開始するか、弊社にお問い合わせの上、ユースケースについてご相談ください。