NGINX Plus R27の発表

NGINX Plus Release 27 (R27)の提供を開始することをお知らせします。NGINX Plusは、NGINXオープンソースをベースにした、唯一のオールインワン・ソフトウェアWebサーバー、ロードバランサー、リバースプロキシ、コンテンツキャッシュ、およびAPIゲートウェイです。

NGINX Plus R27の新機能は以下の通りです。

• Health Check の Keepalive connection – 以前のリリースでは NGINX Plus はすべてのHealth Checkで新しいコネクションを確立していました。新たな keepalive_time パラメータにより、HTTP health_check ディレクティブで指定した期間コネクションを維持することができます。新規コネクションを確立する場合にはリソースが消費されるため、それらに関する大量のアップストリームサーバーを利用する場合に、大幅にCPUリソースを軽減することができます。
• Kernel TLSのサポート – NGINX Plus はKernel TLS (kTLS) の提供に関する条件を満たす３つのOS：FreeBSD 13、RHEL 9.0+、Ubuntu 22.04 LTSでサポートします。
• Virtual Server、アップストリームに関するTLSメトリクス – NGINX PlusはHTTPSのプロキシが有効な場合、前回のリリースが提供する全体の統計に加え、個々のアップストリーム、Virtual Serverに関するTLSの統計をサポートします。クライアント再度とサーバーサイドの双方に関するメトリクスを取得することはTLSハンドシェイクに関する問題のトラブルシュートに役立ちます。
• JWT Validation失敗時のエラーコードのカスタマイズ – NGINX Plus R25、R26で、独自のJWT Validationを定義することができますが、エラーコードはValidation失敗を意味する 401 (Unauthorized) が常に応答されました。NGINX Plus R27から auth_jwt_require directive に関するerrorパラメータが提供され、認証・認可のエラーを区別するためそれぞれの検査に対し401や403(Forbidden)のエラーコードを指定することが可能になります。
• NGINX JavaScriptおよびPrometheus-njs modulesの拡張 – ngx.fetchのより細かな制御を提供する新たな関数や、njs versionを16進数で確認するオブジェクトが提供されることにより、NGINX JavaScript モジュールが拡張されます。Prometheus-njs モジュールは新たにNGINX Plus に追加されたメトリクスをPrometheusに対応したフォーマットに変換します。
  追加メトリクス: 個々のアップストリームやVirtual ServerのHTTP Statusコードを示す「codes」フィールドや、コネクションリミット、リクエストリミットモジュールによって生成されるメトリクス

NGINX Plus API のバージョンが新たに8に変わりました。また、Linux KernelでEPOLLEXCLUSIVEモードが利用される際により均等にコネクションの処理が分散されるようになりました。

重要な動作の変化

注意:R26以外のリリースからアップグレードする場合、現在利用中のリリースから現在まで、ブログで紹介されている「重要な動作の変化」の項目を必ず確認してください。

新たに以下のプラットフォームがサポートされます。

• Alpine Linux 3.16
• RHEL 9.0+ (R27リリース後NGINX Plus R26にも追加されます)
• Ubuntu 22.04 LTS(R27リリース後NGINX Plus R26にも追加されます)

以下プラットフォームはサポート対象外となります。

• Alpine 3.12 (2022/5/1 に end of life(EOL))
• CentOS 8.1+(2021/12/31 に end of life(EOL)、RHEL 8.1+はEOLが異なるためサポート対象)
• Power8 アーキテクチャ (ppc64le。 CentOSとRHELに影響する)

以下プラットフォームはNGINX Plus R28でサポート対象外となる予定です。

• Debian 10 (2022/8 にEOL予定)

新機能の詳細

Health Check の Keepalive connection対応

NGINX Plusとアップストリームサーバー間のKeepalive connectionに対応し、リバースプロキシやロードバランサーの用途においてパフォーマンスを大きく向上します。特にHTTPSをプロキシする場合、すべての新規コネクションでTLSハンドシェイクに関するリソースが必要であり、多くのアップストリームサーバーが動作する本番環境においては、コンピュータリソースに悪影響を与える可能性がありました。

以前のリリースでは、NGINX Plusはkeepalive connectionをhealth checkに利用しておらず、ヘルスチェックのたびに新たなコネクションを確立していました。NGINX Plus R27よりHTTPヘルスチェックのためのkeepalive connectionを提供します。新たな keepalive_time パラメータにより、新規コネクション確立後、 health_check ディレクティブで指定した期間それぞれのコネクションを維持することができます。我々のHTTPSのプロキシに関するテスト結果では、keepalive connectionは、NGINX Plusで10から20の要因により、ヘルスチェックのCPU利用率を下げました。またそれらはアップストリームサーバーに関するCPUリソースも軽減しました。

以下の例は、lifetime を 60秒としたkeepalive connectionの例です。intervalパラメータによりHealth checkの頻度を１秒とし、NGINX Plus は60秒間のHealth Check毎に、一度のTLSハンドシェイクとコネクションの確立を行います。

