ブログ | NGINX

NGINX Plus R18 の発表

NGINX-F5 水平黒タイプ RGB の一部
リアム・クリリー サムネイル
リアム・クリリー
2019年4月9日公開


NGINX Plus リリース 18 (R18)が利用可能になったことをお知らせします。 NGINX Plus は、ロードバランサー、コンテンツ キャッシュ、Web サーバー、API ゲートウェイをオールインワンで提供する唯一の製品です。 NGINX オープンソースをベースにした NGINX Plus には、独自の拡張機能と受賞歴のあるサポートが含まれています。 R18 は DevOps の構成ワークフローを簡素化し、アプリケーションのセキュリティと信頼性を大規模に強化します。

現在、インターネット上の通信を暗号化するために SSL/TLS を使用している Web サイトは 87%を超えており、わずか 3 年前の 66% から増加しています。 エンドツーエンドの暗号化は現在、Web サイトやアプリケーションのデフォルトの展開パターンであり、SSL/TLS 証明書の急増により、一部の企業は実稼働環境で何千もの証明書を管理しています。 これにより、証明書の展開と構成に対してより柔軟なアプローチが必要になります。

このリリースの新機能として、動的な証明書の読み込みがサポートされています。 何千もの証明書がある場合、ディスクから読み込むために構成でそれぞれを手動で定義するのはスケーラブルではありません。そのプロセスは面倒なだけでなく、構成が管理できないほど大きくなり、NGINX Plus の起動が許容できないほど遅くなります。 NGINX Plus R18では、SSL/TLS 証明書を構成に個別にリストすることなく、オンデマンドでロードできるようになりました。 自動展開をさらに簡素化するために、証明書はNGINX Plus APIを使用してプロビジョニングでき、ディスク上に保存する必要さえありません。

NGINX Plus R18の追加の新機能は次のとおりです。

  • OpenID Connect の機能強化– NGINX Plus R15で最初にリリースされた、サポートされている OpenID Connect リファレンス実装を継続的に改善しています。 このリリースでは、不透明セッション トークン、更新トークン、およびログアウト URL のサポートが追加されました。
  • 仮想サーバーのポート範囲– NGINX Plus 仮想サーバーは、 80 ～ 90 などのポート範囲でリッスンするように設定できるようになりました。 これにより、NGINX Plus は、ポート範囲を予約する必要があるパッシブ FTP などのより幅広いアプリケーションをサポートできるようになります。
  • 設定におけるキー値の定義– NGINX Plus のキー値ストアにより、IP アドレスの動的なブラックリスト化や動的な DDoS 緩和など、幅広いユースケースに対応するソリューションが可能になります。 NGINX Plus 設定で変数を使用してキーと値のペアを直接作成できるようになり、さらに多くのユースケースが実現できるようになりました。
  • アクティブ ヘルス チェックの柔軟性が向上– NGINX Plus のアクティブ ヘルス チェックは、バックエンド システムの健全性を監視するための強力なツールです。 NGINX Plus R18では、任意の NGINX 変数の値をテストし、障害が発生したサーバーへの既存の TCP 接続を自動的にシャットダウンできるようになりました。

このリリースには、クラスター環境向けの簡素化された構成と、新規および更新された動的モジュール (Brotli を含む) が含まれています。 NGINX Plus エコシステムのアップデートには、 NGINX JavaScript モジュールを使用したモジュール式コード編成と、Kubernetes 用の公式 NGINX Ingress Controller の直接 Helm インストールが含まれます。

