ブログ | NGINX

NGINX Plus R12 の発表

NGINX-F5 水平黒タイプ RGB の一部
オーウェン・ギャレット サムネイル
オーウェン・ギャレット
2017 年 3 月 14 日公開

[編集者 – この投稿は、元の投稿で説明されていた個別の動的設定およびステータス モジュールを置き換えて非推奨とするNGINX Plus API を参照するように更新されました。]

本日、NGINX Plus R12 がすべての NGINX Plus 加入者向けに無料アップグレードとして利用可能になったことをお知らせいたします。 NGINX Plus は、ロードバランサー、コンテンツ キャッシュ、Web サーバーを含む高性能ソフトウェア アプリケーション配信プラットフォームです。 NGINX Plus R12 は、クラスタリング、カスタマイズ、監視に重点を置いた新機能を備えた重要なリリースです。

NGINX Plus R12 の詳細については、オンデマンド ウェビナーをご覧ください。

エンタープライズ ユーザーは、NGINX Plus サーバーの高可用性クラスターの管理プロセスを簡素化する新しいクラスタリング機能のメリットを享受できます。 すべてのユーザーは、NGINX 構成に直接埋め込まれた軽量で高性能なスクリプト言語である nginScript の公式サポートの恩恵を受けることができます。 監視と計測、キャッシュ、ヘルスチェックの改善により、アプリケーションの信頼性とパフォーマンスが向上します。

さらなる機能強化により、TCP サービスのクライアント証明書認証、OAuth JWT のカスタム フィールドを検査する機能、 Image-Filter モジュールでの WebP 形式のサポート、およびパフォーマンスと安定性のさまざまな改善が提供されます。

このリリースのパフォーマンス、機能、信頼性の向上を活用するために、すべての加入者はすぐに NGINX Plus R12 にアップデートすることをお勧めします。 更新を実行する前に、次のセクションに記載されている動作の変更を必ず確認してください。

行動の変化

NGINX Plus R12 では、アップグレード時に注意する必要があるデフォルトの動作と NGINX Plus 内部にいくつかの変更が導入されています。

  • キャッシュ メタデータ形式- 内部キャッシュ メタデータ ヘッダーの形式が変更されました。 NGINX Plus R12 にアップグレードすると、ディスク上のキャッシュが無効になり、NGINX Plus は必要に応じてキャッシュを自動的に更新します。 古いキャッシュエントリは自動的に削除されます。
  • SSL “DN” 変数– $ssl_client_s_dnおよび$ssl_client_i_dn変数の形式が変更されました。 カンマ（ , ）は、スラッシュ（ / ）の代わりにフィールド区切り文字として機能し、RFCに従ってエスケープされます。2253そして4514。 スラッシュ フィールド区切り文字を使用したX509_NAME_oneline形式を引き続き使用するには、 $ssl_client_s_dn_legacyおよび$ssl_client_i_dn_legacy変数を使用します。
  • 最大接続キュー–キューディレクティブは、アップストリーム サーバーが過負荷になった場合に、NGINX Plus にアップストリーム サーバーへの接続をキューに入れるように指示します。 R12 でのメモリとパフォーマンスの最適化の結果として、キューディレクティブは、負荷分散アルゴリズム ( hash 、 ip_hash 、 least_conn 、またはleast_time ) を指定するディレクティブの下のアップストリームブロックに表示されなければなりません。
  • サードパーティの動的モジュール– NGINX, Inc. によって作成または認定された動的モジュールがリポジトリで提供されます。 NGINX Plus R12 で引き続き動作するには、サードパーティ モジュールを NGINX Open Source バージョン 1.11.10 に対して再コンパイルする必要があります。 詳細については、 NGINX Plus 管理者ガイドを参照してください。
  • サポート終了 OS バージョンの最終リリース– Ubuntu はUbuntu 12.04 LTSのサポート終了を発表し、Red Hat はRed Hat Enterprise Linux 5.10+の製品フェーズのサポート終了を発表しました。どちらも 2017 年 3 月 31 日をもって終了します。 NGINX Plus R12 は、これらの OS バージョンに加えて、CentOS 5.10+ および Oracle Linux 5.10+ のパッケージが含まれ、サポートされる最後のリリースです。 NGINX Plus R12 以降も引き続き更新とサポートを受けるには、サポートされている OS バージョンに更新してください。

