NGINX Plus R15を発表

Liam Crillyプロダクトマネジメント担当シニアディレクター

当社の主力製品であるNGINX Plusの第15版がリリースされたことをお知らせします。NGINX Plusは、2013年の初回リリース以来、機能面でも商業的な支持の面でも大きく成長してきました。現在、NGINX Plusのお客さまは[ngx_snippet name=’nginx-plus-customers’]を超え、NGINX Open Sourceのユーザーは[ngx_snippet name=’number-sites’]に達しています。

NGINX Open SourceをベースとするNGINX Plusは、ロードバランサー、コンテンツキャッシュ、Webサーバー、APIゲートウェイを一体化した唯一のソリューションです。NGINX Plusには、最新のアプリケーション設計の複雑さを軽減するための独自の拡張機能と、受賞歴のあるサポートが含まれています。

NGINX Plus R15では、新たにgRPCのサポート、HTTP/2サーバープッシュ、クラスタリングサポートの改善、APIゲートウェイ機能の強化などが導入されています。

• ネイティブgRPCサポート – gRPCは、Googleが開発した新しいリモートプロシージャコール（RPC）規格です。クライアントとサーバー間で軽量かつ効率的に通信できます。この新機能により、NGINX PlusはgRPCトラフィックのSSL終端、ルーティング、負荷分散を行い、バックエンドサーバーに転送できます。
• HTTP/2サーバープッシュ – HTTP/2サーバープッシュにより、NGINX Plusはクライアントから実際にリクエストされる前にリソースを送信できるため、パフォーマンスが向上し、ラウンドトリップが削減されます。
• クラスター全体での状態共有 – このリリースでは、Sticky Learnのセッション維持に使用される共有メモリデータを、クラスター内のすべてのNGINX Plusインスタンスで共有できます。今後数回のNGINX Plusリリースでは、クラスタリング機能をさらに強化し、クラスター対応の新機能を導入する予定です。
• OpenID Connect統合 – OpenID Connect認可コードフローを使用し、クライアントにJSON Web Token（JWT）を発行することで、NGINX Plusを利用してあらゆるWebアプリケーションにシングルサインオン（SSO）を提供できるようになりました。NGINX Plusは、CA Single Sign-On（旧SiteMinder）、ForgeRock OpenAM、Keycloak、Okta、OneLogin、Ping Identityをはじめとする一般的なアイデンティティプロバイダーと統合できます。
• NGINX JavaScript（njs）モジュールの機能強化 – njsモジュール（旧称nginScript）を使用すると、NGINX Plusのリクエスト処理中にJavaScriptコードを実行できます。HTTP向けnjsモジュールでは、クライアントリクエストから独立した非同期のHTTPサブリクエストを発行できるようになりました。APIゲートウェイのユースケースに役立ち、JavaScriptを使用してAPI呼び出しを柔軟に変更、統合できます。また、HTTP向けとTCP/UDP向けの両方のnjsモジュールに、一般的なハッシュ関数を実装できる暗号化ライブラリが追加されました。

このリリースでは、このほかにも、新しいALPN変数や複数の動的モジュールのアップデートなど、さらに多くの新機能が追加されています。

動作の変更

• NGINX Plus R13では、まったく新しいNGINX Plus APIが導入されました。このAPIでは、アップストリームグループの動的構成や拡張メトリクスなど、従来は個別のAPIで実装されていた機能を利用できます。従来のAPIは、upstream_confおよびstatusディレクティブで構成されており、非推奨です。構成内にこれらのディレクティブがないか確認し、可能な限り早く新しいapiディレクティブに移行することを推奨します（詳細については、F5のブログ記事「NGINX Plus R13の発表」をご覧ください）。次のリリースであるNGINX Plus R16以降、非推奨のAPIは提供されなくなります。
• このリリースでは、NGINX Plus APIがバージョン3に更新されました。以前のバージョンも引き続きサポートされます。APIクライアントの更新を検討している場合は、API互換性に関するドキュメントを参照してください。
• 「公式リポジトリ」で提供されるNGINX Plusパッケージに、新しい番号体系が導入されました。NGINX Plusパッケージとすべての動的モジュールに、NGINX Plusのリリース番号が表示されるようになりました。各パッケージのバージョンがNGINX Plusのバージョンに対応するため、インストールされているバージョンがより明確になり、モジュールの依存関係も簡素化されます。バージョン番号でパッケージを参照する自動化システムを使用していない限り、この変更による影響はありません。使用している場合は、まず非本番環境でアップグレードプロセスをテストしてください。