行動における重要な変化

  • 廃止された API – NGINX Plus R13 (2017 年 8 月) では、メトリクス収集とアップストリーム グループの動的再構成のためのまったく新しいNGINX Plus APIが導入され、以前にこれらの機能を実装していた Status および Upstream Conf API が置き換えられました。 当時発表されたとおり、非推奨の API はかなりの期間にわたって引き続き利用可能でサポートされていましたが、 NGINX Plus R16で終了しました。 構成にstatusディレクティブやuploaded_confディレクティブが含まれている場合は、R18 へのアップグレードの一環として、それらをapiディレクティブに置き換える必要があります。

    新しいNGINX Plus APIへの移行に関するアドバイスやサポートについては、ブログの移行ガイドを参照するか、サポート チームにお問い合わせください。

  • 更新されたlistenディレクティブ- 以前は、 listenディレクティブで複数の IP アドレスに解決されるホスト名が指定された場合、最初の IP アドレスのみが使用されていました。 これで、返される IP アドレスごとに listen ソケットが作成されます。

  • NGINX JavaScript モジュール (njs) の変更–非推奨のreq.responseオブジェクトがNGINX JavaScript モジュールから削除されました。 function(req,res)構文を使用して宣言され、 resオブジェクトのプロパティも参照する関数は、実行時エラーを生成し、HTTPステータスコードを返します。500エラー ログ内の対応するエントリ:

    YYYY / MM / DD hh : mm : ss [エラー] 34#34: js 例外: TypeError: 未定義のプロパティ「return」を取得できません

    JavaScript コードは実行時に解釈されるため、 nginx -t構文検証コマンドは無効なオブジェクトとプロパティの存在を検出しません。 NGINX Plus R18にアップグレードする前に、JavaScript コードを慎重に確認し、そのようなオブジェクトを削除する必要があります。

    さらに、NGINX 状態を表す JavaScript オブジェクト (たとえば、 r.headersIn ) は、特定のプロパティに値がない場合、空の文字列ではなくundefined を返すようになりました。 この変更により、NGINX 固有の JavaScript オブジェクトは組み込みの JavaScript オブジェクトと同じように動作するようになりました。

  • 削除された、または削除される予定の古いオペレーティング システム:

    • Amazon Linux 2017.09 はサポートされなくなりました。現在サポートされている最も古いバージョンは 2018.03 です。
    • CentOS/Oracle Linux/Red Hat Enterprise Linux 7.3 はサポートされなくなりました。現在サポートされている最も古いバージョンは 7.4 です。
    • Debian 8.0 はNGINX Plus R19で削除されます
    • Ubuntu 14.04はNGINX Plus R19で削除されます

新機能の詳細

動的 SSL/TLS 証明書の読み込み

NGINX Plus の以前のリリースでは、安全なサイトやアプリケーションの SSL/TLS 証明書を管理するための一般的なアプローチは、ホスト名ごとに個別のサーバーブロックを作成し、証明書と関連する秘密鍵をディスク上のファイルとして静的に指定することでした。 (読みやすくするために、これからは証明書とキーのペアを証明書と呼ぶことにします。) その後、NGINX Plus が起動すると証明書が読み込まれました。 NGINX Plus R18では、証明書を動的にロードし、オプションでディスクではなくメモリ内の NGINX Plus キー値ストアに保存することができます。

動的証明書の読み込みには、主に 2 つの使用例があります。

どちらの場合も、NGINX Plus は、TLS ハンドシェイクの一部として Server Name Indication (SNI) によって提供されるホスト名に基づいて動的な証明書の読み込みを実行できます。 これにより、NGINX Plus は単一のサーバー構成で複数の安全な Web サイトをホストし、受信リクエストごとに適切な証明書をオンデマンドで選択できるようになります。

ディスクからの SSL/TLS 証明書の遅延読み込み

「遅延読み込み」では、リクエストが到着し、対応するホスト名が指定されたときにのみ、SSL/TLS 証明書がメモリに読み込まれます。 これにより、構成が簡素化され (ホスト名ごとの証明書のリストがなくなるため)、ホスト上のリソース使用率が削減されます。 証明書の数が多い場合 (数千個)、すべての証明書をディスクから読み取ってメモリにロードするには数秒かかることがあります。 さらに、NGINX 構成が再ロードされるときには、新しいワーカー プロセス セットが、以前のワーカー セットによってロードされた証明書とともに、証明書の新しいコピーをメモリにロードするため、大量のメモリが使用されます。 以前の証明書は、古い構成で確立された最終接続が完了し、以前のワーカーが終了するまでメモリに残ります。 構成が頻繁に更新され、クライアント接続が長時間続く場合、メモリ内に証明書のコピーが複数存在し、メモリ不足につながる可能性があります。

