NGINX Plus R13を発表

NGINX | 2017年8月29日

NGINX Plus Release 13（R13）が、すべてのNGINX Plusサブスクライバー向けに無償アップグレードとして提供開始されたことをお知らせします。NGINX Plusは、NGINX Open Sourceを基盤とする、Webサーバー、ロードバランサー、コンテンツキャッシュを統合した製品です。NGINX Plus R13には、動的デプロイメント、デバッグ機能の強化、セキュリティとパフォーマンスの向上に重点を置いた新機能が含まれています。

NGINX Plus R13では、以下が新たにサポートされます。

新しいNGINX Plus API – 単一の統合エンドポイントで動的な設定を行い、拡張ステータスメトリクスを取得できます。また、このAPIではキーバリューストアもサポートされます。
リクエストミラーリング – すべての受信トラフィックのコピーを専用サーバーに送信し、本番サーバーのパフォーマンスに影響を与えることなく、アプリケーショントラフィックを監視、検査、記録できます。
NGINX JavaScriptモジュールの機能強化 – JavaScriptを独自に実装したNGINX JavaScriptモジュールを使用してプログラムによる設定を行い、NGINX Plusを拡張できます。［このモジュールは以前、nginScriptと呼ばれていました。］ 新しいnjs対話型シェルには、JavaScriptのすべての組み込みオブジェクトを表示するコンソールが用意されています。これらのオブジェクトをさらに調べることで、各オブジェクトで使用可能なメソッドとプリミティブを確認できます。
動的モジュール用ビルドツール – 新しいビルドツールを使用して、NGINXおよびNGINX Plus向けに提供されている多数のサードパーティ製モジュールのインストール可能なパッケージを作成できます。

その他の機能強化として、セッション維持のためのsticky learn方式の改善、HTTPトレーラーのサポート、HTTP置換用の新しいサードパーティ製ダイナミックモジュールが含まれます。

動作の変更

非推奨のモジュール – 拡張ステータスおよびアップストリームグループの動的構成に使用されていた従来のAPI（StatusモジュールおよびUpstream Confモジュール）は非推奨となり、統合された「NGINX Plus API」に置き換えられます。非推奨のAPIは、新しいNGINX Plus APIとともに、少なくとも6か月間は引き続きNGINX Plusに同梱されます。今後のNGINX Plusリリースで削除される予定です。
削除されたディレクティブ – sticky_cookie_insertディレクティブは、NGINX Plus R2で非推奨となり、NGINX Plus R13で削除されました。
サードパーティ製ダイナミックモジュール – NGINXリポジトリからインストールされたダイナミックモジュールは、自動的にR13へアップグレードされます。サードパーティ製モジュール（つまり、NGINX公式リポジトリに含まれていないモジュール）をNGINX Plus R13で引き続き使用するには、NGINX Open Source 1.13.4向けに再コンパイルする必要があります。詳細については、NGINX Plus管理ガイドを参照してください。
ModSecurityモジュールのディレクティブはサポート終了 – SecRequestBodyInMemoryLimit ModSecurityのディレクティブはサポートされなくなりました。ModSecurityモジュールはNGINX構成で定義されたリクエストボディの処理に従うため、このディレクティブは安全に削除できます。［編集者注 – NGINX ModSecurity WAF NGINX Plus向けモジュールは、2022年4月1日付で正式に販売終了となり、2024年3月31日付でサポート終了となります。詳細については、F5ブログの「F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla>」をご覧ください。］
サポート終了OSバージョンのサポートを廃止 – NGINX Plusでは、CentOS 5.10+、Red Hat Enterprise Linux 5.10+、Oracle Linux 5.10+、Ubuntu 12.04 LTS、Ubuntu 16.10がサポート対象外となりました。

NGINX R13の機能詳細

NGINX Plus API

NGINX Plus R13には、単一のエンドポイントに統合された新しいREST APIが含まれています。以前のバージョンのNGINX Plusには、Upstream Conf APIとExtended Status APIが個別に含まれていました。新しいAPIは両方の機能を統合し、動的構成のさまざまなユースケースで新しいKey‑Value Storeモジュールもサポートします（後述の「Key‑Value Store」セクションを参照）。

NGINX Plus APIを有効にするには、新しいapiディレクティブをlocationブロックに追加します。

server {    listen 80;

    location /api {
        api write=on;
        # directives that allow access only by authorized users
    }
}

