NGINX Plus R19 の発表

NGINX Plus リリース 19 (R19)が利用可能になったことをお知らせします。 NGINX Plus は、ロードバランサー、コンテンツ キャッシュ、Web サーバー、API ゲートウェイをオールインワンで提供する唯一の製品です。 NGINX オープンソースをベースにした NGINX Plus には、独自の拡張機能と受賞歴のあるサポートが含まれています。 このリリースの主な焦点は監視であり、新しい機能によって監視がよりきめ細かく柔軟になり、大規模なアプリケーションの信頼性が向上します。

NGINX Plus R19の新機能は次のとおりです。

• より柔軟な監視-ロケーションブロックのオプションの個別のメトリック収集、DNS ルックアップ アクティビティに関する新しいメトリック、Prometheus 形式と JSON でのエクスポートのサポートなど、NGINX Plus エコシステムのよりきめ細かい洞察とより簡単な分析のための新しい機能を追加しました。 NGINX Plus ダッシュボードには、新しいロケーションごとのメトリックが表示され、DNS メトリックと NGINX Plus クラスターに関するメトリック用の新しいタブが追加されました。
• レート制限をテストするためのドライラン モード– 実稼働トラフィックに適切なレート制限を設定するのは難しく、非常にリスクが伴います。設定を間違えると、大部分のユーザーのユーザー エクスペリエンスに重大な影響を与える可能性があります。 新しいドライラン モードを使用すると、レート制限を実際に適用しなくても、実稼働トラフィックに対するレート制限の影響を把握できます。
• キー値ストアの機能強化– IP アドレス範囲を個々のアドレスとともにキー値ストアに保存し、個々のエントリに有効期限を設定できるようになりました。
• 動的帯域幅制御- 帯域幅制限を構成するときに、レートを変数として設定できるようになり、着信トラフィックの属性に基づいて異なる制限を適用できるようになりました。

行動における重要な変化

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

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

• 新しいオペレーティングシステムのサポート–

  • アルパイン 3.10
  • Debian 10（「バスター」）
  • Ubuntu 19.04（「ディスコ」）

• 古いオペレーティングシステムはサポートされなくなりました–

  • Debian 8 (“ジェシー”)
  • Ubuntu 14.04（「信頼できる」）
  • Ubuntu 18.10（「コズミック」）

サポートされているプラットフォームの詳細については、 NGINX Plusおよび動的モジュールの技術仕様を参照してください。

新機能の詳細

新機能により監視がさらに柔軟に

NGINX Plus R19 では監視がさらに柔軟になり、収集できるメトリックの種類と分析方法の両方が拡張されます。

場所ごとの指標

NGINX Plus API は、 server{}ブロックにstatus_zoneディレクティブを含めると、仮想サーバーに関するいくつかのカウンターを含む、幅広いリアルタイム監視メトリックを提供します。 NGINX Plus R19では、それらのロケーションブロックにstatus_zoneディレクティブを追加することで、親のserver{}ブロックに加えて (または代わりに)、個々のロケーションブロックのメトリックを収集できるようになりました。 このきめ細かい監視により、Web サイトでエラーが発生している正確な部分をより迅速に検出し、より効果的なトラブルシューティングを行うことができます。

次の構成では、Web サイト全体のメトリック収集が有効になり、さらに/admin/で始まる URI へのすべてのリクエストのメトリック収集も有効になります。

その後、 http/location_zonesエンドポイントでメトリックにアクセスできるようになります。

$ curl http://localhost:8080/api/5/http/location_zones { "www_admin": { "requests": 3393、「応答」: {「1xx」: 0、「2xx」： 3307、「3xx」: 81、「4xx」： 5、「5xx」： 0、「合計」: 3393 }, "破棄されました": 0、「受信済み」: 15403、「送信済み」: 835227 } }

status_zoneディレクティブをifブロック内に配置することもできますが、メトリックは特定の場所に対して 1 回だけカウントされ、リクエスト処理中に最後に検出されたstatus_zoneディレクティブからカウントされることに注意してください。 次の構成は、 /admin/ の場所へのリクエストにクエリ文字列が含まれている場合に個別のメトリックを収集することで、前の例を拡張します。

DNS リゾルバ メトリック

NGINX Plus API は、 DNS ルックアップ アクティビティ、特に DNS 要求タイプと応答ステータスを追跡するためのメトリックも拡張されました。 NGINX Plus が名前検索のためにクエリする DNS サーバーのグループに関するメトリックを収集するには、 resolverディレクティブにstatus_zoneパラメータを追加します。

その後、リゾルバのエンドポイントでメトリックにアクセスできるようになります。

$ curl http://localhost:8080/api/5/resolvers { "internal_dns": { "requests": { "name": 132、「srv」: 0、「アドレス」: 0 }, "応答": { "エラーなし": 130、「以前の」： 0、「サーバ失敗」: 0、「nxドメイン」: 0、「notimp」: 0、「拒否」: 0、「タイムアウト」: 2、「不明」: 0 } } }

ライブアクティビティモニタリングダッシュボードの更新