ディスクからの証明書の遅延読み込みは、証明書の数が多い場合や構成の再読み込みが頻繁に行われる場合の展開に最適です。 たとえば、SaaS 企業では通常、顧客ごとに個別のサブドメインを割り当てます。 新しい顧客のオンボーディングは、顧客ごとに新しい仮想サーバーを作成し、新しい構成と顧客の証明書を各 NGINX Plus インスタンスにコピーする必要があるため、困難です。 遅延読み込みにより構成の変更が不要になり、各インスタンスに証明書をデプロイするだけで完了します。

遅延読み込みをサポートするために、 ssl_certificateおよびssl_certificate_keyディレクティブは変数パラメータを受け入れるようになりました。 変数は、リクエスト ラインとヘッダーが読み取られる前に実行される SNI 処理中に使用可能である必要があります。 最もよく使用される変数は$ssl_server_nameで、SNI 処理中に NGINX Plus によって抽出されたホスト名を保持します。 証明書とキーは、各クライアント セッションの開始時に TLS ハンドシェイク中にディスクから読み取られ、ファイル システム キャッシュ内のメモリにキャッシュされるため、メモリの使用率がさらに削減されます。

安全なサイトの構成は次のように簡単になります。

この同じサーバー構成は、無制限の数の安全なサイトに使用できます。 これには 2 つの利点があります。

  1. 各ホスト名の個別のサーバーブロックがなくなるため、構成が大幅に小さくなり、読みやすく、管理しやすくなります。
  2. 新しいホスト名を追加するたびに構成を再ロードする必要がなくなります。 設定を再読み込みする必要がある場合、NGINX Plus はすべての証明書をロードしないため、はるかに高速になります。

遅延読み込みでは、ディスクから証明書を取得するために必要なファイルシステム呼び出しのため、環境に応じて TLS ハンドシェイクに 20～30% 長くかかることに注意してください。 ただし、追加の遅延はハンドシェイクにのみ影響します。TLS セッションが確立されると、リクエストの処理には通常の時間がかかります。

インメモリ SSL/TLS 証明書ストレージ

SSL/TLS 証明書データをメモリ、NGINX Plusキー値ストア、およびディスク上のファイルに保存できるようになりました。 ssl_certificateまたはssl_certificate_keyディレクティブへのパラメータがdata:プレフィックスで始まる場合、NGINX Plus はパラメータを生の PEM データ (データが実際に存在するキー値ストアのエントリを識別する変数の形式で提供される) として解釈します。

ディスクではなくキー値ストアに保存するもう 1 つの利点は、展開イメージとバックアップに秘密キーのコピーが含まれなくなることです。秘密キーのコピーを使用すると、攻撃者はサーバーとの間で送受信されるすべてのトラフィックを復号化できます。 高度に自動化されたデプロイメント パイプラインを持つ企業は、 NGINX Plus API を使用して証明書をプログラムでキー値ストアに挿入できる柔軟性のメリットを享受できます。 さらに、秘密鍵を保護するための実際のハードウェア セキュリティ モジュール (HSM) がないパブリック クラウド環境にアプリケーションを移行する企業は、秘密鍵をディスクに保存しないことでセキュリティが強化されるというメリットを享受できます。

キー値ストアから証明書をロードするためのサンプル構成を次に示します。

NGINX Plus APIを使用して証明書と秘密鍵をキー値ストアにアップロードする 1 つの方法は、次のcurlコマンドを実行することです (キー データの先頭部分のみが表示されます)。 curlコマンドを使用する場合は、必ず PEM データのコピーを作成し、すべての改行を\nに置き換えてください。そうしないと、JSON ペイロードから改行が削除されます。

