NGINX Plus R19を発表

NGINX | 2019年9月03日
Liam Crilly
Liam Crillyプロダクトマネジメント担当シニアディレクター


NGINX Plus Release 19（R19）の提供開始をお知らせします。NGINX Plusは、ロードバランサー、コンテンツキャッシュ、Webサーバー、APIゲートウェイを一体化した唯一のソリューションです。NGINX Open SourceをベースとするNGINX Plusには、独自の拡張機能と受賞歴のあるサポートが含まれています。本リリースではモニタリングに重点を置き、よりきめ細かく柔軟なモニタリングを可能にする新機能を追加しました。これにより、大規模環境におけるアプリケーションの信頼性向上を支援します。

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

  • より柔軟なモニタリング – NGINX Plusエコシステムをより詳細に把握し、容易に分析できるよう、新たな機能を追加しました。これには、locationブロックごとに個別にメトリクスを収集するオプション、DNSルックアップのアクティビティに関する新しいメトリクス、JSONに加えてPrometheus形式でのエクスポートのサポートが含まれます。NGINX Plusダッシュボードには、新しいロケーション別メトリクスが表示されるほか、DNSメトリクスとNGINX Plusクラスターに関するメトリクス用の新しいタブが追加されています。
  • レート制限をテストするためのドライランモード – 本番トラフィックに適切なレート制限を設定することは難しく、大きなリスクを伴います。設定を誤ると、多くのユーザーのユーザーエクスペリエンスに深刻な影響を及ぼす可能性があります。新しいドライランモードでは、レート制限を実際に適用することなく、本番トラフィックへの影響を把握できます。
  • キー・バリュー・ストアの機能強化 – キー・バリュー・ストアに個別のIPアドレスだけでなくIPアドレス範囲も保存できるようになり、個々のエントリに有効期限を設定することもできます。
  • 動的帯域幅制御 – 帯域幅制限を設定する際に、レートを変数として指定できるようになりました。これにより、受信トラフィックの任意の属性に基づいて異なる制限を適用できます。

動作に関する重要な変更

  • 廃止されたAPI – NGINX Plus R13（2017年8月リリース）では、メトリクス収集とアップストリームグループの動的な再構成に対応する新しいNGINX Plus APIが導入され、それまでこれらの機能を提供していたStatus APIとUpstream Conf APIに置き換わりました。当時の発表どおり、非推奨となったAPIはその後も長期間にわたり利用およびサポートが継続されましたが、NGINX Plus R16をもって終了しました。構成にstatusまたはupstream_confディレクティブ、あるいはその両方が含まれている場合は、R19へのアップグレード時に、これらをapiディレクティブに置き換える必要があります。新しいNGINX Plus APIへの移行に関するガイダンスやサポートについては、F5のブログに掲載されている移行ガイドをご覧いただくか、サポートチームにお問い合わせください。
  • 新たにサポートされるオペレーティングシステム –
    • Alpine 3.10
    • Debian 10（「Buster」）
    • Ubuntu 19.04（「Disco」）
  • サポート対象外となった旧バージョンのオペレーティングシステム –
    • Debian 8（「Jessie」）
    • Ubuntu 14.04（「Trusty」）
    • Ubuntu 18.10（「Cosmic」）

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

新機能の詳細

新機能でモニタリングがさらに柔軟に

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

ロケーション別メトリクス

NGINX Plus APIでは、仮想サーバーのstatus_zoneディレクティブをserver{}ブロックに含めることで、その仮想サーバーに関する複数のカウンターをはじめ、幅広いリアルタイム監視メトリクスを利用できます。NGINX Plus R19では、個々のlocationブロックにstatus_zoneディレクティブを追加することで、親server{}ブロックに加えて（またはその代わりに）、それらのlocationブロックのメトリクスも収集できるようになりました。この詳細な監視により、Webサイト内でエラーが発生している箇所をより迅速かつ正確に特定し、効率的にトラブルシューティングできます。

以下の設定では、Webサイト全体に加え、先頭が「/admin/」のURIに対するすべてのリクエストについて、メトリクスを収集できます。

