NGINX Plus リリース 5 の発表

NGINX Plus リリース 5 (R5) の提供開始を発表できることを大変嬉しく思います。 このリリースには、NGINX オープンソース ディストリビューションで最近リリースされた機能と、NGINX Plus でのみ利用可能ないくつかの機能が統合されています。

主な新機能は、データベース、RPC、チャット プロトコルなどの一般的な TCP ベースのプロトコルの負荷分散です。 関連する「NGINX Plus R5 の TCP ロード バランシング」ブログ投稿に完全な詳細が記載されています。

NGINX Plus R5 には、負荷分散とキャッシュに対する多くの改善も含まれています。

Web アクセラレーション、負荷分散、アプリケーション配信ソリューション、または追加の監視および管理API を備えた完全にサポートされた Web サーバーを探している場合は、 NGINX Plusを検討してください。

TCP 負荷分散

NGINX Plus R5 では、ストリームモジュールに実装された TCP 接続の負荷分散が導入されています。 MySQL や SSL/TLS (復号化なし) など、さまざまな非 HTTP 接続の負荷を分散できます。 既存のメールプロキシ モジュールと新しいストリームモジュールを組み合わせることで、メール プロトコル (SMTP、POP3、IMAP) の負荷分散と管理も行えます。

このリリースでは、さまざまな負荷分散方法 (ラウンドロビン、最小接続、ハッシュ、IP ハッシュ)、接続パラメータの制御、インライン ヘルス チェックによる高可用性、回復したサーバーのスロー スタート、サーバーをアクティブ、バックアップ、またはダウンとして手動で指定する機能が提供されます。

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

負荷分散されたユーザーセッションのより優れた制御

メンテナンスやアップグレードのためにアップストリーム ノードを停止する必要がある場合があります。 リリース 5 の新しいセッション ドレイン機能を使用すると、NGINX Plus にそのノードに新しい接続を送信せず、確立されたセッションをそのノード上で完了するまで維持するように信号を送ることができます。

ライブ アクティビティ モニタリングを使用して、ドレインされたノード上のトラフィックを監視し、ユーザー セッションが完了したと確信できるまでオフラインにするまで待機することができます。

# アップストリーム グループ 'backends' のサーバー 1 が最後に使用されたときの Unix エポック タイムを秒単位で返します (ミリ秒に丸められます) $ curl http://localhost:8080/status/upstreams/backends/1/selected # サーバーがアイドル状態だった時間を計算します (ミリ秒単位) $ expr `date +%s000` - `curl -s http://localhost:8080/status/upstreams/backends/1/selected`

[編集者 – 上記のコマンドは、NGINX Plus Status モジュール ( statusディレクティブによって有効化) を使用します。 このモジュールは、 NGINX Plus リリース 13 (R13)以降ではNGINX Plus APIに置き換えられて非推奨となり、NGINX Plus R15 以降では利用できなくなります。

ユーザー セッションを追跡するためのスティッキー Cookieメカニズムが更新され、有効期限がセッションの最初のリクエストではなく、最新のリクエストに適用されるようになりました。 つまり、セッションがより正確に追跡されることになります。

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

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

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

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

キャッシュされたコンテンツに対して HTTP Varyヘッダーがサポートされる

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

一般的な使用例は、同じリソースの圧縮バージョンと非圧縮バージョンを区別することです。この場合、 Vary: 受け入れエンコード サーバー応答のヘッダーは、キャッシュに 受け入れエンコード クライアントのリクエストのヘッダーに基づいて、配信するバージョンを決定します。

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

キャッシュからのバイト範囲の提供のサポートの改善

クライアントは、リクエストで適切なバイト範囲を指定することにより、ファイルの特定の部分（たとえば、ビデオのダウンロードのセグメントや PDF ドキュメントのページ）を取得できます。 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 モジュールがNGINX Plus Extrasパッケージに追加されました。

NGINX Plus は現在、Ubuntu 14.10、Ubuntu 14.04 上の ARMv8 (aarch64)、および SUSE Linux Enterprise Server 12 で利用できます。

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

NGINX Plus のお客様には、できるだけ早くリリース 5 にアップデートすることを強くお勧めします。 数多くの修正と改善が行われており、サポート チケットを発行する必要がある場合に、当社がサポートしやすくなります。 インストールおよびアップグレードの手順については、カスタマー ポータルをご覧ください。

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