NGINX Plus R31 の発表

NGINX Plus リリース 31 (R31) が利用可能になったことをお知らせいたします。 NGINX オープンソースをベースにした NGINXPlus は、唯一のオールインワン ソフトウェア Web サーバー、ロード バランサー、リバース プロキシ、コンテンツ キャッシュ、API ゲートウェイです。

NGINX Plus R31 の新機能と強化された機能は次のとおりです。

• ネイティブ NGINX 使用状況レポート– NGINX Plus では、組織全体の NGINX 展開に関するレポートをネイティブにサポートするようになり、NGINX インスタンス マネージャーで NGINX インフラストラクチャを統合的に表示できるようになりました。 この機能により、コンプライアンス目的で NGINX インスタンスのガバナンスを強化できます。
• SNI 構成の機能強化– 以前は、サーバー名識別 (SNI) を通過するサーバー名は proxy_ssl_name ディレクティブを使用し、アップストリーム グループ内のすべてのサーバーで使用されていました。 NGINX Plus R31 では、この SNI を選択したアップストリーム サーバーに設定できます。
• NGINX JavaScript による定期的なタスク実行– NGINX JavaScript では、コンテンツを定期的に実行できるようにする js_periodic ディレクティブが導入されています。 この機能強化により、cron ジョブを設定する必要がなくなり、最適なパフォーマンスを得るためにすべてのワーカー プロセスまたは特定のワーカー プロセスで実行するように構成できるようになります。
• より優れた NGINX 起動エクスペリエンス- NGINX Plus R31 では、構成内に多数の「場所」がある場合の全体的な NGINX 起動エクスペリエンスが向上しています。
• QUIC + HTTP/3 の最適化と改善– NGINX Plus R31 では、パス最大転送単位 (MTU) 検出のサポート、輻輳制御の改善、QUIC セッション全体での暗号化コンテキストの再利用機能など、QUIC 実装に多くの機能強化とパフォーマンスの最適化が追加されています。

このリリースの最後を飾るのは、NGINX オープンソースから継承された新機能とバグ修正、および NGINX JavaScript モジュールの更新です。

行動における重要な変化

注記： NGINX Plus R30 以外のリリースからアップグレードする場合は、現在のバージョンとこのバージョン間のすべてのリリースについて、以前の発表ブログの「動作の重要な変更」セクションを必ず確認してください。

OpenTracing モジュールの廃止

NGINX Plus R18 で導入された OpenTracing モジュールは廃止される予定です。 これは、NGINX Plus R34 の将来のリリースから削除される予定です。 それまでの間、このパッケージはすべての NGINX Plus リリースで利用可能になります。 NGINX Plus R29 で導入されたOpenTelemetry モジュールを使用することを強くお勧めします。

NGINX の使用状況を報告しない場合の警告メッセージ

NGINX Plus ユーザーは、コンプライアンス上の理由から、NGINX の使用状況を F5 に報告する必要があります。 NGINX Plus R31 のリリースにより、NGINX の使用状況をNGINX インスタンス マネージャーに報告する機能がネイティブに提供され、デフォルトで有効になっています。 何らかの理由で NGINX インスタンスが NGINX インスタンス マネージャーに使用状況情報を提供できない場合は、警告メッセージが記録されます。

ご使用の環境でこの機能を構成する方法の詳細については、 「ネイティブ NGINX 使用状況レポート」セクションを参照してください。

プラットフォームサポートの変更

サポートされる新しいオペレーティング システム:

• フリーBSD 14
• アルパイン 3.19

削除された古いオペレーティング システム:

• Alpine 3.15は、2023年11月1日にサポート終了（EOL）を迎えました。

NGINX Plus R32 で非推奨となり削除が予定されている古いオペレーティング システム:

• FreeBSD 12 は 2023 年 12 月 31 日に EOL を迎えます

新機能の詳細

ネイティブ NGINX 使用状況レポート

NGINX Plus R31 では、ネットワーク上の NGINX インスタンス マネージャーとのネイティブ通信が導入され、ライセンス コンプライアンスが自動化されます。 F5 Flex Consumption Programに参加すると、NGINX Plus インスタンスを手動で追跡する必要がなくなります。

