NGINX Plus R9リリースのお知らせ

Owen Garrettプロダクトマネジメント担当シニアディレクター

NGINX, Inc.は、アプリケーションデリバリープラットフォームの最新リリースであるNGINX Plus Release 9（R9）の提供開始を発表いたします。このアップデートでは、2つの重要な新機能を提供します。1つは、カスタムバイナリを必要とせずに、NGINX Plusの多彩な拡張機能を動的にロードする機能です。もう1つは、既存のTCPおよびHTTPロードバランシング機能に加えて提供される、商用サポート付きUDPロードバランシングです。

NGINX Plus R9の魅力的な新機能に加え、新しい料金体系とサポートオプションも導入します。NGINX Plusでは、固定料金でアプリケーションや企業全体のあらゆる場所において無制限に利用できる「定額使い放題」料金モデルをご利用いただけるようになりました。また、NGINX Plusは3つの異なるサポートレベルから選択して購入できるようになりました。非本番環境向けのBasic 9×5サポート、電話またはメールによるProfessional 24×7サポート、30分以内の応答を保証するEnterprise 24×7サポートです。

編集者注 – NGINX Plus R9の主な新機能について詳しくは、以下の関連リソースをご覧ください。

• NGINXとNGINX PlusによるDNSトラフィックの負荷分散
• NGINXおよびNGINX PlusでDNSを使用したサービスディスカバリ
• ConsulのDNS SRVレコードを使用したNGINX Plusのサービスディスカバリ
• NGINX Plus R9の新機能（オンデマンドウェビナー）

NGINX Plus R9の主な新機能は次のとおりです。

• 動的モジュール – NGINX Plusは、動的にロード可能なモジュールを使用して実行時に拡張できるようになりました。必要な拡張機能だけを選択し、標準のaptおよびyumコマンドでアクセスできるNGINX Plusリポジトリから直接インストールできます。今後、テスト済みで完全に認定されたソフトウェア拡張機能を順次拡充し、提供していきます。Luaプログラミング言語のサポートなど、NGINXが開発した主要なモジュールや人気の高いサードパーティ製モジュールは、すでに新しい動的ロード形式に変換されています。また、モジュールを新しい形式に変換するためのサードパーティモジュール所有者向け手順も公開しています。モジュールをNGINX Plusリポジトリに追加するには、事前にこの形式へ変換する必要があります。
• UDPロードバランシング – 既存のTCPおよびHTTPロードバランシング機能にUDPロードバランシングが加わり、NGINX Plusでは、ほぼすべてのアプリケーションをロードバランシングできるようになりました。先月、NGINX Open SourceでのUDPロードバランシングを追加しましたが、今回のリリースでは、高度な機能を追加してNGINX Plusにもサポートを拡張しています。NGINX Plusは、アクティブヘルスチェックでUDPサービスを監視し、豊富な統計情報によって重要な可視性を提供するほか、サーバーを動的に追加および削除できます。UDPは、DNS（ドメイン名をアドレスに解決）、syslog（軽量なロギング）、RADIUS（認証プロトコル）など、トランザクション型ではない軽量プロトコルで広く使用されています。また、必要な帯域幅が少ないため、IoTアプリケーションで選ばれるプロトコルの1つとしても注目されています。NGINX Plusなら、こうした既存および新規のアプリケーションを容易に配信し、ロードバランシングできます。
• DNS SRVレコードを使用したサービスディスカバリ – マイクロサービスベースのアプリケーションは動的であり、必要に応じてサービスをスケールアップ、スケールダウン、移動できます。サービスの現在の状態を常に把握するには、サービスディスカバリが有効です。Consulやetcd（SkyDNS）など、多くのサービスディスカバリプラットフォームは、検出されたサービスの情報をNGINX Plusなどのクライアントが要求できるDNSインターフェースを提供しています。サービスが使用するポート番号は、多くの場合、動的に割り当てられます。そのため、サービスディスカバリプラットフォームでは、ポート番号情報を含むDNS SRVレコードを使用します。NGINX PlusはDNS SRVレコードをサポートするようになり、DNSリクエストを使用してサービスレジストリに問い合わせ、動的に割り当てられたポート情報を含むサービスの場所を取得できます。
• NGINX Plus App Pricing – 急成長期、季節的な需要変動、トラフィックの増減時にも最大限のパフォーマンスと稼働時間を確保するため、多くのアプリケーションには動的なインフラストラクチャが必要です。こうしたアプリケーションでは通常、マイクロサービスや分散アーキテクチャを採用し、実行環境としてコンテナや仮想マシンも利用します。ソフトウェアの料金をインスタンス単位またはマシン時間単位で支払う方式では、最新のアプリケーションに必要な柔軟性やコスト効率を実現できません。このようなユースケースに対応するため、NGINX Plus App Pricingを導入します。NGINX Plus App Pricingでは、NGINX Plusの拡張機能と商用サポート付きバイナリを、アプリケーションごとに年間定額で無制限に利用できます。VM、コンテナ、ノード、同時接続、ユーザーの数にかかわらず、年間を通じて低額の定額料金のみで利用できます。アプリケーションインフラストラクチャ内の必要な場所に、必要なタイミングと方法でNGINX Plusを導入でき、開発、テスト、ステージング、災害復旧、本番の各環境で利用できます。予測できない従量課金を心配する必要はなく、急なキャパシティ増強が必要な場合にライセンスキーの取得を待つ必要もありません。