コード例を読み込み中…

その後、メトリクスにはhttp/location_zonesエンドポイントからアクセスできます。

$ curl http://localhost:8080/api/5/http/location_zones{
  "www_admin": {
    "requests": 3393,
    "responses": {
      "1xx": 0,
      "2xx": 3307,
      "3xx": 81,
      "4xx": 5,
      "5xx": 0,
      "total": 3393
    },
    "discarded": 0,
    "received": 15403,
    "sent": 835227
  }
}

It is also possible to place the status_zoneディレクティブはifブロック内にも配置できます。ただし、特定のlocationについてメトリクスがカウントされるのは1回のみで、リクエスト処理中に最後に検出されたstatus_zoneディレクティブに基づいてカウントされる点に注意してください。次の設定では前の例を拡張し、/admin/locationへのリクエストにクエリ文字列が含まれる場合に、個別のメトリクスを収集します。

コード例を読み込み中…

DNSリゾルバーのメトリクス

NGINX Plus APIも拡張され、DNSルックアップのアクティビティ、特にDNSリクエストの種類とレスポンスステータスを追跡するためのメトリクスが追加されました。NGINX Plusが名前解決のために問い合わせるDNSサーバーのグループに関するメトリクスを収集するには、status_zoneパラメーターをresolverディレクティブに追加します。

コード例を読み込み中…

その後、resolversエンドポイントでメトリクスにアクセスできます。

$ curl http://localhost:8080/api/5/resolvers{
  "internal_dns": {
    "requests": {
      "name": 132,
      "srv": 0,
      "addr": 0
    },
    "responses": {
      "noerror": 130,
      "formerr": 0,
      "servfail": 0,
      "nxdomain": 0,
      "notimp": 0,
      "refused": 0,
      "timedout": 2,
      "unknown": 0
    }
  }
}

ライブアクティビティ監視ダッシュボードの更新

NGINX Plusのライブアクティビティ監視ダッシュボードでは、NGINX Plus APIで収集されたメトリクスを一元的かつ簡単に追跡できます。NGINX Plus R19ではダッシュボードが拡張され、前述の新しいリゾルバーおよびロケーション単位のメトリクスが追加されました。さらに、これまでNGINX Plus APIからのみアクセスできた、クラスター内のランタイム状態の共有（Zone Synchronizationモジュールで有効化）に関するメトリクスも表示されるようになりました。

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

  • HTTP Zonesは、Server zonesタブの新しい名称です。このタブには、locationブロックに加えて、serverブロックに関するメトリクスも表示されるようになりました。
  • HTTP Upstreamsは、Upstreamsタブの新しい名称です。HTTPモジュールとTCP/UDPモジュールの両方が構成されている場合に、区別しやすくなります。
  • 新しい［Cluster］タブには、NGINX Plusクラスターでの状態共有に関するメトリクスが表示されます。
  • 新しい［Resolvers］タブには、DNSルックアップのアクティビティに関するメトリクスが表示されます。

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

NGINX Plusライブアクティビティ監視ダッシュボードのスクリーンショット

Prometheus監視用の新しいモジュール

NGINX Plus APIは、外部の監視ソリューションやアプリケーションパフォーマンス管理（APM）ソリューションとの統合に広く利用されている便利なJSON形式でメトリクスを返します。さらに、Kubernetes環境で特に広く利用されているPrometheus形式でもメトリクスをエクスポートできるようになりました。

Prometheus-njsモジュールは、Prometheusメトリクスを公開します。エクスポートされたメトリクスを有効にするには、次の手順を実行します。

  1. Prometheus-njsモジュールをインストールします。
  2. NGINX Plus APIを設定します。
  3. NGINX Plus構成ファイルで、Prometheusメトリクス収集専用のlocationを設定します。

    コード例を読み込み中…

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

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

