NGINX Plus R15 の発表

当社の主力製品である NGINX Plus の 15 番目のバージョンが利用可能になったことをお知らせいたします。 2013 年の最初のリリース以来、NGINX Plus は機能セットと商業的魅力の両面で飛躍的に成長しました。 現在、NGINX Plus の顧客は [ngx_snippet name='nginx-plus-customers'] 社を超え、 NGINX Open Source のユーザーは [ngx_snippet name='number-sites'] 社を超えています。

NGINX オープンソースをベースにした 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 トークン (JWT) を発行することで、NGINX Plus で任意の Web アプリケーションにシングル サインオン (SSO) を提供できるようになりました。 NGINX Plus は、CA Single Sign‑On (旧 SiteMinder)、ForgeRock OpenAM、Keycloak、Okta、OneLogin、Ping Identity、その他の一般的な ID プロバイダーと統合されます。
• 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 は、 upstream_confおよびstatusディレクティブで設定されており、非推奨です。 これらのディレクティブの設定を確認し、できるだけ早く新しいapiディレクティブに変換することをお勧めします (詳細については、ブログの「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 は、Google が高効率で低遅延のサービス間通信用に設計したオープンソースの高性能リモート プロシージャ コール (RPC) フレームワークです。gRPC では、HTTP/2 の機能 (フロー制御、多重化、低遅延の双方向トラフィック ストリーミング) が大規模なマイクロサービス接続に最適であるため、トランスポート メカニズムとして HTTP 1.1 ではなく HTTP/2 が必須となっています。

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

• 公開された gRPC サービスに、HTTP/2 TLS 暗号化、レート制限、IP アドレスベースのアクセス制御リスト、ログ記録などの NGINX Plus 機能を適用します。
• 内部サービスへの gRPC 接続を検査およびプロキシすることで、単一のエンドポイントを通じて複数の gRPC サービスを公開します。
• 追加の容量が必要な場合は、gRPC 接続をアップストリーム バックエンド プールに負荷分散することで、gRPC サービスを拡張します。
• gRPC と RESTful エンドポイントの両方の API ゲートウェイとして NGINX Plus を使用します。

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

HTTP/2 サーバープッシュ

第一印象は重要であり、ページの読み込み時間はユーザーが Web サイトに再度アクセスするかどうかを決定する重要な要素です。 HTTP/2 サーバー プッシュを使用してユーザーに高速応答を提供する方法の 1 つは、ユーザーが待機しなければならない RTT (ラウンドトリップ時間、要求と応答に必要な時間) の数を削減することです。

HTTP/2 サーバー プッシュは、NGINX オープン ソース コミュニティから強く要望され、期待されていた機能であり、NGINX オープン ソース 1.13.9 で導入されました。 NGINX Plus R15に搭載されたこの機能により、サーバーは、以前のクライアントが開始したリクエストを完了するために必要になる可能性のあるデータを事前に送信できるようになります。 たとえば、ブラウザは Web サイトのページをレンダリングするためにスタイルシートや画像などのさまざまなリソースを必要とするため、ブラウザが明示的にリソースを要求するのを待つのではなく、クライアントがページに初めてアクセスしたときにそれらのリソースをすぐに送信することが理にかなっている場合があります。

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

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

詳細については、弊社のブログの「NGINX 1.13.9 を使用した HTTP/2 サーバー プッシュの導入」をご覧ください。

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

複数の NGINX Plus サーバーを高可用性クラスターに構成すると、アプリケーションの耐障害性が向上し、アプリケーション スタック内の単一障害点が排除されます。 NGINX Plus クラスタリングは、回復力と高可用性が最も重要となるミッションクリティカルな本番環境向けに設計されています。 NGINX Plus を使用して高可用性クラスタリングを展開するためのソリューションは多数あります。

クラスタリング サポートは NGINX Plus の以前のリリースで導入され、2 層のクラスタリングが提供されました。

• keepalived パッケージを使用したネットワークの復元力- NGINX Plus サーバーがダウンした場合にフェイルオーバーを処理します。
• nginx-syncパッケージを使用した構成の同期- すべての NGINX Plus サーバー間で構成が同期されていることを確認します。

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

新しいzone_syncモジュール

状態共有ではプライマリ ノードは存在せず、すべてのノードがピアとなり、フル メッシュ トポロジでデータを交換します。 さらに、状態共有クラスタリング ソリューションは、ネットワークの復元力のための高可用性ソリューションからは独立しています。 したがって、状態共有クラスターは物理的な場所にまたがることができます。

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

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

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

上記の最小限の構成には、実稼働環境で同期データを保護するために必要なセキュリティ制御が欠けています。 次の構成スニペットでは、このような安全対策がいくつか採用されています。

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

スティッキーラーンセッション持続性のための状態共有

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

次の設定では、 sticky learnディレクティブによってsessionsと呼ばれる共有メモリ ゾーンが定義されます。 syncパラメータは、NGINX Plus に共有メモリ ゾーンの内容に関するメッセージをクラスタ内の他のノードに公開するように指示することで、クラスタ全体の状態共有を可能にします。

状態データの同期が正しく機能するためには、クラスター内のすべての NGINX Plus ノードの設定に、 sticky learnディレクティブを含む同じアップストリームブロックと、 zone_syncモジュールを有効にするディレクティブ (上記で説明) が含まれている必要があることに注意してください。

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

OpenID Connect 統合

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

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

• アプリケーションを変更したり最新化したりすることなく、SSO をレガシー アプリケーションに拡張します。
• アプリケーション コードに SSO や認証を実装せずに、新しいアプリケーションに SSO を統合します。
• ベンダーロックインを排除。アプリケーションに独自のIAMベンダーエージェントソフトウェアを導入することなく、標準ベースのSSOを実現

NGINX Plus と OpenID Connect の統合は、GitHub でリファレンス実装として利用できます。 GitHub リポジトリには、特定のユースケースに合わせたインストール、構成、微調整の手順が記載されたサンプル構成が含まれています。

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

[編集者注– 以下の例は、NGINX JavaScript モジュールの多くの使用例のうちのほんの一部です。 完全なリストについては、 「NGINX JavaScript モジュールの使用例」を参照してください。

このセクションのコードは、ブログが最初に公開されてから NGINX JavaScript の実装に加えられた変更を反映するために、次のように更新されています。

• NGINX JavaScript 0.2.4で導入された Stream モジュールのリファクタリングされたセッション ( s ) オブジェクトを使用します。
• 使用するには js_インポート 指令は、 js_include 指令の NGINX プラス 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進数

ハッシュ関数の使用例の 1 つは、アプリケーション クッキーにデータの整合性を追加することです。 次の njs コード サンプルには、Cookie にデジタル署名を追加するsignCookie()関数と、署名された Cookie を検証するvalidateCookieSignature()関数が含まれています。

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

NGINX Plus R15 の追加の新機能

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

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

NGINX Open Source 1.13.10 で初めて導入された新しい NGINX 変数$ssl_preread_alpn_protocolsは、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パラメータを使用して、各アップストリーム サーバーの同時接続の最大数を定義できます。 キューディレクティブは、接続制限に達したか、ヘルス チェックに失敗したために利用可能なバックエンドがない場合に、リクエストをキューに入れます。

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

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

逃げずにログにアクセス

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

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

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

ルート権限なしの透過プロキシ

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

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

JWT 猶予期間

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

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 モジュールのアップデート

ModSecurity 3.0 に基づく NGINX Plus の動的モジュールであるNGINX ModSecurity WAFが、次の機能強化を加えて更新されました。

• libmodsecurityのパフォーマンス改善
• ModSecurity-nginxのメモリリークの修正

[編集者注– NGINX ModSecurity WAF は、2022 年 4 月 1 日をもって正式に販売終了となり、 2024 年 3 月 31 日をもってサポート終了となります。 詳細については、弊社ブログの「F5 NGINX ModSecurity WAF はサポート終了に移行しています<.htmla>」をご覧ください。

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

NGINX Plus R15には、クライアント アプリケーションの認証機能の改善、クラスタリング機能の追加、njs の機能強化、および注目すべきバグ修正が含まれています。

NGINX Plus を実行している場合は、できるだけ早くリリース 15 にアップグレードすることを強くお勧めします。 アップグレードすることで、さまざまな修正や改善が受けられ、サポート チケットを発行する必要があるときにサポートしやすくなります。 NGINX Plus R15のインストールおよびアップグレードの手順は、カスタマー ポータルで入手できます。

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

NGINX Plus をまだ使用したことがない場合は、Web アクセラレーション、負荷分散、アプリケーション配信、または強化された監視および管理 API を備えた完全にサポートされた Web サーバーとして、ぜひお試しください。 30 日間の無料評価版で、今すぐ無料で始めることができます。 NGINX Plus がアプリケーションの配信と拡張にどのように役立つかを実際にご確認ください。