NGINX Plus ライブ アクティビティ モニタリング ダッシュボードは、 NGINX Plus APIによって収集されたメトリックを追跡するための便利な一元的な場所を提供します。ダッシュボードはNGINX Plus R19で拡張され、上記の新しいリゾルバと場所ごとのメトリックが含まれるようになりました。 さらに、以前はNGINX Plus API経由でのみアクセス可能だった、クラスター内のランタイム状態共有に関連するメトリック ( Zone Synchronizationモジュールで有効化) もレポートされるようになりました。

名前が変更されたタブが 2 つと新しいタブが 2 つあります。

• HTTP ゾーンは、サーバー ゾーンタブの新しい名前です。 タブには、サーバーブロックだけでなく、ロケーションブロックに関するメトリックも表示されるようになりました。
• HTTP Upstreams は、 Upstreamsタブの新しい名前です。 これにより、HTTP モジュールと TCP/UDP モジュールの両方が構成されている場合の明確さが確保されます。
• 新しい「クラスター」タブには、NGINX Plus クラスター内の状態共有に関するメトリックが表示されます。
• 新しい「リゾルバー」タブには、DNS ルックアップ アクティビティに関するメトリックが表示されます。

新しいダッシュボードを調べるには、 https://demo.nginx.com/にアクセスしてください。

Prometheus モニタリング用の新しいモジュール

NGINX Plus API は、外部監視およびアプリケーション パフォーマンス管理 (APM) ソリューションとの統合に一般的かつ便利な形式である JSON 形式でメトリックを返します。 Kubernetes 環境で特に人気のある Prometheus 形式でメトリックをエクスポートすることもできるようになりました。

Prometheus-njsモジュールは Prometheus メトリックを公開します。 エクスポートされたメトリックを有効にするには:

1. Prometheus-njsモジュールをインストールします。
2. NGINX Plus APIを設定します。

3. NGINX Plus 構成ファイルで、Prometheus メトリック収集専用の場所を構成します。

4. Prometheus 構成ファイルのscrape_configセクションで NGINX Plus インスタンスのネットワーク アドレスを指定して、NGINX Plus からメトリックを取得するように Prometheus を構成します。

ドライランモードでのレート制限のテスト

NGINX Plus は、レート制限に対して非常に柔軟なアプローチを提供します。 複数のレート制限を一度に追跡して適用できます。 強制措置自体には、過剰な要求を遅らせる、要求を完全に拒否する、強制措置の前に制限のない要求の集中を許可する、およびそれらの動作の組み合わせを含む 5 つの異なる種類があります。 詳しい説明については、ブログをご覧ください。

この柔軟性により、非常に洗練されたレート制限が可能になりますが、そもそもトラフィックの適切なレート制限をどのように決定するのでしょうか? 計画したレート制限が高すぎるか (サーバーが過負荷になる可能性があります)、低すぎるか (ユーザー エクスペリエンスに影響する可能性があります) を事前に判断するにはどうすればよいでしょうか。

最良の情報源は NGINX Plus のエラー ログです。NGINX Plus がリクエストを遅延または拒否すると、次のような詳細なエントリが作成されます。

2019/09/03 11:42:12 [エラー] 57#57: *339 リクエスト制限超過: ゾーン「my_limit」による 0.600、クライアント: 172.17.0.1、サーバー: www.example.com、リクエスト: 「GET / HTTP/1.1」、ホスト:「www.example.com:80」

このエントリには、設定されたレートを超過した 1 ミリ秒あたりのリクエスト数 (超過フィールド)、超過した特定の制限 (ゾーンフィールド)、クライアントの IP アドレス (クライアントフィールド) などの役立つ情報が表示されます。 ただし、実際にトラフィック制限を適用する前に情報を取得できる場合にのみ、計画の目的に役立ちます。

NGINX Plus R19 では、レート制限のための「ドライラン」モードを備えたこの予測機能が追加されました。 ログ エントリは通常どおり作成されますが、レート制限は適用されません。 ドライラン モードを有効にするには、 limit_reqディレクティブと同じブロックに新しいlimit_req_dry_runディレクティブを含めます。

次の例では、 limit_req_zoneディレクティブは、1 秒あたり 10,000 リクエストから 1 秒あたり 10 リクエストまでの 4 つの異なるレート制限を定義します。 これらのレートは、ルートロケーションブロック (9 ～ 12 行目) のlimit_reqディレクティブと、強制を無効にするlimit_req_dry_runディレクティブを使用して適用します。

NGINX Plus は、指定されたレート制限を超えるすべてのリクエストに対して、 dry runと明確にマークされたログエントリを書き込みます。 ログを分析すると、ゾーンフィールドでエントリをフィルター処理して、どのレート制限が目的の動作を実現するかを判断できます。

2019/09/03 11:56:26 [エラー] 142#142: *22282 リクエスト制限、ドライラン、超過: 1.000、ゾーン「1000rs」、クライアント: 172.17.0.1、サーバー: www.example.com、リクエスト: 「GET / HTTP/1.1」、ホスト:「www.example.com:80」

