NGINX Plus R31リリースのお知らせ

Prabhat Dixit

NGINX Plus Release 31（R31）の提供開始をお知らせします。NGINX Open SourceをベースとするNGINX Plusは、Webサーバー、ロードバランサー、リバースプロキシ、コンテンツキャッシュ、APIゲートウェイの機能をオールインワンで提供する唯一のソフトウェアです。

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

• ネイティブのNGINX使用状況レポート – NGINX Plusは、組織全体のNGINXデプロイに関するレポートをネイティブでサポートするようになりました。これにより、NGINX Instance ManagerでNGINXインフラストラクチャを一元的に把握できます。この機能により、コンプライアンスを目的としたNGINXインスタンスのガバナンスを強化できます。
• SNI設定の機能強化 – 従来、Server Name Identification（SNI）で渡されるサーバー名にはproxy_ssl_nameディレクティブが使用され、アップストリームグループ内のすべてのサーバーで共通して使用されていました。NGINX Plus R31では、このSNIを選択したアップストリームサーバーに設定できます。
• NGINX JavaScriptによる定期的なタスク実行 – NGINX JavaScriptに、コンテンツを一定間隔で実行できるjs_periodicディレクティブが導入されました。この機能強化により、cronジョブを設定する必要がなくなります。また、パフォーマンスを最適化するため、すべてのワーカープロセスまたは特定のワーカープロセスで実行するように設定できます。
• NGINXの起動エクスペリエンスを向上 – NGINX Plus R31では、構成内に多数の「location」がある場合のNGINX全体の起動エクスペリエンスが向上しています。
• QUIC+HTTP/3の最適化と改善 – NGINX Plus R31では、パス最大転送単位（MTU）探索のサポート、輻輳制御の改善、QUICセッション全体で暗号化コンテキストを再利用する機能など、QUIC実装に多くの機能強化とパフォーマンス最適化が加えられています。

このリリースには、NGINX Open Sourceから継承された新機能とバグ修正、および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 Instance Managerに報告する機能が標準で搭載され、デフォルトで有効になっています。何らかの理由でNGINXインスタンスが使用状況の情報をNGINX Instance Managerに提供できない場合は、警告メッセージがログに記録されます。

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

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

新たにサポートされるオペレーティングシステム：

• FreeBSD 14
• Alpine 3.19

削除された旧バージョンのオペレーティングシステム：

• 2023 年 11 月 1 日にサポート終了（EOL）となったAlpine 3.15

非推奨となり、NGINX Plus R32で削除予定の旧バージョンのオペレーティングシステム：

• 2023年12月31日にEOLを迎えるFreeBSD 12

新機能の詳細

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

NGINX Plus R31では、ネットワーク上のNGINX Instance Managerとのネイティブ通信により、ライセンスコンプライアンスを自動化できます。F5 Flex Consumption Programに参加している場合、NGINX Plusインスタンスを手動で追跡する必要がなくなります。

デフォルトでは、NGINX Plusは起動時にnginx-mgmt.localホスト名をDNSで検索し、NGINX Instance Managerの検出を試みます。ホスト名は設定可能ですが、簡単に構成するには、ローカルDNSにAレコードを追加し、デフォルトのホスト名をNGINX Instance Managerが稼働しているシステムのIPアドレスに関連付けることを推奨します。その後、NGINX PlusはNGINX Instance ManagerへのTLS接続を確立し、バージョン番号、ホスト名、一意の識別子を30分ごとに報告します。

セキュリティをさらに強化するため、オプションの「mgmt」設定ブロックを使用して、この接続にmTLSを設定することも推奨します。設定後、NGINX Instance ManagerはNGINX Plusインスタンスの総使用量を定期的にF5サービスへ報告します。

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

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

2023/12/21 21:02:01 [warn] 3050#3050: usage report: host not found resolving endpoint "nginx-mgmt.local”

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

2023/12/21 21:02:01 [warn] 3184#3184: usage report: connection timed out

Customizing the mgmt設定ブロックのカスタマイズ

