NGINX Plus R20を発表

NGINX | 2019年12月03日

NGINX Plus Release 20（R20）の提供開始をお知らせします。NGINX Plusは、ロードバランサー、コンテンツキャッシュ、Webサーバー、APIゲートウェイを一体化した唯一の製品です。NGINX Open SourceをベースとするNGINX Plusには、独自の拡張機能と受賞歴のあるサポートが含まれています。

NGINX Plus R20では、R19で実施したレート制限とキーバリューストアの機能強化をさらに発展させています。新機能は次のとおりです。

レート制限対象トラフィックのリアルタイム監視とログ記録 – レート制限を設定すると、NGINX Plus APIで、即時に処理されたリクエスト、遅延されたリクエスト、拒否されたリクエストの件数を確認できるようになりました。また、個々のリクエストのレート制限ステータスに関する情報をアクセスログに含めるよう設定することもできます。
接続数制限の機能強化 – R19および本リリースで導入されたリクエスト数制限の機能強化が、接続数制限にも拡張されました。
キー・バリューストアでのプレフィックスマッチング – キー・バリューストア内のキーを、指定したプレフィックス（文字列の先頭にある文字）と照合できます。重要なユースケースの1つは、動的なリクエストルーティングです。
アップストリームグループごとのDNS名前解決 – グループ内のバックエンドサーバーを名前解決可能なホスト名で表すアップストリームグループごとに、異なるDNSサーバーのセットを指定できるようになりました。
追加のPROXY Protocol変数 – 新しい変数に、クライアントが最初に接続したプロキシサーバーのIPアドレスとポートが格納されます。
HTTP/2のセキュリティ強化 – 不正または無効なクライアント動作の検出精度向上や、特定のディレクティブのより堅牢な実装など、複数の変更によりHTTP/2トラフィック全体のセキュリティが向上します。

動作に関する重要な変更

廃止されたAPI – NGINX Plus R13（2017年8月リリース）では、まったく新しいNGINX Plus API<.htmlspan>が導入されました。これは、メトリクスの収集とアップストリームグループの動的な再構成に使用され、それまでこれらの機能を実装していたStatus APIとUpstream Conf APIに代わるものです。当時の発表どおり、非推奨となったAPIはその後も長期間にわたり利用およびサポートが継続されましたが、NGINX Plus R16をもって終了しました。構成にstatusまたはupstream_confディレクティブが含まれている場合は、R20へのアップグレードの一環として、これらをapiディレクティブに置き換える必要があります。新しいNGINX Plus APIへの移行に関するガイダンスやサポートについては、F5のブログに掲載されている移行ガイドをご覧いただくか、サポートチームにお問い合わせください。
新たにサポートされるオペレーティングシステム –
- CentOS 8.0+
- FreeBSD 12.1
- Red Hat Enterprise Linux 8.1
- Ubuntu 19.10（「Eoan Ermine」）

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

新機能の詳細

レート制限されたトラフィックのリアルタイム監視とログ記録

NGINX Plus R20では、運用チームとDevOpsチームがレート制限の動作をリアルタイムで監視し、どのクライアントがレート制限を超過したかを正確に特定しやすくする機能が導入されています。
NGINX Plusは従来から、レート制限の対象とするクライアントリクエストの種類や、過剰なリクエストの処理方法を柔軟に定義できます。各リクエストは、次のいずれかの方法で処理されます。

通過（リクエストレートが制限値未満、または設定されたバーストサイズの範囲内であるため）遅延なく
遅延（通過させてもレート制限を超過しなくなるまで。別名「スロットリング」）
拒否され、HTTPエラーレスポンスコードが返される

以前のリリースでは、リクエストが遅延または拒否されたことをNGINX Plusが記録する場所はエラーログのみで、次のような標準形式のエントリとして記録されていました。

2019/12/02 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.0", host: "www.example.com:80"

エラーログのメッセージ形式は構造化されておらず、設定も変更できないため、有用な情報を抽出するのは容易ではありません。さらに、レート制限のキーが、エラーログエントリに記録されているもの以外のメッセージ特性（HTTPヘッダーやID情報など）に基づく場合、どのクライアントがレート制限を超過したかを正確に特定するには、アクセスログで対応するエントリを見つける必要があります。新機能は、これらの問題に対処します。

NGINX Plus APIから取得するレート制限メトリクス

NGINX Plus APIの新しいエンドポイントである「/api/version/http/limit_reqs」は、limit_req_zoneディレクティブで定義された各ゾーンについて、レート制限の判定結果をすべてカウンターで記録します。これらのカウンターは、レート制限の判定をリアルタイムで監視するために使用できるほか、APMソリューションと統合して、レート制限のアクティビティに関するダッシュボードやアラートを提供することもできます。

次の例では、定義されているゾーンは1つで、my_limitです。