デフォルトでは、NGINX Plus は起動時にnginx-mgmt.localホスト名の DNS ルックアップを介して NGINX インスタンス マネージャーを検出しようとします。 ホスト名は設定可能ですが、(簡単にするために) ローカル DNS に A レコードを追加し、デフォルトのホスト名を NGINX インスタンス マネージャーを実行しているシステムの IP アドレスに関連付けることをお勧めします。 その後、NGINX Plus は NGINX インスタンス マネージャーへの TLS 接続を確立し、バージョン番号、ホスト名、一意の識別子を 30 分ごとに報告します。

セキュリティをさらに強化するために、オプションのmgmt構成ブロックを使用して、この接続を mTLS でプロビジョニングすることもお勧めします。 NGINX インスタンス マネージャーは、定期的に、NGINX Plus インスタンスの合計使用量を F5 サービスに報告します。

NGINX Plus でnginx-mgmt.localホスト名の解決または NGINX インスタンス マネージャーとの通信に問題が発生した場合、エラー ログに警告メッセージが表示されます。

これは、NGINX Plus インスタンスがnginx-mgmt.localを解決できないことを示すエラー メッセージの例です。

2023/12/21 21:02:01 [警告] 3050#3050: 使用状況レポート: エンドポイント「nginx-mgmt.local」を解決するホストが見つかりません

以下は、NGINX Plus インスタンスが NGINX インスタンス マネージャーとの通信に問題が発生していることを示すエラー メッセージの例です。

2023/12/21 21:02:01 [警告] 3184#3184: 使用状況レポート: 接続がタイムアウトしました

mgmt構成ブロック設定のカスタマイズ

NGINX Plus インスタンスが NGINX インスタンス マネージャーと通信する方法を微調整したい場合は、新しいmgmt構成ブロックと関連するディレクティブを使用することを選択できます。 これにより、カスタム リゾルバを定義し、IP アドレスまたは代替ホスト名を使用して NGINX インスタンス マネージャー システムを識別し、TLS オプションを指定し、セキュリティ強化のために mTLS を使用し、その他のカスタム パラメータを指定できるようになります。

以下はカスタム構成のサンプルです。

mgmt {
    usage_report endpoint=instance-manager.local interval=30m;
    resolver 192.168.0.2; # Sample internal DNS IP

    uuid_file /var/lib/nginx/nginx.id;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers DEFAULT;

    ssl_certificate          client.pem;
    ssl_certificate_key      client.key;

    ssl_trusted_certificate  trusted_ca_cert.crt;
    ssl_verify               on;
    ssl_verify_depth         2;
}

これらのディレクティブの詳細については、製品ドキュメントを参照してください。

NGINX インスタンス マネージャーのダウンロードとインストールの詳細については、インストール ガイドを参照してください。

注記： 以前のバージョンの NGINX Plus を使用している場合でも、次の手順に従ってインスタンスをレポートできます。

SNI 構成の強化

このリリースより前は、NGINX Plus はアップストリーム グループ内のすべてのサーバーが同一であると想定していました。 つまり、同じリクエストに応答し、同じ SNI 名 ( proxy_ssl_server_nameが使用されている場合) に応答し、同じ名前に一致する SSL 証明書を返すことができる必要がありました。

ただし、この動作では不十分なシナリオが存在します。 たとえば、アップストリーム サーバーの背後で複数の仮想サーバーが共有されており、特定のリソースにリクエストをルーティングするために異なる SNI やホスト ヘッダーで区別する必要がある場合などです。 また、アップストリーム グループ内のすべてのサーバーで同じ証明書を使用できない場合や、アップストリーム サーバーを別のアップストリーム グループに配置する際に制限がある場合もあります。

NGINX Plus R31 では、アップストリーム サーバーごとに構成できる SNI のサポートが導入されました。 変数$upstream_last_server_nameは、選択されたアップストリーム サーバーの名前を参照します。この名前は、 proxy_ssl_server_nameおよびproxy_ssl_nameディレクティブを使用してプロキシ サーバーに渡すことができます。

