NGINX Plus R12を発表

NGINX | 2017年3月14日

［編集者注 – 本記事は、初版で説明した個別の動的構成モジュールとステータスモジュールに代わり、これらを非推奨とするNGINX Plus APIを参照するよう更新されています。］

本日、すべてのNGINX Plusサブスクライバー向けに、NGINX Plus R12の無償アップグレードの提供を開始したことをお知らせします。NGINX Plusは、ロードバランサー、コンテンツキャッシュ、Webサーバーを備えた高性能なソフトウェアアプリケーションデリバリープラットフォームです。NGINX Plus R12は、クラスタリング、カスタマイズ、モニタリングに重点を置いた新機能を搭載した重要なリリースです。

NGINX Plus R12の詳細については、オンデマンドウェビナーをご覧ください。

新しいクラスタリング機能により、高可用性を備えたNGINX Plusサーバークラスターの管理が簡素化され、エンタープライズユーザーにメリットをもたらします。また、NGINXの設定に直接組み込まれた軽量かつ高性能なスクリプト言語nginScriptが正式にサポートされ、すべてのユーザーがそのメリットを享受できます。監視と計測、キャッシュ、ヘルスチェックの改善により、アプリケーションの信頼性とパフォーマンスが向上します。

構成共有 – サポート対象の構成共有スクリプトを使用すると、プライマリNGINX Plusインスタンスから一連のピアへ構成を確実にプッシュできます。このプロセスでは、バックアップを実行し、各リモートピアで構成が有効であることを検証してから、構成をコミットし、ピアのnginxプロセスを再読み込みします。
NGINX JavaScriptモジュールの一般提供 – NGINX JavaScript module<.htmla>を使用すると、使い慣れたJavaScript構文で、NGINX Plusによる高度なトラフィック処理ソリューションを作成できます。［このモジュールは以前nginScriptと呼ばれていたため、この記事では両方の名称を同じ意味で使用しています。］ JavaScriptコードをNGINX Plusの設定に埋め込むことで、HTTP、TCP、UDPトラフィックに対してカスタム処理を実行できます。
新しい統計情報 – アプリケーションの健全性と高いパフォーマンスを維持するには、可視性が重要です。NGINX Plus R12では、サーバー応答時間、共有メモリゾーンの使用率、TCP/UDPサービスのエラーコードなどの指標が追加され、アプリケーションパフォーマンスをより詳細に把握できます。新しい統計情報は、組み込みのライブアクティビティ監視ダッシュボードで確認するか、JSON形式で任意の監視ツールにエクスポートできます。
キャッシュ機能の強化 – キャッシュのパフォーマンスがさらに向上します。NGINX Plus R12は、stale-while-revalidateおよびstale-if-errorのキャッシュ拡張機能をサポートしています。これらはRFC 5861で定義されています。キャッシュの再検証をバックグラウンドで実行できるため、ユーザーはオリジンサーバーとのラウンドトリップが完了するまで待つ必要がありません。
ヘルスチェックの改善 – NGINX Plus APIまたはDNSを使用してロードバランシングプールに新しいサーバーを追加した場合、NGINX Plusでは、設定済みの通常のヘルスチェックに合格するまでトラフィックの送信を遅らせ、その後スロースタート機能を適用してトラフィックを徐々に増やすことができます。また、UDP向けの新しい簡易ヘルスチェックにより、信頼性の高いUDPサービスをユーザーに提供しやすくなります。

さらに、TCPサービスのクライアント証明書認証、OAuth JWTのカスタムフィールドを検査する機能、Image-FilterモジュールでのWebP形式のサポートに加え、パフォーマンスと安定性に関するさまざまな改善が行われています。

本リリースで強化されたパフォーマンス、機能、信頼性をご活用いただくため、すべてのサブスクライバーにNGINX Plus R12への早急なアップデートを推奨します。アップデートを実行する前に、次のセクションに記載されている動作の変更点を必ずご確認ください。

動作の変更点