NGINX PlusインスタンスとNGINX Instance Managerとの通信方法を細かく調整する場合は、新しいmgmt設定ブロックと関連ディレクティブを使用できます。これにより、カスタムリゾルバーの定義、IPアドレスまたは別のホスト名によるNGINX Instance Managerシステムの識別、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 Instance Managerのダウンロードとインストールの詳細については、インストールガイドを参照してください。

注：以前のバージョンのNGINX Plusを使用している場合でも、こちらの手順に従ってインスタンスを報告できます。

SNI設定の機能強化

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

ただし、この動作では不十分な場合があります。たとえば、1台のアップストリームサーバーの背後で複数の仮想サーバーを共有し、特定のリソースにリクエストをルーティングするために、異なるSNIやHostヘッダーで仮想サーバーを識別する必要がある場合です。また、アップストリームグループ内のすべてのサーバーで同じ証明書を使用できない場合や、アップストリームサーバーを別々のアップストリームグループに分けることに制約がある場合もあります。

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 on;

また、選択したアップストリームサーバー名を渡すには、proxy_ssl_nameを次のように使用します：
proxy_ssl_name $upstream_last_server_name;

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

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

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

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

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 docsをご参照ください。

NGINXの起動エクスペリエンスを向上

NGINXの設定に多数の「location」が含まれている場合、NGINXの起動にかなりの時間がかかることがあります。多くの場合、これは許容できない可能性があります。根本的な問題は、locationのリストを並べ替えるために使用されるソートアルゴリズムにあります。

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

20,000個のlocationを含むテスト構成では、この更新後、全体の起動時間が8秒から0.9秒に短縮されたことが確認されました。

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

NGINX Plus R31では、QUIC+HTTP/3実装に対して、以下のような機能強化とパフォーマンス最適化が行われています。

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

その他のパフォーマンス最適化には、確認応答パケット送信時に発生し得る遅延の低減、確認応答（ACK）フレームをキューの先頭に配置することによるフレームの再送およびACKフレーム配信の遅延の低減、Generic Segmentation Offload（GSO）モードにおける輻輳制御動作の改善が含まれます。

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

追加の「mgmt」モジュール

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

このモジュールには、NGINXインスタンスとNGINX Instance Manager間の通信を細かく調整するためのディレクティブが複数用意されています。利用可能なディレクティブと設定オプションの完全な一覧については、NGINX Docsを参照してください。

MQTTモジュールのバグ修正

Message Queuing Telemetry Transport（MQTT）のサポートはNGINX Plus R29で導入されました。このリリースには、MQTTモジュールで確認された問題に対する複数のバグ修正が含まれています。

重要な修正の1つでは、パスワードが指定されていない場合にCONNECTメッセージが拒否される問題に対処しています。以前は、ユーザー名フィールドの後には必ずパスワードが続くものと想定していました。しかし、MQTT仕様では、匿名認証など、パスワードの指定が必須ではない特殊なケースがあります。この修正では、パケットのcflagsフィールドを参照し、パスワードが必要かどうかを条件に応じて確認します。フラグが設定されていない場合、パスワードは必須ではないことを示します。

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

HTTP/3「server_tokens」での変数のサポート

NGINX Plus R31では、HTTP/3接続で未対応だったserver_tokens変数がサポートされます。stringフィールドを使用すると、エラーページの署名と「Server」レスポンスヘッダーフィールドの値を明示的に設定できます。stringフィールドが空の場合、「Server」フィールドは送信されません。

NGINX Open Sourceから継承された変更

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

機能

• QUIC使用時のパスMTU探索 – 従来は、すべてのデータグラムにデフォルトのMTUサイズとして1200が使用されていました。QUIC+HTTP/3の改善の一環として、パスMTUサイズを探索し、すべての送信データグラムに適用する機能を追加しました。
• QUICのパフォーマンス最適化 – NGINXメインラインバージョン1.25.2では、QUICセッション全体で暗号化コンテキストを再利用するようにQUIC実装が最適化されました。これにより、ACKパケットの送信遅延が短縮され、ACKフレームがキューの先頭に配置されるため、フレームの再送とACKフレームの配信遅延が軽減されます。
• HTTP/3使用時のTLS_AES_128_CCM_SHA256暗号スイートのサポート – この機能強化により、QUICでTLS_AES_128_CCM_SHA256がサポートされます。これは現在、NGINX 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が定義され、真であるかをテストするようになりました。これにより、追加のライブラリ初期化設定（特にOPENSSL_INIT_set_config_appname()呼び出し）が提供されていないBoringSSLおよびLibreSSLでは、このインターフェースが使用されなくなります。