NGINX Plusは、レート制限に対して非常に柔軟なアプローチを提供します。複数のレート制限を同時に追跡し、適用できます。適用方法には、過剰なリクエストの遅延、即時拒否、適用開始前の一時的な無制限リクエストの許可など5種類があり、これらを組み合わせることもできます。詳しくは、F5のブログをご覧ください。

この柔軟性により、きめ細かなレート制限が可能になりますが、そもそもトラフィックに適したレート制限値はどのように決めればよいのでしょうか。設定予定の値が高すぎてサーバーが過負荷になる可能性があるのか、あるいは低すぎてユーザーエクスペリエンスに影響する可能性があるのかを、事前に判断するにはどうすればよいのでしょうか。

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

2019/09/03 11:42:12 [error] 57#57: *339 limiting requests, excess: 0.600 by zone "my_limit", client: 172.17.0.1, server: www.example.com, request: "GET / HTTP/1.1", host: "www.example.com:80"

このエントリからは、このリクエストが設定レートを1ミリ秒あたり何件上回っているか（excessフィールド）、超過した具体的な制限（zoneフィールド）、クライアントのIPアドレス（clientフィールド）など、有用な情報を確認できます。ただし、この情報を計画に役立てるには、トラフィックに対する制限を実際に適用する前に取得できる必要があります。

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

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

コード例を読み込み中…

NGINX Plusは、指定されたレート制限を超える可能性があるリクエストごとに、ログエントリを記録し、dry runと明確にマークします。その後、ログ分析時にエントリをzoneフィールドでフィルタリングし、どのレート制限で目的の動作が得られるかを判断できます。

2019/09/03 11:56:26 [error] 142#142: *22282 limiting requests, dry run, excess: 1.000 by zone "1000rs", client: 172.17.0.1, server: www.example.com, request: "GET / HTTP/1.1", host: "www.example.com:80"

Key-Value Storeの機能強化

NGINX Plusのインメモリキーバリューストアでは、NGINX Plus APIを使用して、リクエストの属性に基づきトラフィック管理を動的に設定できます。主なユースケースには、IPアドレスの動的な拒否リスト登録、帯域幅の動的な制限、認証トークンのキャッシュなどがあります。

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

NGINX Plus R19では、個々のIPアドレスに加えてIPネットワーク範囲（サブネット）もサポートするように、キーバリューストアが拡張されています。これにより、キーバリューストアの1つのエントリでネットワーク範囲内のすべてのIPアドレスを照合できます。範囲を構成するアドレスを個別に追加する必要がないため、設定が簡素化され、時間を節約できます。キーバリューストアでは、ネットワーク範囲の表記に「CIDR表記」を使用します。たとえば、192.168.13.0/24は192.168.13.0～192.168.13.255のアドレスを表します。IPv4とIPv6のアドレスおよび範囲の両方がサポートされています。

ネットワーク範囲を有効にするには、IPアドレスを動的に拒否リストへ登録する次の設定例のように、type=ipという新しいパラメーターをkeyval_zoneディレクティブに追加します。NGINX Plusが検索を実行すると、キー・バリューストアに保存されているネットワーク範囲内のすべてのIPアドレスが一致します。

コード例を読み込み中…

2行目では、$in_denylist変数の値を評価するために、denylistキーバリューストアで$remote_addr（クライアントIPアドレス）をキーとして検索するよう指定しています。その後、単純な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

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

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

NGINX Plus R19では、キーと値のストア全体に対してtimeoutパラメーターで設定されたデフォルトのタイムアウトを、エントリごとに異なるタイムアウトで上書きできます。個別のタイムアウトは、デフォルトより長くすることも短くすることもできます。

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

  • value – 目的の値に設定します。この場合は、1を設定して$in_denylist変数に値を格納します
  • expire – 作成後、値が期限切れになるまでのミリ秒数を設定します

次のJSONは、1時間（3,600,000ミリ秒）後に期限切れとなるlocalhost（127.0.0.1）の拒否リストエントリを表します。

{
  "127.0.0.1": {
    "value": "1",
    "expire": 3600000
  }
}

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