NGINX Plus R12 の機能詳細

構成の共有

NGINX Plus サーバーは、高可用性とスケーラビリティを実現するために、2 つ以上のインスタンスのクラスターに導入されることがよくあります。 これにより、サーバー障害の影響からサービスを保護することでサービスの信頼性を向上できるほか、スケールアウトして大量のトラフィックを処理することも可能になります。

NGINX Plus は、アクティブ/パッシブまたはアクティブ/アクティブのいずれかの形式でクラスター全体にトラフィックを分散する方法をサポートしています。 NGINX Plus R12 では、クラスター全体で構成を同期するためのサポートされる方法がさらに追加されました。 この設定同期機能により、管理者は単一の場所から NGINX Plus サーバーの「クラスター」を設定できます。 これらのサーバーは、構成の共通サブセットを共有します。

NGINX Plusの設定はプライマリからピアにプッシュされます

構成を同期する方法は次のとおりです。

  1. クラスター内の 1 つ以上の「プライマリ」ノードを指定します。
  2. プライマリ ノードに新しいnginx-syncパッケージをインストールします。
  3. プライマリ ノードに構成の変更を適用します。

  4. nginx-syncパッケージに含まれている構成同期プロセスnginx-sync.shを呼び出して、クラスター内の他の各サーバー (ピア) を更新します。 同期プロセスは、各ピアで次の手順を実行します。

    1. 更新された構成をsshまたはrsync経由でピアにプッシュします。
    2. ピアに対して構成が有効であることを確認し、有効でない場合はロールバックします。
    3. 設定が有効な場合はそれを適用し、ピア上の NGINX Plus サーバーをリロードします。

この機能は、NGINX Plus がフォールト トレラントなサーバーのペア (またはそれ以上の数) に導入されている場合に特に役立ちます。 この方法を使用すると、クラスター内での構成の信頼性の高い展開を簡素化したり、ステージング サーバーから運用サーバーのクラスターに構成をプッシュしたりできます。

詳細な手順については、 NGINX Plus 管理者ガイドを参照してください。

NGINX JavaScript モジュールの一般提供

NGINX Plus R12 では、NGINX JavaScript モジュールが NGINX Open Source と NGINX Plus の両方で安定したモジュールとして一般提供されるようになったことをお知らせします。 [このモジュールは以前は nginScript と呼ばれていましたが、この投稿では名前を同じ意味で使用しています。] nginScript は、NGINX Plus サブスクライバーに対して完全にサポートされています。

nginScript は、 NGINX および NGINX Plus 用の独自の JavaScript 実装<.htmla> であり、サーバー側の使用例とリクエストごとの処理に特化して設計されています。 これにより、JavaScript コードを使用して NGINX Plus 構成構文を拡張し、高度な構成ソリューションを実装できるようになります。

nginScript を使用すると、複雑なロジックを使用してカスタム変数をログに記録したり、アップストリームの選択を制御したり、負荷分散アルゴリズムを実装したり、セッションの永続性をカスタマイズしたり、単純な Web サービスを実装したりすることができます。 今後数週間以内に、これらのソリューションの一部に関する詳細な手順をブログで公開し、利用可能になり次第、ここにリンクを追加します。

具体的には、NGINX Plus R12 には次の機能強化が含まれています。

  • ストリームモジュールの事前読み取りフェーズ
  • ECMAScript 6 数学メソッドと定数
  • endsWith 、 include 、 repeat 、 startsWith 、 trimなどの追加の文字列メソッド
  • スコープ

nginScript は安定していますが、さらに多くのユースケースと JavaScript 言語のサポートに向けた作業が継続されています。 詳細については、弊社のブログの「NGINX JavaScript モジュールを使用して各リクエストに JavaScript のパワーと利便性を活用する」<.htmla> をご覧ください。

新しい統計

NGINX Plus の監視とインストルメンテーションは重要な付加価値であり、NGINX Plus とアップストリーム アプリケーションの両方のパフォーマンスと動作に関する詳細な情報を提供します。 統計情報は、組み込みのグラフィカル ダッシュボードと、お気に入りの監視ツールにエクスポートできる JSON 形式の両方で提供されます。

リリース 12 のアップデートを含む NGINX Plus ライブ アクティビティ監視ダッシュボード
ライブアクティビティモニタリングダッシュボードがNGINX Plus R12向けに更新されました

