NGINX Plus R18リリースのお知らせ

NGINX | 2019年4月09日

NGINX Plus Release 18（R18）の提供開始をお知らせします。NGINX Plusは、ロードバランサー、コンテンツキャッシュ、Webサーバー、APIゲートウェイを一体化した唯一のソリューションです。NGINX Open SourceをベースとするNGINX Plusには、独自の拡張機能と受賞歴のあるサポートが含まれています。R18は、DevOps向けの構成ワークフローを簡素化し、大規模環境におけるアプリケーションのセキュリティと信頼性を向上させます。

現在、87%を超えるWebサイトがSSL/TLSを使用し、インターネット経由の通信を暗号化しています。わずか3年前の66%から増加しました。現在では、Webサイトやアプリケーションの導入においてエンドツーエンド暗号化が標準となっています。また、SSL/TLS証明書の急増により、本番環境で数千もの証明書を管理している企業もあります。そのため、証明書の導入と設定には、より柔軟なアプローチが求められます。

このリリースでは、証明書の動的読み込みが新たにサポートされました。数千もの証明書を扱う場合、ディスクから読み込む証明書を1つずつ手動で設定に定義する方法では拡張性を確保できません。この作業は煩雑なだけでなく、設定が管理できないほど大規模になり、NGINX Plusの起動も許容できないほど遅くなります。NGINX Plus R18では、SSL/TLS証明書を設定に個別に記載することなく、必要に応じて読み込めるようになりました。自動デプロイをさらに簡素化するため、NGINX Plus APIを使用して証明書をプロビジョニングでき、ディスク上に配置する必要もありません。

NGINX Plus R18には、次の新機能も追加されています。

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

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

動作に関する重要な変更

廃止されたAPI – NGINX Plus R13（2017年8月）では、メトリクス収集とアップストリームグループの動的な再構成に対応する新しいNGINX Plus APIが導入され、それまでこれらの機能を実装していたStatus APIとUpstream Conf APIに置き換わりました。当時の発表どおり、非推奨となったAPIはその後も長期間にわたり利用およびサポートが継続されましたが、NGINX Plus R16をもって終了しました。構成にstatusディレクティブまたはupstream_confディレクティブ、あるいはその両方が含まれている場合は、R18へのアップグレード時に、これらをapiディレクティブに置き換える必要があります。新しいNGINX Plus APIへの移行に関するガイダンスやサポートについては、F5のブログに掲載されている移行ガイドをご覧いただくか、サポートチームにお問い合わせください。
更新された「listen」ディレクティブ – 以前は、「listen」ディレクティブで複数のIPアドレスに解決されるホスト名を指定した場合、最初のIPアドレスのみが使用されていました。現在は、返されたすべてのIPアドレスに対してリッスンソケットが作成されます。
NGINX JavaScript Module (njs)の変更 – 非推奨の req.responseオブジェクトがNGINX JavaScriptモジュールから削除されました。function(req,res)構文を使用して宣言され、かつresオブジェクトのプロパティを参照する関数ではランタイムエラーが発生し、HTTPステータスコード 500が返されるとともに、対応するエントリがエラーログに記録されます：

YYYY/MM/DD hh:mm:ss [error] 34#34: js exception: TypeError: cannot get property "return" of undefined

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証明書を管理する一般的な方法として、ホスト名ごとに個別のserverブロックを作成し、証明書と対応する秘密鍵をディスク上のファイルとして静的に指定していました。（読みやすくするため、以降は証明書と鍵のペアを証明書と表記します。）これらの証明書は、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で、NGINX PlusがSNI処理中に抽出したホスト名を保持します。証明書とキーは、各クライアントセッションの開始時に行われるTLSハンドシェイク中にディスクから読み込まれ、ファイルシステムキャッシュによってメモリ内にキャッシュされるため、メモリ使用量がさらに削減されます。

セキュアなサイトの設定は、次のようにシンプルになります。

コード例を読み込み中…

この同じ「server」設定は、数に制限なくセキュアなサイトに使用できます。これには2つのメリットがあります。

ホスト名ごとに個別の「server」ブロックを設ける必要がなくなるため、構成が大幅に簡素化され、読みやすく管理しやすくなります。
新しいホスト名を追加するたびに設定を再読み込みする必要がなくなります。設定の再読み込みが必要な場合も、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":"-----BEGIN RSA PRIVATE KEY-----\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から鍵を取得するようにするには、engine:engine-name:key-idパラメーターをssl_certificate_keyディレクティブに指定します。

OpenID Connectの機能強化

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

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

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

OpenID Connectリファレンス実装で、ログアウトURLが提供されるようになりました。ログイン中のユーザーが/logout URIにアクセスすると、IDトークンとリフレッシュトークンがキーバリューストアから削除され、次回のリクエスト時に再認証が必要になります。

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

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

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

コード例を読み込み中…

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

変数を使用したキー・バリューストアの更新

キー・バリュー・ストアを有効にすると、NGINX Plusは入力キー（通常はリクエストメタデータの一部）に基づいて、そこに格納されている値を保持する変数を提供します。これまでは、キー・バリュー・ストア内の値を作成、変更、削除するには、NGINX Plus APIを使用する必要がありました。NGINX Plus R18では、値を保持する変数を設定することで、設定内でキーの値を直接変更できます。

次の例では、キー・バリューストアを使用して、最近サイトにアクセスしたクライアントのIPアドレスと、各クライアントが最後にリクエストしたURIのリストを保持します。

コード例を読み込み中…

