NGINX Plus Release 21(R21)の提供開始をお知らせします。NGINX Open SourceをベースとするNGINX Plusは、ロードバランサー、コンテンツキャッシュ、Webサーバー、APIゲートウェイを一体化した唯一のソリューションです。NGINXは4億5,000万を超えるWebサイトで利用されており、NGINX Plus R21では、主にNGINX Open Sourceのバグ修正と安定性の向上を反映することで、信頼性とセキュリティがこれまで以上に強化されています。
NGINX Plus R21の新機能は次のとおりです。
- 動的gRPCプロキシ – バックエンドのgRPCサービスにgRPC接続を渡す際に、変数を使用できるようになりました。これにより、クライアント属性に基づいて、gRPC接続をサービスグループへ動的にルーティングできます。
- NGINX JavaScriptモジュールの機能強化 – NGINX JavaScriptモジュール(njs)がバージョン 0.3.9に更新され、複数のバグ修正に加え、サブリクエストとファイルシステムのサポートに関する機能が強化されました。
動作に関する重要な変更
- 許可されるリクエスト – RFC 7230に従い、NGINX Plusでは複数の
Hostヘッダーを含むクライアントリクエストは許可されなくなりました。 - 新たにサポートされるオペレーティングシステム – Alpine Linux 3.11.
- サポート対象外となった旧オペレーティングシステム – 32ビットプラットフォーム(i386アーキテクチャ)。
品質向上への投資
効率的なソフトウェアとコード品質は、オープンソース版とNGINX Plusのいずれにおいても、NGINX開発の中核をなす原則です。
NGINXチームは、商用ソフトウェアに求められる最新のCI/CDツールと自動テストツールをすべて活用しています。日次テストの結果、現在開発中のブランチの「欠陥密度」はコード1,000行あたりわずか0.01件と、同規模のコードベースにおける平均の1,000行あたり0.7件を大幅に下回っています。
また、オープンソースとNGINX Plusの両方のコンポーネントを対象に、外部の独立機関による侵入テストとコードレビューも実施しています。直近の侵入テストとコードレビューで特定された複数の問題は、本リリースで修正されています。
バグ修正
NGINX Plus R21では、合計14件のバグが修正されています:
- HTTP/2使用時のソケットリーク(別々の2件のバグ)
- Socket leak when using subrequests in the njsモジュールおよび
aioディレクティブでサブリクエストを使用した場合のソケットリーク - メモリ枯渇の可能性(WebDavモジュール)
- 「MP4」モジュールでメモリ情報が漏えいする可能性
- ステータスコード
494のエラーがerror_pageディレクティブによってリダイレクトされた際、400ではなく494が返されました - SSL接続でパイプライン化されたリクエストを処理している際に、タイムアウトが発生する可能性がある
- Segmentation fault might occur in a worker process if OCSP staplingを使用した場合、ワーカープロセスでセグメンテーションフォールトが発生する可能性があります
- 構成に空の置換文字列を指定した
rewriteディレクティブが含まれている場合、起動時または再構成中にセグメンテーションフォールトが発生する可能性がありました - 次の場合、ワーカープロセスでセグメンテーションフォールトが発生する可能性がありました。
breakディレクティブをaliasディレクティブと併用した場合、またはURIを指定したproxy_passディレクティブと併用した場合 - 最初の
Transfer-Encodingリクエストヘッダーのみが処理されていました - リクエストURIがヌル文字を含むURIに書き換えられた場合、
Locationレスポンスヘッダー行に不正なデータが含まれる可能性がありました - 本文を含むリクエストは、
error_pageディレクティブでリダイレクトを返す際に正しく処理されませんでした - HTTP/2使用時の
debug_pointsディレクティブのバグ
これらのバグはいずれも重大なものではなく、関連するCVEレコードもありません。
NGINX Plusロードマップへの投資
本リリースの時点では、2020年のロードマップに鋭意取り組んでいます。今年後半には、プロダクションレベルの実装であるHTTP/3(別名QUIC)を提供する予定です。このテクノロジーの動向を追跡したり、テストしたりする場合は、今後数週間以内に公開される実験的なパッチにご注目ください。
新機能の詳細
動的gRPCプロキシ
NGINX Plus R15では、アップストリームグループへのgRPCトラフィックのルーティングと負荷分散がサポートされました。grpc_passディレクティブを含めることで、NGINX Plusを使用してgRPCトラフィックをルーティングできます。
NGINX Plus R21では、grpc_passディレクティブで変数がサポートされ、gRPCワークロードにも適用できる動的なAPI駆動型ルーティングポリシーを実現します。これにより、次のようなユースケースに対応できます。
- A/Bテスト – gRRCリクエストを複数のアップストリームに統計的に分散し、どのアップストリームのパフォーマンスが優れているかを判断します。
- デバッグルーティング – トラフィックは本番環境のgRPCサービスにルーティングし、特定の属性(送信元IPアドレス、gRPCメタデータ)を持つリクエストはデバッグ用gRPCサービスにルーティングします。
次の設定は、デバッグルーティングの実装例です。
コード例を読み込み中…
1行目では、ネットワーク範囲をキーとして使用できるキーバリューストアを定義します( type=ipパラメーターで有効化)。2行目では、$greeter_upstream変数の値を、クライアントIPアドレス($remote_addr)をキーとしてgrpc-greeterキーバリューストアを検索することで評価するよう指定します。
10行目では、grpc://$greeter_upstreamをgrpc_passディレクティブのパラメーターとして指定し、TLS終端を行うとともに、クライアントのIPサブネットに基づいてgRPCリクエストを動的にルーティングします。
たとえば、NGINX Plusインスタンスで次のコマンドを実行すると、192.168.80.0/24サブネットからのリクエストをgrpc-servers-greeter-debugにルーティングできます。
$ curl -iX POST -d '{"192.168.80.0/24":"grpc-servers-greeter-debug"}' http://localhost:8080/api/6/http/keyvals/grpc-greetergRPCトラフィックを本番環境のサービスグループ(grpc-servers-greeter-prod)に切り替えるには、次のコマンドを実行します。
$ curl -iX PATCH -d '{"192.168.80.0/24":"grpc-servers-greeter-prod"}' https://localhost:8080/api/6/http/keyvals/grpc-greeterNGINX JavaScript Moduleの機能強化
NGINX JavaScriptモジュール(njs)がバージョン 0.3.9に更新され、複数のバグ修正に加え、サブリクエストとファイルシステムのサポートに関連する機能が一部強化されました。
サブリクエスト
The r.subrequest関数を使用すると、njsコードから任意のURIに非同期HTTPリクエストを送信できます。さまざまなユースケースが考えられますが、代表的な例として、外部認証サーバーへのAPI呼び出し(OAuth 2.0トークンイントロスペクションなど)があります。このリリースでは、サブリクエストにプロミスとデタッチされたサブリクエストという2つの重要な機能強化が加わりました。
[編集者 – 以下の2つのユースケース例は、NGINX JavaScriptモジュールの数あるユースケースの一部にすぎません。完全な一覧については、「NGINX JavaScriptモジュールのユースケース」を参照してください。]
Promise
サブリクエストには通常、そのレスポンスを処理するコールバック関数が含まれます。JavaScriptのPromiseを使用すると、呼び出し元のコード内でレスポンスをインライン処理できるため、コールバック関数を省略できるようになりました。次の例は、コールバックを使用せずに、連続するサブリクエストを1つのコードシーケンス内で連結する方法を示しています。
コード例を読み込み中…
分離されたサブリクエスト
サブリクエストは非同期であり、以前はjs_contentディレクティブから呼び出す必要がありました。現在は、変数の評価中にjs_setディレクティブからサブリクエストをトリガーすることもできます。これらの「デタッチされた」サブリクエストも引き続き非同期で動作しますが、呼び出し元の関数にはデータを返さず、レスポンスはすべて無視されます。
次のサンプルコードでは、デタッチされたサブリクエストを使用し、交換されたデータの総量が1 MBを超えた場合に、リクエストヘッダーのコピーをセキュリティ情報およびイベント管理(SIEM)システムに送信します。
[編集者 – 以下の設定は、 js_importディレクティブを使用するように更新されています。このディレクティブは、 js_includeディレクティブに代わり、NGINX Plus R23<.htmla>で導入されました。詳細については、NGINX JavaScript moduleのリファレンスドキュメントを参照してください。Example Configurationセクションに、NGINX設定ファイルとJavaScriptファイルの正しい構文が記載されています。]
コード例を読み込み中…
その後、アクセスログの書き込み時に変数の評価を要求することで、ログフェーズでJavaScriptコードが実行されます。
コード例を読み込み中…
ファイルシステム
JavaScriptのファイルシステムオブジェクトfsが拡張され、非同期処理でPromiseをサポートするようになりました。また、新しいファイルシステムメソッドとして、access()、realpath()、symlink()、unlink()が追加されました。
NGINX Plusをアップグレードまたはお試しください
NGINX Plusをご利用の場合は、できるだけ早くNGINX Plus R21へアップグレードすることを強く推奨します。これにより、追加の修正や改善も適用され、サポートチケットが必要になった際に、NGINXがお客さまをより円滑に支援できるようになります。
アップグレードを実行する前に、このブログ記事で説明している「新機能」と「動作の変更点」をよくご確認ください。
NGINX Plusをまだお試しでない場合は、ぜひご利用ください。セキュリティ、負荷分散、APIゲートウェイとして、または強化された監視・管理APIを備え、充実したサポートを受けられるWebサーバーとして活用できます。今すぐ30日間の無料トライアルを開始できます。NGINX Plusがアプリケーションの提供とスケーリングにどのように役立つか、ぜひお確かめください。
著者について

