NGINX Plus R27を発表

NGINX | 2022年6月28日

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

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

ヘルスチェック用のキープアライブ接続 – 以前のリリースでは、NGINX Plusはヘルスチェックごとに新しい接続を確立していました。HTTP keepalive_time ディレクティブの新しい health_check パラメーターを使用すると、ヘルスチェック用のキープアライブ接続を有効にし、その有効期間を設定できます。新しい接続の確立には多くの計算リソースが必要となるため、アップストリームサーバーが多数ある場合は、接続を再利用することでCPU使用率を大幅に削減できます。
Kernel TLSのサポート – NGINX Plusは、Kernel TLS（kTLS）のサポート要件を満たす3つのオペレーティングシステム（FreeBSD 13、RHEL 9.0以降、Ubuntu 22.04 LTS）を新たにサポートします。
アップストリームおよび仮想サーバーのTLSメトリクス – NGINX Plusでは、HTTPS経由のプロキシが有効な場合、以前のリリースで生成していたグローバル統計に加えて、個々のアップストリームおよび仮想サーバーのTLS統計も生成するようになりました。クライアント側とサーバー側の両方のメトリクスは、TLSハンドシェイクの問題をトラブルシューティングする際に役立ちます。
JWT検証失敗時のエラーコードのカスタマイズ – NGINX Plus R25およびR26では、カスタムのJWT検証チェックを定義できますが、検証に失敗した場合に返されるエラーコードは常に401 (Unauthorized)です。NGINX Plus R27では、errorパラメーターがauth_jwt_requireディレクティブに導入され、認証エラーと認可エラーをより明確に区別できるよう、チェックごとにコードを401または403 (Forbidden)に設定できます。
NGINX JavaScriptおよびPrometheus-njsモジュールの機能強化 – NGINX JavaScriptモジュールの機能強化には、ngx.fetch関数の動作を微調整するための新しいディレクティブと、njsのバージョンを16進数で報告する新しいオブジェクトが含まれます。Prometheus-njsモジュールでは、さらに多くのNGINX PlusメトリクスをPrometheus準拠の形式に変換できるようになりました。対象となるのは、codesフィールド（アップストリームサーバーおよび仮想サーバーのHTTPステータスコード別の件数を報告）と、Limit ConnectionsおよびLimit Requestsモジュールによって生成されるメトリクスです。

今回のリリースを締めくくる機能として、NGINX Plus APIの新しいバージョン番号（8）と、LinuxカーネルでEPOLLEXCLUSIVEモードを使用する際の接続分散のさらなる均等化が追加されています。

動作に関する重要な変更

注：NGINX Plus R26以外のリリースからアップグレードする場合は、現在お使いのリリースから本リリースまでのすべてのリリースについて、発表ブログの「動作に関する重要な変更」セクションを必ず確認してください。

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

Alpine Linux 3.16
RHEL 9.0+（初回リリース後にNGINX Plus R26へ追加）
Ubuntu 22.04 LTS（初回リリース後にNGINX Plus R26へ追加）

削除された旧バージョンのオペレーティングシステムとアーキテクチャ：

2022年5月1日にサポート終了（EOL）となったAlpine 3.12
CentOS 8.1+（2021年12月31日にEOLを迎えました。RHEL 8.1+はEOLの日付が異なるため、引き続きサポートされます）
Power 8アーキテクチャ（ppc64le、CentOSおよびRHELに影響）

非推奨となり、NGINX Plus R28で削除される予定の旧バージョンのオペレーティングシステムおよびアーキテクチャ：

2022年8月にEOLを迎えるDebian 10

新機能の詳細

ヘルスチェック用のキープアライブ接続

キープアライブ接続をNGINX Plusとアップストリームサーバーの間で使用すると、リバースプロキシや負荷分散のユースケースでパフォーマンスが大幅に向上します。特にHTTPS経由のプロキシでは、新しい接続のたびに必要となる完全なTLSハンドシェイクの計算負荷により、コンピューティングリソースが圧迫される可能性があります。アップストリームサーバーが多数存在する本番環境では、特に大きな負荷となります。

以前のリリースでは、NGINX Plusはヘルスチェックにキープアライブ接続を使用せず、ヘルスプローブごとに新しい接続を確立していました。NGINX Plus R27では、HTTPヘルスチェックにキープアライブ接続が導入されました。新しいkeepalive_timeパラメーターをhealth_checkディレクティブに指定すると、各キープアライブ接続の有効期間が設定され、その期間が経過すると新しい接続が確立されます。F5のテストでは、HTTPS経由のプロキシの場合、キープアライブ接続によってNGINX PlusサーバーでのヘルスチェックのCPU使用量が10分の1～20分の1に削減されることが示されています。また、アップストリームサーバーのCPUリソースも節約できます。