$ curl -X POST -d '{"127.0.0.1":{"value":"1","expire":3600000}}' http://localhost:8080/api/5/http/keyvals/denylist

動的帯域幅制御

The 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 module (njs)などのスクリプト拡張機能を使用して、接続ごとに適切な帯域幅制限を決定する高度なカスタムロジックを実装できます。

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

NGINX JavaScript Module

NGINX JavaScript module（njs）がversion 0.3.5に更新されました。以前のバージョンからの累積で、主な機能強化は次のとおりです。

  • アロー関数のサポート（洪志道 [Hong Zhi Dao] 氏とArtem S. Povalyukhin氏の貢献によるもの）
  • グローバルな「process」オブジェクト（環境変数の読み取りに特に便利）
  • String.prototype.trim関数

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

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

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

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

共有
注目のブログ記事
クラウドネイティブ技術、プラットフォームエンジニアリング、AIの最新トレンドF5 NGINX OneによるアプリとAPIデリバリーのライフサイクル全体の管理モダンアプリケーションデリバリをシンプルに：F5 NGINX Oneの9か月
タグ： DNS

著者について

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

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

関連するブログ記事

チュートリアル：NGINXを使用してアプリケーション向けにOpenTelemetryを構成する
NGINX | 2024/01/18

チュートリアル：NGINXを使用してアプリケーション向けにOpenTelemetryを構成する

OpenTelemetryを使用してNGINXサーバーの状態と健全性をより明確に把握することで、問題のトラブルシューティングを行い、Webアプリケーションのパフォーマンスを向上できます。

AkitaのNGINX Plus認定モジュールでAPIエンドポイントの問題を特定・修正
NGINX | 2023/05/31

AkitaのNGINX Plus認定モジュールでAPIエンドポイントの問題を特定・修正

Akita SoftwareのAPIオブザーバビリティ向け新しいNGINX Plus Certified Moduleを活用して、APIエンドポイントの問題をより迅速に特定し、修正できます。

JavaプロジェクトをスキャフォールディングしてKubernetesネイティブアプリを構築する方法
NGINX | 2023/02/09

JavaプロジェクトをスキャフォールディングしてKubernetesネイティブアプリを構築する方法

Red HatのシニアプリンシパルデベロッパーアドボケイトであるDaniel Oh氏が、Javaプロジェクトをゼロから構築するためのひな形を作成し、Kubernetesネイティブアプリケーションとしてビルドする方法を解説します。

F5 NGINXaaS for Azureのご紹介：Microsoft Azureでネイティブに利用できるSaaS型ロードバランシング
NGINX | 2022/05/24

F5 NGINXaaS for Azureのご紹介：Microsoft Azureでネイティブに利用できるSaaS型ロードバランシング

NGINXaaS for Azureは、NGINX PlusをAzureネイティブのSaaSとして利用できるサービスです。NGINXの設定を容易にリフト＆シフトできるため、クラウド導入とモダンアプリの展開を加速できます。

SELinuxでNGINXおよびNGINX Plusを使用する
NGINX | 2018/08/17

SELinuxでNGINXおよびNGINX Plusを使用する

Red Hat Enterprise Linux（RHEL）および関連ディストリビューションでSecurity-Enhanced Linux（SELinux）を有効にすると、デフォルト設定によりNGINXとNGINX Plusの一部の操作が制限されます。この記事では、すべての機能を利用できるようにSELinuxの設定を変更する方法について説明します。

NGINX PlusによるAWS Auto Scalingグループの負荷分散
NGINX | 2017/03/06

NGINX PlusによるAWS Auto Scalingグループの負荷分散

新しいnginx-asg-sync統合ソフトウェアにより、NGINX PlusはAWS Auto Scalingグループの負荷を直接分散できるため、クラウドでの負荷分散がさらに柔軟になります

あらゆるアプリを配信し、保護する
F5のアプリケーション配信およびセキュリティ ソリューションは、どこに展開されたアプリとAPIも、高速で、利用可能かつ安全に保ちます。常に優れた体験を実現するために、どのように連携できるかをご覧ください。
F5とつながる