The setディレクティブ（7行目）は、クライアントの各IPアドレス（$last_uri）に値（$remote_addr）を割り当てます。エントリが存在しない場合は新規作成し、存在する場合は現在のリクエストの$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つの機能が追加されています。

ヘルスチェックでの任意の変数のテストをサポート
ヘルスチェック失敗時にTCPセッションを終了する機能

ヘルスチェックでの任意の変数のテスト

バックエンドアプリケーションのヘルスチェックを定義する際は、matchブロックを使用して、HTTPステータスコードやレスポンスヘッダー、本文、またはその両方に含まれる文字列など、レスポンスの複数の項目に期待される値を指定できます。レスポンスに期待される値がすべて含まれている場合、バックエンドは正常とみなされます。

さらに複雑なチェックに対応するため、NGINX Plus R18では、requireディレクティブを使用して、標準のNGINX変数と独自に宣言した変数の両方を含む、任意の変数の値をテストできるようになりました。変数は、mapブロック、正規表現、さらにはスクリプト拡張機能を使用して評価できるため、ヘルスチェックをより柔軟に定義できます。

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

コード例を読み込み中…

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

ヘルスチェック失敗時のレイヤー4接続の終了

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

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

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

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

クラスタリング構成の簡素化

NGINX Plusは、NGINX Plus R15以降、ランタイム状態のクラスター全体での同期をサポートしています。現在、Zone Synchronizationモジュールは、NGINX Plusインスタンスのクラスター構成全体で、スティッキーセッション、レート制限、およびキーバリューストアの状態データの共有をサポートしています。

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

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

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

このリリースでは、以下の動的モジュールが追加または更新されています。

新規：Brotli compression module – Brotliは、LZ77アルゴリズムの一種、ハフマン符号化、2次コンテキストモデリングを使用する汎用の可逆データ圧縮アルゴリズムです。
新しいOpenTracingモジュール – Datadog、Jaeger、Zipkinなど、さまざまな分散トレーシングサービス向けのOpenTracing準拠リクエストを使用して、NGINX Plusを計測できるようになりました。
更新された「Lua module」 – LuaはNGINX Plus向けのスクリプト言語です。このモジュールではLuaJIT 2.1が使用されるようになりました。

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

NGINX JavaScript Moduleの機能強化

NGINX JavaScriptモジュール（njs）がバージョン0.3.0に更新されました。最も注目すべき機能強化は、JavaScriptのimportおよびexportモジュールへの対応です。これにより、JavaScriptコードを機能別の複数ファイルに分けて整理できます。以前は、すべてのJavaScriptコードを1つのファイルに格納する必要がありました。

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

［編集者 – このセクションの例は、NGINX JavaScript moduleの数あるユースケースの1つにすぎません。完全な一覧については、「NGINX JavaScript Moduleのユースケース」を参照してください。

コードは、 js_importディレクティブを使用するように更新されています。このディレクティブは、js_includeディレクティブに代わり、NGINX Plus R23以降で使用されます。詳細については、NGINX JavaScriptモジュールのリファレンスドキュメントを参照してください。設定例セクションでは、NGINX設定ファイルとJavaScriptファイルの正しい構文を示しています。

NGINX Plus R22以降では、JavaScriptの importおよび exportモジュールに加えて、njsの js_importディレクティブを使用し、JavaScriptコードを機能別の複数ファイルに分けて整理できます。]

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

コード例を読み込み中…

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

コード例を読み込み中…

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

コード例を読み込み中…

新機能により、特に多数のnjsディレクティブを使用している場合や、JavaScriptコードの量が多い場合に、可読性と保守性が大幅に向上します。各チームは、メインのJavaScriptファイルに複雑なマージを行うことなく、それぞれのJavaScriptコードを保守できるようになりました。

HelmによるNGINX Ingress Controller for Kubernetesの直接インストール

新しいHelmリポジトリからNGINX Ingress Controller for Kubernetesを直接インストールできるようになりました。Helmチャートのソースファイルをダウンロードする必要はありません（従来の方法も引き続きサポートされます）。詳細については、GitHubリポジトリをご覧ください。

主なバグ修正

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

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

ヘルスチェックでPROXY Protocol TLVを使用するとNGINXがクラッシュする

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

Least Timeロードバランシングで最も遅いアップストリームが無視される

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

これは、アップストリームの応答時間を選択指標として使用するロードバランシングアルゴリズム、具体的には「least_time」と、randomにleast_timeパラメーターを指定した場合に適用されます。

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

NGINX Plusをご利用の場合は、できるだけ早くNGINX Plus R18にアップグレードすることを強く推奨します。追加の修正や改善も多数適用されるほか、サポートチケットが必要になった際に、NGINX, Inc.がより円滑にサポートを提供できるようになります。

アップグレードを実行する前に、このブログ記事で説明している新機能と動作の変更をよくご確認ください。

NGINX Plusをまだお試しでない場合は、セキュリティ、負荷分散、APIゲートウェイとして、または強化された監視・管理APIを備え、充実したサポートを受けられるWebサーバーとして、ぜひお試しください。今すぐ30日間の無料評価版をご利用いただけます。NGINX Plusがアプリケーションの提供とスケーリングにどのように役立つか、ぜひご確認ください。

注目のブログ記事

クラウドネイティブ技術、プラットフォームエンジニアリング、AIの最新トレンド

F5 NGINX OneによるアプリとAPIデリバリーのライフサイクル全体の管理

モダンアプリケーションデリバリをシンプルに：F5 NGINX Oneの9か月

タグ： SSL/TLS