次の例では、有効期間が60秒のキープアライブ接続を有効にします。intervalパラメーターでヘルスチェックの頻度を1秒に設定しているため、NGINX PlusでTLSハンドシェイクと接続確立の処理が発生するのは、60回のヘルスチェックにつき1回だけです。

コード例を読み込み中…

Kernel TLSのサポート

Transport Layer Security（TLS）は、インターネット上のデータ暗号化における事実上の標準プロトコルです。ただし、データを保護するとレイテンシーも増加します。カーネルにTLS（kTLS）を実装することで、ユーザー空間とカーネル間のコピー処理を大幅に削減できるため、静的コンテンツ配信時のパフォーマンスが向上します。

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

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

オペレーティングシステムのカーネルがkTLSをサポートしていること
オペレーティングシステムのディストリビューションに、kTLSサポートを有効にしてコンパイルされたOpenSSL 3.0以降の暗号ライブラリが含まれている
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

アップストリームサーバーと仮想サーバーのTLSメトリクス

NGINX Plusをリバースプロキシまたはロードバランサーとして導入すると、NGINX Plus APIから各アップストリームサーバーおよび仮想サーバーのトラフィック、レスポンスコード、レイテンシーに関する豊富なメトリクスが提供され、サーバーのパフォーマンスと可用性を可視化して監視できます。

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

NGINX Plus R27では、構成にzoneディレクティブが含まれる個々のアップストリームサーバーと、構成にstatus_zoneディレクティブが含まれる仮想サーバーについて、これらのTLSメトリクスが生成されます。クライアント側とサーバー側の両方のメトリクスを取得することで、TLSハンドシェイクの問題をトラブルシューティングしやすくなります。

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

コード例を読み込み中…

この出力は、最初のアップストリームサーバーが4回のTLSハンドシェイクと2回のセッション再利用に関与したことを示しています（簡潔にするため、最初のサーバーについては出力の一部のみを示し、その他のアップストリームサーバーの出力は省略しています）。

$ curl http://127.0.0.1:8000/api/8/http/upstreams/upstream1 | 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検証失敗時のエラーコードのカスタマイズ

NGINX Plus R25で、JWT検証プロセス中のカスタムチェックを定義するための auth_jwt_requireディレクティブが導入されました。NGINX Plus R25およびR26では、検証に失敗した場合に返されるエラーコードは常に401 (Unauthorized)です。

NGINX Plus R27では、errorパラメーターがauth_jwt_requireディレクティブに導入され、ディレクティブごとに個別にコードを401または403 （Forbidden）に設定できます。ユーザーのアクセス要求が失敗した場合、コードを選択することで、認証の失敗（JWTが無効）と認可の失敗（必須クレームがない）を区別して伝えられます。また、エラーコード用のカスタムハンドラーを作成することもできます。たとえば、error_pageディレクティブを使用してエラーを説明する専用ページを返したり、追加処理のためにリクエストを名前付き内部ロケーションへリダイレクトしたりできます。

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

常に実行される（カスタムではない）チェック
Custom checks configured with auth_jwt_requireで設定されているものの、errorパラメーターが指定されていないカスタムチェック

複数のauth_jwt_requireディレクティブがlocationブロックにある場合、記述された順に評価されます。最初の失敗時に処理が停止し、指定されたエラーコードが返されます。

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

コード例を読み込み中…

NGINX JavaScriptおよびPrometheus-njsモジュールの機能強化

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とも呼ばれます）が導入されました。（この関数のユースケースについては、F5のブログ記事「シンプルなHTTPクライアントによるTCP.htmlUDP向けHTTPサービスの活用」をご覧ください。）

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進数で報告されるバージョン番号

新しい「njs.version_number」オブジェクトは、njsモジュールのバージョンを16進数で返します。（既存の「njs.version」オブジェクトは、バージョンを文字列で返します。）

Prometheus-njsモジュールが追加のメトリクスを変換

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

/http/limit_conns
/http/limit_reqs
The codes field (which reports counts of individual HTTP status codes<.htmla>) under /http/server_zones and /http/upstreams
/stream/limit_conns

NGINX Plus R27のその他の機能強化

NGINX Plus APIのバージョン変更

「ssl」フィールドがアップストリームサーバーおよび仮想サーバーについて報告されるメトリクスに追加されたことを反映し、NGINX Plus APIのバージョン番号が7から8に更新されました。詳細については、「アップストリームサーバーおよび仮想サーバーのTLSメトリクス」を参照してください。以前のバージョン番号も引き続き使用できますが、後続のAPIバージョンで追加されたメトリクスは出力に含まれません。

Linux EPOLLEXCLUSIVEモードでの接続分散の改善

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