$ curl -d '{"www.example.com":"----- RSA 秘密鍵の開始-----\n..."}' http://localhost:8080/api/4/http/keyvals/ssl_key

証明書にキー値ストアを使用することは、証明書を一度アップロードするだけでクラスター全体に自動的に伝播されるため、NGINX Plus のクラスター化されたデプロイメントに最適です。 証明書データ自体を保護するには、 zone_sync_sslディレクティブを使用して、クラスター メンバー間の接続を TLS 暗号化します。 キー値ストアの使用は、有効期間が短い証明書や、 Let's EncryptやHashicorp Vaultなどの証明書発行者との統合を自動化する場合にも最適です。

ディスクからの遅延読み込みと同様に、キー値ストアからの証明書の読み込みは各 TLS ハンドシェイク中に行われるため、パフォーマンスが低下します。 最も高速な TLS ハンドシェイクを実現するには、ディスク上のファイルにハードコードされたパラメータを指定してssl_certificateおよびssl_certificate_keyディレクティブを使用します。 さらに、 ECC 証明書はRSA 証明書よりも高速です。

キーバリューストアでは、ディスクストレージよりも攻撃者が秘密鍵ファイルを取得することが困難になりますが、NGINX Plus ホストへのシェルアクセス権を持つ攻撃者は、メモリにロードされたキーにアクセスできる可能性があることに注意してください。 キー値ストアは、ハードウェア セキュリティ モジュール(HSM) と同じ程度には秘密鍵を保護しません。NGINX Plus で HSM からキーを取得するには、 ssl_certificate_keyディレクティブにengine: engine-name : key-idパラメータを使用します。

OpenID Connect の機能強化

NGINX Plus は、リファレンス実装を通じて、バックエンド アプリケーションの OpenID Connect 認証とシングル サインオンをサポートします。 キー値ストアを変数を使用して JavaScript モジュールから直接変更できるようになったため、これは簡素化および強化されました (以下を参照)。

OpenID Connect リファレンス実装では、ブラウザ クッキーの形式で不透明なセッション トークンがクライアントに発行されるようになりました。 不透明トークンにはユーザーに関する個人を特定できる情報は含まれないため、クライアントに機密情報は保存されません。 NGINX Plus は実際の ID トークンをキー値ストアに保存し、クライアントが提示する不透明トークンの代わりに使用します。 JWT 検証はリクエストごとに実行されるため、期限切れまたは無効なトークンは拒否されます。

OpenID Connect リファレンス実装では、更新トークンもサポートされるようになったため、期限切れの ID トークンはユーザーの操作を必要とせずにシームレスに更新されます。 NGINX Plus は、認可サーバーから送信されたリフレッシュ トークンをキー値ストアに保存し、それを不透明セッション トークンに関連付けます。 ID トークンの有効期限が切れると、NGINX Plus は更新トークンを認可サーバーに送り返します。 セッションがまだ有効な場合、認可サーバーは新しい ID トークンを発行し、キー値ストアでシームレスに更新されます。 リフレッシュ トークンを使用すると、有効期間の短い ID トークンを使用できるようになり、ユーザーに迷惑をかけずにセキュリティを強化できます。

OpenID Connect リファレンス実装では、ログアウト URL が提供されるようになりました。 ログインしたユーザーが/logout URI にアクセスすると、そのユーザーの ID と更新トークンがキー値ストアから削除され、今後のリクエストを行うときに再認証が必要になります。

仮想サーバーのポート範囲

サーバーブロックには通常、NGINX Plus がリッスンする単一のポートを指定するlistenディレクティブが 1 つあります。複数のポートを設定する必要がある場合は、ポートごとに追加のlistenディレクティブがあります。 NGINX Plus R18では、多数の個別のlistenディレクティブを指定するのが不便な場合に、 80‑90などのポート範囲も指定できるようになりました。