NGINX Plus R12 では、負荷分散サーバーのパフォーマンス (応答時間) に関する詳細情報、TCP および UDP サービスの動作に関する洞察、問題を特定するためのトラブルシューティングや NGINX Plus を調整してパフォーマンスを最適化するのに役立つさまざまな内部データなど、いくつかの改善が追加されています。

NGINX Plus R12 の新しい統計には以下が含まれます。

  • アップストリーム サーバーの応答時間- NGINX Plus R11 以前では、アップストリーム サーバーからの応答時間は、最小時間負荷分散アルゴリズムが使用された場合にのみ計算されていました。 NGINX Plus R12 以降では、すべてのアルゴリズムの応答時間が測定され、JSON データと組み込みダッシュボードの両方でレポートされます。
  • グラフィカルダッシュボードのTCP/UDPアップストリームの応答コード– TCP/UDP負荷分散用のストリームモジュールは、接続がどのように閉じられたかを識別するための疑似ステータスコードを生成します（200 「成功」を意味する502エラー（「アップストリームが利用できない」など）を$status変数に報告します。 NGINX Plus R12 では、ダッシュボードに一連の列が追加され、HTTP 仮想サーバーにすでに提供されているものと同様に、TCP および UDP 仮想サーバーの応答コードの数が表示されます。 疑似ステータス コードをログに記録して、既存のログ分析ツールと統合することもできます。
  • NGINX Plusのバージョン情報– トラブルシューティングを支援するために、JSONデータでは、NGINX Plusのリリース番号をnginx_build （例： nginx-plus-r12 ）として報告し、NGINXオープンソースのバージョン番号をnginx_version （例：1.11.10 ）。 ダッシュボードでは、メイン タブの左上のボックスに両方の値が表示されます。

  • アップストリーム ホスト名- JSON データでは、サーバーフィールドは IP アドレスとポートによってアップストリーム グループ内のサーバーを識別します。 新しい名前フィールドは、アップストリーム構成ブロック内のサーバーディレクティブへの最初のパラメータを報告します。このパラメータは、ドメイン名または UNIX ドメイン ソケット パス、IP アドレス、ポートのいずれかになります。 ダッシュボードの「 Upstreams」タブと「TCP/UDP Upstreams」タブの左端の「Name」列に、サーバーフィールド (NGINX Plus R11 以前では報告されていた) ではなく、名前フィールドの値が報告されるようになりました。

    新しいメトリックを使用すると、DNS 名、特に複数の IP アドレスに解決される名前を使用して JSON データとダッシュボードを定義すると、アップストリーム サーバーとの相関関係が容易になります。

  • 拡張ステータス データでの共有メモリ ゾーンの使用率– 共有メモリ ゾーンは固定サイズで構成されており、大きすぎない (メモリは割り当てられるが使用されない) また小さすぎない (メモリが使い果たされ、キャッシュされた項目が破棄される) サイズを選択することが困難な場合があります。

    メトリックの新しいインストルメンテーションにより、各共有ゾーンのメモリ使用量の詳細な内部レポートが提供され、メモリ使用量を監視し、NGINX テクニカル サポートから NGINX 構成の最適化に関するより情報に基づいたアドバイスを受けることができます。

  • NGINX Plus アクセス ログでの JSON 準拠のエスケープ– 最新のログ分析ツールの中には、JSON 形式のログ ファイルを効率的に取り込むことができ、フォーマットされていないログ ファイルよりも簡単に洞察を引き出すことができるものがあります。 標準の NGINX Plus log_formatディレクティブで JSON テンプレートを定義でき、ディレクティブの新しいオプションのescapeパラメータは、ログ行が正しくフォーマットされるように JSON 準拠のエスケープを強制します。

詳細については、 「ライブ アクティビティの監視」を参照してください。

強化されたキャッシュ

NGINX Plus R12 では、NGINX Plus キャッシュ エンジンが大幅に強化されています。

更新中に古いコンテンツを提供する