NGINX Plus R12では、デフォルトの動作とNGINX Plusの内部仕様にいくつかの変更が加えられています。アップグレードする際は、以下の変更点に注意してください。

キャッシュメタデータ形式 – 内部キャッシュメタデータヘッダーの形式が変更されました。NGINX Plus R12にアップグレードすると、ディスク上のキャッシュが無効になり、NGINX Plusが必要に応じてキャッシュを自動的に更新します。古いキャッシュエントリは自動的に削除されます。
SSL「DN」変数 – $ssl_client_s_dn変数と$ssl_client_i_dn変数の形式が変更されました。フィールド区切り文字には、スラッシュ（,）の代わりにカンマ（/）が使用されるようになり、RFC 2253および4514に従ってエスケープされます。スラッシュをフィールド区切り文字とするX509_NAME_oneline形式を引き続き使用するには、$ssl_client_s_dn_legacy変数と$ssl_client_i_dn_legacy変数を使用してください。
最大接続数キュー – queueディレクティブは、アップストリームサーバーが過負荷状態の場合に、そのサーバーへの接続をキューに入れるようNGINX Plusに指示します。R12でメモリとパフォーマンスが最適化されたため、queueディレクティブは、upstreamブロック内で、負荷分散アルゴリズムを指定するディレクティブの後に記述する必要があります（hash、ip_hash、least_conn、またはleast_time）。
サードパーティ製ダイナミックモジュール – ダイナミックモジュールのうち、NGINX, Inc.が開発または認定したものは、F5のリポジトリで提供されています。サードパーティ製モジュールをNGINX Plus R12で引き続き使用するには、NGINX Open Sourceバージョン 1.11.10に対して再コンパイルする必要があります。詳細については、NGINX Plus管理ガイドを参照してください。
サポート終了OSバージョン向けの最終リリース – UbuntuはUbuntu 12.04 LTSのサポート終了を、Red HatはRed Hat Enterprise Linux 5.10+のProduction Phaseサポート終了を発表しました。いずれも2017年3月31日付で終了します。NGINX Plus R12は、これらのOSバージョンに加え、CentOS 5.10+およびOracle Linux 5.10+向けのパッケージ提供とサポートを含む最後のリリースです。NGINX Plus R12以降もアップデートとサポートを継続して受けるには、サポート対象のOSバージョンに更新してください。

NGINX Plus R12の機能詳細

設定の共有

NGINX Plusサーバーは、高可用性とスケーラビリティを確保するため、2つ以上のインスタンスで構成されるクラスターとして導入されることがよくあります。これにより、サーバー障害の影響を抑えてサービスの信頼性を向上できるほか、スケールアウトして大量のトラフィックを処理できます。

NGINX Plusでは、クラスター全体にトラフィックを分散するためのサポート対象の方法として、すでにアクティブ‑パッシブまたはアクティブ‑アクティブ方式が提供されています。NGINX Plus R12では、クラスター全体で構成を同期するための新たなサポート対象の方法が追加されました。この構成同期機能により、管理者は1か所からNGINX Plusサーバーの「クラスター」を構成できます。これらのサーバーは、構成の共通サブセットを共有します。

NGINX Plusの設定はプライマリからピアにプッシュされます

構成を同期する手順は次のとおりです。

クラスター内の1つ以上のノードを「プライマリ」として指定します。
プライマリノードに新しいnginx-syncパッケージをインストールします。
プライマリノードに構成変更を適用します。
nginx-syncパッケージに含まれる構成同期プロセス「nginx-sync.sh」を実行し、クラスター内の他の各サーバー（ピア）を更新します。同期プロセスは、各ピアで次の手順を実行します。
1. 更新された構成をピアに転送します。転送には「ssh」または「rsync」を使用します。
2. 構成がピアに対して有効であることを検証し、無効な場合はロールバックします。
3. 構成が有効な場合はその構成を適用し、ピア上のNGINX Plusサーバーを再読み込みします。