proxy_ssl_server_name をonに設定して、サーバー名が SNI を通過できるようにする方法は次のとおりです。
proxy_ssl_server_name をオンにします。

proxy_ssl_nameを使用して選択したアップストリーム サーバー名を渡す方法は次のとおりです。
proxy_ssl_name $アップストリームの最後のサーバー名;

NGINX JavaScript による定期的なタスク実行

NGINX JavaScript v0.8.1 では、 http コンテキストとstreamコンテキストの両方で使用できる新しいディレクティブjs_periodicが導入されました。 このディレクティブを使用すると、JavaScript コンテンツ ハンドラーを定期的に実行する指定ができます。 これは、カスタム コードを定期的に実行する必要があり、NGINX 変数にアクセスする必要がある場合に役立ちます。 コンテンツ ハンドラーは、セッション オブジェクトを引数として受け取り、グローバル オブジェクトにもアクセスできます。

デフォルトでは、コンテンツ ハンドラーはワーカー プロセス 0 で実行されますが、特定のワーカー プロセスまたはすべてのワーカー プロセスで実行されるように構成できます。

このディレクティブは、場所のコンテキストで使用できます。

example.conf:

location @periodics {

    # to be run at 15 minute intervals in worker processes 1 and 3
    js_periodic main.handler interval=900s worker_affinity=0101;

    resolver 10.0.0.1;
    js_fetch_trusted_certificate /path/to/certificate.pem;
}

example.js:

async function handler(s) {
    let reply = await ngx.fetch('https://nginx.org/en/docs/njs/');
    let body = await reply.text();

    ngx.log(ngx.INFO, body);
}

構文と設定の詳細については、 NGINX JavaScript ドキュメントを参照してください。

より優れたNGINXスタートアップエクスペリエンス

NGINX 構成に多数の「場所」が含まれているシナリオでは、NGINX の起動にかなりの時間がかかる可能性があります。 多くの場合、これは受け入れられないかもしれません。 根本的な問題は、場所のリストを並べ替えるために使用される並べ替えアルゴリズムにあります。

NGINX R31 では、既存のソートアルゴリズムを、時間計算量がO(n2)の挿入ソートから、時間計算量が O(n*log n)のマージソートに置き換える機能強化が導入されています。

20,000 の場所のテスト構成では、この更新後に合計起動時間が 8 秒から 0.9 秒に短縮されたことが確認されました。

QUIC+HTTP/3 の最適化と改善

NGINX Plus R31 では、QUIC + HTTP/3 実装に次のようないくつかの機能強化とパフォーマンスの最適化が導入されています。

• QUIC + HTTP/3 使用時のパス最大転送単位 (MTU) 検出– パス MTU は、ネットワーク経由で送信できる最大サイズのフレームまたはデータ パケットのバイト単位の測定値です。 この変更の前は、QUIC 実装ではすべてのデータグラムに対して 1200 バイトのパス MTU を使用していました。 NGINX Plus では、すべての送信データグラムに使用されるパス MTU サイズの検出がサポートされるようになりました。
• QUIC セッション全体で暗号化コンテキストを再利用– この最適化は、QUIC パケットの暗号化と復号化の動作に関係します。 以前は、暗号化または復号化操作ごとに個別の暗号化コンテキストが作成されていました。 これで、QUIC セッション全体で同じコンテキストが使用されるようになり、パフォーマンスが向上します。

追加のパフォーマンス最適化には、確認応答パケットの送信時に発生する可能性のある遅延の削減、確認応答 (ACK) フレームをキューの先頭に配置してフレームの再送信と ACK フレームの配信の遅延を削減すること、および汎用セグメンテーション オフロード (GSO) モードでの輻輳制御動作の改善が含まれます。

NGINX Plus R31 のその他の機能強化とバグ修正

追加の管理モジュール

NGINX Plus R31 では、 ngx_mgmt_module を使用すると、NGINX の使用状況情報を NGINX インスタンス マネージャーに報告できます。 この情報には、NGINX ホスト名、NGINX バージョン、一意のインスタンスの識別子が含まれます。