$ curl http://localhost/api/6/http/limit_reqs
{
 "my_limit": {
   "delayed": 540,
   "delayed_dry_run": 12162,
   "passed": 804541,
   "rejected": 63,
   "rejected_dry_run": 1209
 }
}

これらのカウンターには、ドライランモードで処理された過剰なリクエストのエントリも含まれます。このモードはNGINX Plus R19で導入されました。

アクセスログへのレート制限アクティビティの記録

リアルタイムメトリクスは、NGINX Plusが過剰なリクエストを処理しているのが「いつ」かを把握するうえで非常に役立ちますが、それらのリクエストを生成しているのが「誰」かまではわかりません。この課題に対応するため、NGINX Plus R20では新しい変数「$limit_req_status」が提供されています。この変数には、リクエストのレート制限ステータスとして、DELAYED、DELAYED_DRY_RUN、PASSED、REJECTED、またはREJECTED_DRY_RUNが記録されます。

そのうえで、クライアントやURIを一意に識別する変数など、関連する情報をログ形式に含めることができます。次の設定では、JSON Web Token（JWT）の検証に基づき（1行目）、クライアントごとに1秒あたり10リクエストという厳格なレート制限を適用します。上限を超えたリクエストは拒否され（16行目）、別のログファイルに記録されます（21行目）。また、ログ形式には$jwt_claim_sub変数も含まれており、subクレームを取得します（4行目）。

コード例を読み込み中…

Sample entries in the reject.logファイルのサンプルエントリ：

time=1575289305.350 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTEDtime=1575289305.395 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTED
time=1575289305.402 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTED

接続数制限の機能強化

NGINX Plusでは、リクエストのレート制限に加えて、Limit Connectionsモジュールを使用してクライアント接続を制限できます。クライアントがNGINX Plusに対して確立できる個別の接続数（HTTP/2を使用する場合は同時リクエスト数）を定義できます。通常、クライアントはリモートIPアドレス（変数$remote_addrまたは$binary_remote_addr）で識別されます。ただし、リモートIPアドレスが不明確な場合や、複数のクライアントで共有されている可能性がある場合は、別の変数（JWT内のユーザー名を示す$jwt_claim_subなど）を使用できます。

NGINX Plus R20では、接続制限にも、NGINX Plus R19および本リリースでレート制限に導入されたものと同じ機能強化が適用されています。

Dry‑run mode with the limit_conn_dry_runディレクティブを使用するドライランモード
NGINX Plus APIエンドポイントでのリアルタイム監視：/api/version/http/limit_conns
各リクエストに対する接続制限の判定（$limit_conn_status、PASSED、REJECTED、またはREJECTED_DRY_RUN）を記録する新しい変数です。アクセスログへのレート制限アクティビティの記録に記載されている$limit_req_status変数と同様に使用できます

次の設定では、同時接続数が10を超えるクライアントに低帯域幅を適用します。

コード例を読み込み中…

キー・バリューストアでのプレフィックスマッチング

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

NGINX Plus R20では、指定したプレフィックス（文字列の先頭にある文字）とのキーマッチングがサポートされ、キー・バリューストアの新たなユースケースが可能になります。たとえば、完全一致するURIではなくURIプレフィックス（ベースパス）とのキーマッチングが可能になるため、各ベースパスをアップストリームグループにマッピングする動的ルーティングテーブルを作成し、locationディレクティブで定義された静的マッピングを置き換えたり補完したりできます。

プレフィックスマッチングを有効にするには、新しい「type=prefix」パラメーターを「keyval_zone」ディレクティブに追加します。次の設定では、「keyval」ディレクティブによって、各URIプレフィックスに「Cache-Control」ディレクティブ（「max-age」や「no-cache」など）が関連付けられます。また、「add_header」ディレクティブによって、NGINX Plusがリクエストをアップストリームサーバーに転送する際に、「Cache-Control」レスポンスヘッダーがその値に設定されます。

コード例を読み込み中…

We use the NGINX Plus APIを使用して、キーバリューストア内の各ベースパス（この場合は、Cache-Controlレスポンスヘッダーの値を定義します。対象となるのは、/images/または/reports/で始まるパスです：

$ curl -i -X POST --data '{"/images/":"max-age=3600", "/reports/":"no-cache"}' http://localhost:8080/api/6/http/keyvals/pathsHTTP/1.1 201 Created
Server: nginx/1.17.6
Date: Mon, 2 Dec 2019 12:36:31 GMT
Content-Length: 0
Location: http://localhost:8080/api/6/http/keyvals/paths/
Connection: keep-alive

キー・バリュー・ストアに存在するベースパスを指定してリクエストすると、レスポンスには設定した「Cache-Control」ヘッダーが含まれます。

$ curl -I http://localhost/images/sample.jpgHTTP/1.1 200 OK
Server: nginx/1.17.6
Date: Mon, 2 Dec 2019 12:27:39 GMT
Content-Type: image/jpeg
Content-Length: 120847
Connection: keep-alive
Cache-Control: max-age=3600