NGINX Plus R9の機能詳細

このセクションでは、NGINX Plus R9のすべての新機能について詳しく説明します。

動的モジュール

NGINXとNGINX Plusはいずれもモジュール型アーキテクチャを採用しています。サードパーティーの開発者やNGINXのコアエンジニアリングチームが作成したモジュールにより、コア機能を拡張できます。これらのモジュールは、Luaスクリプトの組み込みやIPアドレスに基づくユーザーの位置情報特定など、主要な機能を追加します。利用可能なモジュールは、100を超えるサードパーティーモジュールと60を超える公式NGINXモジュールです。このうち56個は基本のnginx‑plusパッケージに、さらに10個はnginx‑plus‑extrasパッケージに含まれています（全リストは「NGINX Plus Technical Specifications」でご確認いただけます）。

今回のリリースでは、nginx‑plus‑extrasパッケージに含まれる追加モジュール（サードパーティ製およびNGINX公式）も、基本のNGINX Plusパッケージであるnginx‑plusに動的に読み込めるようになりました。これにより、実際に必要な追加モジュールだけを読み込むことができます。

これらのモジュールはNGINX Plusリポジトリで提供されています。今後数か月のうちに、同リポジトリへモジュールを追加する予定です。現在nginx‑plus‑extrasパッケージを使用している場合は、コアのnginx‑plusパッケージへの移行を推奨します。今後のリリースでnginx‑plus‑extrasパッケージを非推奨とする予定です。

各ダイナミックモジュールをNGINX Plusコアにロードしてから広範なリリーステストを実施し、未設定のモジュールがNGINX Plusの正常な動作を妨げないことを確認しています。モジュールの更新を追跡し、リリースのたびに、またリリース間に重大なセキュリティ問題が報告された場合にも、新しいビルドを提供します。

動的モジュールにより、広く利用される機能を備えた単一のNGINX Plusバイナリを配布できます。管理者は、使用する追加モジュールを必要に応じて選択できます。

NGINX Plusで動的モジュールを読み込む方法

モジュールをインストールして動的にロードするには、以下の手順を実行します。この手順では、OSベンダーのディストリビューションではなく、NGINX, Inc.からファイルを取得するようにパッケージ管理ツールが設定されていることを前提としています。

1. オペレーティングシステムの標準パッケージ管理ツール（例：aptまたはyum）を使用して、ベースとなるnginx‑plusイメージと、動的にロードするモジュールをインストールします（モジュールごとにインストールコマンドを実行してください）。以下のコマンドはDebianベースのシステムに適しています。

# apt-get update# apt-get install nginx-plus
# apt-get install module-name