このモジュールは、NGINX インスタンスが NGINX インスタンス マネージャーと通信する方法を微調整するためのいくつかのディレクティブを提供します。 利用可能なディレクティブと設定オプションの完全なリストについては、 NGINX Docsを参照してください。

MQTT モジュールのバグ修正

メッセージ キューイング テレメトリ トランスポート (MQTT) サポートはNGINX Plus R29 で導入され、このリリースには MQTT モジュールで確認された問題に対するいくつかのバグ修正が含まれています。

重要な修正の 1 つは、パスワードが提供されなかった場合に CONNECT メッセージが拒否される問題に対処することです。 以前は、ユーザー名フィールドの後にパスワードが続くことが無条件に想定されていました。 ただし、MQTT 仕様には、匿名認証など、パスワードの提供が必須ではない特別なケースがあります。 この修正では、パケットのcflagsフィールドを調べて、パスワードが期待されているかどうかを条件付きでチェックします。 フラグが設定されていない場合は、パスワードが必須ではないことを意味します。

別のバグ修正では、メッセージの長さが受信したバイト数より少ない場合に MQTT CONNECT メッセージの解析が停止されます。

変数による HTTP/3 server_tokensのサポート

NGINX Plus R31 では、HTTP/3 接続で不足しているserver_tokens変数のサポートが追加されました。 文字列フィールドを使用すると、エラー ページの署名と「Server」応答ヘッダー フィールドの値を明示的に設定できます。 文字列フィールドが空の場合、「Server」フィールドの発行が無効になります。

NGINXオープンソースから継承された変更

NGINX Plus R31 は NGINX Open Source 1.25.3 をベースとしており、NGINX Plus R30 のリリース以降 (NGINX 1.25.2 および 1.25.3) に行われた機能変更、特徴、バグ修正を継承しています。

特徴

• QUIC 使用時のパス MTU 検出- 以前は、すべてのデータグラムにデフォルト サイズ 1200 MTU が使用されていました。 QUIC+HTTP/3 の改善の一環として、すべての送信データグラムに使用されるパス MTU サイズを検出するサポートを追加しました。
• QUIC のパフォーマンス最適化– NGINX メインライン バージョン 1.25.2 では、QUIC セッション全体の暗号化コンテキストを再利用するために、QUIC 実装の最適化が導入されました。 これにより、ACK パケットの送信の遅延が短縮され、ACK フレームがキューの先頭に配置され、フレームの再送信と ACK フレームの配信の遅延が軽減されます。
• HTTP/3 使用時のTLS_AES_128_CCM_SHA256暗号スイートのサポート– この機能強化により、現在 NGINX QUIC 実装でサポートされていない唯一の暗号スイートであるTLS_AES_128_CCM_SHA256サポートが QUIC に追加されます。 OpenSSL ではデフォルトで無効になっていますが、次のディレクティブで有効にできます: ssl_conf_command Ciphersuites TLS_AES_128_CCM_SHA256;
• OpenSSL 構成の読み込み中にnginx appName を提供します– OPENSSL_init_ssl()インターフェイスを使用する場合、NGINX はOPENSSL_VERSION_NUMBERをチェックする代わりに、 OPENSSL_INIT_LOAD_CONFIGが定義され、true であるかどうかをテストするようになりました。 これにより、BoringSSL および LibreSSL では追加のライブラリ初期化設定 (特に、 OPENSSL_INIT_set_config_appname()呼び出し) が提供されないため、このインターフェースがこれらのサーバーで使用されなくなります。

変更点

• NGINX キュー ソート アルゴリズムの変更– 上で詳述したように、NGINX では現在、時間計算量がO(n*log n)のマージ ソートを使用しています。 これにより、特に構成内の「場所」の数が非常に多い場合に、 NGINX の起動エクスペリエンスが向上します。
• HTTP/2 反復ストリーム処理制限– この改善により、1 つのイベント ループで導入できる新しいストリームの数に制限を課すことで、NGINX に対するフラッド攻撃の早期検出が保証されます。 この制限は値の 2 倍であり、 http2_max_concurrent_streamsを使用して構成されます。 リクエストの送信直後にストリームがリセットされる場合を考慮して、許可される同時ストリームの最大しきい値に達しない場合でも適用されます。