Kernel TLSのサポート

Transport Layer Security (TLS)はインターネット上のデータ暗号化における業界標準です。ただ残念なことに、データを防御することは同時に遅延を発生させます。カーネルでTLSを実行する(kTLS)は、莫大な量のユーザースペースとカーネル間のメモリコピーの操作を軽減することで静的ファイルを提供する際のパフォーマンスを向上します。

kTLS と sendfile() システムコールを組み合わせることで、データは、TLS ライブラリを使用して暗号化のためにユーザースペースにコピーされ、送信前にカーネルスペースにコピーされるのではなく、送信のためにネットワークスタックに渡される前にカーネルスペースで直接暗号化されます。また、kTLS では、TLS 対称暗号処理のネットワークデバイスへのオフロードを含むハードウェアへのオフロードも可能です。

kTLSをサポートするためには、3つの要件があります。

1. オペレーティングシステムのカーネルがkTLSをサポートしている
2. オペレーティングシステムのディストリビューションに、kTLSをサポートしてコンパイルされたOpenSSL 3.0+暗号化ライブラリが含まれている
3. NGINX Plus（またはNGINX Open Source）はOpenSSL 3.0+暗号化ライブラリを使用して構築されている

2021年10月、要件1および2を満たすプラットフォーム上でのNGINX Open Source 1.21.4にkTLSのサポートを追加しました。今回、以下のプラットフォーム上のNGINX PlusでkTLSのサポートを追加します。

• FreeBSD 13 (NGINX Plus R26以降)
• RHEL 9.0+
• Ubuntu 22.04 LTS

Virtual Server、アップストリームに関するTLSメトリクス

NGINX Plusがリバースプロキシまたはロードバランサーとして導入されている場合、NGINX Plus APIは各アップストリームおよびVirtual Serverのトラフィック、レスポンスコード、レイテンシーに関する豊富なメトリクスを提供し、お客様はサーバーパフォーマンスと可用性をモニター、監視することが可能です。