1. このリリースでmodule‑nameに指定できる名前は次のとおりです。選択したモジュールの.soファイルがインストールされている場所へのシンボリックリンクを含む/etc/nginx/modulesディレクトリが自動的に作成されます。注：
   • nginx-plus-module-geoip
   • nginx-plus-module-headers-more
   • nginx-plus-module-image-filter
   • nginx-plus-module-lua
   • nginx-plus-module-passenger
   • nginx-plus-module-perl
   • nginx-plus-module-rtmp
   • nginx-plus-module-set-misc
   • nginx-plus-module-xslt
   • 以前のリリースのNGINX Plus向けnginx‑plus‑extrasパッケージを使用している場合は、R9のnginx‑plusパッケージをインストールする前に削除する必要があります。Debianベースのシステムでは、次のコマンドを実行します。

# apt-get update# apt-get remove nginx-plus-extras
# apt-get install nginx-plus
# apt-get install module-name

• OSの制限により、一部のOSバージョンでは利用できないモジュールがあります。詳細および各モジュールの説明については、NGINX Plus Technical Specificationsを参照してください。

1. In the main (top‑level) context in /etc/nginx/nginx.confのmain（最上位）コンテキストに、動的にロード可能な各モジュールのload_moduleディレクティブを追加します：

load_module modules/module-name.so;

1. 新しい設定の構文が有効であることを確認し、NGINX Plusを再読み込みします。

# nginx -t && nginx -s reload

1. nginx.confに記載されているモジュールは、NGINX Plusに動的に読み込まれます。

UDPロードバランシング

先月、NGINX Open SourceのUDPロードバランシングをリリースしました。NGINX Plus R9では、この機能がヘルスチェック、拡張ステータス監視、動的な再構成に対応しました。

TCPロードバランシングと同様に、UDPロードバランシングの設定はstreamコンテキストに記述します。また、HTTPおよびTCPロードバランシングと同様に、UDPロードバランシングでは、upstream groupを使用して、UDPベースのサービスを提供するオリジンサーバーのセットと、サーバー間でトラフィックをロードバランシングする際に使用するalgorithmを定義します。

また、この設定ではUDPポートごとに仮想サーバーを定義し、関連するサービスを提供するアップストリームグループをproxy_passディレクティブで指定します。

stream {    upstream dns_upstreams {
        least_time;
        server dns-server-1-ip:53;
        server dns-server-2-ip:53;
    }
 
    server {
        listen 53 udp;
        listen 53; #tcp
        proxy_pass dns_upstreams;
        proxy_timeout 1s;
        proxy_responses 1;
        error_log logs/dns.log;
    }
}

この設定例では、DNSサービスの負荷分散を行います。upstreamブロックではLeast Timeアルゴリズムを設定し、現在の「接続」数が最も少なく、応答が最も速いサーバーにNGINX Plusが各リクエストを送信するようにします。serverブロックでは、DNSが両方のプロトコルで動作できるため、UDPとTCPの両方のトラフィックをリッスンします。proxy_responsesディレクティブは、UDPの「接続」に関連付けられたリソースを解放するまでに、NGINX Plusがアップストリームサーバーから受信するレスポンス数を制御します。DNSは単純なリクエスト／レスポンス型プロトコルであるため、通常は1件のレスポンスで十分です。

NGINX Open Sourceには、UDP向けの基本的なヘルスチェック機能が含まれています。アップストリームUDPサーバーが、設定されたタイムアウト時間内にリクエストに応答しない場合、またはICMPエラーを返した場合、NGINXとNGINX Plusは設定された期間、そのサーバーへのトラフィック送信を停止します。

NGINX Plus R9では、UDPサービス向けに、HTTPおよびTCPトラフィック向けと同様のアクティブヘルスチェックが追加されました。NGINX Plusを構成して、アップストリームサーバーに特別なUDPリクエストを送信し、サーバーが正常と見なされるために返す必要があるレスポンスの種類を定義できます。UDPには、HTTPでTCPが提供する信頼性の高い配信の仕組みがないため、UDPアプリケーションでは、TCPおよびHTTPアプリケーション以上にアクティブヘルスチェックが重要です。

