NGINX Plus R31 リリース

NGINX Plus Release 31（R31）の提供を開始することをお知らせします。NGINX PlusはNGINXオープンソースをベースにした唯一のオールインワンソフトウェア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では、構成に「ロケーション」が多数ある場合の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 Instance Managerに報告する機能がネイティブで提供され、デフォルトで有効になっています。NGINXインスタンスが使用状況に関する情報を何らかの理由でNGINX Instance Managerに提供できない場合、警告メッセージがログに記録されます。

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

プラットフォーム対応の変更

以下のオペレーティングシステムが新たにサポートされます。

• FreeBSD 14
• Alpine 3.19

以下のオペレーティングシステムはサポート対象外となります。

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

以下のオペレーティングシステムはNGINX Plus R32でサポート対象外となる予定です。

• FreeBSD 12（2023年12月31日にサポート終了予定）

新機能の詳細

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

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

デフォルトではNGINX Plusは起動時にnginx-mgmt.localホスト名のDNSルックアップを介してNGINX Instance Managerの検出を試みます。このホスト名は設定可能ですが、（わかりやすいように）AレコードをローカルDNSに追加し、デフォルトのホスト名と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

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は、アップストリームグループ内のすべてのサーバーが同一であることを前提としていました。つまり、これらのサーバーは同じリクエストに答え、同じ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 on;

また、以下に、proxy_ssl_nameを使用して選択したアップストリームサーバー名を渡す方法を示します。
proxy_ssl_name $upstream_last_server_name;

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

NGINX JavaScript v0.8.1では、httpとstreamの両方のコンテキストで利用できる新しいディレクティブjs_periodicが導入されました。このディレクティブは定期的な間隔で実行する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のドキュメントを参照してください。

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の実装はすべてのデータグラムに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のドキュメントを参照してください。

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」レスポンスヘッダーフィールド値を明示的に設定できます。文字列フィールドが空の場合、「Server」フィールドの値が無効になります。

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

NGINX Plus R31は、NGINXオープンソース1.25.3をベースとしていて、NGINX Plus R30のリリース以降（NGINX 1.25.2および1.25.3）に行われた機能変更、機能、およびバグ修正を継承しています。

機能

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

変更点

• 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からの変更点が含まれています。以下に、NGINX Plus R30でリリースされた0.8.0以降のnjsにおける主な変更点を示します。

機能

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

変更点

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

バグ修正

• 「xml」モジュールを修正しました。parse()メソッドにおける壊れたXMLの例外の処理を修正しました。
• グローバル正規表現（regexp）とUnicode入力を含むRegExp.prototype.exec()を修正しました。
• SharedDictのsize()およびkeys()メソッドを修正しました。
• 0.8.0で導入されたr.internalRedirect()のエラー例外を修正しました。
• Object.getOwnPropertyNames()の正しくないキー順序を修正しました。
• フェッチAPIでContent-Lengthが大きいHEADレスポンスの処理を修正しました。
• SharedDictのitems()メソッドを修正しました。

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

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

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

NGINX Plusをまだお試しでない方は、ぜひお試しください。セキュリティ、ロードバランシング、APIゲートウェイのユースケースとして、またはモニタリングと管理APIが強化された完全サポートのWebサーバーとして使用できます。30日間の無料トライアルで、今すぐ始めることができます。