NGINX Plus R15の機能詳細

gRPCサポート

このリリースでは、NGINX PlusでgRPCトラフィックのプロキシ処理と負荷分散が可能になりました。gRPCは、すでに多くの組織でマイクロサービスとの通信に使用されています。gRPCは、サービス間で高効率かつ低遅延の通信を実現するためにGoogleが設計した、オープンソースの高性能リモートプロシージャコール（RPC）フレームワークです。gRPCでは、トランスポートメカニズムとしてHTTP 1.1ではなくHTTP/2が必須です。これは、フロー制御、多重化、低遅延の双方向トラフィックストリーミングといったHTTP/2の機能が、大規模なマイクロサービス間の接続に最適だからです。

NGINXはgRPCトラフィックをルーティングし、SSL終端を行います

gRPCのサポートはNGINX Open Source 1.13.10で導入され、現在はNGINX Plus R15にも含まれています。これにより、gRPCメソッド呼び出しを検査してルーティングし、以下のことが可能になります。

• 公開されているgRPCサービスに、HTTP/2 TLS暗号化、レート制限、IPアドレスベースのアクセス制御リスト、ロギングなどのNGINX Plus機能を適用できます。
• gRPC接続を検査し、内部サービスにプロキシすることで、単一のエンドポイントを介して複数のgRPCサービスを公開します。
• 追加のキャパシティが必要な場合は、gRPC接続をアップストリームのバックエンドプールに負荷分散することで、gRPCサービスをスケールできます。
• NGINX Plusを、gRPCとRESTfulの両方のエンドポイントに対応するAPIゲートウェイとして使用します。

詳細については、F5のブログ記事「NGINX 1.13.10でのgRPCサポートの導入」をご覧ください。

HTTP/2サーバープッシュ

第一印象は重要です。ページの読み込み時間は、ユーザーがWebサイトを再訪するかどうかを左右する重要な要因です。HTTP/2 Server Pushを使用すると、ユーザーが待機するRTT（ラウンドトリップ時間、リクエストの送信からレスポンスの受信までに要する時間）の回数が減り、より迅速にレスポンスを提供できます。

NGINXは、クライアントにリソースを先行してプッシュすることで、パフォーマンスを向上できます

HTTP/2サーバープッシュは、NGINXオープンソースコミュニティから多くの要望と期待が寄せられていた機能で、NGINX Open Source 1.13.9で導入されました。現在はNGINX Plus R15にも搭載されており、クライアントが開始した先行リクエストの完了に必要となる可能性が高いデータを、サーバーから先回りして送信できます。たとえば、ブラウザでWebページを表示するには、スタイルシートや画像など、さまざまなリソースが必要です。そのため、ブラウザから明示的にリクエストされるのを待つのではなく、クライアントが最初にページへアクセスした時点で、それらのリソースを直ちに送信することが有効な場合があります。

以下の設定例では、http2_pushディレクティブを使用して、demo Webページのレンダリングに必要なスタイルシートと画像をあらかじめクライアントに送信します。

コード例を読み込み中…

ただし、クライアントが必要とするリソースを正確に特定できず、NGINX設定ファイルに特定のファイルを列挙することが現実的でない場合もあります。このような場合、NGINXはHTTP Linkヘッダーをインターセプトし、その中でpreloadと指定されたリソースをプッシュできます。Linkヘッダーのインターセプトを有効にするには、http2_push_preloadディレクティブをonに設定します。