NGINX Plusでは、アップストリームサーバーを動的に追加または削除することもできます。これにより、たとえばメンテナンスのためにサーバーをオフラインにし、その後ロードバランシング対象のプールに戻す作業が容易になります。NGINX Plusの「Status」モジュールと「ライブアクティビティモニタリング」ダッシュボードに追加されたUDP関連の統計情報により、サーバーのパフォーマンスを把握するうえで重要な可視性が得られます。

NGINX Plus R9は、DNS、RADIUS、syslog、NTPなど、最も一般的に使用されるシンプルなUDPベースのアプリケーションの負荷を分散します。現時点では、Voice over IPやその他のSIPベースのアプリケーションなど、長時間接続を維持するUDPプロトコルはサポートされていません。

DNSを使用したサービスディスカバリ「SRV」レコード

最新のWebアプリケーションは、Webサーバー、アプリケーションサーバー、データベースなど、複数の小規模なアプリケーションコンポーネントで構成されています。NGINX Plusなどのフロントエンドロードバランサーは、受信トラフィックを検査し、アプリケーションコンポーネント間でリクエストをルーティングして負荷分散します。

アプリケーションコンポーネントを仮想プラットフォームやコンテナベースのプラットフォームにデプロイすると、IPアドレスやポートが予測できない場合があります。サービスディスカバリとは、ローカルクライアント（フロントエンドのNGINX Plusロードバランサーなど）が、トラフィックの送信先となるこれらのコンポーネントを検出するプロセスです。サービスディスカバリは通常、Consul、etcd、ZooKeeperなどの「サービスデータベース」によって実現されます。

NGINX Plus R8では、オンザフライ再構成APIの永続版を発表するとともに、サービスデータベースを確認して構成変更をNGINX Plusにプッシュする、Consul、etcd、ZooKeeper向けのデモソリューションを公開しました。NGINX Plus R9では、DNS SRVクエリを使用する別の方法のサポートを発表します。DNS SRVクエリは、特定の種類のアプリケーションサーバーのIPアドレス、ポート、優先度、重みを返します。

ConsulとSkyDNS for etcdは、いずれもクライアントがSRVレコードを取得するために使用できるDNSインターフェースを提供します。NGINX Plusは、サービスのDNSインターフェースに直接クエリを実行して、負荷分散設定を取得します。また、サービスを定期的に再確認するため、変更は迅速かつ自動的に反映されます。

次の例では、NGINX PlusがDNS経由でmy_serviceのアップストリームサーバーのリストを取得するように設定します。service=httpパラメーターをserverディレクティブに指定すると、DNSのSRVレコードがサポートされます。これにより、my_serviceを構成するアプリケーションインスタンスがNGINX Plusによって自動的に検出されます。

http {     resolver dns-server-ip;
 
    upstream my_service {
        zone backend 64k;
        server hostname-for-my_service service=http resolve;
    }
 
    server {
        # ...
 
        location /my_service {
            # ...
            proxy_pass http://my_service;
        }
    }
}

NGINX Plusアプリの料金

インスタンス単位の料金体系は、NGINX Plusを導入するうえで優れた選択肢であり、ハードウェアロードバランサーに代わる非常に費用対効果の高い方法です。しかし、NGINX Plusの用途は、単なるハードウェアの置き換えにとどまりません。軽量なソフトウェアアーキテクチャを採用しているため、NGINX Plusはアプリケーションごとに専用のロードバランシングを行う用途に最適です。また、NGINX PlusはNGINX Open Sourceを基盤としているため、アプリケーション内のWebサーバーやアプリケーションサーバーも置き換えることができます。こうしたユースケースの増加に伴い、インスタンス単位の料金体系では費用対効果や柔軟性が十分でないNGINX Plusの導入が増えています。

NGINX Plus R9では、特定のアプリケーション向けにNGINX Plusのインスタンスを必要な数だけ実行できる、新しい「使い放題」のApp Pricingモデルを導入します。アプリケーションインフラストラクチャ内の必要な場所に、必要なタイミングと方法でNGINX Plusを導入でき、開発、テスト、ステージング、災害復旧、本番の各環境で利用できます。VM、コンテナ、ノードの数にかかわらず、年間料金は一律です。