この機能は、NGINX Plusをフォールトトレラント構成の2台（またはそれ以上）のサーバーに導入する場合に特に役立ちます。この方法を使用すると、クラスター内での信頼性の高い構成のデプロイを簡素化したり、ステージングサーバーから本番サーバーのクラスターに構成をプッシュしたりできます。

詳しい手順については、「NGINX Plus Admin Guide」を参照してください。

NGINX JavaScript Moduleの一般提供

NGINX Plus R12のリリースに伴い、NGINX JavaScriptモジュールがNGINX Open SourceとNGINX Plusの両方で安定版モジュールとして一般提供されるようになりました。［このモジュールは以前nginScriptと呼ばれていたため、本記事では両方の名称を同じ意味で使用します。］nginScriptは、NGINX Plusサブスクライバー向けにフルサポートされています。

nginScriptは、NGINXおよびNGINX Plus向けの独自のJavaScript実装<.htmla>であり、サーバーサイドのユースケースとリクエスト単位の処理に特化して設計されています。JavaScriptコードでNGINX Plusの設定構文を拡張し、高度な設定ソリューションを実装できます。

nginScriptを使用すると、複雑なロジックを用いてカスタム変数をログに記録したり、アップストリームの選択を制御したり、負荷分散アルゴリズムを実装したり、セッション永続性をカスタマイズしたりできるほか、シンプルなWebサービスを実装することも可能です。今後数週間のうちに、これらのソリューションの一部について詳しい手順をブログで公開し、公開され次第、こちらにリンクを追加します。

具体的には、NGINX Plus R12には以下の機能強化が含まれています：

Preread phase in the Streamモジュールの事前読み取りフェーズ
ECMAScript 6のMathメソッドと定数
次のような追加のStringメソッド：endsWith、includes、repeat、startsWith、trim
スコープ

nginScriptは安定していますが、さらに多くのユースケースとJavaScript言語仕様に対応するため、開発は継続されています。詳しくは、ブログ記事「NGINX JavaScript ModuleでリクエストごとにJavaScriptのパワーと利便性を活用する<.htmla>」をご覧ください。

新しい統計情報

NGINX Plusの監視および計測機能は、NGINX Plusとアップストリームアプリケーションの両方について、パフォーマンスと動作を詳細に把握できる重要な付加価値です。統計情報は、組み込みのグラフィカルダッシュボードに加え、任意の監視ツールにエクスポートできるJSON形式でも提供されます。

ライブアクティビティ監視ダッシュボードがNGINX Plus R12向けに更新されました

NGINX Plus R12では、ロードバランシング対象サーバーのパフォーマンス（応答時間）に関する詳細情報、TCPおよびUDPサービスの動作状況に関する分析情報、問題の特定に向けたトラブルシューティングや、パフォーマンスを最適化するためのNGINX Plusのチューニングに役立つ各種内部データなど、さまざまな機能が強化されています。

NGINX Plus R12では、次の統計情報が新たに追加されました。