キー・バリューストアはNGINX Plusインスタンスのクラスター全体で同期できるため、各API呼び出しは1つのインスタンスに対してのみ行えば済みます。これにより、クラスター構成の変更を自動化するプロセスは、構成ファイルへの変更を調整する場合よりもはるかに簡単になります。

アップストリームグループごとのDNS名前解決

NGINX Plusを使用して複数のアップストリームサーバー間で負荷分散を行う場合、アップストリームグループのメンバーは、複数のIPアドレスに解決されるホスト名を指定することで定義できます。これは、アップストリームグループのメンバーが頻繁に変更される可能性がある動的環境や自動スケーリング環境で特に有用です。

これらの動的アップストリームグループの設定を完了するには、さらにresolverディレクティブを追加し、ホスト名に関連付けられたIPアドレスをNGINX Plusが照会するDNSサーバーを指定します。以前のリリースでは、resolverディレクティブは、そのディレクティブを含むコンテキスト（http、server、またはlocation）内のproxy_passディレクティブから参照されるすべてのアップストリームグループに適用されていました。NGINX Plus R20では、アップストリームグループごとに異なるDNSリゾルバーを指定できるようになりました。

この新たな柔軟性は、DevOps環境で特に有用です。アプリケーションチームは、一元化された共有サービスに依存することなく、DNSサーバーやサービスレジストリを含むアプリケーションデリバリーインフラストラクチャを、より広範に自ら管理できるようになります。

You can still define a global resolver in the top‑level http context, and in server and location blocks. If an upstream block does not include a resolver directive, it inherits the resolver setting of the context or block that includes a proxy_pass directive referencing the upstream group, as in previous releases.

次の例では、websiteアップストリームグループはグローバルリゾルバーを使用し、mobile_appは独自のリゾルバーを使用します。

コード例を読み込み中…

エラーをはじめとするリゾルバーの動作に関するメトリクスを収集するため、両方のstatus_zoneパラメーター（NGINX Plus R19で導入）をresolverディレクティブに指定している点に注目してください。

PROXY Protocolサーバーメタデータ用の変数

PROXY Protocolは、レイヤー4プロキシが元のクライアント接続に関する情報を、クライアントリクエストを処理する次のプロキシまたはロードバランサーに伝達するための仕組みです。これは、クライアントのIPアドレスを把握する必要があるユースケースで特に重要です。たとえば、least_connディレクティブを使用して各クライアントからの接続数を制限したり、実際のクライアントのIPアドレスをログに記録したりする場合です。以前のリリースと同様に、$proxy_protocol_addr変数でこの情報を取得できます。

アプリケーション環境に複数のレイヤー4プロキシが導入されている場合、クライアントが最初に接続したプロキシサーバーのIPアドレスとポートをNGINX Plusでも把握することが重要になる場合があります。PROXY Protocolのメタデータにはこの情報が含まれており、NGINX Plus R20では、この情報を取得するための変数が追加されています。

これらの変数はHTTPモジュールとStream（TCP/UDP）モジュールの両方で使用でき、PROXY Protocolのバージョン1と2の両方をサポートしています。変数を使用する前に、proxy_protocolパラメーターをlistenディレクティブに追加し、NGINX PlusがPROXY Protocolを処理できるよう明示的に有効化する必要があります。

HTTP/2のセキュリティ強化

NGINX Plus R18 P1では、HTTP/2に存在し、8月に発表された3件のセキュリティ脆弱性に対処しました。NGINX Plus R20には、F5のHTTP/2実装の全体的なセキュリティを向上させる追加の変更が含まれています。

不正または無効なクライアント動作の検出を改善
クライアントのリクエストボディを読み取る前のHTTP/2エラーレスポンス送信を改善
長時間維持されるHTTP/2接続に対するworker_shutdown_timeoutディレクティブの堅牢性を向上
HTTP/2クライアント向けのproxy_request_bufferingディレクティブの堅牢性を向上

本番環境でHTTP/2をNGINX Plus R18（パッチ未適用）以前とともに使用している場合は、できるだけ早くNGINX Plus R20へアップグレードすることを推奨します。

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

NGINX JavaScriptモジュール

NGINX JavaScript module（njs）がバージョン0.3.7に更新され、より多くのJavaScriptオブジェクトがサポートされるようになりました。

Function()コンストラクター
Object.assign()メソッド
Numberのメソッド：toFixed()、toPrecision()、toExponential()
Array.prototype.copyWithin()メソッド
Label parameter to the console.time()メソッドのラベルパラメーター

njsの詳細については、プロジェクトのホームページおよびブログ<.htmla>をご覧ください。

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

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

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

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

注目のブログ記事

クラウドネイティブ技術、プラットフォームエンジニアリング、AIの最新トレンド

F5 NGINX OneによるアプリとAPIデリバリーのライフサイクル全体の管理

モダンアプリケーションデリバリをシンプルに：F5 NGINX Oneの9か月