NGINX Plus R13 の発表

NGINX Plus リリース 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 で利用可能な多数のサードパーティ モジュール用のインストール可能なパッケージを作成します。

さらに、セッション永続性のためのスティッキー ラーニング メソッドの改善、HTTP トレーラーのサポート、HTTP 置換用の新しいサードパーティの動的モジュールなどの機能強化も行われます。

行動の変化

• 非推奨モジュール– アップストリーム グループの拡張ステータスと動的構成用の以前の API (Status モジュールとUpstream Confモジュール) は非推奨となり、統合されたNGINX Plus APIに置き換えられました。非推奨 API は、新しいNGINX Plus APIとともに、少なくとも 6 か月間は NGINX Plus に同梱されます。非推奨 API は、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 モジュールのディレクティブはサポートされなくなりました– ModSecurity のSecRequestBodyInMemoryLimitディレクティブはサポートされなくなりました。 ModSecurity モジュールは NGINX 構成で定義されたリクエスト本文の処理に従うため、このディレクティブを安全に削除できます。

  [編集者注– NGINX Plus 用のNGINX ModSecurity WAFモジュールは、 2022 年 4 月 1 日をもって正式に販売終了となり、 2024 年 3 月 31 日をもってサポート終了となります。 詳細については、弊社ブログの「F5 NGINX ModSecurity WAF はサポート終了に移行しています<.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 プラス API

NGINX Plus R13 には、単一のエンドポイントに統合された新しい REST API が含まれています。 以前のバージョンの NGINX Plus には、 Upstream Conf API とExtended Status API が別々に含まれていました。 新しい API は両方の機能を組み合わせ、動的構成のさまざまなユースケースで新しい Key-Value ストア モジュールもサポートします (以下のKey-Value ストアのセクションで説明します)。

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

server { listen 80;

location /api {
api write=on;
# 許可されたユーザーのみにアクセスを許可するディレクティブ
}
}

デフォルトでは、 NGINX Plus API はデータへの読み取り専用アクセスを提供します。 上流サーバーと新しいKey-Value Storeモジュールに変更を加えることができるように、読み取り/書き込みアクセスを有効にするには、 apiディレクティブにwrite=onパラメータを追加します。 特に読み取り/書き込みモードが有効になっている場合は、API へのアクセスを許可されたユーザーのみに制限することを強くお勧めします。

API エンドポイントから入手できるすべての種類の情報を表示するには、次のコマンドを実行します。

$ curl http://localhost:80/api/1/ ["nginx","プロセス","接続","ssl","スラブ","http","ストリーム"]

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

• 接続– 合計接続数の指標を表示

• http – HTTPトラフィックのメトリックを表示し、HTTPアップストリーム構成を変更します。

  httpには 2 つの「サブタイプ」もあります。

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

拡張ステータス監視

NGINX Plus は、NGINX Open Source で利用可能なものに加えて、40 を超える独自のメトリックを報告します。 NGINX Plus API を使用してこれらのメトリックにアクセスできるようになりました。API を使用して、重要なメトリックにアクセスします。

たとえば、URI に接続を追加すると、受け入れられた、アクティブな、ドロップされた、およびアイドル状態のクライアント接続の数を含む接続ステータスのスナップショットが出力されます。

$ 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 を有効にします。

アップストリーム バックエンド { ゾーン バックエンド 64k;
サーバー 10.10.10.2; 
サーバー 10.10.10.4;
}

サーバー {
listen 80;
サーバー名 www.example.org;

場所 /api {
api write=on;
}
}

バックエンドグループにサーバーを追加するには、 /api/1/http/upstreams/backend/serversへのcurlリクエストに-dオプションを含め、新しいサーバーの 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/servers HTTP/1.1 201 作成されました...

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

キーバリューストア

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

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

使用例の例:

• 動的 IP 拒否リスト ( NGINX Plus 管理者ガイドを参照)
• バックエンドサーバーへのURIのルーティング
• ユーザーごとに許可された URI のリストを管理する
• リダイレクトルールの管理（次の例を参照）

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

keyval_zone zone=redirects:1M state=state/redirects.json; # キーと値のペアをファイル keyval $uri $target zone=redirects; # $uri はキー、$target は値

server {
listen 80;

location /api {
api write=on; # NGINX Plus API を有効にします (本番環境ではこの場所を保護します)

}

if ($target) { # $uri が 'redirects' keyval ゾーンに存在する場合は True
return 301 $target; # クライアントを $uri に一致する値にリダイレクトします

}

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

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/redirects HTTP/1.1 201 作成されました...

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

$ curl -i http://localhost/conf HTTP/1.1 301 一時的に移動しました 場所: http://localhost/conf2017

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

$ curl -iX PATCH -d '{"/conf":"/conf2018"}' http://localhost/api/1/http/keyvals/redirects HTTP/1.1 204 コンテンツがありません...

keyvalディレクティブを使用してそれぞれに異なる共有メモリ ゾーンを定義することにより、複数の個別のキー値ストアを構成できます。 詳細については、 Key-Value Storeモジュールのリファレンス ドキュメントを参照してください。

Swagger ドキュメント

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

Swagger UI の対話型部分では、 NGINX Plus API を有効にする必要があります。これは、 conf.d/default.confファイルの/api/ location ブロックのコメントを解除することで実現できます。

# NGINX Plus API を利用するために、適切なアクセス制御で /api/ ロケーションを有効にします
#
#location /api/ {
# api write=on;
# allow 127.0.0.1;
# deny all;
#}

https://demo.nginx.com/swagger-ui/でNGINX Plus APIドキュメントを参照することもできます。

注記： 拡張ステータス メトリック、アップストリーム構成、新しい Key-Value ストア モジュールを含むNGINX Plus API全体は、NGINX Plus 専用です。

リクエストミラーリング

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

• 学習モードで展開すると、Web アプリケーション ファイアウォール (WAF) と統合されるため、本番トラフィックに影響を与えることなく、一般的なリクエスト パターンを分析できます。
• 実際の本番トラフィックを使用したリスクのないパフォーマンスチューニング
• ウェブサーバー間のファイルシステムの複製を避けるために、バックアップサーバーにファイルのアップロードを複製する

リクエストミラーリングを有効にしても、システム全体のスループットとパフォーマンスにはほとんど影響がありません。 次の構成スニペットは、新しいミラーディレクティブを使用してリクエストを複製し、別のアップストリーム サーバーに渡す方法を示しています。

場所 / { ミラー /mirror;
proxy_pass http://backend;
}

場所 /mirror {
内部;
proxy_pass http://test_backend$request_uri;
}

リクエストは、通常の処理のためにバックエンドのアップストリーム グループにプロキシされます。 これらは、元のリクエストの URI を保持したまま、 test_backendという名前の別のアップストリーム グループに複製され、プロキシされます。

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

NGINX JavaScript モジュールの機能強化

NGINX Plus R12で一般公開されて以来、NGINX JavaScript モジュール (旧称 nginScript) は、コア JavaScript 言語サポートによって拡張され続けています。 このリリースでは、16 進数 (0x7b など) と科学的記数法 (512e10 など) のサポートが導入されています。 Objectクラスのプリミティブ メソッドも実装されました。

NGINX JavaScript では、NGINX JavaScript コードの開発を支援するために、 njsコマンドで呼び出される対話型シェルも提供されるようになりました。

次のシェル スニペットは、NGINX JavaScript インタラクティブ シェルを入力し、最大 30 秒先のランダムな日付を生成する式を定義し、2 つの数値の合計を計算する方法を示しています。

$ njsインタラクティブ 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 バージョンとの依存関係を維持して尊重するビルド ツールを提供します。

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

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

より高速なスティッキーラーンセッション持続

セッション永続性は、NGINX Plus ロードバランシングの非常に便利な機能であり、特定のクライアントからのすべてのリクエストを 1 つのサーバーに送信できます。 セッションの永続性を確立する方法は複数あります。「スティッキー ラーニング」方式では、NGINX Plus は特定の Cookie の存在を探し、その Cookie がリクエストに含まれている場合は常にクライアントを同じサーバーに固定します。

NGINX Plus R13 では、完全な応答ペイロードが到着するまで待つのではなく、アップストリーム サーバーが応答のヘッダーを送信するとすぐにスティッキー セッションを確立できるようになりました。 したがって、NGINX Plus は、スティッキー セッションをできるだけ早くクライアントに送信できます。 新しいヘッダーパラメータをスティッキーラーニングディレクティブに含めます。

アップストリーム バックエンド { ゾーン バックエンド 64k;
サーバー 10.10.10.2; 
サーバー 10.10.10.4;

スティッキー ラーニング create=$upstream_cookie_sessionid
lookup=$cookie_sessionid
ゾーン=client_sessions:1m
ヘッダー;
}

ヘッダーパラメータは、アプリケーションがエラーを起こしやすく、クライアントが失敗したリクエストを同じアップストリーム サーバーに再送信する場合に特に便利です。

注記： スティッキーラーン セッション永続性は、NGINX Plus 専用です。

追加機能

NGINX Plus R13 では、次の追加機能が導入されています。

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

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

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

アップグレードを進める前に、このブログ投稿に記載されている新機能と動作の変更をよく確認してください。

NGINX Plus をまだお試しいただいていない方は、Web アクセラレーション、負荷分散、アプリケーション配信、または強化された監視および管理 API を備えた完全にサポートされた Web サーバーとして、ぜひお試しいただくことをお勧めします。 今すぐ30 日間の無料評価版を始めて、NGINX Plus がアプリケーションの配信とスケールアウトにどのように役立つかを実際に確認することができます。