ポート範囲は、HTTP listenディレクティブと TCP/UDP (ストリーム) listenディレクティブの両方に指定できます。 次の設定により、NGINX Plus はパッシブ モードで FTP サーバーのプロキシとして機能し、データ ポートは広範囲の TCP ポートから選択されます。

この構成では、接続が到着したのと同じポートで FTP サーバーへの接続をプロキシする仮想サーバーを設定します。

変数によるキーバリューストアの更新

キー値ストアが有効になっている場合、NGINX Plus は入力キー (通常はリクエスト メタデータの一部) に基づいて、そこに保存される値の変数を提供します。 これまで、キー値ストアで値を作成、変更、または削除する唯一の方法は、NGINX Plus API を使用することでした。NGINX Plus R18では、値を保持する変数を設定することで、設定でキーの値を直接変更できます。

次の例では、キー値ストアを使用して、最近サイトにアクセスしたクライアント IP アドレスのリストと、それらが最後に要求した URI を維持します。

setディレクティブ (7 行目) は、各クライアント IP アドレス ( $remote_addr ) に値 ( $last_uri ) を割り当て、存在しない場合は新しいエントリを作成し、現在のリクエストの$uri を反映するように値を変更します。 したがって、最近のクライアントとそれらが要求した URI の現在のリストは、 NGINX Plus APIを呼び出すことで利用できます。

$ curl http://localhost:8080/api/4/http/keyvals/recents { "10.19.245.68": "/blog/nginx-plus-r18-released/", "172.16.80.227": "/products/nginx/", "10.219.110.168": "/blog/nginx-unit-1-8-0-now-available" }

NGINX JavaScript モジュール (njs) や Lua モジュールなどのスクリプト拡張機能を使用すると、さらに強力なユースケースを実現できます。 njs を利用するすべての構成は、 r.variables.last_uriなどのキー値ストアによってサポートされる変数も含め、すべての変数にアクセスできます。

アクティブヘルスチェックの柔軟性の向上

NGINX Plus のアクティブ ヘルス チェックは、バックエンド システムを定期的にテストし、トラフィックが不健全であると判明しているシステムに送信されることがないようにします。 NGINX Plus R18 では、この重要な機能が 2 つの追加機能によって拡張されています。

ヘルスチェックにおける任意の変数のテスト

バックエンド アプリケーションのヘルス チェックを定義するときに、一致ブロックを使用して、HTTP ステータス コードや応答ヘッダーおよび本文の文字列など、応答の複数の側面の予想値を指定できます。 応答にすべての期待値が含まれている場合、バックエンドは正常であると見なされます。

さらに複雑なチェックのために、 NGINX Plus R18 では、標準の NGINX 変数と宣言した変数の両方の変数の値をテストするためのrequireディレクティブが提供されるようになりました。 これにより、変数はマップブロック、正規表現、さらにはスクリプト拡張機能を使用して評価できるため、ヘルス チェックを定義する際の柔軟性が向上します。

matchブロック内のrequireディレクティブは 1 つ以上の変数を指定します。テストに合格するには、すべての変数の値が 0 以外の値である必要があります。 次のサンプル構成では、正常なアップストリーム サーバーを、応答がキャッシュ可能であることを示すヘッダー (ゼロ以外の値を持つExpiresヘッダー、またはCache-Controlヘッダー) を返すサーバーとして定義しています。

このようにマップブロックを使用することは、OR ロジックを NGINX Plus 構成に組み込む一般的な方法です。 requireディレクティブを使用すると、ヘルスチェックでこの手法を活用したり、高度なヘルスチェックを実行したりできるようになります。 JavaScript モジュール (njs) を使用して、応答時間など、各アップストリーム サーバーからの応答の追加属性を分析することで、高度なヘルス チェックを定義することもできます。

ヘルスチェックが失敗した場合にレイヤー 4 接続を終了する