アップストリームサーバーの応答時間 – NGINX Plus R11以前では、アップストリームサーバーからの応答時間は、Least Time負荷分散アルゴリズムを使用した場合にのみ計算されていました。NGINX Plus R12以降では、すべてのアルゴリズムで応答時間が測定され、JSONデータと組み込みダッシュボードの両方に表示されます。
グラフィカルダッシュボードでのTCP/UDPアップストリームのレスポンスコード – TCP/UDPロードバランシング用のStreamモジュールは、接続がどのように終了したかを識別するための疑似ステータスコードを生成し（200は「成功」、502は「アップストリームを利用不可」など）、$status変数で報告します。NGINX Plus R12では、HTTP仮想サーバー向けにすでに提供されているものと同様に、TCPおよびUDP仮想サーバーのレスポンスコード数を表示する一連の列がダッシュボードに追加されました。疑似ステータスコードは、既存のログ分析ツールと連携できるよう、ログに記録することもできます。
NGINX Plusのバージョン情報 – トラブルシューティングに役立つよう、JSONデータでNGINX Plusのリリース番号がnginx_build（例：nginx-plus-r12）として、NGINX Open Sourceのバージョン番号がnginx_version（例：1.11.10）として報告されるようになりました。ダッシュボードでは、メインタブの左上にあるボックスに両方の値が表示されます。
アップストリームのホスト名 – JSONデータでは、serverフィールドにより、アップストリームグループ内のサーバーがIPアドレスとポートで識別されます。新しいnameフィールドには、serverディレクティブの最初のパラメーターが、upstream設定ブロック内で報告されます。このパラメーターには、IPアドレスとポートのほか、ドメイン名またはUNIXドメインソケットのパスを指定できます。ダッシュボードでは、Name列（UpstreamsタブおよびTCP/UDP Upstreamsタブの左端）に、serverフィールド（NGINX Plus R11以前で使用）ではなく、nameフィールドの値が表示されるようになりました。アップストリームサーバーをDNS名、特に複数のIPアドレスに解決される名前で定義している場合、この新しいメトリックにより、JSONデータおよびダッシュボードとアップストリームサーバーとの対応関係を把握しやすくなります。
拡張ステータスデータにおける共有メモリゾーンの使用状況 – 共有メモリゾーンは固定サイズで構成されるため、大きすぎず（メモリが割り当てられても使用されない）、小さすぎない（メモリが枯渇し、キャッシュされた項目が破棄される）適切なサイズを選択するのは容易ではありません。メトリクスに新たに追加された計測機能により、各共有ゾーンのメモリ使用状況に関する詳細な内部レポートが提供されます。これにより、メモリ使用状況を監視できるほか、NGINXテクニカルサポートがNGINX構成の最適化について、より的確なアドバイスを提供できるようになります。
NGINX PlusアクセスログでのJSON準拠のエスケープ – 最新のログ分析ツールの中には、JSON形式のログファイルを効率的に取り込み、書式設定されていないログファイルよりも容易に知見を引き出せるものがあります。標準のNGINX Plus log_formatディレクティブでJSONテンプレートを定義できます。また、このディレクティブの新しいオプションパラメーターであるescapeを使用すると、JSON準拠のエスケープが適用され、ログ行が正しく書式設定されます。

詳細については、「ライブアクティビティの監視」を参照してください。

キャッシュ機能の強化

NGINX Plus R12では、NGINX Plusのキャッシュエンジンが大幅に強化されています。

更新中は古いコンテンツを配信

NGINX Plus R12では、Cache-Controlの拡張機能であるRFC 5861で定義された「stale-while-revalidate」と「stale-if-error」がサポートされるようになりました。NGINX PlusでこれらのCache-Control拡張機能に従うよう設定すると、クライアントリクエストのレイテンシーを増加させることなく、バックグラウンドでリソースを更新しながら、期限切れのリソースをキャッシュから引き続き配信できます。同様に、アップストリームサーバーが利用できない場合も、NGINX Plusは期限切れのリソースをキャッシュから配信できます。これは、マイクロサービスアプリケーションにサーキットブレーカーパターンを実装するための手法です。

Unless it is configured to ignore the Cache-Controlヘッダーを無視するように設定されていない限り、NGINX Plusは、RFC 5861に準拠したstaleタイマーを含むCache-Controlヘッダーを返すオリジンサーバーの設定に従います。次に例を示します。

Cache-Control: max-age=3600 stale-while-revalidate=120 stale-if-error=900

バックグラウンド更新を伴うCache-Control拡張機能のサポートを有効にするには、強調表示されたディレクティブを含めます。

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;

server {
    # ...
    location / {
        proxy_cache my_cache;

        # Serve stale content when updating
        proxy_cache_use_stale updating;
        
        # In addition, don’t block the first request that triggers the update
        # and do the update in the background
        proxy_cache_background_update on;

        proxy_pass http://my_upstream;
    }
}