関連するブログ記事
チュートリアル:NGINXを使用してアプリケーション向けにOpenTelemetryを構成する
OpenTelemetryを使用してNGINXサーバーの状態と健全性をより明確に把握することで、問題のトラブルシューティングを行い、Webアプリケーションのパフォーマンスを向上できます。
AkitaのNGINX Plus認定モジュールでAPIエンドポイントの問題を特定・修正
Akita SoftwareのAPIオブザーバビリティ向け新しいNGINX Plus Certified Moduleを活用して、APIエンドポイントの問題をより迅速に特定し、修正できます。
JavaプロジェクトをスキャフォールディングしてKubernetesネイティブアプリを構築する方法
Red HatのシニアプリンシパルデベロッパーアドボケイトであるDaniel Oh氏が、Javaプロジェクトをゼロから構築するためのひな形を作成し、Kubernetesネイティブアプリケーションとしてビルドする方法を解説します。
F5 NGINXaaS for Azureのご紹介:Microsoft Azureでネイティブに利用できるSaaS型ロードバランシング
NGINXaaS for Azureは、NGINX PlusをAzureネイティブのSaaSとして利用できるサービスです。NGINXの設定を容易にリフト&シフトできるため、クラウド導入とモダンアプリの展開を加速できます。

SELinuxでNGINXおよびNGINX Plusを使用する
Red Hat Enterprise Linux(RHEL)および関連ディストリビューションでSecurity-Enhanced Linux(SELinux)を有効にすると、デフォルト設定によりNGINXとNGINX Plusの一部の操作が制限されます。この記事では、すべての機能を利用できるようにSELinuxの設定を変更する方法について説明します。
NGINX PlusによるAWS Auto Scalingグループの負荷分散
新しいnginx-asg-sync統合ソフトウェアにより、NGINX PlusはAWS Auto Scalingグループの負荷を直接分散できるため、クラウドでの負荷分散がさらに柔軟になります