NGINX Plus Release 5を発表

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

NGINX Plus Release 5（R5）の提供開始を発表できることを大変うれしく思います。本リリースには、NGINX Open Sourceディストリビューションで最近リリースされた機能に加え、NGINX Plusでのみ利用できる複数の機能が含まれています。

主な新機能は、汎用TCPベースプロトコルの負荷分散です。対象には、データベース、RPC、チャットの各プロトコルなどが含まれます。詳細については、関連記事「NGINX Plus R5におけるTCP負荷分散」をご覧ください。

NGINX Plus R5では、負荷分散とキャッシュ機能にもさまざまな改善が加えられています。

Consider NGINX Plus if you are looking for a web acceleration, load balancing, or application delivery solution, or a fully supported web server with additional monitoring and management APIs.

TCPロードバランシング

NGINX Plus R5では、TCP接続のロードバランシングが導入され、streamモジュールに実装されています。MySQLやSSL/TLS（復号なし）など、さまざまな非HTTP接続の負荷を分散できます。さらに、既存のmailプロキシモジュールと新しいstreamモジュールを組み合わせることで、メールプロトコル（SMTP、POP3、IMAP）の負荷分散と管理も可能です。

このリリースでは、各種の負荷分散方式（ラウンドロビン、最小接続、ハッシュ、IPハッシュ）、接続パラメーターの制御、インラインヘルスチェックによる高可用性、復旧したサーバーのスロースタート、およびサーバーをアクティブ、バックアップ、ダウンのいずれかに手動で指定する機能を提供します。

詳細については、F5のブログの「NGINX Plus R5におけるTCPロードバランシング」およびNGINX Plus管理者ガイドの「TCPロードバランシング」をご覧ください。この機能はNGINX Plus独自のものです。

負荷分散されたユーザーセッションをより適切に制御

メンテナンスやアップグレードのために、アップストリームノードを停止しなければならない場合があります。Release 5の新しいセッションドレイニング機能を使用すると、そのノードには新しい接続を送信せず、確立済みのセッションは完了するまで維持するようNGINX Plusに指示できます。

You can use ライブアクティビティ監視を使用すると、ドレイン中のノードのトラフィックを監視し、ユーザーセッションが完了したことを確認してからオフラインにできます。

# Return the Unix epoch time in seconds (rounded to milliseconds) when # Server 1 in upstream group 'backends' was last used
$ curl http://localhost:8080/status/upstreams/backends/1/selected

# Calculate how long the server has been idle (in milliseconds)
$ expr `date +%s000` - `curl -s http://localhost:8080/status/upstreams/backends/1/selected`

［編集者注：上記のコマンドでは、statusディレクティブで有効になるNGINX Plus Statusモジュールを使用しています。このモジュールは、NGINX Plus APIによってNGINX Plus Release 13（R13）以降で置き換えられ、非推奨となっています。また、NGINX Plus R15より後のリリースでは利用できません。］

ユーザーセッションを追跡するための「sticky cookie」メカニズムが更新され、有効期限の基準がセッションの最初のリクエストではなく、直近のリクエストになりました。これにより、セッションをより正確に追跡できます。

セッションドレイニング機能とスティッキーCookie機能は、NGINX Plusでのみ利用できます。

ノード障害時のトラフィック制御を改善

アップストリームグループ内のサーバーがリクエストに応答しない場合、NGINX Plusはグループ内の他のサーバーに対してリクエストを自動的に再試行します。新しいproxy_next_upstream_triesディレクティブとproxy_next_upstream_timeoutディレクティブでは、それぞれ再試行回数とNGINX Plusが再試行を継続できる時間を制限できるため、この動作をより細かく制御できます。

この機能はNGINX 1.7.5でリリースされ、HTTP、FastCGI、uWSGI、SCGI、memcachedトラフィックのプロキシに適用されます。

HTTP「Vary」ヘッダーをキャッシュ済みコンテンツでサポート

一部のWebサーバーは、リソースを要求するクライアントの種類に応じて、異なるバージョンを配信します。たとえば、ブラウザがWebサイトのホームページを要求した場合、サーバーは高解像度画像を含むバージョンを配信しますが、クライアントがモバイルデバイスの場合は、画像を含まないバージョンを配信します。このようなサーバーは、応答にVaryヘッダーを設定することで、送信するバージョンの決定にクライアント要求内のどのヘッダーを使用しているかをキャッシュプロキシに通知できます（これにより、キャッシュされたリソースのどのバージョンを送信するかを決定する際に、プロキシが使用する必要のあるヘッダーも示されます）。

一般的なユースケースとして、同じリソースの圧縮版と非圧縮版を区別する場合があります。この場合、サーバー応答の「Vary: Accept-Encoding」ヘッダーは、クライアント要求の「Accept-Encoding」ヘッダーの値を使用して、配信するバージョンを決定するようキャッシュに指示します。

NGINX Plusは、同じリソースの複数のバリアントを正しくキャッシュできるよう、Varyヘッダーを完全にサポートするようになりました。この機能はNGINX 1.7.7で導入されました。

キャッシュからのバイト範囲配信サポートの強化

クライアントは、リクエストで適切なバイト範囲を指定することで、ファイルの特定部分（たとえば、ダウンロードする動画の一部やPDFドキュメントの1ページ）を取得できます。コンテンツのオリジンサーバーがバイト範囲をサポートしていない場合でも、NGINX Plusはこのようなリクエストに対応し、キャッシュされたアセットから指定されたバイト範囲をクライアントに配信できます。

NGINX Plusは、ファイル（ファイル全体またはバイト範囲）に対するリクエストを初めて受信すると、オリジンサーバーにファイル全体をリクエストし、キャッシュします。その後、NGINX Plusはキャッシュからバイト範囲リクエストに応答します。これにより、アップストリーム（オリジン）サーバーの負荷が軽減されます。

この機能はNGINX 1.7.7で導入され、proxy_force_rangesディレクティブで有効にできます。

アップストリーム帯域幅をより細かく制御

新しい「proxy_limit_rate」ディレクティブは、NGINX Plusがアップストリームサーバーからデータを読み取る速度を制限します。これにより、1つの大きなリクエストがNGINXとオリジンサーバー間の帯域幅をすべて消費するのを防ぎます。キャッシュが有効な場合は、コンテンツをディスクキャッシュに書き込む速度を効果的に制御できるため、ディスクへの書き込みで高いレイテンシが発生する場合に役立ちます。

このディレクティブはNGINX 1.7.7で導入されました。

NGINX Plus R5のその他の変更点

サードパーティ製の「RTMP module」が「NGINX Plus Extras」パッケージに追加されました。

NGINX PlusがUbuntu 14.10、Ubuntu 14.04上のARMv8（aarch64）、およびSUSE Linux Enterprise Server 12で利用できるようになりました。

NGINX Plusをアップグレードまたは試用

NGINX Plusをご利用のお客さまには、できるだけ早くRelease 5へアップデートすることを強く推奨します。アップデートにより、複数の修正と改善が適用されるほか、サポートチケットを起票する必要が生じた場合に、F5がより円滑にサポートできるようになります。インストールとアップグレードの手順については、カスタマーポータルをご覧ください。

NGINX Plusをまだお試しでない場合は、今すぐ30日間の無料トライアルを開始し、NGINX Plusがアプリケーションのスケールアウトと配信にどのように役立つかをご確認ください。

著者について

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

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