NGINX Plus が TCP/UDP アプリケーションのレイヤー 4 (L4)ロード バランサとして機能する場合、クライアントとバックエンド サーバーの間で確立された接続で両方向にデータをプロキシします。 アクティブ ヘルス チェックはこのような構成の重要な部分ですが、デフォルトでは、バックエンド サーバーのヘルス ステータスは、新しいクライアントが接続を確立しようとしたときにのみ考慮されます。 バックエンド サーバーがオフラインになると、確立されたクライアントがサーバーにデータを送信するときにタイムアウトが発生する可能性があります。

NGINX Plus R18の新機能であるproxy_session_dropディレクティブを使用すると、オフライン サーバーから次のパケットを受信または送信したときに、すぐに接続を閉じることができます。 クライアントは強制的に再接続され、その時点で NGINX Plus はリクエストを正常なバックエンド サーバーにプロキシします。

このディレクティブを有効にすると、アクティブなヘルス チェックの失敗と、何らかの理由によるアップストリーム グループからのサーバーの削除という 2 つの条件によっても既存の接続の終了がトリガーされます。 これには、DNS ルックアップによる削除が含まれます。この場合、バックエンド サーバーは、サービス レジストリによって提供されるものなど、複数の IP アドレスを持つホスト名によって定義されます。

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

簡素化されたクラスタリング構成

NGINX Plus は、NGINX Plus R15以降、クラスター全体でのランタイム状態の同期をサポートしています。 ゾーン同期モジュールは現在、NGINX Plusインスタンスのクラスター化された展開全体で、スティッキーセッション、レート制限、およびキー値ストアに関する状態データの共有をサポートしています。

単一のzone_sync構成をクラスター内のすべてのインスタンスに使用できるようになりました。 以前は、各メンバーの IP アドレスまたはホスト名を明示的に構成する必要があり、各インスタンスの構成が若干異なっていました。 listenディレクティブのaddress : portパラメータにワイルドカード値を指定することにより、 zone_syncサーバーがすべてのローカル インターフェイスでリッスンできるようになりました。 これは、インスタンスの IP アドレスがデプロイ時まで不明な動的クラスターに NGINX Plus をデプロイする場合に特に役立ちます。

すべてのインスタンスで同じ構成を使用すると、動的な環境 (自動スケーリング グループやコンテナ化されたクラスターなど) でのデプロイメントが大幅に簡素化されます。

新規および更新された動的モジュール

このリリースでは、次の動的モジュールが追加または更新されました。

  • 新しいBrotli 圧縮モジュール– Brotli は、LZ77 アルゴリズム、ハフマン符号化、および 2 次コンテキスト モデリングのバリエーションを使用する汎用のロスレス データ圧縮アルゴリズムです。
  • 新しいOpenTracing モジュール– Datadog、Jaeger、Zipkin などのさまざまな分散トレース サービスに対する OpenTracing 準拠のリクエストを使用して NGINX Plus をインストルメントできるようになりました。
  • 更新されたLua モジュール– Lua は NGINX Plus のスクリプト言語です。 モジュールは現在 LuaJIT 2.1 を使用します。

NGINX Plus エコシステムのアップデート

NGINX JavaScript モジュールの機能強化

NGINX JavaScript モジュール (njs) がバージョン 0.3.0に更新されました。 最も注目すべき機能強化は、JavaScript のインポートおよびエクスポートモジュールのサポートです。これにより、JavaScript コードを複数の関数固有のファイルに整理できるようになります。 以前は、すべての JavaScript コードを 1 つのファイルに格納する必要がありました。

次の例は、JavaScript モジュールを使用して、比較的単純なユースケースに必要なコードを整理および簡素化する方法を示しています。 ここでは、ユーザーのプライバシーを保護するために JavaScript を使用してデータ マスキングを実行し、実際のアドレスではなく、クライアント IP アドレスのハッシュ化された (マスクされた) バージョンがログに記録されるようにします。 ログ内の特定のマスクされた IP アドレスは常に同じクライアントを表しますが、実際の IP アドレスに戻すことはできません。