変更点

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

バグ修正

• HTTP/2自動検出時のバッファ管理を修正 – プレーンTCP接続でHTTP/2を自動検出する際、初期データはまず、状態保存用の領域が確保されていないclient_header_buffer_sizeディレクティブで指定されたバッファに読み込まれます。このため、状態の保存時にバッファの範囲を超えて読み取る可能性がありました。今回の修正により、固定バッファサイズではなく、利用可能なバッファサイズの範囲内でのみ読み取るようになりました。このバグは、NGINXメインラインバージョン1.25.1（NGINX Plus R30）で初めて発生しました。
• OpenSSL互換モードでの不正なトランスポートモード – このリリースより前は、クライアントから不正なトランスポートパラメーターが送信されると、OpenSSL Compatibility Layerによって接続に遅延が発生していました。この修正により、まず不正なパラメーターについてユーザーに通知し、その後接続を閉じることで、この動作を円滑に処理できるようになりました。
• 理由フレーズのないtatusヘッダーの処理を修正 – 「理由フレーズ」が空のステータスヘッダー（例：Status: 404）は、Common Gateway Interface（CGI）仕様では有効でしたが、解析時に末尾のスペースが失われていました。その結果、レスポンスにHTTP/1.1 404というステータス行が生成され、末尾にスペースがないためHTTP仕様に違反していました。このバグ修正により、このような短いStatusヘッダー行からはステータスコードのみが使用されるため、NGINXがスペースを含むステータス行を生成し、該当する理由フレーズがある場合はそれも付加します。
• PCRE2使用時の設定再読み込みに伴うメモリリークを修正 – この問題は、バージョン1.21.5以降のNGINXでPCRE2を使用するよう設定した場合に発生していました。

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

NGINX JavaScript Moduleの変更点

NGINX Plus R31には、NGINX JavaScript（njs）モジュールのバージョン0.8.2での変更が取り込まれています。以下は、NGINX Plus R30に含まれていたバージョン0.8.0以降のnjsにおける主な変更点です。

機能

• consoleオブジェクトが導入されました。次のメソッドが導入されました：error()、info()、log()、time()、timeEnd()、warn()。
• Introduced the js_periodicディレクティブをhttpおよびstream向けに導入しました。これにより、一定間隔で実行するJSハンドラーを指定できます。
• Implemented items()メソッドを共有ディクショナリに実装しました。このメソッドは、有効期限が切れていないすべてのキーと値のペアを返します。

変更点

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

バグ修正

• 「xml」モジュールを修正しました。parse()メソッドで正常に機能していなかったXML例外処理を修正しました。
• グローバル正規表現（regexp）とUnicode入力を使用した場合のRegExp.prototype.exec()の問題を修正しました。
• Fixed size()とkeys()（共有ディクショナリのメソッド）を修正しました。
• 0.8.0で導入された、r.internalRedirect()の誤った例外を修正しました。
• キーの順序が正しくない問題を修正しました（Object.getOwnPropertyNames()）。
• fetch APIでContent-Lengthが大きい場合のHEADレスポンス処理を修正しました。
• 共有ディクショナリのitems()メソッドを修正しました。

すべての機能、変更、バグ修正の包括的な一覧については、njsの「変更履歴」を参照してください。

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

NGINX Plusをご利用の場合は、できるだけ早くNGINX Plus R31へアップグレードすることを強く推奨します。優れた新機能に加えて、複数の修正や改善も適用されます。また、最新の状態に保つことで、サポートチケットを起票する必要が生じた際に、NGINXによるサポートを受けやすくなります。

NGINX Plusをまだお試しでない場合は、ぜひご検討ください。セキュリティ、負荷分散、APIゲートウェイのユースケースに利用できるほか、強化された監視・管理APIを備え、充実したサポートを受けられるWebサーバーとしても利用できます。今すぐ30日間の無料トライアルを開始してください。

著者について

Prabhat Dixit

Prabhat Dixitのその他のブログ記事