デフォルトでは、NGINX Plus APIによるデータへのアクセスは読み取り専用です。write=onパラメーターをapiディレクティブに追加して読み取り／書き込みアクセスを有効にすると、アップストリームサーバーと新しいKey‑Value Storeモジュールを変更できるようになります。特に読み取り／書き込みモードを有効にする場合は、APIへのアクセスを承認済みユーザーのみに制限することを強く推奨します。

APIエンドポイントから取得できるすべての情報タイプを確認するには、次のコマンドを実行します。

$ curl http://localhost:80/api/1/ ["nginx","processes","connections","ssl","slabs","http","stream"]

特定の種類の情報の詳細を表示するには、リクエストURIに該当する文字列を追加します。

connections – 総接続数のメトリクスを表示
http – HTTPトラフィックのメトリクスを表示し、HTTPアップストリーム設定を変更します。また、httpには2つの「サブタイプ」があります：
- http/server_zones – HTTP仮想サーバーに関する情報を表示
- http/upstreams – HTTPアップストリームサーバーグループに関する情報を表示し、その設定を変更します
nginx – NGINXに関する一般情報を表示
processes – NGINXワーカープロセスに関する情報を表示
slabs – NGINXによって割り当てられた共有メモリに関する情報を表示します
ssl – SSL/TLSクライアントのメトリクスをリアルタイムで表示
stream – TCP/UDPトラフィックのメトリクスを表示し、TCP/UDPアップストリームサーバーグループの構成を変更（stream/upstreamsで）

拡張ステータス監視

NGINX Plusでは、NGINX Open Sourceで利用できるメトリクスに加えて、40を超える独自のメトリクスが提供されます。これらのメトリクスには、NGINX Plus APIを使用してアクセスできるようになりました。APIを使用して、必要なメトリクスにアクセスできます。

例として、URIに「connections」を追加すると、接続ステータスのスナップショットが出力されます。これには、受け入れ済み、アクティブ、ドロップ済み、アイドル状態の各クライアント接続数が含まれます。

$ curl http://localhost:80/api/1/connections{"accepted":3,"dropped":0,"active":1,"idle":0}

別の例として、URIに「ssl」を追加すると、SSLクライアント統計のスナップショットをリアルタイムで出力できます。

$ curl http://localhost:80/api/1/ssl {"handshakes":0,"handshakes_failed":0,"session_reuses":0}

アップストリームサーバーグループの動的構成

NGINX Plus R12以前では、upstream_confディレクティブを使用することで、NGINX Plusを再読み込みせずに既存のアップストリームサーバーグループを動的に構成できました。この機能は現在、NGINX Plus APIに組み込まれています。

このNGINX Plus構成スニペットでは、「backend」というアップストリームグループに2台のサーバーを定義し、/apiでNGINX Plus APIを有効にします。

upstream backend {    zone backends 64k;
    server 10.10.10.2; 
    server 10.10.10.4;
}

server {
    listen 80;
    server_name www.example.org;

    location /api {
        api write=on;
    }
}

サーバーをbackendグループに追加するには、-dオプションを指定したcurlリクエストを/api/1/http/upstreams/backend/serversに送信します。このリクエストには、新しいサーバーのIPアドレス（ここでは10.10.10.6）を定義するJSONテキストを含めます。-iオプションを指定すると、レスポンスにHTTPヘッダーが含まれます。（-X POSTは-dを指定した場合のデフォルトメソッドであるため省略できますが、他のメソッドとの一貫性を保つため、ここでは指定しています。）

$ curl -iX POST -d '{"server":"10.10.10.6"}' http://localhost/api/1/http/upstreams/backend/serversHTTP/1.1 201 Created
...

アップストリームグループを構成するためのすべてのオプションについて詳しくは、NGINX Plus APIモジュールのリファレンスドキュメントを参照してください。

キーと値のストア

NGINX Plus R13では、新しいKey-Value Storeモジュールが導入されました。NGINX Plus APIを使用すると、1つ以上の「keyval」共有メモリゾーンでキーと値のペアを動的に作成、変更、削除できます。各キーと値のペアの値は変数として評価でき、NGINX Plusの他の機能で使用できます。

キー・バリュー・ストアのエントリを追加、変更、読み取り、削除するには、それぞれHTTPメソッドの「POST」、「PATCH」、「GET」、「DELETE」を使用します。キー・バリュー・ストアは、外部システムとのリアルタイム統合を可能にする多様な動的構成ソリューションを提供します。

ユースケースの例：

動的IP拒否リスト（「NGINX Plus管理ガイド」を参照）
バックエンドサーバーへのURIのルーティング
ユーザーごとの許可済みURIリストの管理
リダイレクトルールの管理（以下の例を参照）