コード例を読み込み中…

詳しくは、F5のブログ記事「NGINX 1.13.9で導入されたHTTP/2サーバープッシュ」をご覧ください。

クラスター全体での状態共有

複数のNGINX Plusサーバーで高可用性クラスターを構成すると、アプリケーションのレジリエンスが向上し、アプリケーションスタックの単一障害点を排除できます。NGINX Plusクラスタリングは、レジリエンスと高可用性が最優先されるミッションクリティカルな本番環境への導入を想定して設計されています。NGINX Plusによる高可用性クラスタリングの導入には、さまざまなソリューションがあります。

NGINX Plusの以前のリリースでクラスタリングのサポートが導入され、次の2つのクラスタリング階層が提供されています。

• keepalivedパッケージを使用したネットワークの耐障害性 – NGINX Plusサーバーが停止した場合にフェイルオーバーを処理します。
• Configuration synchronization using the nginx-syncパッケージを使用した構成の同期 – すべてのNGINX Plusサーバー間で構成が同期されていることを保証します。

NGINX Plus R15では、クラスタリングの第3の階層として、実行時の状態共有が導入され、クラスタノード間で共有メモリゾーン内のデータを同期できるようになりました。具体的には、Sticky Learnセッション永続化のために共有メモリゾーンに保存されたデータを、新しいTCP/UDPトラフィック用の「zone_sync」モジュールを使用して、クラスタ内のすべてのノード間で同期できるようになりました。

新しい「zone_sync」モジュール

状態共有ではプライマリノードは存在せず、すべてのノードが対等な関係で、フルメッシュトポロジーを介してデータを交換します。また、状態共有クラスタリングソリューションは、ネットワークの耐障害性を確保する高可用性ソリューションから独立しています。そのため、状態共有クラスタは複数の物理拠点にまたがって構成できます。

NGINX Plusの状態共有クラスターは、次の3つの要件を満たす必要があります。

• すべてのクラスターノード間のネットワーク接続
• 同期されたクロック
• 各ノードで次のように設定すると、zone_syncモジュールが有効になります。

  コード例を読み込み中…

The zone_syncディレクティブを使用すると、クラスター内の共有メモリゾーンを同期できます。zone_sync_serverディレクティブは、クラスター内の他のNGINX Plusインスタンスを指定します。NGINX PlusはDNSサービスディスカバリをサポートしているため、クラスターのメンバーをホスト名で識別でき、各メンバーに同一の構成を使用できます。

上記の最小構成には、本番環境で同期データを保護するために必要なセキュリティ制御がありません。次の構成スニペットでは、そのような保護対策をいくつか使用しています。

• 同期データのSSL/TLS暗号化
• クライアント証明書認証により、各クラスターノードが相互に自身を識別（相互TLS）
• IPアドレスを使用するアクセス制御リスト（ACL）により、同じ物理ネットワーク上のNGINX Plusノードのみが同期のために接続可能

コード例を読み込み中…

Sticky Learnセッション永続化のための状態共有

クラスタ全体で共有される状態データを使用する、最初にサポートされたNGINX Plusの機能は、Sticky Learnセッション永続化です。セッション永続化では、クライアントからのリクエストが、そのクライアントの最初のリクエストを処理したサーバーに常に転送されます。これは、セッション状態がバックエンドに保存されている場合に役立ちます。

以下の設定では、sticky learnディレクティブにより、sessionsという共有メモリゾーンが定義されます。syncパラメーターは、NGINX Plusに対して共有メモリゾーンの内容に関するメッセージをクラスター内の他のノードに送信するよう指示することで、クラスター全体での状態共有を有効にします。

状態データを正しく同期するには、クラスター内のすべてのNGINX Plusノードの設定に、同一のupstreamブロックと、sticky learnディレクティブ、およびzone_syncモジュールを有効にするディレクティブ（上記を参照）を含める必要があります。

