NGINX 1.18 および 1.19 の紹介

本日、インターネット上で最も人気のある Web サーバーであるNGINX Open Source の最新バージョンである NGINX 1.19 をリリースしました。 このリリースは、先月の NGINX 1.18 安定ブランチのリリースに続き、NGINX 1.19 開発ブランチのリリースを示しています。

このブログでは、NGINX のバージョン管理スキームについて説明し、NGINX 1.17 の開発サイクル中に何が起こったかを振り返り、NGINX 1.19 で何が起こるかに期待します。

NGINX のバージョン管理の説明

NGINX では、NGINX オープンソース コード リポジトリでmainlineとstableという 2 つのブランチを管理しています。

• メインラインは、最新の機能とバグ修正が追加されるアクティブな開発ブランチです。 バージョン番号の 2 番目の部分が奇数で示されます (例: 1)。19.0.
• 安定版では、重大度の高いバグの修正は行われますが、新しい機能は更新されません。 バージョン番号の 2 番目の部分が偶数で示されます (例: 1)。18.0.

「安定」とはどういうことか

NGINX Open Source の場合、「安定」という言葉はソフトウェアの品質ではなく、機能性と更新頻度を指します。 安定ブランチは、そのライフサイクル中に新しい機能が追加されることはなく、通常は重大なバグ修正のために 1 回または 2 回の更新のみを受け取ります。

安定ブランチには年間ライフサイクルがあります。 毎年 4 月に現在の安定ブランチが廃止され、それ以降はバグ修正は行われません。 これにより、次の 2 つのイベントがトリガーされます。

1. 現在のメインライン ブランチがフォークされ、次の安定したブランチが作成されます。 新しい安定ブランチは、前年にメインライン ブランチに加えられたバグ修正、機能、およびその他の変更をすべて継承します。 先月、NGINX 1.17.10 がフォークされ、NGINX 1.18.0 が作成されました。 新しいメインライン ブランチがリリースされるまで、「安定」は現在のメインライン ブランチと同一であり、数日前の新機能が含まれる可能性があることに注意してください (NGINX 1.18 ブランチではその状態は今日で終了します)。
2. メインライン ブランチは「バージョン バンプ」を取得します。つまり、バージョン番号の 2 番目の部分が次の奇数に増加します。 メインライン ブランチでは継続的な開発が続けられており、4 ～ 6 週間ごとにメインラインから新しいリリースが構築されます。 本日は、NGINX 1.19 メインラインの最初のリリースである NGINX 1.19.0 がリリースされました。

NGINX Plus はどのブランチを使用しますか?

NGINX の商用バージョンであるNGINX Plus は、別のプライベート コード リポジトリで管理されています。 これは常に最新バージョンの NGINX メインラインに基づいており、NGINX Plus の追加の独自の機能と統合されています。 執筆時点での最新バージョンは、NGINX 1.17.10 をベースにしたNGINX Plus R21です。

どのブランチを使用すればよいですか?

通常はメインライン ブランチを使用することをお勧めします。 ここで、すべての新機能、パフォーマンスの改善、機能強化がコミットされます。 私たちはメインライン ブランチを積極的にテストおよび QA しており、NGINX Plus ビルドのソースとして本番環境での使用に完全に適しています。

メインライン ブランチで新機能やバグ修正を監視するオーバーヘッドが懸念される場合は、安定ブランチを使用すると、新機能を年に 1 回、バグ修正を頻繁に確認するだけで済みます。

NGINX 1.17 のレビュー、別名 NGINX 1.18 安定ブランチの新機能

NGINX 1.17 開発サイクルでは、 ngx_http_limit_req_moduleとngx_http_limit_conn_moduleでのリクエスト レートと接続制限の強化、 ngx_http_core_moduleへの認証遅延ディレクティブの追加、 grpc_passディレクティブの変数サポートと PROXY プロトコルでサーバー アドレスとポートをキャプチャする変数の導入など、いくつかの新機能と機能強化が導入されました。 最も重要な機能強化の詳細を見る前に、NGINX 1.17 を数字で説明します。

• 10 本のメインラインリリース
• 37 個のバグ修正
• 11の新機能

HTTP リクエスト レートと接続制限の強化

limit_rateおよびlimit_rate_afterディレクティブは、NGINX がリクエストに応答する帯域幅 (1 秒あたりのバイト単位のレート) を制御します。 NGINX 1.17.0 以降では、レートを設定するパラメータを変数にすることができ、リクエストの属性に基づいて動的な制御が可能になります。 例については、 「動的帯域幅制御」を参照してください。

NGINX 1.17.1 では、 limit_req_dry_runディレクティブを使用して、リクエスト レート制限のためのドライ ラン モードが追加されました。 ドライラン モードでは、NGINX Plus はレート制限を適用しませんが、共有メモリ ゾーン内の過剰なリクエストのレートを追跡し、構成された制限を超えるリクエストごとにエラー ログにエントリを書き込みます。 これにより、サイトのトラフィックのパターンに適したレート制限をより簡単に判断できるようになります。 詳細については、 「ドライラン モードでのレート制限のテスト」を参照してください。