次の設定スニペットでは、Key-Value Storeモジュールを使用して、WebサイトのバニティURLを管理します。

keyval_zone zone=redirects:1M state=state/redirects.json;  # Save key-val pairs to filekeyval $uri $target zone=redirects;                        # $uri is the key, $target is the value

server {
    listen 80;

    location /api {
        api write=on; # Enable the NGINX Plus API (secure this location in production environments)
    }

    if ($target) {          # True when $uri exists in the 'redirects' keyval zone
        return 301 $target; # Redirect client to the matching value for the $uri
    }

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

In the keyvalディレクティブでは、HTTPリクエストを発行したリモートマシンのURIがキーとして設定されます。$uriがキーバリューストア内のキーである場合、そのキーに関連付けられた値が、$targetという新しい変数に割り当てられます。その後、$targetが存在する場合、NGINX Plusはクライアントを$uriに対応する値へリダイレクトします。

キー・バリュー・ストアに初期バニティURLを登録するため、データをJSON形式でエンコードし、NGINX Plus APIのURIに送信します。

$ curl -iX POST -d '{"/conf":"/conf2017"}' http://localhost/api/1/http/keyvals/redirectsHTTP/1.1 201 Created
...

これで、/confをリクエストするクライアントは、/conf2017にリダイレクトされます。

$ curl -i http://localhost/confHTTP/1.1 301 Moved Temporarily
Location: http://localhost/conf2017

You can use the PATCHメソッドを使用すると、キーバリューストアにバニティURLのリダイレクトを追加し、既存のエントリを動的に変更できます。

$ curl -iX PATCH -d '{"/conf":"/conf2018"}' http://localhost/api/1/http/keyvals/redirectsHTTP/1.1 204 No Content
...

複数の独立したキーバリューストアを構成するには、keyvalディレクティブを使用して、ストアごとに異なる共有メモリゾーンを定義します。詳細については、Key-Value Storeモジュールのリファレンスドキュメントを参照してください。

Swaggerドキュメント

新しいNGINX Plus APIには、APIを調査し、各リソースの機能を把握するために使用できるSwagger仕様が付属しています。SwaggerドキュメントはNGINX Plusに同梱されており、http://nginx-host/swagger-ui/からアクセスできます。

Swagger UIのインタラクティブ機能を使用するには、NGINX Plus APIを有効にする必要があります。有効にするには、/api/のlocationブロックをconf.d/default.confファイル内でコメント解除します。

# enable /api/ location with appropriate access control in order# to make use of NGINX Plus API
#
#location /api/ {
#    api write=on;
#    allow 127.0.0.1;
#    deny all;
#}

NGINX Plus APIのドキュメントは、こちらでもご覧いただけます：https://demo.nginx.com/swagger-ui/。

注：拡張ステータスメトリクス、アップストリーム設定、新しいKey‑Value Storeモジュールを含むNGINX Plus APIの全機能は、NGINX Plusでのみ利用できます。

リクエストミラーリング

NGINX Plus R13では、HTTPリクエストミラーリングを有効にできます。この機能を使用すると、アップストリームグループにプロキシされるHTTPリクエストが複製され、別の宛先にも送信されます。元のリクエストは通常どおり処理されますが、複製されたリクエストに対するレスポンスはすべて無視されます。リクエストミラーリングには、次のようなさまざまなユースケースがあります。

学習モードで導入されたWebアプリケーションファイアウォール（WAF）との統合により、本番トラフィックに影響を与えることなく、一般的なリクエストパターンを分析できます
本番環境のライブトラフィックを使用した、リスクを伴わないパフォーマンスチューニング
Webサーバー間でのファイルシステムのレプリケーションを回避するため、アップロードされたファイルをバックアップサーバーに複製

リクエストミラーリングを有効にしても、システム全体のスループットとパフォーマンスへの影響はごくわずかです。次の設定スニペットは、新しい「mirror」ディレクティブを使用してリクエストを複製し、別のアップストリームサーバーに渡す方法を示しています。

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

location /mirror {
    internal;
    proxy_pass http://test_backend$request_uri;
}

リクエストは通常の処理のために、backendアップストリームグループにプロキシされます。また、リクエストは複製され、元のリクエストのURIを維持したまま、test_backendという別のアップストリームグループにもプロキシされます。

注：リクエストミラーリングは、NGINX Open Source 1.13.4で初めてリリースされました。

NGINX JavaScript Moduleの機能強化

一般提供が開始されたNGINX Plus R12以降、NGINX JavaScriptモジュール（旧称nginScript）では、JavaScriptのコア言語機能のサポートが継続的に拡張されています。今回のリリースでは、16進数（0x7bなど）と科学的記数法（512e10など）のサポートを導入しました。また、Objectクラスのプリミティブメソッドも実装しました。

NGINX JavaScriptでは、NGINX JavaScriptコードの開発を支援するために、njsコマンドで起動できる対話型シェルも利用できるようになりました。

次のシェルスニペットは、NGINX JavaScriptの対話型シェルを起動し、現在から最大30秒後までのランダムな日時を生成する式を定義して、2つの数値の合計を計算する方法を示しています。

$ njsinteractive njscript
>> Date.now() + Math.round(Math.random()*30*1000);
1500976350968
>> 0x7b + 512e10;
5120000000123
>>

詳細については、ブログの「NGINX JavaScript<.htmla>入門」をご覧ください。

注： NGINX JavaScriptは、NGINX Open SourceとNGINX Plusの両方で利用できます。

動的モジュール用ビルドツール

NGINX 1.11.5とNGINX Plus R11では、NGINX本体とは別に動的モジュールをコンパイルできるようになりました。これにより、NGINXおよびNGINX Plusのユーザーは、NGINX, Inc.のリポジトリにある公式ビルドを使用し、必要な動的モジュールだけを読み込めます。

NGINX Plus R13では、動的モジュールをコンパイルし、そのモジュールとリンク先のベースNGINXバージョンとの依存関係を維持して適用する、インストール可能なモジュールとしてパッケージ化するためのビルドツールを提供します。

ビルドツールの詳細については、F5のブログ記事「動的モジュール用のインストール可能なパッケージの作成」をご覧ください。

注：このビルドツールは、NGINX Open SourceとNGINX Plusの両方で利用できます。

Sticky Learnによるセッション永続化の高速化

セッション永続化は、特定のクライアントからのすべてのリクエストを1台のサーバーに送信できる、NGINX Plusのロードバランシングにおける非常に便利な機能です。セッション永続化を確立する方法はいくつかあります。「sticky learn」方式では、NGINX Plusが特定のCookieの有無を確認し、そのCookieがリクエストに含まれている場合は常に、クライアントを同じサーバーに固定します。

NGINX Plus R13では、応答ペイロード全体の到着を待たずに、アップストリームサーバーが応答ヘッダーを送信した時点でスティッキーセッションを確立できるようになりました。これにより、NGINX Plusは可能な限り早い段階でスティッキーセッションをクライアントに送信できます。新しいheaderパラメーターをsticky learnディレクティブに追加します。

upstream backends {    zone backends 64k;
    server 10.10.10.2; 
    server 10.10.10.4;
   
    sticky learn create=$upstream_cookie_sessionid
                 lookup=$cookie_sessionid
                 zone=client_sessions:1m
                 header;
 }

アプリケーションでエラーが発生しやすく、失敗したリクエストをクライアントから同じアップストリームサーバーに再送信させたい場合、headerパラメーターが特に役立ちます。

注： Sticky-learnセッション永続化はNGINX Plusでのみ利用できます。

その他の機能

NGINX Plus R13では、以下の機能も追加されています。

HTTPトレーラー – add_trailerディレクティブを使用すると、任意のトレーラーをHTTPレスポンスの末尾に追加できます。トレーラーレスポンスヘッダーを使用すると、送信者はチャンク形式のメッセージの末尾に追加フィールドを含めることができます。これにより、メッセージ本文の送信中に動的に生成される可能性があるメタデータ（メッセージの整合性チェックやデジタル署名など）を提供できます。
Substitutions Filter動的モジュール – HTTP Substitutions Filterコミュニティ動的モジュールが新たにサポートされ、NGINX Plusディストリビューションに含まれるようになりました。このモジュールでは、レスポンス本文に正規表現と固定文字列の両方を使用した置換を適用できます。出力チェーンのバッファーをスキャンし、1行ずつ文字列を照合します。また、Dynamic Modulesページからもこのモジュールにアクセスできます。
ワーカープロセスの正常なシャットダウン – worker_shutdown_timeoutディレクティブを使用してタイムアウトを設定すると、ワーカープロセスの正常なシャットダウンをより迅速に完了できます。シャットダウンまたは再起動のシグナルを受信してからタイムアウト時間が経過すると、NGINX Plusは開いているすべてのクライアント接続を閉じようとします。

R13にアップグレードするか、NGINX Plusをお試しください

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

アップグレードを実行する前に、このブログ記事で説明している新機能と動作の変更点をよくご確認ください。

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