NGINX Plus R27 の発表

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

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

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

このリリースでは、 NGINX Plus APIの新しいバージョン番号 (8) と、Linux カーネルで EPOLLEXCLUSIVE モードが使用される場合の接続のより均等な分散が追加されました。

行動における重要な変化

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

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

• アルパインLinux3.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 で非推奨となり削除が予定されている古いオペレーティング システムとアーキテクチャ:

• Debian 10 は 2022 年 8 月に EOL を迎えます。

新機能の詳細

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

NGINX Plus とアップストリーム サーバー間のキープアライブ接続により、リバース プロキシおよび負荷分散の使用例のパフォーマンスが大幅に向上します。 特に HTTPS 経由のプロキシの場合、新しい接続ごとに必要な完全な TLS ハンドシェイクの計算コストが、特に多数のアップストリーム サーバーがある実稼働環境では、コンピューティング リソースに負担をかける可能性があります。

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

次の例では、有効期間が 60 秒のキープアライブ接続を有効にします。 間隔パラメータによって設定された 1 秒のヘルスチェック頻度を考えると、NGINX Plus では TLS ハンドシェイクと接続確立のコストが 60 回のヘルスチェックごとに 1 回だけ発生します。

カーネル TLS のサポート

トランスポート層セキュリティ (TLS) は、インターネット上のデータ暗号化の事実上の標準プロトコルです。 残念ながら、データを保護すると遅延も発生します。 カーネルに TLS を実装する (kTLS) と、ユーザー空間とカーネル間のコピー操作の必要性が大幅に減少し、静的コンテンツを提供する際のパフォーマンスが向上します。

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

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

1. オペレーティングシステムカーネルがサポートしている
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以降)
• RHEL9.0以降
• Ubuntu 22.04 LTS

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

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

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

NGINX Plus R27 は、構成にゾーンディレクティブが含まれる個々のアップストリーム サーバーと、構成にstatus_zoneディレクティブが含まれる仮想サーバーに対してこれらの TLS メトリックを生成します。 クライアント側とサーバー側の両方からのメトリックを取得すると、TLS ハンドシェイクの問題をトラブルシューティングするときに役立ちます。

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

この出力は、最初のアップストリーム サーバーが 4 つの TLS ハンドシェイクと 2 つの再利用セッションに参加したことを示しています (簡潔にするために、最初のサーバーの部分的な出力を示し、他のアップストリーム サーバーの出力は省略しています)。

$ curl http://127.0.0.1:8000/api/8/http/upstreams/upstream1 | jq { "peers": [ { "id": 0、「サーバー」: "127.0.0.1:8081", "名前": "127.0.0.1:8081", "バックアップ": false, "重み": 1、「状態」：「アップ」、「アクティブ」： 0, "ssl": { "ハンドシェイク": 4、「ハンドシェイクに失敗しました」: 0、「セッション再利用」: 2 } 、「リクエスト」: 4、「ヘッダー時間」: 4、「応答時間」: 4、... } ... ] }

この出力は、NGINX Plus が 7 つの TLS ハンドシェイクに参加したことを示しています。

$ curl http://127.0.0.1:8000/api/8/http/server_zones/srv | jq { "処理中": 0、「リクエスト」: 7、「応答」：{「1xx」： 0、「2xx」： 7、「3xx」： 0、「4xx」： 0、「5xx」： 0, "コード": { "200": 7 }, "合計": 7 }, "破棄": 0、「受信済み」: 546、「送信済み」: 1134, "ssl": { "ハンドシェイク": 7、「ハンドシェイクに失敗しました」: 0、「セッション再利用」: 0 } ... }

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

$ curl http://127.0.0.1:8000/api/8/ssl | jq { "ハンドシェイク": 21、「ハンドシェイクに失敗しました」: 0、「セッション再利用」: 6 }

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

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

NGINX Plus R27では、 auth_jwt_requireディレクティブにエラーパラメータが導入され、これを使用してコードを次のように設定できます。401または403(禁止)各ディレクティブごとに独立して実行します。 ユーザーのアクセス要求が失敗した場合、コードを選択することで、認証失敗 (JWT が無効) と承認失敗 (必要なクレームが欠落している) を区別することができます。 また、エラー コードに対してカスタマイズされたハンドラーを作成して、エラーを説明する特別なページを返す ( error_pageディレクティブを使用) か、リクエストを名前付きの内部の場所にリダイレクトしてさらに処理を進めることもできます。

デフォルトのステータスコードはそのまま401次の種類の JWT チェックに失敗した場合:

• 常に実行される（カスタムではない）チェック
• auth_jwt_requireで設定されているがエラーパラメータが設定されていないカスタムチェック

ロケーションブロック内に複数のauth_jwt_requireディレクティブがある場合、それらは出現順に評価されます。 最初の失敗で処理が停止し、指定されたエラー コードが返されます。

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

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

NGINX Plus R27にはバージョンが組み込まれています0.7.3そして0.7.4NGINX JavaScript モジュールの次の機能強化が含まれています。

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進数で報告されます

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

Prometheus-njsモジュールは追加のメトリックを変換します

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

• /http/接続制限
• /http/制限要件
• /http/server_zonesおよび/http/upstreamsのコードフィールド (個々の HTTP ステータス コードの数を報告する <.htmla>)
• /ストリーム/接続制限

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

NGINX Plus API バージョンの変更

NGINX Plus APIのバージョン番号が 7 から 8 に更新され、「アップストリームおよび仮想サーバーの TLS メトリック」で説明されているように、アップストリームおよび仮想サーバーに対して報告されるメトリックにsslフィールドが追加されたことが反映されます。 以前のバージョン番号も引き続き機能しますが、出力にはそれ以降の API バージョンで追加されたメトリックは含まれません。

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

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

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

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

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