コード例を読み込み中…

注記：クラスタリングのサポートとSticky Learnセッション永続化は、NGINX Plusでのみ利用できます。

OpenID Connect統合

多くの企業では、IDおよびアクセス管理（IAM）ソリューションを使用してユーザーアカウントを管理し、複数のアプリケーションにシングルサインオン（SSO）環境を提供しています。また、複雑さとコストを最小限に抑えるため、新規および既存のアプリケーション全体にSSOを拡張することがよくあります。

「NGINX PlusでOpenID Connectを使用することで、アイデンティティプロバイダーとの統合を迅速かつ容易に行うと同時に、アプリケーションアーキテクチャを簡素化できました」— Scott Macleod、NHS Digital、ソフトウェアエンジニア

NGINX Plus R10では、OpenID Connectトークンの検証がサポートされました。このリリースではこの機能が拡張され、NGINX Plusが認可コードフローを制御して、OpenID Connect 1.0による認証を行えるようになりました。NGINX Plusはアイデンティティプロバイダーと通信し、クライアントにアクセストークンを発行します。これにより、CA Single Sign‑On（旧SiteMinder）、ForgeRock OpenAM、Keycloak、Okta、OneLogin、Ping Identityなど、主要なアイデンティティプロバイダーのほとんどと統合できます。今回拡張された機能では、さらに以下のことが可能です。

• レガシーアプリケーションを変更またはモダナイズすることなく、SSOを適用
• アプリケーションコードにSSOや認証を実装することなく、新しいアプリケーションにSSOを統合
• ベンダーロックインを解消し、独自仕様のIAMベンダー製エージェントソフトウェアをアプリケーションとともに導入することなく、標準規格に準拠したSSOを利用できます

NGINX PlusとOpenID Connectの統合は、リファレンス実装としてGitHubで提供されています。GitHubリポジトリには、インストール、設定、および特定のユースケースに応じた微調整の手順とサンプル設定が含まれています。

NGINX JavaScript Moduleの機能強化

［編集者 – 以下の例は、NGINX JavaScriptモジュールの数多くあるユースケースの一部にすぎません。完全な一覧については、「NGINX JavaScriptモジュールのユースケース」を参照してください。

このセクションのコードは、ブログの初回公開以降に行われたNGINX JavaScriptの実装変更を反映するため、次のように更新されています。

• Streamモジュール向けにリファクタリングされたセッション（s）オブジェクトを使用するため。このオブジェクトは、NGINX JavaScript 0.2.4で導入されました。
• 使用するには、js_importディレクティブを使用します。このディレクティブは、js_includeディレクティブに代わるもので、NGINX Plus R23以降で利用できます。詳細については、NGINX JavaScriptモジュールのリファレンスドキュメントを参照してください。設定例セクションに、NGINX設定ファイルとJavaScriptファイルの正しい構文が記載されています。

]

NGINX JavaScriptモジュールのnjs（旧称nginScript）を使用すると、NGINX設定にJavaScriptコードを組み込み、HTTPまたはTCP/UDPリクエストの処理時に実行時評価を行えます。これにより、トラフィックをよりきめ細かく制御する、複数のアプリケーションにまたがるJavaScript関数を統合する、セキュリティ脅威から防御するなど、幅広いユースケースに対応できます。

NGINX Plus R15では、njsに2つの重要なアップデートが加わりました。サブリクエストとハッシュ関数です。

サブリクエスト

クライアントリクエストから独立した非同期のHTTPリクエストを、同時に発行できるようになりました。これにより、さまざまな高度なユースケースに対応できます。

以下のJavaScriptサンプルコードは、2つの異なるバックエンドにHTTPリクエストを同時に送信します。最初のレスポンスはNGINX Plusに送信され、クライアントに転送されます。2番目のレスポンスは無視されます。

コード例を読み込み中…