The proxy_cache_use_stale updatingディレクティブは、コンテンツの更新中に古いバージョンを配信するようNGINX Plusに指示します。このディレクティブだけを指定した場合、古いコンテンツを最初にリクエストしたユーザーには「キャッシュミス」による遅延が発生します。つまり、NGINX Plusがオリジンサーバーからコンテンツを取得してキャッシュするまで、そのユーザーにはコンテンツが配信されません。更新中に同じ古いコンテンツを後からリクエストしたユーザーには、キャッシュから直ちに配信されますが、最初のユーザーには、更新されたコンテンツの取得とキャッシュが完了するまで何も配信されません。

新しい「proxy_cache_background_update」ディレクティブを使用すると、NGINX Plusがバックグラウンドでコンテンツを更新している間、最初のユーザーを含むすべてのユーザーに古いコンテンツが配信されます。

この新機能は、FastCGI、SCGI、uwsgiの各モジュールでも利用できます。

バイト範囲リクエスト

キャッシュエンジンがさらに強化され、キャッシュされていないファイルの先頭から設定されたバイト数を超える位置で始まるバイト範囲リクエストについて、NGINX Plusがキャッシュをバイパスできるようになりました。これにより、動画コンテンツなどの大容量ファイルで、ファイル内の先の位置にあるバイト範囲をリクエストしても、クライアントリクエストに遅延が加わりません。以前のバージョンのNGINX Plusでは、NGINX Plusがファイルの先頭からリクエストされたバイト範囲までのすべてのコンテンツを取得してキャッシュに書き込むまで、クライアントはリクエストしたバイト範囲を受信できませんでした。

新しい「proxy_cache_max_range_offset」ディレクティブでは、ファイルの先頭からのオフセットを指定します。このオフセットを超えるバイト範囲リクエストは、NGINX Plusからオリジンサーバーに直接渡され、レスポンスはキャッシュされません。（この新機能は、FastCGI、SCGI、uwsgiの各モジュールでも利用できます。）

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;
server {
    location / {
        proxy_cache my_cache;

        # Bypass cache for byte range requests beyond 10 megabytes
        proxy_cache_max_range_offset 10m;

        proxy_pass http://my_upstream;
    }
}

これらの機能強化により、NGINX Plusは、アプリケーション配信の高速化から本格的なコンテンツ配信ネットワーク（CDN）の構築まで、あらゆる環境に適した高性能かつ標準準拠のキャッシュエンジンとしての地位をさらに確固たるものにします。

ヘルスチェックの改善

NGINX Plus R12では、NGINX Plusのアクティブヘルスチェック機能がさらに強化されています。

新しく追加されたサーバーのヘルスチェック

コンテナ化環境やアプリケーションの自動スケーリンググループの導入が進む中、ロードバランサーには、アプリケーションレベルのプロアクティブなヘルスチェックを実装し、新しいサーバーが本稼働する前に内部リソースを初期化するための時間を確保することが不可欠です。

NGINX Plus R12より前のバージョンでは、NGINX Plus APIまたはDNSを使用して新しいサーバーを負荷分散プールに追加すると、NGINX Plusはそのサーバーを直ちに正常とみなし、すぐにトラフィックを送信していました。新しいmandatoryパラメーターをhealth_checkディレクティブ（HTTPまたはTCP/UDP）に指定すると、NGINX Plusがトラフィックを送信する前に、新しいサーバーが設定済みのヘルスチェックに合格する必要があります。slow‑start機能と組み合わせることで、この新しいパラメーターにより、新しいサーバーは割り当てられたトラフィックをすべて処理する前に、データベースへの接続と「ウォームアップ」にさらに時間をかけられます。

upstream my_upstream {     zone my_upstream 64k;
     server backend1.example.com slow_start=30s;
}

server {
    location / {
        proxy_pass http://my_upstream;
  
        # Require new server to pass health check before receiving traffic
        health_check mandatory;
    }
}

