NGINX 1.18と1.19のご紹介

NGINX | 2020年5月26日

本日、インターネット上で最も広く利用されているWebサーバー、NGINX Open Sourceの最新バージョンであるNGINX 1.19をリリースします。今回のリリースは、先月のNGINX 1.18安定版ブランチのリリースに続く、NGINX 1.19開発版ブランチの開始を示すものです。

このブログでは、NGINXのバージョン体系について説明し、NGINX 1.17の開発サイクルを振り返るとともに、NGINX 1.19で予定されている内容をご紹介します。

NGINXのバージョン体系を解説

NGINXでは、NGINX Open Sourceコードリポジトリで、次の2つのブランチを管理しています。mainlineとstableです：

Mainlineは、最新の機能やバグ修正が追加されるアクティブな開発ブランチです。バージョン番号の2番目の部分が奇数になります（例：1.19.0）。
Stableには重大度の高いバグの修正が適用されますが、新機能は追加されません。バージョン番号の2番目の部分が偶数で示されます（例：1.18.0）。

「Stable」であることの意味

NGINX Open Sourceにおける「stable」とは、ソフトウェアの品質ではなく、機能と更新頻度を指します。stableブランチには、そのライフサイクル中に新機能が追加されることはなく、通常、重大なバグ修正のために1～2回更新されるだけです。

stableブランチのライフサイクルは1年間です。毎年4月に現行のstableブランチを廃止し、それ以降はバグ修正を行いません。これに伴い、次の2つのイベントが発生します。

現在のメインラインブランチをフォークして、次の安定版ブランチを作成します。新しい安定版ブランチには、前年にメインラインブランチへ加えられたすべてのバグ修正、機能、その他の変更が引き継がれます。先月、NGINX 1.17.10をフォークしてNGINX 1.18.0を作成しました。新しいメインラインブランチがリリースされるまでは、「安定版」は現在のメインラインブランチと同一であり、追加されてから数日しか経っていない新機能が含まれる場合もあります（NGINX 1.18ブランチでは、この状態は本日終了します）。
メインラインブランチでは「バージョンアップ」が行われます。つまり、バージョン番号の2番目の部分が次の奇数に繰り上がります。継続的な開発はメインラインブランチで進められ、4～6週間ごとにメインラインから新しいリリースがビルドされます。本日、NGINX 1.19.0がNGINX 1.19メインラインの最初のリリースとして公開されました。

NGINX Open Sourceブランチの年次「バージョン更新」2020年版

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

NGINX Plusは、NGINXの商用版であり、独立した非公開のコードリポジトリで保守されています。常にNGINXメインラインの最新バージョンをベースとし、NGINX Plus独自の追加機能とケイパビリティが統合されています。本稿執筆時点での最新バージョンはNGINX Plus R21で、NGINX 1.17.10をベースとしています。

どのブランチを使用すべきか

通常はmainlineブランチの使用を推奨します。すべての新機能、パフォーマンス改善、機能強化は、このブランチにコミットされます。mainlineブランチは積極的にテストおよび品質保証を行っており、NGINX Plusビルドのソースでもあるため、本番環境での使用に十分適しています。

新機能やバグ修正を把握するためにmainlineブランチを継続的に監視する負担が懸念される場合は、stableブランチを使用することで、新機能の確認は年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 Protocolでサーバーのアドレスとポートを取得する変数の導入などが含まれます。主な機能強化を詳しく見ていく前に、NGINX 1.17を数字で振り返ります。

メインラインリリース10回
37件のバグ修正
11件の新機能

HTTPリクエストレートおよび接続数制限の機能強化

The 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変数が追加されました。この変数をアクセスログのエントリに含めることで、レート制限がリクエスト処理に与える影響、具体的にはリクエストが次のいずれに該当するかを記録できます。

通過（遅延なくバックエンドサーバーに転送）［PASSED］
遅延した［DELAYED］
拒否された［REJECTED］
ドライランモードで遅延としてカウントされた［DELAYED_DRY_RUN］
ドライランモードで拒否としてカウントされました［REJECTED_DRY_RUN］

NGINX 1.17.6では、接続数制限用のドライランモードを有効にするlimit_conn_dry_runディレクティブと、接続リクエストが以下のいずれに該当するかを記録する$limit_conn_status変数も追加されました。

通過（バックエンドサーバーに転送）[PASSED]
拒否されました［REJECTED］
ドライランモードで拒否としてカウントされた［REJECTED_DRY_RUN］

設定例については、「接続制限の機能強化」を参照してください。

新しい「`auth_delay`」ディレクティブ

The auth_delayディレクティブ（NGINX 1.17.10で追加）を使用すると、認証されていないリクエストの処理を遅延させ、ステータスコード401 (Unauthorized)をクライアントに返すことができます。これにより、アクセスリクエストの処理時に発生するタイミング攻撃を防止できます。利用可能な認証方式は次のとおりです。

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

Variables Support for the `grpc_pass`ディレクティブでの変数のサポート

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

追加のPROXY Protocol変数

PROXY Protocolを使用すると、レイヤー4プロキシは、リクエストを処理する次のプロキシまたはロードバランサーに元のクライアント情報を提供できます。これは、クライアントごとの接続数を制限する場合（least_connディレクティブを使用）など、クライアントのIPアドレスを把握する必要があるユースケースで重要です。このデータは、$proxy_protocol_addr変数（HTTP | Stream）で利用できます。

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

$proxy_protocol_server_addr（HTTP | Stream）
$proxy_protocol_server_port (HTTP | Stream)

注： PROXY Protocolの処理を有効にするため、proxy_protocolパラメーターをlistenディレクティブにも指定した場合にのみ、変数に値が設定されます。

変数のサポートを追加：`proxy_upload_rate`および`proxy_download_rate`ディレクティブ

Streamモジュールのproxy_upload_rateディレクティブとproxy_download_rateディレクティブは、それぞれNGINXがクライアントおよびプロキシ対象サーバーからデータを読み取る速度を制御します。NGINX 1.17.0以降では、これらのディレクティブに変数パラメーターを指定できるため、条件ごとに速度を定義できます。

Added Support for the `ioctl(FIONREAD)`システムコールのサポートを追加

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