Every subscription includes the full features of the NGINX Plus software and our award‑winning support and configuration assistance. In addition, opting for the App Pricing model entitles you to:

• ご希望に応じて、NGINX Professional Servicesによるインストールやチューニングのサポート
• トレーニング：チーム向けに、NGINXの基礎、高度なトピック、またはその両方を学習

アプリケーション単位で無制限に使用できます。アプリケーションとは、単一のWebアプリケーション、または個別に命名されたデスクトップアプリケーションやモバイルアプリケーションを支えるソフトウェアコンポーネントとチームを指します。このモデルは、マイクロサービスベースのアーキテクチャをはじめとする分散アーキテクチャを想定し、対応しています。

組織全体でNGINX Plusを無制限に利用できるSite Licenseサブスクリプションもご用意しています。

追加機能

NGINX Plus R9では、以下をはじめとするさまざまな機能強化が行われています。

• キャッシュパフォーマンスの向上 – 昨年、F5はスレッドプールモデルを導入し、キャッシュ読み取り処理を改善するとともに、この処理によってNGINXコアがブロックされる可能性を回避しました。これにより、特定のキャッシュワークロードではパフォーマンスが最大9倍向上する可能性が生まれました。本リリースでは、NGINX Plusでキャッシュのディスク書き込みをスレッドにオフロードすることもできます。
• TCP経由のDNSルックアップ – デフォルトでは、NGINX PlusはDNSルックアップにUDPを使用します。ただし、たとえば名前解決の結果として多数のサーバーが返される場合など、DNS応答が大きいと、応答全体が1つのUDPデータグラム（上限512バイト）に収まらないことがあります。不完全な応答には切り詰められたことを示すフラグが付けられ、NGINX PlusはTCPを使用して直ちにリクエストを再試行するようになりました。これにより、NGINX Plusは非常に大規模で動的なサーバー環境をより適切にサポートできます。
• 非べき等リクエストの再試行 – HTTPリクエストがエラーまたはタイムアウトによって失敗した場合、NGINX Plusはデフォルトで、アップストリームグループ内の別のサーバーに対して自動的に再試行します。proxy_next_upstreamディレクティブを使用すると、特定の4xxまたは5xxレスポンスコードを含め、NGINX Plusがリクエストを再試行するエラーの種類を定義できます。通常、POSTリクエストでは本文データがサーバーにストリーミングされ、サーバーに障害が発生した場合に再送できないため、一般に再試行されません。ただし、以前のバージョンのNGINX Plusでは、特定の障害状況下でPOSTリクエストが再試行されることがありました。これは、非べき等であるため再試行されないという前提と一致しない動作でした。NGINX Plusでは、失敗した非べき等HTTPリクエスト（POST、LOCK、PATCH）が自動的に再試行されなくなりました。以前の動作に戻し、可能な場合にNGINX Plusが失敗した非べき等リクエストを再試行できるようにするには、non_idempotentという新しいパラメーターをproxy_next_upstreamディレクティブに追加します。

NGINX Plusへのアップグレードまたはお試し

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

まだNGINX Plusをお試しでない場合は、Web高速化、負荷分散、アプリケーションデリバリーのためのソリューションとして、または高度な監視と動的再構成に対応するAPIを備えた、完全なサポート付きWebサーバーとして、ぜひお試しください。今すぐ30日間の無料トライアルを開始し、NGINX Plusがアプリケーションのデリバリーとスケールアウトにどのように役立つかをご確認ください。

編集者注 – NGINX Plus R9の主な新機能の詳細については、以下の関連リソースをご覧ください。

• NGINXとNGINX PlusによるDNSトラフィックの負荷分散
• NGINXおよびNGINX PlusでDNSを使用したサービスディスカバリ
• ConsulのDNS SRVレコードを使用したNGINX Plusのサービスディスカバリ
• NGINX Plus R9の新機能（オンデマンドウェビナー）

著者について

Owen Garrettプロダクトマネジメント担当シニアディレクター

Owen Garrettのその他のブログ記事