ここでは、mandatoryパラメーターをhealth_checkディレクティブに、slow_startパラメーターをserverディレクティブ（HTTPまたはTCP/UDP）に指定しています。APIまたはDNSインターフェイスを使用してアップストリームグループに追加されたサーバーは異常とマークされ、ヘルスチェックに合格するまでトラフィックを受信しません。合格すると、30 秒かけて徐々に増加するトラフィックを受信し始めます。

設定不要のUDPヘルスチェック

本番トラフィックが完全に機能していないサーバーに送信されないようにするには、HTTPサーバーやTCPサーバーと同様に、UDPサーバーにもアプリケーションレベルのヘルスチェックを実装することが重要です。NGINX PlusはUDPのアクティブヘルスチェックをサポートしていますが、NGINX Plus R12より前のバージョンでは、送信するデータと想定する応答を定義したmatchブロックを作成する必要がありました。つまり、送信するデータをsendで、想定する応答をexpectで定義していました。バイナリプロトコルや複雑なハンドシェイクを伴うプロトコルでは、適切な値の特定が難しい場合があります。このようなアプリケーション向けに、NGINX Plus R12では、send文字列とexpect文字列を定義せずにアプリケーションの可用性をテストできる、UDPの「ゼロコンフィグ」ヘルスチェックがサポートされるようになりました。基本的なUDPヘルスチェックを行うには、udpパラメーターをhealth_checkディレクティブに追加します。

upstream udp_app {    server backend1.example.com:1234;
    server backend2.example.com:1234;
}

server {
    listen 1234 udp;
    proxy_pass udp_app;

    # Basic UDP health check
    health_check udp;
}

SSLの更新 – TCPサービス向けクライアント証明書、変数の更新

SSLクライアント証明書は、保護されたWebサイトでユーザーを認証するために広く使用されています。NGINX Plus R12では、従来のHTTPに加え、SSLで保護されたTCPサービスの認証もサポートされます。これは通常、エンドユーザーのログインではなくマシン間認証に使用され、レイヤー4プロトコルの負荷分散時に、NGINX PlusをSSL終端とクライアント認証の両方に使用できます。たとえば、MQTTプロトコルで通信するIoTデバイスの認証に利用できます。

The $ssl_client_verify変数に、クライアント認証の失敗イベントに関する追加情報が含まれるようになりました。これには、証明書が「失効済み」または「期限切れ」であるといった理由が含まれます。

The format of the $ssl_client_i_dn変数と$ssl_client_s_dn変数の形式が、RFC 2253およびRFC 4514に準拠するよう変更されました。詳細については、「動作の変更」を参照してください。

JWT検証の強化

NGINX Plus R10では、OAuth 2.0およびOpenID Connectのユースケース向けに、JSON Web Token（JWT）のネイティブサポートが導入されました。主なユースケースの1つは、NGINX PlusでJWTを検証し、そのフィールドを確認して、HTTPヘッダーとしてバックエンドアプリケーションに渡すことです。これにより、トークン検証をNGINX Plusにオフロードし、HTTPヘッダーを読み取ってユーザーIDを取得できるため、アプリケーションをOAuth 2.0シングルサインオン（SSO）環境に容易に参加させることができます。

NGINX Plus R10以降では、JWT仕様で定義されたフィールドを検査できます。NGINX Plus R12ではJWTサポートが拡張され、カスタムフィールドを含むJWT内の任意のフィールドにNGINX変数としてアクセスできるため、プロキシ転送やログ記録、認可の判断に使用できます。

NGINX Plusへのアップグレードまたはお試し

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

アップグレードを続行する前に、上記の動作変更をご確認ください。

まだNGINX Plusをお試しでない場合は、Web高速化、負荷分散、アプリケーションデリバリーに加え、高度な監視と構成管理のためのAPIを備え、フルサポートが提供されるWebサーバーとして、ぜひお試しください。今すぐ無料の30日間評価版を利用して、NGINX Plusがアプリケーションのデリバリーとスケールアウトにどのように役立つかをご確認いただけます。