対応するNGINX Plus設定のjs_importディレクティブは、fastest_wins.jsからJavaScriptコードを読み込みます。ルートロケーション（/）に一致するすべてのリクエストは、sendFastest()関数に渡されます。この関数は、/server_oneおよび/server_twoロケーションへのサブリクエストを生成します。クエリパラメーターを含む元のURIは、対応するバックエンドサーバーに渡されます。両方のサブリクエストがdoneコールバック関数を実行します。ただし、この関数にはr.return()が含まれているため、先に完了したサブリクエストのみがクライアントにレスポンスを送信します。

コード例を読み込み中…

ハッシュ関数

HTTPトラフィックとTCP/UDPトラフィックの両方に対応するnjsモジュールに、以下を実装した暗号ライブラリが追加されました。

• ハッシュ関数：MD5、SHA‑1、SHA‑256
• 使用するHMAC：MD5、SHA‑1、SHA‑256
• ダイジェスト形式：Base64、Base64URL、16進数

ハッシュ関数の使用例として、アプリケーションCookieにデータ整合性を付加する方法があります。次のnjsコードサンプルには、Cookieにデジタル署名を付加するsignCookie()関数と、署名付きCookieを検証するvalidateCookieSignature()関数が含まれています。

コード例を読み込み中…

次のNGINX Plus構成では、njsコードを使用して受信HTTPリクエストのCookie署名を検証し、検証に失敗した場合はクライアントにエラーメッセージを返します。検証に成功した場合、またはCookieが存在しない場合、NGINX Plusはリクエストをプロキシします。

コード例を読み込み中…

NGINX Plus R15のその他の新機能

ストリームモジュール向けのALPN変数

Application Layer Protocol Negotiation（ALPN）はTLSの拡張機能です。クライアントとサーバーはTLSハンドシェイク中に、確立する接続で使用するプロトコルをネゴシエートできます。これにより、遅延を招いてユーザーエクスペリエンスを低下させる可能性がある追加のラウンドトリップを回避できます。ALPNの最も一般的なユースケースは、クライアントとサーバーの両方がHTTP/2をサポートしている場合に、接続をHTTPからHTTP/2へ自動的にアップグレードすることです。

新しいNGINX変数$ssl_preread_alpn_protocolsは、NGINX Open Source 1.13.10で初めて導入され、ALPNの事前読み取りフェーズでクライアントがClientHelloメッセージにより通知したプロトコルのリストを取得します。以下の設定では、XMPPクライアントがALPNを介して自身を識別できるため、NGINX Plusは単一のエンドポイントを通じて、XMPPトラフィックをxmpp_backendアップストリームグループに、gRPCトラフィックをgrpc_backendに、その他すべてのトラフィックをhttp_backendにルーティングします。

NGINX PlusがClientHelloメッセージから情報を抽出し、$ssl_preread_alpn_protocols変数に値を設定できるようにするには、ssl_preread onディレクティブも含める必要があります。

コード例を読み込み中…

詳細については、ngx_stream_ssl_prereadモジュールのドキュメントをご覧ください。

キュー待機時間変数

NGINX Plusは、アップストリームキューイングをサポートしているため、アップストリームグループ内のすべてのサーバーが新しいリクエストを受け付けられない場合でも、クライアントリクエストを即座に拒否する必要はありません。

アップストリームキューイングの一般的なユースケースは、すべてのサーバーがビジー状態の場合でもリクエストを即座に拒否せずに、バックエンドサーバーを過負荷から保護することです。各アップストリームサーバーの最大同時接続数は、max_connsパラメーターをserverディレクティブに指定して定義できます。queueディレクティブは、接続数が上限に達した場合やヘルスチェックに失敗した場合など、利用可能なバックエンドがないときにリクエストをキューに格納します。