バグ修正

• HTTP/2 自動検出によるバッファ管理の修正- プレーン TCP 接続での HTTP/2 自動検出の一環として、初期データはまず、状態予約のないclient_header_buffer_sizeディレクティブで指定されたバッファに読み込まれます。 これにより、状態を保存中にバッファが読み取られる可能性があるという問題が発生しました。 現在の修正により、固定バッファ サイズではなく、使用可能なバッファ サイズのみを読み取ることができるようになりました。 このバグは、NGINX メインライン バージョン 1.25.1 (NGINX Plus R30) で初めて発生しました。
• OpenSSL 互換モードでの不正なトランスポート モード- このリリースより前では、クライアントによって不正なトランスポート パラメータが送信された場合、OpenSSL 互換レイヤーによって接続が遅延していました。 この修正では、まずユーザーに誤ったパラメータを通知し、その後接続を閉じることで、この動作を簡単に処理します。
• 理由フレーズのないステータス ヘッダーの処理を修正しました- Status のような空の「理由フレーズ」を持つステータス ヘッダー: 404 はCommon Gateway Interface (CGI) 仕様では有効ですが、解析中に末尾のスペースが失われました。 この結果、応答にHTTP/1.1 404ステータス ラインが生成されましたが、末尾のスペースが欠落しているため HTTP 仕様に違反しています。 このバグ修正により、このような短いステータス ヘッダー行からはステータス コードのみが使用されるようになり、NGINX は、スペースと適切な理由フレーズ (使用可能な場合) を含むステータス行自体を生成します。
• PCRE2 を使用した構成の再読み込み時のメモリ リークを修正しました- この問題は、NGINX がバージョン 1.21.5 以降で PCRE2 を使用するように構成されている場合に発生しました。

最近のリリースから継承された新しい変更、機能、バグ修正、回避策の完全なリストについては、NGINX CHANGESファイルを参照してください。

NGINX JavaScript モジュールの変更

NGINX Plus R31 には、NGINX JavaScript (njs) モジュール バージョン 0.8.2 からの変更が組み込まれています。 以下は、0.8.0 (NGINX Plus R30 リリースの一部) 以降の njs の注目すべき変更点のリストです。

特徴

• コンソール オブジェクトを導入しました。 導入されたメソッド: error() 、 info() 、 log() 、 time() 、 timeEnd() 、 warn() 。
• 定期的に実行される JS ハンドラーを指定できる、 httpおよびストリーム用のjs_periodicディレクティブを導入しました。
• 共有辞書のitems()メソッドを実装しました。 このメソッドは、期限切れでないすべてのキーと値のペアを返します。

変更点

• 「fs」モジュールを拡張しました。 existsSync()メソッドを追加しました。

バグ修正

• 「xml」モジュールを修正しました。 parse()メソッドでの壊れた XML 例外処理を修正しました。
• グローバル正規表現 (regexp) と Unicode 入力を使用したRegExp.prototype.exec() を修正しました。
• 共有辞書のsize()およびkeys()メソッドを修正しました。
• 0.8.0 で導入されたr.internalRedirect()の誤った例外を修正しました。
• Object.getOwnPropertyNames()内のキーの誤った順序を修正しました。
• フェッチ API での大きな Content-Length による HEAD 応答の処理を修正しました。
• 共有辞書のitems()メソッドを修正しました。

すべての機能、変更、バグ修正の包括的なリストについては、njs変更ログを参照してください。

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

NGINX Plus を実行している場合は、できるだけ早く NGINX Plus R31 にアップグレードすることを強くお勧めします。 素晴らしい新機能に加えて、いくつかの追加の修正と改善も得られます。最新の状態にしておくと、サポート チケットを発行する必要がある場合に NGINX がサポートしやすくなります。

NGINX Plus をまだお試しいただいていない方は、ぜひお試しください。 セキュリティ、負荷分散、API ゲートウェイのユースケースに使用したり、強化された監視および管理 API を備えた完全にサポートされた Web サーバーとして使用したりできます。 今すぐ30 日間の無料トライアルを始めましょう。