NGINX Plus R20 の発表
NGINX Plus リリース 20 (R20)が利用可能になったことをお知らせします。 NGINX Plus は、ロードバランサー、コンテンツ キャッシュ、Web サーバー、API ゲートウェイをオールインワンで提供する唯一の製品です。 NGINX オープンソースをベースにした NGINX Plus には、独自の拡張機能と受賞歴のあるサポートが含まれています。
NGINX Plus R20 は、 R19 でレート制限とキー値ストアに加えた機能強化に基づいて構築されています。 新しい機能は次のとおりです:
- レート制限されたトラフィックのリアルタイム監視とログ記録– レート制限が設定されている場合、 NGINX Plus API は、すぐに渡されたリクエスト、遅延されたリクエスト、または拒否されたリクエストの数を報告するようになりました。 個々のリクエストのレート制限ステータスに関する情報を含めるようにアクセス ログを構成することもできます。
- 接続制限の機能強化– レート制限の機能強化は R19 で導入され、このリリースでは接続制限まで拡張されました。
- キー値ストアでのプレフィックス マッチング- キー値ストア内のキーは、指定されたプレフィックス (文字列の先頭の文字) と一致できます。 重要な使用例の 1 つは、動的リクエスト ルーティングです。
- アップストリーム グループごとの DNS 解決- グループ内のバックエンド サーバーを表すために解決可能なホスト名を使用するアップストリーム グループごとに、異なる DNS サーバーのセットを指定できるようになりました。
- 追加の PROXY プロトコル変数- 新しい変数は、クライアントが最初に接続したプロキシ サーバーの IP アドレスとポートを取得します。
- HTTP/2 のセキュリティ強化– 不正または無効なクライアント動作の検出の改善や、特定のディレクティブのより堅牢な実装など、いくつかの変更により、HTTP/2 トラフィックの全体的なセキュリティが向上します。
行動における重要な変化
廃止された API – NGINX Plus R13 (2017 年 8 月リリース) では、メトリクス収集とアップストリーム グループの動的再構成のためのまったく新しいNGINX Plus API<.htmlspan>が導入され、以前にこれらの機能を実装していた Status および Upstream Conf API が置き換えられました。 当時発表されたとおり、非推奨の API はかなりの期間にわたって引き続き利用可能でサポートされていましたが、 NGINX Plus R16で終了しました。 構成に
statusまたはuploader_confディレクティブが含まれている場合は、R20 へのアップグレードの一環として、それらをapiディレクティブに置き換える必要があります。新しいNGINX Plus APIへの移行に関するアドバイスやサポートについては、ブログの移行ガイドを参照するか、サポート チームにお問い合わせください。
新しいオペレーティングシステムのサポート–
- CentOS 8.0以降
- フリーBSD12.1
- レッドハットエンタープライズLinux8.1
- Ubuntu 19.10 (「エオアン アーミン」)
サポートされているプラットフォームの詳細については、 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 ソリューションと統合してダッシュボードを提供し、レート制限アクティビティに関するアラートを提供することもできます。
次の例では、 my_limit という1 つのゾーンが定義されています。
$ 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で導入されたdry-run モードで処理された過剰なリクエストのエントリも含まれていることに注意してください。
アクセスログにレート制限アクティビティを記録する
リアルタイム メトリックは、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変数も含まれます (行 4)。
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およびこのリリースで導入されたレート制限と同じ機能強化により、接続制限を拡張します。
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 プレフィックス (ベース パス) に対してキーを照合できるということは、場所ディレクティブによって定義された静的マッピングを置き換えたり拡張したりして、各ベース パスをアップストリーム グループにマッピングする動的ルーティング テーブルを作成できることを意味します。
プレフィックス マッチングを有効にするには、 keyval_zoneディレクティブに新しいtype=prefixパラメータを含めます。 次の設定では、 keyvalディレクティブはCache-Controlディレクティブ ( max-ageやno-cacheなど) を各 URI プレフィックスに関連付け、 add_headerディレクティブは、NGINX Plus がリクエストをアップストリーム サーバーに転送するときにCache-Control応答ヘッダーをその値に設定します。
NGINX Plus API を使用して、キー値ストア内の各ベースパス（この場合は、 /images/または/reports/で始まるパス）のCache-Control応答ヘッダーの値を定義します。
$ 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 アドレスに解決されるホスト名を指定して、アップストリーム グループのメンバーを定義できます。 これは、アップストリーム グループのメンバーが頻繁に変更される可能性がある動的環境または自動スケーリング環境で特に役立ちます。
これらの動的アップストリーム グループの構成を完了するには、ホスト名に関連付けられた IP アドレスを NGINX Plus が照会する DNS サーバーを指定するためのリゾルバディレクティブも含めます。 以前のリリースでは、 resolverディレクティブは、ディレクティブを含むコンテキスト ( http 、 server 、またはlocation ) 内のproxy_passディレクティブによって参照されるすべてのアップストリーム グループに適用されていました。 NGINX Plus R20では、アップストリーム グループごとに異なる DNS リゾルバを指定できるようになりました。
この新しい柔軟性は、DevOps 環境で特に役立ちます。これにより、アプリケーション チームは、集中化された共有サービスに依存するのではなく、DNS サーバーやサービス レジストリなどのアプリケーション配信インフラストラクチャをより多く所有できるようになります。
最上位レベルのhttpコンテキスト、およびserver ブロックとlocationブロックでグローバル リゾルバを定義することもできます。 アップストリームブロックにリゾルバディレクティブが含まれていない場合は、以前のリリースと同様に、アップストリーム グループを参照するproxy_passディレクティブを含むコンテキストまたはブロックのリゾルバ設定が継承されます。
次の例では、 Web サイトのアップストリーム グループはグローバル リゾルバを使用し、 mobile_app は独自のリゾルバを使用します。
リゾルバのアクティビティに関するエラーやその他のメトリックを収集するために、両方のリゾルバディレクティブにstatus_zoneパラメータ ( NGINX Plus R19で導入) を含めていることに注意してください。
PROXY プロトコル サーバー メタデータの変数
PROXY プロトコルは、レイヤー 4 プロキシが元のクライアント接続に関する情報を、クライアント要求を処理する次のプロキシまたはロード バランサに伝達できるメカニズムです。 これは、クライアントの IP アドレスを知る必要があるユースケースで特に重要です。たとえば、各クライアントによる接続の数を制限する場合 ( least_connディレクティブを使用) や、実際のクライアントの IP アドレスをログに記録する場合などです。 以前のリリースと同様に、 $proxy_protocol_addr変数がこの情報をキャプチャします。
アプリケーション環境に複数のレイヤー 4 プロキシが展開されている場合、クライアントが最初に接続したプロキシ サーバーの IP アドレスとポートを NGINX Plus が認識することも重要になることがあります。 PROXY プロトコル メタデータにはこの情報が含まれており、 NGINX Plus R20 ではそれをキャプチャするための変数が追加されています。
変数は HTTP モジュールと Stream (TCP/UDP) モジュールの両方で使用でき、PROXY プロトコルのバージョン 1 と 2 の両方をサポートします。 変数を使用する前に、 listenディレクティブにproxy_protocolパラメータを追加して、NGINX Plus が PROXY プロトコルを処理できるように明示的に有効にする必要があることに注意してください。
HTTP/2 のセキュリティ強化
NGINX Plus R18 P1 は、 8 月に発表されたHTTP/2 の 3 つのセキュリティ脆弱性に対処しました。 NGINX Plus R20には、HTTP/2 実装の全体的なセキュリティを向上させる追加の変更が含まれています。
- 不正または無効なクライアント動作の検出の改善
- クライアントのリクエスト本文が読み取られる前に HTTP/2 エラー応答を送信する機能の改善
- 長時間の HTTP/2 接続に対する
worker_shutdown_timeoutディレクティブの堅牢性が向上しました。 - HTTP/2 クライアントの
proxy_request_bufferingディレクティブの堅牢性が向上しました
NGINX Plus R18 (パッチ未適用) 以前で本番環境で HTTP/2 を使用している場合は、できるだけ早くNGINX Plus R20にアップグレードすることをお勧めします。
NGINX Plus エコシステムのアップデート
NGINX JavaScript モジュール
NGINX JavaScriptモジュール（njs）がバージョンに更新されました0.3.7より多くの JavaScript オブジェクトのサポートが追加されました。
Function()コンストラクタObject.assign()メソッド数値メソッド:toFixed()、toPrecision()、toExponential()Array.prototype.copyWithin()メソッドconsole.time()メソッドへのラベルパラメータ
njs の詳細については、プロジェクトのホームページとブログ <.htmla> をご覧ください。
NGINX Plus をアップグレードまたは試用する
NGINX Plus を実行している場合は、できるだけ早くNGINX Plus R20にアップグレードすることを強くお勧めします。 また、多数の追加の修正と改善も行われ、サポート チケットを発行する必要があるときに NGINX がサポートしやすくなります。
アップグレードを進める前に、このブログ投稿に記載されている新機能と動作の変更をよく確認してください。
NGINX Plus をまだお試しいただいていない方は、セキュリティ、負荷分散、API ゲートウェイとして、または強化された監視および管理 API を備えた完全にサポートされた Web サーバーとして、ぜひお試しください。 30 日間の無料トライアルを今すぐ開始できます。 NGINX Plus がアプリケーションの配信と拡張にどのように役立つかを実際にご確認ください。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 q。"