以前のリリースでは、NGINX Plusとアップストリームサーバー間でHTTPSが使用された場合、httpとstreamの(proxy_pass https://path-to-upstreamやproxy_sslのそれぞれで確立される)コンテキストの両方で、システム全体のレベルでTLSアクティビティとエラーに関するメトリックを生成しました。この統計情報は、ハンドシェイク、失敗、セッションの再利用（proxy_ssl_session_reuseディレクティブで設定されたもの）を対象としています。

NGINX Plus R27は、zoneディレクティブを含む設定を持つ個々のアップストリームサーバーとstatus_zoneディレクティブを含む設定をもつVirtual Serverについて、これらのTLSメトリックスを生成します。クライアント側とサーバー側の両方からメトリクスを取得することは、TLSハンドシェイクの問題をトラブルシューティングする際に便利です。

以下の例は、アップストリームサーバー upstream1 と、そのサーバーへのトラフィックをプロキシするVirtual Serverの統計情報の収集を有効にします。

この出力は、１つ目のアップストリームサーバーが4つのTLSハンドシェイクと2つのセッションの再利用を処理したことを示しています。

$ curl http://127.0.0.1:8000/api/8/http/upstreams/upstream1/servers/0 | jq{  "peers": [    {      "id": 0,      "server": "127.0.0.1:8081",      "name": "127.0.0.1:8081",      "backup": false,      "weight": 1,      "state": "up",      "active": 0,      "ssl": {        "handshakes": 4,        "handshakes_failed": 0,        "session_reuses": 2      },      "requests": 4,      "header_time": 4,      "response_time": 4,      ...    }  ]}

この出力は、NGINX Plusが7つのTLSハンドシェイクを処理したことを示します。

$ curl http://127.0.0.1:8000/api/8/http/server_zones/srv | jq{  "processing": 0,  "requests": 7,  "responses": {    "1xx": 0,    "2xx": 7,    "3xx": 0,    "4xx": 0,    "5xx": 0,    "codes": {      "200": 7    },    "total": 7  },  "discarded": 0,  "received": 546,  "sent": 1134,  "ssl": {    "handshakes": 7,    "handshakes_failed": 0,    "session_reuses": 0  }  ...}

NGINX Plus APIは、以前のNGINX Plusリリースで利用可能なグローバルTLSメトリックを引き続き収集することに留意してください。

$ curl http://127.0.0.1:8000/api/8/ssl | jq{  "handshakes": 21,  "handshakes_failed": 0,  "session_reuses": 6}

JWT Validation失敗時のエラーコードのカスタマイズ

NGINX Plus R25、R26で、独自のJWT Validationを定義することができますが、エラーコードはValidation失敗を意味する 401 (Unauthorized) が常に応答されました。NGINX Plus R27から auth_jwt_require directive に関するerrorパラメータが提供され、認証・認可のエラーを区別するためそれぞれの検査に対し401や403(Forbidden)のエラーコードを指定することが可能になります。

NGINX Plus R27から auth_jwt_require directive に関するerrorパラメータが提供され、認証・認可のエラーを区別するためそれぞれの検査に対し401や403(Forbidden)のエラーコードを指定することが可能になります。ユーザーのアクセス要求が失敗したとき、コードの選択によって、認証失敗（JWTが無効）と認可失敗（必須のクレームがない）を区別して伝えることができます。エラーコードのためにカスタマイズされたハンドラを作成することもできます。たとえば、エラーについて説明する特別なページを返したり（error_page ディレクティブを利用）、さらなる処理のためにリクエストを指定の内部ロケーションにリダイレクトしたりすることができます。

以下のタイプのJWTチェックに失敗した場合、デフォルトのステータスコードは401のままです。

• 常に実行される(非カスタム)チェック
• auth_jwt_require で設定されたカスタムチェックで、errorパラメータを指定しないもの

locationブロック内に複数の auth_jwt_require ディレクティブがある場合、それらは記述順に評価されます。Validationがエラーとなるとそこで処理を停止し、指定されたエラーコードが返されます。

この例では、auth_jwt_requireディレクティブは、$req1または$req2のいずれかが空値または0（ゼロ）と評価された場合、403を返します。

NGINX JavaScriptおよびPrometheus-njs modulesの拡張

NGINX Plus R27は、NGINX JavaScriptモジュールのバージョン0.7.3および0.7.4を組み込み、以下の機能強化が行われています。

njs Fetch API のためのディレクティブの追加

NGINX Plus R24 に組み込まれた NGINX Javascript 0.5.3 では、TCP/UDP 接続のコンテキスト内から単純な HTTP クライアントをインスタンス化する ngx.fetch 関数（Fetch API と呼ばれる）が導入されました。(この関数の使用例については、ブログの「Leveraging HTTP Services for TCP.htmlUDP with a Simple HTTP Client」を参照してください)。

NGINX Plus R27 では、Fetch API の動作を微調整するための次のディレクティブが導入されています。

• js_fetch_buffer_size[HTTP][Stream] – 読み書きする際に使用するバッファーのサイズを設定します。
• js_fetch_max_response_buffer_size[HTTP][Stream] – Fetch API で受信するレスポンスの最大サイズを設定します。
• js_fetch_timeout[HTTP][Stream] – 2 つの連続した読み取りまたは書き込み操作の間のタイムアウトを定義します (レスポンス全体に対してではありません)。タイムアウト時間内にデータが送信されない場合、接続は切断されます。
• js_fetch_verify[HTTP][Stream] – HTTPS サーバー証明書の検証を有効または無効にします。

16進数表記のVersion番号の通知

新しい njs.njs.version_number オブジェクトは、16進数として njs モジュールのバージョンを報告します。(既存の njs.njs.version オブジェクトは、文字列としてバージョンを返します)。

Prometheus-njsモジュール、追加のメトリクスを変換可能に

NGINX Plus のメトリクスを Prometheus 準拠のフォーマットに変換する Prometheus-njs モジュールが、以下の追加エンドポイントで公開されるメトリクスを変換できるようになりました。

• /http/limit_conns
• /http/limit_reqs
• /http/server_zones and /http/upstreamsでのcodes フィールド (個々の HTTP ステータス コードのカウントを示す)
• /stream/limit_conns

NGINX Plus R27のその他の強化点

NGINX Plus API のバージョン変更

NGINX Plus APIのバージョン番号が7から8に更新され、「Virtual Server、アップストリームに関するTLSメトリクス」に記載の通り、アップストリームおよびVirtual Serverのメトリクスにsslフィールドが追加されたことが反映されています。以前のバージョン番号でも動作しますが、出力には、それ以降のAPIバージョンで追加されたメトリクスは含まれません。

Linux KernelでEPOLLEXCLUSIVEモードでの接続の管理が改善しました

NGINX Plus R27は、LinuxカーネルでEPOLLEXCLUSIVEモードが使用されている場合、NGINXワーカープロセス間でより均等に接続を分散します。通常、このモードでは、カーネルは、リッスン中のソケットをEPOLLインスタンスに最初に追加したプロセスに対してのみに通知します。その結果、多くの接続が初めのワーカープロセスによって処理されることになります。最新のNGINXは他のワーカープロセスが接続を受け入れる機会を得るために、ソケットを定期的に再追加しています。

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

NGINX Plusを実行している場合、できるだけ早くNGINX Plus R27にアップグレードすることを強くお勧めします。また、いくつかの追加修正と改善点をピックアップしておくと、サポートチケットを発行する必要があるときにNGINXにとって役立ちます。

NGINX Plusをまだお試しでない方は、セキュリティ、ロードバランシング、APIゲートウェイとして、あるいは強化された監視・管理APIを備えたフルサポートのWebサーバーとして、ぜひお試しください。30日間の無料トライアルで、今すぐ始めることができます。