NGINX Plus R12 では、 RFC 5861で定義されているCache-Control拡張機能、 stale-while-revalidateおよびstale-if-errorのサポートが追加されました。 NGINX Plus を設定して、これらのCache-Control拡張機能を尊重し、クライアント要求に遅延を追加することなく、バックグラウンドで更新しながら期限切れのリソースをキャッシュから引き続き提供できるようになりました。 同様に、NGINX Plus は、アップストリーム サーバーが利用できない場合に、期限切れのリソースをキャッシュから提供できます。これは、マイクロサービス アプリケーションにサーキット ブレーカー パターンを実装するための手法です。

Cache-Controlヘッダーを無視するように設定されていない限り、NGINX Plus は、次の例のように、RFC 5861 準拠のCache-Controlヘッダーを返すオリジン サーバーからの古いタイマーを尊重します。

キャッシュ制御: max-age=3600 stale-while-revalidate=120 stale-if-error=900

バックグラウンド更新によるCache-Control拡張機能のサポートを有効にするには、強調表示されたディレクティブを含めます。

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off; server { # ... location / { proxy_cache my_cache; # 更新時に古いコンテンツを提供するproxy_cache_use_stale updating ; # さらに、更新をトリガーする最初のリクエストをブロックせず、バックグラウンドで更新を実行しますproxy_cache_background_update on ; proxy_pass http://my_upstream; } }

proxy_cache_use_stale更新ディレクティブは、更新中にコンテンツの古いバージョンを提供するように NGINX Plus に指示します。 このディレクティブのみを含めると、古いコンテンツを要求した最初のユーザーは「キャッシュ ミス」のペナルティを負うことになります。つまり、NGINX Plus がオリジン サーバーからコンテンツを取得してキャッシュするまで、そのコンテンツを受け取ることができません。 更新中に古いコンテンツを要求したユーザーは、すぐにキャッシュからコンテンツを取得しますが、最初のユーザーは、更新されたコンテンツが取得されてキャッシュされるまで何も取得しません。

新しいproxy_cache_background_updateディレクティブを使用すると、NGINX Plus がバックグラウンドで更新している間、最初のユーザーを含むすべてのユーザーに古いコンテンツが提供されます。

新しい機能は、 FastCGI 、 SCGI 、 uwsgiモジュールでも利用できます。

バイト範囲リクエスト

キャッシュ エンジンのさらなる強化により、NGINX Plus は、キャッシュされていないファイルの開始後、設定されたバイト数を超えて開始するバイト範囲リクエストのキャッシュをバイパスできるようになりました。 つまり、ビデオ コンテンツなどの大きなファイルの場合、ファイルの奥深くにあるバイト範囲を要求しても、クライアント要求に遅延は発生しません。 以前のバージョンの NGINX Plus では、NGINX Plus がファイルの先頭から要求されたバイト範囲までのすべてのコンテンツを取得してキャッシュに書き込むまで、クライアントは要求されたバイト範囲を受け取りませんでした。

新しいproxy_cache_max_range_offsetディレクティブは、NGINX Plus がバイト範囲リクエストを直接オリジン サーバーに渡し、レスポンスをキャッシュしないファイルの先頭からのオフセットを指定します。 (新しい機能は、 FastCGI 、 SCGI 、 uwsgiモジュールでも利用できます。)

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off; server { location / { proxy_cache my_cache; # 10メガバイトを超えるバイト範囲のリクエストではキャッシュをバイパスしますproxy_cache_max_range_offset 10m ; proxy_pass http://my_upstream; } }

これらの機能強化により、NGINX Plus は、アプリケーション配信の高速化から本格的なコンテンツ配信ネットワーク (CDN) の構築まで、あらゆる環境に適した、高性能で標準に準拠したキャッシュ エンジンとしての地位をさらに強化します。

ヘルスチェックの改善

NGINX Plus R12 では、NGINX Plus のアクティブ ヘルス チェック機能がさらに強化されています。

新しく追加されたサーバーのヘルスチェック

コンテナ化された環境と自動スケーリングされたアプリケーション グループの採用が増加するにつれて、ロード バランサーがプロアクティブなアプリケーション レベルのヘルス チェックを実装し、新しいサーバーが稼働する前に内部リソースを初期化する時間を確保することが不可欠になります。

NGINX Plus R12 より前では、 NGINX Plus APIまたは DNS を使用して新しいサーバーをロード バランシング プールに追加すると、NGINX Plus はすぐにそのサーバーを正常であると見なし、トラフィックをすぐに送信していました。 health_checkディレクティブ ( HTTPまたはTCP/UDP ) に新しい必須パラメータを含めると、NGINX Plus がトラフィックを送信する前に、新しいサーバーは構成されたヘルスチェックに合格する必要があります。 スロースタート機能と組み合わせると、新しいパラメータにより、トラフィックの全量を処理するよう要求される前に、新しいサーバーがデータベースに接続して「ウォームアップ」する時間がさらに長くなります。

アップストリーム my_upstream { ゾーン my_upstream 64k; サーバー backend1.example.com slow_start=30s ; } サーバー { location / { proxy_pass http://my_upstream; # トラフィックを受信する前に新しいサーバーがヘルスチェックに合格することを要求します health_check必須; } }

ここでは、 health_checkディレクティブへの必須パラメータと、 serverディレクティブへのslow_startパラメータ ( HTTPまたはTCP/UDP ) の両方が含まれます。 API または DNS インターフェースを使用してアップストリーム グループに追加されたサーバーは、正常でないとマークされ、ヘルス チェックに合格するまでトラフィックを受信しません。ヘルス チェックに合格すると、30 秒間にわたって徐々に増加する量のトラフィックを受信し始めます。

ゼロ構成UDPヘルスチェック

実稼働トラフィックが完全に機能していないサーバーに送信されないように、UDP サーバーに対して HTTP サーバーや TCP サーバーと同様にアプリケーション レベルのヘルス チェックを実装することが重要です。 NGINX Plus は UDP のアクティブ ヘルス チェックをサポートしていますが、NGINX Plus R12 より前では、送信するデータと期待される応答を定義する一致ブロックを作成する必要がありました。 バイナリ プロトコルや複雑なハンドシェイクを使用するプロトコルを使用する場合、適切な値を決定するのは難しい場合があります。 このようなアプリケーションの場合、NGINX Plus R12 では、送信文字列と期待文字列を定義することなくアプリケーションの可用性をテストする UDP の「ゼロ構成」ヘルスチェックがサポートされるようになりました。 基本的な UDP ヘルス チェックを行うには、 health_checkディレクティブにudpパラメータを追加します。

アップストリーム udp_app { server backend1.example.com:1234; server backend2.example.com:1234; } server { listen 1234 udp; proxy_pass udp_app; # 基本的な UDP ヘルスチェックhealth_check udp ; }

SSL アップデート – TCP サービスのクライアント証明書、更新された変数

SSL クライアント証明書は、保護された Web サイトへのユーザーを認証するためによく使用されます。 NGINX Plus R12 では、既存の HTTP サポートに加えて、SSL で保護された TCP サービスの認証サポートが追加されました。 これは通常、エンドユーザーのログインではなく、マシン間認証に使用され、レイヤー 4 プロトコルの負荷分散時に SSL 終了とクライアント認証の両方に NGINX Plus を使用できるようになります。 例としては、MQTT プロトコルとの通信のための IoT デバイスの認証が挙げられます。

$ssl_client_verify変数に、失敗したクライアント認証イベントに関する追加情報が含まれるようになりました。 これには、「失効」や「期限切れ」の証明書などの理由が含まれます。

$ssl_client_i_dnおよび$ssl_client_s_dn変数の形式は、RFCに準拠するように変更されました。2253そして4514。 詳細については、 「動作の変更」を参照してください。

強化された JWT 検証

NGINX Plus R10 では、OAuth 2.0 およびOpenID Connect のユースケース向けにネイティブ JSON Web Token (JWT) サポートが導入されました。 主な使用例の 1 つは、NGINX Plus が JWT を検証し、その中のフィールドを検査し、それらを HTTP ヘッダーとしてバックエンド アプリケーションに渡すことです。 これにより、トークン検証を NGINX Plus にオフロードし、HTTP ヘッダーを読み取ってユーザー ID を使用することで、アプリケーションは OAuth 2.0 シングル サインオン (SSO) 環境に簡単に参加できるようになります。

NGINX Plus R10 以降では、JWT 仕様で定義されたフィールドを検査できます。 NGINX Plus R12 では JWT サポートが拡張され、JWT 内の任意のフィールド (カスタム フィールドを含む) に NGINX 変数としてアクセスできるようになり、プロキシ、ログ記録、または認証の決定に使用できるようになりました。

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

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

アップグレードを進める前に、上記の動作の変更を参照してください。

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

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

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