このリリースでは、NGINX Open Source 1.13.9で初めて導入された新しいNGINX変数$upstream_queue_timeにより、リクエストがキュー内で待機した時間を取得できます。以下の設定には、各リクエストのさまざまなタイミング指標を取得するカスタムログ形式が含まれています。取得した指標は、パフォーマンスチューニングの一環としてオフラインで分析できます。my_backendアップストリームグループでキューに入れるリクエスト数は20件に制限します。timeoutパラメーターでは、クライアントにエラーメッセージ（デフォルトでは503）を返すまでリクエストをキューに保持する時間を設定します。ここでは5秒に設定します（デフォルトは60秒です）。

コード例を読み込み中…

詳細については、queueディレクティブのドキュメントを参照してください。

エスケープなしのアクセスログ

NGINX Plusのアクセスログでエスケープ処理を無効にできるようになりました。新しい「escape=none」パラメーターは、log_formatディレクティブに指定するもので、NGINX Open Source 1.13.10で初めて導入されました。このパラメーターを指定すると、変数内の特殊文字にエスケープ処理が適用されません。

LDAP認証リファレンス実装の更新

LDAP認証システムを使用してユーザーを認証するためのリファレンス実装を更新し、問題への対処とバグ修正を行いました。GitHubでご確認ください。

root権限を使用しない透過プロキシ

NGINX Plusを透過プロキシとして使用するには、transparentパラメーターをproxy_bindディレクティブに指定します。ワーカープロセスがマスタープロセスからCAP_NET_RAW Linuxケイパビリティを継承できるようになったため、NGINX Plusで透過プロキシを使用する際に特別な権限は不要になりました。

注記：この機能はLinuxプラットフォームにのみ適用されます。

JWT猶予期間

JWTに時間ベースのクレーム（nbf（有効開始日時）、exp（有効期限）、またはその両方）が含まれている場合、NGINX PlusによるJWTの検証では、現在時刻が指定された時間範囲内にあるかどうかも確認されます。ただし、IDプロバイダーのクロックがNGINX Plusインスタンスのクロックと同期していない場合、トークンが予期せず期限切れになったり、有効開始時刻が未来に設定されているように見えたりすることがあります。2つのクロック間で許容される最大のずれを設定するには、auth_jwt_leewayディレクティブを使用します。

Cookie Flag動的モジュール

Cookieフラグを設定するサードパーティ製モジュールが、NGINXリポジトリでCookie-Flag動的モジュールとして利用できるようになりました。このモジュールは、NGINX Plusサポート契約の対象です。パッケージ管理ツールを使用してインストールできます。

$ apt-get install nginx-plus-module-cookie-flag # Ubuntu/Debian$ yum install nginx-plus-module-cookie-flag     # Red Hat/CentOS

NGINX ModSecurity WAFモジュールのアップデート

NGINX ModSecurity WAFは、ModSecurity 3.0をベースとするNGINX Plus向けの動的モジュールです。今回のアップデートでは、以下の機能強化が行われました。

• パフォーマンスの向上：libmodsecurity
• メモリリークの修正：ModSecurity-nginx

［編集者注 — NGINX ModSecurity WAFは、2022年4月1日付で正式に販売終了となり、2024年3月31日付でサポート終了となります。詳細については、F5のブログ記事「F5 NGINX ModSecurity WAFのサポート終了への移行<.htmla>」をご覧ください。］

NGINX Plusへのアップグレードまたはトライアル

NGINX Plus R15では、クライアントアプリケーション向けの認証機能の改善、クラスタリング機能の追加、njsの機能強化に加え、重要なバグ修正が行われています。

NGINX Plusをご利用の場合は、できるだけ早くRelease 15へアップグレードすることを強く推奨します。アップグレードにより、さまざまな修正や改善が適用されるほか、サポートチケットを起票する際に、より円滑なサポートを受けられます。NGINX Plus R15のインストールおよびアップグレード手順については、カスタマーポータルをご覧ください。

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

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

著者について

Liam Crillyプロダクトマネジメント担当シニアディレクター

Liam Crillyのその他のブログ記事