キーバリューストアの強化

NGINX Plus のインメモリ キー値ストアを使用すると、 NGINX Plus API を使用して、リクエストの属性に基づいてトラフィック管理を動的に構成できます。 サンプルの使用例には、 IP アドレスの動的なブラックリスト、動的な帯域幅の制限、認証トークンのキャッシュなどがあります。

ネットワーク範囲のサポート

NGINX Plus R19 では、既存の個々の IP アドレスのサポートに IP ネットワーク範囲 (サブネット) のサポートを追加することで、キー値ストアを拡張します。 つまり、キー値ストア内の単一のエントリがネットワーク範囲内のすべての IP アドレスと一致するため、範囲を構成するアドレスを個別に追加する必要がなくなり、構成が簡素化され、時間が節約されます。 キー値ストアでは、ネットワーク範囲を表すためにCIDR 表記を使用します。 たとえば、192.168.13.0/24 は、アドレス 192.168.13.0 から 192.168.13.255 を表します。 IPv4 と IPv6 の両方のアドレスと範囲がサポートされています。

ネットワーク範囲を有効にするには、IP アドレスの動的ブラックリストの次の構成のように、 keyval_zoneディレクティブに新しいtype=ipパラメータを含めます。 NGINX Plus が検索を実行すると、キー値ストアに保存されているネットワーク範囲内の IP アドレスが一致を返します。

2 行目では、 $remote_addr (クライアント IP アドレス) をキーとして使用して、 denylistキー値ストアで検索を実行し、 $in_denylist変数を評価することを指定します。 単純なifブロック (8 ～ 10 行目) は、クライアント IP アドレスが拒否リストに含まれている場合に要求を拒否します。

次のcurlコマンドは、 NGINX Plus API を呼び出して、上記のネットワーク範囲のキー値ストアにエントリを作成します。

$ curl -X POST -d '{"192.168.13.0/24":"1"}' http://localhost:8080/api/5/http/keyvals/denylist

エントリごとの有効期限のタイムアウト

前のセクションでは、 denylist.confの 1 行目のkeyval_zoneディレクティブのtimeout=24hパラメータは、denylist キー値ストア内の各エントリが作成後 24 時間で期限切れになり (ストアから削除される) ことを意味します。

NGINX Plus R19では、デフォルトのタイムアウト（タイムアウトパラメータによってキー値ストア全体に設定）を、個々のエントリごとに異なるタイムアウトで上書きできます。 個々のタイムアウトはデフォルトより大きくしたり小さくしたりできます。

デフォルト以外のタイムアウトを持つエントリを作成するには、次の 2 つのフィールドを持つ JSON オブジェクトとして値を指定します。

• 値– 希望する値に設定します。この場合は1$in_denylist変数を設定する
• 有効期限– 作成後、値が期限切れになるまでのミリ秒数を設定します

次の JSON は、1 時間 (3,600,000 ミリ秒) で期限切れになる localhost (127.0.0.1) のブラックリスト エントリを表します。

{
"127.0.0.1": {
"値": 「1」、
「期限切れ」: 3600000
}
}

次のcurlコマンドは、キー値ストアにそのエントリを作成します。

$ curl -X POST -d '{"127.0.0.1":{"値":"1","有効期限":3600000}}' http://localhost:8080/api/5/http/keyvals/denylist

動的帯域幅制御

limit_rateディレクティブは、NGINX Plus が HTTP リクエストに応答を送信するレート (1 秒あたりのバイト数) を設定し、 limit_rate_afterディレクティブは、その制限が適用される前に NGINX Plus が送信するバイト数を設定します。 NGINX Plus R19では、各ディレクティブのパラメータを静的な値ではなく変数にすることができるため、リクエストの属性に基づいて帯域幅の使用を動的に制御できます。

次の構成例では、クライアントが使用する TLS のバージョンに応じて帯域幅を設定し、最新のブラウザに高速な応答を効果的に提供します。

以前の NGINX Plus リリースでは、 $limit_rate変数を設定することで帯域幅を制限できましたが、代わりにこのより合理化された方法を使用することをお勧めします。 詳細については、 limit_rateディレクティブのドキュメントを参照してください。

TCP/UDP トラフィックのproxy_download_rateおよびproxy_upload_rateディレクティブも、変数パラメータを受け入れるようになりました。

さらに高度な帯域幅制限を行うには、 NGINX JavaScript モジュール (njs)などのスクリプト拡張機能を使用して、特定の接続に適切な帯域幅制限を決定するための高度なカスタム ロジックを実装できます。

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

NGINX JavaScript モジュール

NGINX JavaScript モジュール (njs) がバージョン 0.3.5に更新されました。 最も注目すべき機能強化（以前のバージョンからの累積）は次のとおりです。

• 矢印関数のサポート (洪志道 [Hong Zhi Dao] と Artem S. Povalyukhin に感謝)
• グローバルプロセスオブジェクト (特に環境変数の読み取りに便利)
• String.prototype.trim関数

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

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

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

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