ドライラン モードをさらに便利にするために、NGINX 1.17.6 では$limit_req_status変数が追加されました。この変数をアクセス ログ エントリに含めることで、リクエスト処理に対するレート制限の影響 (具体的には、リクエストが次のいずれであるか) をキャプチャできます。

• 合格（遅延なくバックエンドサーバーに転送されました）[合格]
• 遅延しました [遅延]
• 拒否されました [拒否]
• ドライランモードで遅延としてカウントされました [ DELAYED_DRY_RUN ]
• ドライランモードで拒否されたとカウントされました [ REJECTED_DRY_RUN ]

NGINX 1.17.6 では、 limit_conn_dry_runディレクティブを使用した接続制限のドライラン モードと、接続要求時にキャプチャする$limit_conn_status変数も追加されました。

• 合格（バックエンドサーバーに転送されました）[合格]
• 拒否されました [拒否]
• ドライランモードで拒否されたとカウントされました [ REJECTED_DRY_RUN ]

サンプル構成については、 「接続制限の機能強化」を参照してください。

新しいauth_delayディレクティブ

auth_delayディレクティブ（NGINX 1.17.10で追加）は、ステータスコード付きの不正なリクエストの遅延処理を可能にします。 401(無許可)クライアントに返却されました。 これにより、アクセス要求を処理する際のタイミング攻撃を防止できます。 利用可能な認証方法は次のとおりです。

• パスワード（ ngx_http_auth_basic_module を使用する場合）
• サブリクエストの結果（ ngx_http_auth_request_moduleで利用可能）
• JWT の存在 ( ngx_http_auth_jwt_moduleで利用可能)

grpc_passディレクティブの変数サポート

NGINX 1.13.10 では、NGINX が gRPC リクエストを渡すサーバーを指定するgrpc_passディレクティブを含む、gRPC トラフィックのネイティブ サポートが追加されました。 NGINX 1.17.8 では、アップストリーム サーバー グループ間の検索をサポートするために、サーバー識別子にドメイン名を含める機能が追加されました。 ドメイン名が見つからない場合、NGINX はリゾルバを使用してサーバー アドレスを識別します。

追加のPROXYプロトコル変数

PROXY プロトコルにより、レイヤー 4 プロキシは、要求を処理する次のプロキシまたはロード バランサに元のクライアント情報を提供できるようになります。 これは、クライアントの IP アドレスを知る必要があるユースケースで重要です。たとえば、各クライアントの接続数を制限する場合 ( least_connディレクティブを使用) などです。 このデータは$proxy_protocol_addr変数 ( HTTP | Stream ) で利用できます。

複数のレイヤー 4 プロキシが展開されている場合、クライアントが最初に接続したプロキシ サーバーの IP アドレスとポートを NGINX が認識することが重要になる場合があります。 PROXY プロトコル メタデータにはこの情報が含まれており、NGINX 1.17.6 ではこれをキャプチャするために HTTP および Stream モジュールに次の変数が追加されました。

• $proxy_protocol_server_addr ( HTTP |ストリーム)
• $proxy_protocol_server_port ( HTTP |ストリーム)

注記： 変数は、PROXY プロトコルの処理を有効にするためにlistenディレクティブにproxy_protocolパラメータも含めた場合にのみ設定されます。

proxy_upload_rateおよびproxy_download_rateディレクティブに変数のサポートが追加されました

Stream モジュールのproxy_upload_rateおよびproxy_download_rateディレクティブは、それぞれ NGINX がクライアントまたはプロキシ サーバーからデータを読み取る速度を制御します。 NGINX 1.17.0 以降では、ディレクティブは可変パラメータを受け入れるため、条件固有のレート定義が可能になります。

ioctl(FIONREAD)システムコールのサポートを追加しました

Linux システムでは、 ioctl()システム コールによって、ホスト デバイスから読み取り可能なバイト数が提供されます。 NGINX 1.17.5 では、NGINX が読み取って処理するよりも速くデータがソケット バッファーに追加されたときにループが発生するのを防ぐため、ioctl(FIONREAD)が追加されました。 カーネルが利用可能なバイト数を提供しない場合は、 ioctl(FIONREAD)を使用して、設定されたバッファからこの情報を取得できます。

Perl のinternal_redirect関数で名前付きの場所を指定する

NGINX 1.17.2 以降では、NGINX Perl モジュールのinternal_redirect関数のuriパラメータは、エスケープされた URI または名前付きの場所にすることができます。

NGINX 1.19 で何が来るのか

NGINX 1.19 メインラインの最初のリリースが間もなく登場します。 NGINX 1.19.0 には、クライアントと Web サイト、アプリケーション、API 間の通信に使用されるトランスポート プロトコルの次の重要な更新であるQUIC (HTTP/3) のサポートが含まれています。

NGINX Plus の強化された機能を試してみたい場合は、今すぐ30 日間の無料トライアルを開始するか、弊社にお問い合わせの上、使用事例についてご相談ください。