[編集者– このセクションの例は、NGINX JavaScript モジュールの多くの使用例の 1 つにすぎません。 完全なリストについては、 「NGINX JavaScript モジュールの使用例」を参照してください。

コードが更新され、 js_インポート 指令は、 js_include 指令の NGINX プラス R23 そしてその後。 詳細については、 NGINX JavaScript モジュールのリファレンス ドキュメントを参照してください。構成例のセクションに、NGINX 構成と JavaScript ファイルの正しい構文が示されています。

NGINX Plus R22 以降では、JavaScriptインポートおよびエクスポートモジュールに加えて、njs js_importディレクティブを使用して JavaScript コードを複数の関数固有のファイルに整理できます。 ]

IP アドレスのマスキングに必要な関数を、単一の関数maskIp()をエクスポートする JavaScript モジュールに配置します。 エクスポートされた関数は、モジュール内でのみ使用可能なプライベート関数に依存しており、他の JavaScript コードからは呼び出すことができません。

このモジュールをメインの JavaScript ファイル ( main.js ) にインポートし、エクスポートされた関数を参照できるようになりました。

その結果、 main.jsは非常にシンプルになり、NGINX 構成によって参照される関数のみが含まれます。 importステートメントは、モジュール ファイルへの相対パスまたは絶対パスを指定します。 相対パスが指定されている場合は、新しいjs_pathディレクティブを使用して、検索する追加のパスを指定できます。

新しい機能により、特に多数の njs ディレクティブが使用されている場合や、大量の JavaScript コードが使用されている場合に、読みやすさとメンテナンス性が大幅に向上します。 メインの JavaScript ファイルへの複雑なマージを実行する必要なく、別々のチームが独自の JavaScript コードを維持できるようになりました。

Kubernetes 用 NGINX Ingress コントローラーの直接 Helm インストール

Helm チャート ソース ファイルをダウンロードしなくても、新しい Helm リポジトリから Kubernetes 用の NGINX Ingress Controller を直接インストールできるようになりました (ただし、これも引き続きサポートされています)。 詳細については、 GitHub リポジトリを参照してください。

注目すべきバグ修正

UDP アプリケーションの帯域幅制限

proxy_upload_rateおよびproxy_download_rateディレクティブが UDP データグラムに対して正しく機能するようになりました。

ヘルスチェック付きの PROXY プロトコル TLV により NGINX がクラッシュする

以前は、 AWS PrivateLink環境内など、 $proxy_protocol_tlv_0xEA変数を参照する場所にhealth_checkディレクティブが含まれていると、NGINX Plus がクラッシュする可能性がありました。

最小時間負荷分散は無視され、最も遅いアップストリーム

以前は、アップストリーム サーバーの応答が長時間にわたって遅かった場合、指定された時間メトリックの値が他のアップストリーム サーバーと比較して非常に高かったため、そのサーバーが再度選択されない可能性がありました。 現在、新しい測定値によって移動平均が減少するため、以前は低速だったアップストリーム サーバーは最終的にロード バランサーの選択プロセスに再導入されます。

これは、アップストリーム応答時間を選択メトリックとして使用する負荷分散アルゴリズム、具体的にはleast_timeおよびleast_timeパラメータを使用したrandomに適用されます。

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

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

アップグレードを進める前に、このブログ投稿に記載されている新機能と動作の変更をよく確認してください。

NGINX Plus をまだお試しいただいていない方は、セキュリティ、負荷分散、API ゲートウェイとして、または強化された監視および管理 API を備えた完全にサポートされた Web サーバーとして、ぜひお試しください。 今すぐ30 日間の無料評価版をお試しください。 NGINX Plus がアプリケーションの配信と拡張にどのように役立つかを実際にご確認ください。

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"