※本記事はNGINX,Inc.のデプロイメントガイド「Load Balancing Apache Tomcat Servers with NGINX Open Source and NGINX Plus」を和訳した内容となります。
【URL】
https://docs.nginx.com/nginx/deployment-guides/apache-tomcat-load-balancing-nginx-plus/
このデプロイメントガイドでは、コミュニティ版NGINXとNGINX Plusを使い、Apache Tomcat TMアプリケーションサーバー群でHTTPトラフィックとHTTPSトラフィックのロードバランシングを行う方法について説明します。このガイドで紹介する詳細手順は、クラウドベース、オンプレミス構成のTomcatに利用できます。
- NGINXとNGINX Plusについて
- Apache Tomcatについて
- 前提条件とシステム要件
- クライアントトラフィックのSSL / TLS証明書の設定
- 設定ファイルの作成と変更
- NGINXまたはNGINX Plusの基本的なロードバランシング設定
- HTTPおよびHTTPSトラフィック用に仮想サーバーを構成する
- 基本的なロードバランシング設定を行う
- 基本的なセッション・パーシステンス（永続性）を設定する
- WebSocketトラフィックのプロキシを設定する
- コンテンツキャッシュを設定する
- HTTP / 2サポートを設定する
- 基本的なロードバランシングの全設定
- NGINX Plusによる拡張ロードバランシングの設定
- 高度なセッション・パーシステンスを設定する
- アプリケーションヘルスチェックを設定する
- ライブ アクティビティ モニタリングを有効化する
- upstreamグループのダイナミック リコンフィギュレーションを有効化する
- 拡張ロードバランシングの全設定
- リソース
コミュニティ版NGINXとNGINX Plusについて
コミュニティ版NGINXはオープンソースのWebサーバー兼リバースプロキシで、そのスケーラビリティ、優れたパフォーマンス、軽量性から、近年幅広く普及してきています。コミュニティ版NGINXは当初、C10K（クライアント1万台問題：単一のWebサーバー上で10,000の同時接続を処理できない）を解決するために開発されました。その機能とパフォーマンスによって、コミュニティ版NGINXは高性能サイトの定番となり、現在、世界で最も混雑しているトップ10万ウェブサイトの大部分を支えています。
NGINX Plusは、このコミュニティ版NGINXの商用サポート版です。NGINX Plusは、完全なアプリケーション配信プラットフォームであり、Tomcatの導入を強化し、大規模なWebアプリケーションを構築するために不可欠なエンタープライズ対応の機能群を備え、コミュニティ版NGINXの機能を拡張しています。
- フル機能のHTTP、TCP、およびUDPロードバランシング（英語）
- インテリジェントなセッション・パーシステンス（英語）
- 高性能リバースプロキシ（英語）
- 動的コンテンツと静的コンテンツのキャッシングとオフロード（英語）
- 任意のデバイスに音声や動画を配信する適応型ストリーミング（英語）
- アプリケーション認識のヘルスチェックと高可用性（英語）
- ダッシュボードまたはAPIを介した高度なアクティビティモニタリングの利用（英語）
- DevOpsにやさしいツールによる管理とリアルタイム設定変更（英語）
Apache Tomcatについて
Apache Tomcatは、Java Servlet、JavaServer Pages、Java Expression Language、およびJava WebSocketテクノロジーのオープンソース・ソフトウェアでの実装です。
このガイドの手順に従い、Apache Tomcat 8.0に対してテストを実施しました。
前提条件とシステム要件
- 物理または仮想システムにインストール、設定されたTomcatアプリケーションサーバー。
- コミュニティ版NGINXまたはNGINX Plus をホストするLinuxシステム。ソフトウェアのインストールは他のアプリケーションとの潜在的な競合を避けるため、まっさらな状態の物理または仮想システムで行うことをお勧めします。NGINX Plusでサポートされているオペレーティングシステムの一覧については、「NGINX Plusの技術仕様」（英語）をご覧ください。
- コミュニティ版NGINX1.9.5以降、NGINX Plus R7以降。
この手順書では、基本的なLinuxシステムの管理スキルがあることを前提とし、以下の作業についての詳細な説明は記載していません。
- Tomcatアプリケーションの設定とデプロイ
- ベンダー提供のパッケージからLinuxソフトウェアをインストールする
- 設定ファイルの編集
- 中央管理システムとLinuxサーバー間でのファイルのコピー
- 基本的なコマンドを実行してサービスを開始および停止する
- ログファイルを読む
サンプル値とテキストのコピーについて
- example.comをサンプルドメイン名として使用します（キー名と構成ブロック内）。それを組織の名前に置き換えます。
- このガイドでは、コミュニティ版NGINXとNGINX Plusの多くの設定ブロックに、2つのサンプルTomcatアプリケーションサーバーがリストされており、それぞれIPアドレスは10.100.100.11と10.100.100.12です。これらのアドレスを、ご自分のTomcatサーバーのIPアドレスに置き換えてください。サーバー数が2台以外の台数の場合は、各サーバーを構成ブロックに記載してください。
- 読みやすくするために、複数行で表示されているコマンドがあります。ターミナルウィンドウにコピーして貼り付ける場合は、最初にテキストエディタにコピーして、ご自分の構成に合わせたオブジェクト名に置き換え、ブラウザが挿入する余計な書式設定文字を削除することをお勧めします。
- このガイドの例は部分的なものもありますので、ディレクティブやパラメーターを補足する必要があります。基本ファイルと拡張ロードバランシング用の完全な設定ファイルは、「設定ファイルの作成と変更」（英語）の指示に従って、NGINX、Inc.のサイトからダウンロードできます。特定のディレクティブまたはパラメーター詳細については、NGINXリファレンスドキュメンテーション（英語）を参照してください。
- このガイドの設定スニペットのテキストを設定ファイルにコピーすることはお勧めしません。設定ファイルを作成する推奨方法については、「設定ファイルの作成と変更」（英語）を参照してください。
クライアントトラフィックのSSL / TLS証明書の設定
もし、コミュニティ版NGINXまたはNGINX PlusとTomcatアプリケーションのクライアント間で、トラフィックのSSL / TLS暗号化をするのであれば、コミュニティ版NGINXまたはNGINX Plusのサーバー証明書を設定する必要があります。
- SSL / TLSサポートは、NGINX,Inc.が提供するすべてのNGINX Plusパッケージおよびコミュニティ版NGINXバイナリでデフォルトで有効になっています。
- ソースからコミュニティ版NGINXをコンパイルする場合は、HTTPトラフィックのSSL / TLSサポートを有効にするために–with-http_ssl_moduleパラメーターを含めます（TCPに対応するパラメーターは–with-stream_ssl_moduleです。eメール用は、–with-mail_ssl_moduleですが、このガイドではどちらのプロトコルタイプもカバーしません）。
- 他のプロバイダのバイナリを使用する場合は、プロバイダのマニュアルを参照して、SSL / TLSをサポートしているかどうかを確認してください。
サーバー証明書を取得するには、次のような方法があります。2番目と3番目のオプションについて、順を追っての手順を掲載しています。
- 既に他のUNIXまたはLinuxシステム（Apache HTTPサーバーを実行しているシステムを含む）上にインストールされた、コミュニティ版NGINXまたはNGINX Plus用のSSL / TLS証明書がある場合、それをコミュニティ版NGINXまたはNGINX Plus サーバー上の/etc/nginx/SSLディレクトリにコピーしてください。
- 以下の「自己署名証明書を生成する」で説明する通りに、自己署名証明書を生成してください。これはテストには十分ですが、本番環境のクライアントには通常、認証局（CA）によって署名された証明書が必要です。
- 以下の「証明書要求の生成」の説明に従って、CAまたは所属先団体のセキュリティグループからの新しい証明書を要求します。
SSL / TLS Terminationの詳細については、「NGINX Plus管理者ガイド」（英語）を参照してください。
自己署名証明書の生成
公開鍵と秘密鍵のペアと、それに基づいたPEM形式の自己署名入りサーバー証明書を生成します。
- opensslソフトウェアがインストールされているマシンに、rootユーザーとしてログインします。
- キーペアをPEM形式で生成します（デフォルト）。秘密鍵を暗号化するには、-des3パラメーターを含めます。（他の暗号化アルゴリズムも利用可能で、genrsaコマンドのマニュアルページに記載されています。）暗号化の基礎として使用されるパスフレーズの入力が求められます。
- root# openssl genrsa -des3 -out ~/private-key.pem 2048Generating RSA private key …Enter pass phrase for private-key.pem:
- 安全な場所に、キーファイルのバックアップを作成します。鍵を失った場合、証明書は使用できなくなります。
root＃cp〜/ private-key.pem <SECURE-DIR> /private-key.pem.backup
- 証明書を生成します。新しい自己署名証明書を作成するため、-newおよび-x509パラメーターを含めます。オプションで-daysパラメーターを含めると、キーの有効期間をデフォルトの30日から変更することができます（10950日は約30年です）。テスト環境に適した値でプロンプトに応答してください。
root# openssl req -new -x509 -key ~/private-key.pem -out ~/self-cert.pem -days 10950
- 証明書ファイルおよび関連するキーファイルを、コミュニティ版NGINXまたはNGINX Plusサーバーの/etc/nginx/sslディレクトリにコピーまたは移動します。
証明書要求の生成
- opensslソフトウェアがインストールされているマシンに、rootユーザーとしてログインします。
- 証明書にパッケージ化する秘密鍵を作成します。
root# openssl genrsa -out ~/example.com.key 2048
- 安全な場所に、キーファイルのバックアップを作成します。鍵を失うと、証明書が使用できなくなります。
root# cp ~/example.com.key <SECURE-DIR>/example.com.key.backup
- 証明書署名要求（CSR）ファイルを作成します。
root# openssl req -new -sha256 -key ~/example.com.key -out ~/example.com.csr
- CSRファイル（example.com.csr）を渡して、CAまたは組織内のセキュリティ管理グループに証明書を要求します。注意点として、プライベートキー（.keyファイル）を第三者と直接共有しないようにしてください。
証明書はWindows互換のPFX形式ではなく、PEM形式である必要があります。CAウェブサイトから証明書を要求する場合は、証明書を生成するサーバープラットフォームを選択するように求められたら、NGINXまたはApache（使用可能な場合）を選択します。
- 証明書ファイルと関連するキーファイルを、NGINX Plusサーバーの/etc/nginx/sslディレクトリにコピーまたは移動します。
設定ファイルの作成と変更
このガイドではエラーを減らすため、ディレクティブはテキストエディタに直接入力するのではなく、NGINX,Inc.が提供するファイルからご自身の設定ファイルにコピーします。次に、このガイドの「HTTPとHTTPSトラフィックのための仮想サーバーの設定」（英語）から始まるセクションで、ご自身の環境に合わせたディレクティブの変更方法について学習していきます。
ここで紹介されているように、基本的なロードバランシング用（コミュニティ版NGINX、NGINX Plusで可能）に１つのファイル、拡張したロードバランシング用（NGINX Plusで可能）に1つファイルがあります。新しいLinuxシステムにコミュニティ版NGINXまたはNGINX Plusをインストールして設定し、Tomcatトラフィックの負荷分散にのみ使用する場合は、提供しているファイルをメインの設定ファイルとして使用できます。これは慣例的に、下記のように指定されています。
/etc/nginx/nginx .conf
ただし、単一の設定ファイルの代わりに、NGINX Plusパッケージをインストールするとき、自動的に設定される仕組みを使うことをお勧めします。これは既存のコミュニティ版NGINXまたはNGINX Plus環境がある場合や、それらを将来、他の目的に拡張して使う計画がある場合には、特に有効です。従来の方式では、メインの設定ファイルは引き続き/etc/nginx/nginx.confと呼ばれますが、その中にすべてのディレクティブを含めるのではなく、HTTP関連の機能ごとに別々の設定ファイルを作成し、/etc/nginx/conf.dディレクトリに置いてあります。次にメインファイルのhttpコンテキスト内のincludeディレクティブを使って、関数固有のファイルの内容を読み込みます。
基本的なロードバランシングのための完全な設定ファイルをダウンロードする方法
root# cd /etc/nginx/conf.d
root# curl https://www.nginx.com/resource/conf/tomcat-basic.conf > tomcat-basic.conf
拡張ロードバランシングのための完全な設定ファイルをダウンロードする方法
root# cd /etc/nginx/conf.d
root# curl https://www.nginx.com/resource/conf/tomcat-enhanced.conf > tomcat-enhanced.conf
（ブラウザで上記のURLにアクセスして、ファイルをダウンロードすることもできます）
従来の設定方法でセットアップするには、メインのnginx.confファイルに、もしまだ存在しなければhttp設定ブロックを追加します。（標準的な場所は、グローバルディレクティブの下です）このincludeディレクティブを適切なファイル名で追加してください。
http {
include conf.d/tomcat-(basic|enhanced).conf;
}
ワイルドカード表記で、適切なコンテキストブロック内の特定の機能またはトラフィックタイプに関連するすべてのファイルを参照することもできます。たとえば、すべてのHTTP設定ファイルであるFunction-http.confを挙げたいのであれば、以下が適切なincludeディレクティブです。
http {
include conf.d / * – http.conf ;
}
参考までに、このドキュメントには、設定ファイルの完全なテキストが公開されています。
ただし、このドキュメントから直接テキストをコピーすることはお勧めしません。テキストエディタと同じように、改行や空白などを配置してくれるとは限らないからです。エディターにコピーされたテキストでは、行が一緒に実行されたり、設定ブロック内の子ステートメントのインデントが欠落したり、不一致になることがあります。多くのコンパイラ同様、コミュニティ版NGINXでもNGINX Plusでも構文中の空白は無視し、セミコロンや中括弧のみを区切り文字として使っているため、フォーマットがないことは問題になりません。でも人間にとっては、空白がないと、設定を解釈して間違いなく修正することは難しくなります。
更新された設定のリロードについて
設定ファイルの構文の有効性をテストするため、設定更新のたびにnginx –tコマンドを実行することをお勧めします。
root# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
コミュニティ版NGINXまたはNGINX Plusに新しい設定を使わせるには、次のいずれかのコマンドを実行します。
root＃nginx -s reload
または
root＃service nginx reload
コミュニティ版NGINXまたはNGINX Plusで基本のロードバランシングを設定する
このセクションでは、2つのTomcatサーバーの前に、ロードバランサーとしてコミュニティ版NGINXまたはNGINX Plus を設定する方法を説明します。最初の2つのセクションの手順は必須です。
残りのセクションの手順は、アプリケーション要件に応じたオプションです。
完全な設定ファイル内容は、「基本的なロードバランシングの全設定」に掲載しています。
NGINX Plusを使用している場合は、基本的なロードバランシングの設定を完了した後に追加の拡張機能を設定できます。「NGINX Plusの拡張ロードバランシング設定」を参照してください。
HTTPおよびHTTPSトラフィック用の仮想サーバーの設定
これらのディレクティブは、HTTPおよびHTTPSトラフィック用の仮想サーバーを、最上位のhttp構成ブロック内の別々のserverブロックに定義します。すべてのHTTPリクエストはHTTPSサーバーにリダイレクトされます。
- ポート443で受信したhttps://example.comへのリクエストをlistenするserverブロックを構成します。
ssl_certificateとssl_certificate_keyディレクティブは必須です。「クライアントトラフィックのSSL / TLS証明書の設定」で選択した証明書と秘密鍵の名前を置き換えます。
他のディレクティブはオプションですが、推奨されています。
# In the ‘http’ block
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/nginx/ssl/example.com.crt;
ssl_certificate_key /etc/nginx/ssl/example.com.key;
ssl_session_cache shared:SSL:1m;
ssl_prefer_server_ciphers on;
}
ディレクティブのドキュメント：listen、server、server_name、ssl_certificateとssl_certificate_key、ssl_prefer_server_ciphers、ssl_session_cache
- 前の手順で定義したHTTPSサーバーに、http://example.comのポート80で受信したリクエストを永続的にリダイレクトするserverブロックを構成します。
クライアント接続にSSL / TLSを使用していない場合は、returnディレクティブを省略してください。このガイドの残りの部分で、serverブロックにHTTPSトラフィックのディレクティブを追加するよう指示された場合は、代わりにこのブロックにディレクティブを追加してください。
# In the ‘http’ block
server {
listen 80;
server_name example.com;
# Redirect all HTTP requests to HTTPS
location / {
return 301 https://$server_name$request_uri;
}
}
ディレクティブのドキュメント：location、return
SSL / TLSの設定情報は、「NGINX Plus管理者ガイド」（英語）および「HTTP SSL / TLSモジュール」（英語）のリファレンスドキュメントを参照してください。
基本的なロードバランシングの設定
ロードバランシングを設定するには、まずクライアントリクエストが送られるバックエンドサーバーをリストアップし、名前を付けたupstreamグループを作成します。その後、1つまたは複数のproxy_passディレクティブ内でupstreamグループを参照することで、コミュニティ版NGINXまたはNGINX Plusをリバースプロキシおよびロードバランサーとして設定します。
- Tomcatと呼ぶupstreamグループを設定し、2つのTomcatアプリケーションサーバーで構成します。ポート8080で、IPアドレスはそれぞれ、10.100.100.11および10.100.100.12とします。
# In the ‘http’ block
upstream tomcat {
server 10.100.100.11:8080;
server 10.100.100.12:8080;
}
ディレクティブのドキュメント：server、upstream
- HTTPおよびHTTPSトラフィック用の仮想サーバーの設定で作成したHTTPSトラフィックのserverブロックに、次の2つのlocationブロックを含めます。
- 最初のものは、パスが/ tomcat-app /で始まるHTTPSリクエストに一致し、前の手順で作成したtomcat upstreamグループにプロキシします。
- 2番目のものは、http://example.com/のすべてのリクエストを一時的にリダイレクトすることで、最初のlocationブロックにすべてのトラフィックを集めます。
# In the ‘server’ block for HTTPS traffic
location /tomcat-app/ {
proxy_pass http://tomcat;
}
location = / {
return 302 /tomcat-app/;
}
ディレクティブのドキュメント：location、proxy_pass、return
これらのブロックは、標準HTTPSトラフィックのみを処理することに注意してください。WebSocketトラフィックの負荷を分散する場合は、「WebSocketトラフィックのプロキシ設定」の説明に従って別のlocationブロックを追加する必要があります。
デフォルトでは、コミュニティ版NGINXとNGINX Plusはサーバー間の負荷分散にラウンドロビンアルゴリズムを使用します。ロードバランサーは、 upstream グループ内のサーバーのリストを順番に実行し、新しいリクエストを次のサーバーに転送します。この例では、最初のリクエストは10.100.100.11に、2番目のリクエストは10.100.100.12に、3番目は10.100.100.11へと続いていきます。その他の利用可能なロードバランシングアルゴリズムについては、「NGINX Plus管理者ガイド」を参照してください。
NGINX Plusでは、DNSまたはAPIを使用して、一連のバックエンドサーバーが変更されたときに、upstreamグループの動的な再構成を設定することもできます。「upstreamグループの動的な再構成を有効にする」を参照してください。
プロキシとロードバランシングの詳細については、「NGINX Plus管理者ガイド」の「リバースプロキシとHTTPロードバランサー」および「プロキシとupstreamモジュール」のマニュアルを参照してください。
基本的なセッション・パーシステンスの設定
アプリケーションで基本的なセッション・パーシステンス（スティッキーセッションとも呼ばれます）が必要な場合、IPハッシュ ロードバランシング アルゴリズムを使って、コミュニティ版NGINXで実装できます。（NGINX Plusは、高度なセッション・パーシステンスの設定で説明されているように、より洗練された形式のセッション・パーシステンスを提供します）。
IPハッシュアルゴリズムでは、各リクエストに対して、クライアントのIPアドレスに基づくハッシュが計算され、upstreamサーバーの1つに関連付けられます。同じハッシュを持つすべてのリクエストがそのサーバーに送信され、セッション・パーシステンスが確立されます。
クライアントにIPv6アドレスがある場合、ハッシュはアドレス全体に基づいています。IPv4アドレスがある場合、ハッシュはアドレスの最初の3オクテットだけに基づいています。これは、サブネットワーク（/ 24）の範囲から動的にIPアドレスが割り当てられたISPクライアントを最適化するように設計されています。ただし、次の場合は有効ではありません。
- サイトへのトラフィックの大部分が、1つのフォワードプロキシから、または同じ/ 24ネットワーク上のクライアントから送信されている場合。この場合、IPハッシュはすべてのクライアントを同じサーバーにマップするためです。
- クライアントのIPアドレスが、セッション中に変わりうる場合。例えば、モバイルクライアントがWiFiネットワークから携帯通信網に切り替えるときなどです。
NGINXでセッション・パーシステンスを構成するには、「基本的なロードバランシングの設定」で作成しip_hashディレクティブをupstreamブロックに追加します。
# In the ‘http’ block
upstream tomcat {
ip_hash;
server 10.100.100.11:8080;
server 10.100.100.12:8080;
}
ディレクティブのドキュメント： ip_hash
また、指定したテキストとNGINX変数の任意の組み合わせに基づいたハッシュを使って、セッション・パーシステンスにハッシュ ロードバランシング メソッドを使用することもできます。たとえば、次の設定でフル（4オクテット）のクライアントIPアドレスをハッシュできます。
# In the ‘http’ block
upstream tomcat {
hash $remote_addr;
server 10.100.100.11:8080;
server 10.100.100.12:8080;
}
ディレクティブのドキュメント： hash
WebSocketトラフィックのプロキシ設定
WebSocketプロトコル（RFC 6455で定義されています）は、クライアントとサーバー間で単一のTCP接続を介し、同時双方向通信を可能にします。両サイドから、互いに独立してデータを送ることができます。WebSocket接続を開始するために、クライアントはハンドシェイクをサーバーに送信し、リクエストを標準HTTPからWebSocketにアップグレードします。ハンドシェイクが正当性チェックを通り、サーバーがリクエストを受け入れると、接続が確立されます。WebSocket接続が作成されると、ブラウザクライアントはそのサーバーからデータを受信しながら、同時にデータを送信できます。
Tomcat 8は、デフォルトではWebSocketを有効にしていませんが、有効にする方法はTomcatのドキュメントに記載しています。コミュニティ版NGINXまたはNGINX Plus で、TomcatアプリケーションサーバーへのWebSocketトラフィックをプロキシする場合は、
このセクションで説明するディレクティブを追加します。
コミュニティ版NGINXとNGINX Plusは、デフォルトで、upstream接続にHTTP / 1.0を使用します。WebSocket接続が正しくプロキシされるためには、HTTPヘッダーを設定するその他の設定ディレクティブとともにHTTP / 1.1が必要です。
# In the ‘http’ block
map $http_upgrade $connection_upgrade {
default upgrade;
” close;
}
# In the ‘server’ block for HTTPS traffic
location /wstunnel/ {
proxy_pass http://tomcat;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
ディレクティブのドキュメント：location、map、proxy_http_version、proxy_pass、proxy_set_header
upgradeリクエストのheaderはホップバイホップ方式であるため、最初のproxy_set_headerディレクティブが必要です。つまり、HTTP仕様では、プロキシの転送を明示的に禁止しています。このディレクティブは、禁止を無効にします。
2番目のproxy_set_headerディレクティブは、mapブロック内のテストに依存する値にConnectionのheaderを設定します。リクエストにUpgradeのheaderがある場合、Connectionのheaderはupgradeに設定されます。それ以外の場合は、closeに設定されます。
WebSocketトラフィックのプロキシの詳細については、「WebSocketプロキシ」と「WebSocketプロキシとしてのNGINX」を参照してください。
コンテンツキャッシュの設定
適格な応答は、サーバー上で再生成されるのではなくキャッシュから即座に提供されるため、Tomcatアプリケーションサーバーからの応答をキャッシュすることで、クライアントへの応答時間が短縮されてサーバー負荷が軽減されます。キャッシングの動作を微調整するには、さまざまな便利なディレクティブが使えます。詳細については、「NGINXとNGINX Plusによるキャッシングガイド」を参照してください。
コミュニティ版NGINXまたはNGINX Plusで基本的なキャッシングを有効にするには、次の設定を追加します。
- proxy_cache_pathディレクティブを含めて、ローカルディスクディレクトリ/tmp/NGINX_cache/を作り、キャッシュとして使います。このkeys_zoneパラメーターは、バックキャッシュと呼ばれるゾーンに10 MBの共有メモリを割り当てます。このゾーンは、キャッシュキーと使用タイマなどのメタデータを格納するために使われます。1 MBのゾーンには、約8,000個のキーのデータを格納できます。
# In the ‘http’ block
proxy_cache_path /tmp/NGINX_cache/ keys_zone=backcache:10m;
ディレクティブのドキュメント： proxy_cache_path
- パスが/tomcat-app/で始まるHTTPSリクエストと一致するlocationブロックで、前の手順で作成したキャッシュを参照するproxy_cacheディレクティブを含めます。
# In the ‘server’ block for HTTPS traffic
location /tomcat-app/ {
proxy_pass http://tomcat;
proxy_cache backcache;
}
ディレクティブのドキュメント：location、proxy_cache、proxy_pass
デフォルトでは、キャッシュキーは、nginxの変数である以下の文字列に似ています。
$scheme$proxy_host$request_uriです。変数のリストを変更するには、proxy_cache_keyディレクティブで変数のリストを指定します。このディレクティブの効果的な使用法の1つは、JSESSIONID cookieに基づき、各ユーザーのキャッシュキーを作成することです。これは、キャッシュがプライベート（たとえば、ショッピングカートのデータやその他のユーザー固有のリソースを含む）の場合に便利です。次のディレクティブを使って、キャッシュキーにJSESSIONID cookieを含めます。
proxy_cache_key $ proxy_host $ request_uri $ cookie_jessionid ;
ディレクティブのドキュメント： proxy_cache_key
キャッシングの詳細については、「NGINX Plus管理者ガイド」およびプロキシモジュールのリファレンスドキュメントを参照してください。
HTTP / 2サポートの設定
HTTP / 2は、コミュニティ版NGINX1.9.5以降、NGINX Plus R7以降で完全にサポートされています。常に最新のバージョンのソフトウェアを実行して、改善とバグ修正を利用することをお勧めします。
- コミュニティ版NGINXを使用している場合は、バージョン1.9.5以降でSPDYモジュールがコードベースから完全に削除され、HTTP / 2モジュールに置き換えられていることに注意してください。バージョン1.9.5以降にアップグレードした後、SPDYを使用するようコミュニティ版NGINXを設定することはできません。SPDYを引き続き使用したい場合は、NGINX 1.8.xブランチのソースからコミュニティ版NGINXをコンパイルする必要があります。
- NGINX Plus R8以降では、デフォルトでHTTP / 2をサポートしています。（SPDYのサポートはそのリリース時点で廃止されました）。具体的には以下の通りです。
NGINX Plus R11以降、nginx-plusパッケージはデフォルトでHTTP / 2をサポートし
続けますが、以前のリリースで利用可能だったnginx-plus-extrasパッケージが動的
モジュールにより廃止されました。
NGINX Plus R8からR10を通じて、nginx-plusとnginx-plus-extrasパッケージは、
デフォルトでHTTP / 2をサポートしています。
NGINX Plus R7を使用する場合は、nginx-plusまたはnginx-plus-extrasパッケージの代わりに、nginx-plus-http2パッケージをインストールする必要があります。
HTTP / 2サポートを有効にするには、HTTPおよびHTTPSトラフィック用の仮想サーバーの設定で作成した、HTTPSトラフィック用serverブロック内のlistenディレクティブに、次のようにhttp2パラメーターを追加します。
# In the ‘server’ block for HTTPS traffic
listen 443 ssl http2;
ディレクティブのドキュメント： listen
HTTP / 2変換が機能していることを確認するには、Google ChromeとFirefox用の「HTTP / 2およびSPDYインジケータ」プラグインが使えます。
基本的なロードバランシングの全設定
参照用に、ここでは基本的なロードバランシングの全設定を掲載しておきます。これらはhttpコンテキスト中に入ります。完全なファイルは、NGINX、Inc.のWebサイトからダウンロードできます。
このドキュメントからテキストを直接コピーするのではなく、「設定ファイルの作成と変更」で説明されている方法を使って、既存の設定にこれらのディレクティブを含めることをお勧めします。/etc/nginx/conf.d/tomcat-basic.confのコンテキストで読むためには、メインのnginx.confファイルのhttpコンテキストにincludeディレクティブを追加してください。
proxy_cache_path /tmp/NGINX_cache/ keys_zone=backcache:10m;
map $http_upgrade $connection_upgrade {
default upgrade;
” close;
}
upstream tomcat {
# Use IP Hash for session persistence
ip_hash;
# List of Tomcat application servers
server 10.100.100.11:8080;
server 10.100.100.12:8080;
}
server {
listen 80;
server_name example.com;
# Redirect all HTTP requests to HTTPS
location / {
return 301 https://$server_name$request_uri;
}
}
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /etc/nginx/ssl/example.com.crt;
ssl_certificate_key /etc/nginx/ssl/example.com.key;
ssl_session_cache shared:SSL:1m;
ssl_prefer_server_ciphers on;
# Load balance requests for /tomcat-app/ across Tomcat application servers
location /tomcat-app/ {
proxy_pass http://tomcat;
proxy_cache backcache;
}
# Return a temporary redirect to the /tomcat-app/ directory
# when user requests ‘/’
location = / {
return 302 /tomcat-app/;
}
# WebSocket configuration
location /wstunnel/ {
proxy_pass https://tomcat;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
}
NGINX Plusの拡張ロードバランシングの設定
このセクションでは、NGINX Plusのいくつかの拡張機能を使って、拡張ロードバランシングを設定する方法について説明します。
注：このセクションで説明する拡張機能を設定する前には、以下の2つのセクションで説明している基本的なロードバランシングの手順を終えている必要があります。
- HTTPおよびHTTPSトラフィック用の仮想サーバーを設定する
- 基本的なロードバランシングの設定
特に明記されている場合を除き、すべてのオプションの基本機能（コミュニティ版NGINXおよびNGINX Plusの基本的なロードバランシング設定については他のサブセクションで説明しています）を、ここで説明する拡張機能と組み合わせることができます。
次のセクションで説明する機能はすべてオプションです。
- 高度なセッション・パーシステンスの設定
- アプリケーションのヘルスチェックの設定
- ライブ アクティビティ モニタリングの有効化
- upstreamグループのダイナミック・リコンフィギュレーションを有効化する
完全な設定ファイルは、拡張ロードバランシングの全設定で入手できます。
高度なセッション・パーシステンスの設定
NGINX Plusは、コミュニティ版NGINXよりも洗練されたセッション・パーシステンスの手段を提供しています。これは、3つのstickyディレクティブの変形で実装されています。次の例では、Tomcatアプリケーションで設定されたjvmRoute属性にセッション・パーシステンスを設定するために、基本的なロードバランシング設定で作成したupstreamグループにsticky routeディレクティブを追加します。
- ip_hashディレクティブを削除またはコメントアウトし、serverディレクティブのみを残します。
# In the ‘http’ block
upstream tomcat {
#ip_hash;
server 10.100.100.11:8080;
server 10.100.100.12:8080;
}
ディレクティブのドキュメント：server、 upstream
- バックエンドのTomcatサーバーの設定ファイルに次の行を追加して、jvmRoute属性に基づく識別子（ここでは、aまたはbに設定）をJSESSIONID cookie 値の最後に追加します。
# on host 10.100.100.11
<Engine name=”Catalina” defaultHoast=”www.example.com” jvmRoute=”a”>
# on host 10.100.100.12
<Engine name=”Catalina” defaultHoast=”www.example.com” jvmRoute=”b”>
- NGINX Plusを設定して、upstreamサーバーを選択します。各リクエストのJSESSIONID cookieとURLを確認し、jvmRoute値を抽出します。
in the ‘http’ block
map $cookie_jsessionid $route_cookie {
~.+\.(?Pw+)$ $route;
}
map $request_uri $route_uri {
~jsessionid=.+\.(?Pw+)$ $route_uri;
}
upstream tomcat {
server 10.100.100.11:8080 route=a;
server 10.100.100.12:8080 route=b;
sticky route $route_cookie $route_uri;
}
ディレクティブのドキュメント：map、server、sticky routeupstream
- 最初のmapディレクティブは、JSESSIONID cookieの最後の要素（期間に続く）を抽出し、$route_cookie変数に記録します。
- 2番目のmapディレクティブは、リクエストURLで続くjsessionid=要素から最後の要素（期間に続く）を抽出し、$route_uri変数に記録します。
- sticky routeディレクティブは、NGINX Plusに、パラメーターーのリストで最初に見つかった空でない変数の値を使うように指示します。ここには、mapディレクティブが設定した2つの変数があります。言い換えれば、JESSIONID cookieの最後の要素が存在する場合はそれを使い、そうでない場合はjessionid=URL要素の最後の要素を使います。
serverディレクティブのrouteパラメーターは、値がaの場合はリクエストが10.100.100.11に送信され、値がbの場合はリクエストが10.100.100.12に
送信されることを意味します。
sticky learnディレクティブは、セッション・パーシステンスの別のオプションです。この場合、セッション識別子は、Tomcatアプリケーションによって作成されたJSESSIONID cookieです。
- 上記の手順1のように、upstreamブロック内のip_hashディレクティブを削除またはコメントアウトします。
- upstreamブロックにsticky learnディレクティブを含めます。
# In the ‘http’ block
upstream tomcat {
server 10.100.100.11:8080;
server 10.100.100.12:8080;
sticky learn create=$upstream_cookie_JSESSIONID
lookup=$cookie_JSESSIONID
zone=client_sessions:1m;
}
ディレクティブのドキュメント：map、server、sticky learnupstream
- createおよびlookupパラメーターーは、どのように新しいセッションが作られ、それに伴ってどのように既存のセッションが検索されるかを指定します。新しいセッションの場合、NGINX Plusはセッション識別子を$upstream_cookie_JSESSIONID変数の値に設定します。これは、Tomcatアプリケーションサーバーが送信するJSESSIONID cookie を取得します。既存のセッションをチェックするときは、セッション識別子としてクライアントが送信したJSESSIONID cookie（$cookie_JSESSIONID 変数）を使用します。
両方のパラメーターを、複数回指定することができます（異なる変数を使用する毎）。その場合、NGINX Plusはそれぞれの空でない最初の変数を使用します。
- このzone引数は、セッションに関する情報を格納する共有メモリゾーンを作成します。割り当てられるメモリの量（ここでは1 MB）は、一度に格納できるセッションの数を決定します（数はプラットフォームによって異なります）。ゾーンに割り当てられた名前（ここではclient_sessions）は、 各stickyディレクティブごとに一意でなければなりません。
セッション・パーシステンスの詳細については、「NGINX Plus管理者ガイド」を参照してください。
アプリケーションヘルスチェックの設定
ヘルスチェックは、決まった間隔でサーバーに送信される帯域外 HTTPリクエストです。これらは、クライアントから実際のリクエストはせずに、サーバーが応答して正しく機能するかどうかを判断するために使用されます。
locationブロック内にhealth_checkディレクティブを置くことで、アプリケーションごとに異なるヘルスチェックを有効にできます。
- パスが（基本的なロードバランシング設定で作成された）/tomcat-app/で始まるHTTPSリクエストに一致するlocationブロックで、health_checkディレクティブを追加します。
ここではNGINX Plusを設定して、Tomcat upstreamグループの各サーバーに対し、デフォルトの5秒間隔よりも短い2秒ごとに、最上位URI /（スラッシュ）の帯域外リクエストを送信するようにします。サーバーが正しく応答しない場合はマークダウンされ、5つの連続したヘルスチェックが渡されるまで、NGINX Plusはリクエストの送信を停止します。デフォルト以外のヘルスチェックテスト一式を定義するため、matchパラメーターが含まれています。
# In the ‘server’ block for HTTPS traffic
location /tomcat-app/ {
proxy_pass http://tomcat;
proxy_cache backcache;
health_check interval=2s fails=1 passes=5 uri=/ match=tomcat_check;
}
ディレクティブのドキュメント：health_check、location、proxy_cache、proxy_pass
- このhttpコンテキストではmatchディレクティブを含め、サーバーが機能しているとみなされるために渡さなければならないテストを定義しています。この例では、ステータスコード200を返す必要があり、Content-Typeレスポンスのheaderはtext/htmlでなければなりません。レスポンスのbodyは指定された正規表現と一致する必要があります。
# In the ‘http’ block
match health_check {
status 200;
header Content-Type = text/html;
body ~ “Apache Tomcat/8″;
}
ディレクティブのドキュメント： match
- Tomcatのupstreamグループにzoneディレクティブを含め、グループの構成およびワーカープロセス間で共有されているランタイム状態を格納する、共有メモリ領域を定義します。
# In the ‘http’ block
upstream tomcat {
zone tomcat 64k;
server 10.100.100.11:8080;
server 10.100.100.12:8080;
# …
}
ディレクティブのドキュメント：server、upstream、zone
NGINX Plusにはスロースタート機能もあり、ヘルスチェックの補助機能として役立ちます。障害が発生したサーバーが回復するか、または新しいサーバーがupstreamグループに追加されると、NGINX Plusは定義された時間をかけて、徐々にそれらのサーバーへのトラフィックを増やしていきます。これにより、起動時に処理でき、これ以上の接続に圧倒されないよう、サーバーに「ウォームアップ」時間を与えることができます。詳細については、「NGINX Plus管理者ガイド」を参照してください。
たとえば、Tomcatアプリケーションサーバーのスロースタート時間を30秒に設定するには、そのserverディレクティブにslow_startパラメーターを含めます。
# In the ‘upstream’ block
#…
server 10.100.100.11:8080 slow_start=30s;
server 10.100.100.12:8080 slow_start=30s;
ヘルスチェックのカスタマイズについては、「NGINX Plus管理者ガイド」を参照してください。
ライブアクティビティ モニタリングの有効化
NGINX Plusには、R6以降のTCPメトリックを含む、主要な負荷およびパフォーマンスメトリックをリアルタイムで提供するライブアクティビティ モニタリング インターフェースが含まれています。統計は、RESTfulなJSONインターフェースで報告されるので、カスタムまたはサードパーティーの監視ツールにも、簡単にデータを送信できます。また、ビルトインのダッシュボードもあります。以下の手順に従って展開します。
ライブアクティビティのモニタリング詳細については、「NGINX Plus管理者ガイド」を参照してください。
モジュールと組み込みダッシュボードを設定する最も簡単な方法は、サンプル設定ファイルをNGINX,Inc.のWebサイトからダウンロードし、必要に応じて変更することです。詳細な手順については、「NGINX Plusのライブアクティビティモニタリング 簡単3ステップ」を参照してください。
- status.confファイルをNGINX Plusサーバーにダウンロードします。
＃cd /etc/nginx/conf.d
＃curl https://www.nginx.com/resource/conf/status.conf> status.conf
- メインのnginx.confファイル内、トップレベルのhttpコンフィギュレーションブロックで、status.confを読みこみます。
# In the ‘http’ block
include conf.d/status.conf
ディレクティブのドキュメント： include
従来のコンフィギュレーション手法を使い、既存のincludeディレクティブが設定ファイルの作成と変更で取り上げたワイルドカード表記を使用している場合、2通りのやり方があります。上記のように、status.conf用に別のincludeディレクティブを加えることもできますし、または、status.confの名前を変更し、httpブロック内の既存のincludeディレクティブ内のワイルドカードでキャプチャさせることもできます。例えば、それをstatus-http.confに変更すると、includeディレクティブによって*-http.confとして捉えられます。
- status.confのコメントは、自分の環境向けにカスタマイズする必要のあるディレクティブを説明しています。特に、サンプル設定ファイルのデフォルト設定では、ネットワーク上の誰もがダッシュボードにアクセスできるようになっています。ダッシュボードへのアクセスを制限するには、次のいずれかの方法を使用することを強くお勧めします。
- IPアドレスベースのアクセス制御リスト（ACL）サンプル設定ファイルで、allowおよびdenyディレクティブのコメントアウトし、管理ネットワークのアドレスを10.0.0.0/8に置き換えます。指定したネットワーク上のユーザーのみがステータスページにアクセスできます。
allow 10.0.0.0/8;
deny all;
- HTTP 基本認証（RFC 7617で定義されています） サンプル設定ファイルで、auth_basicおよびauth_basic_user_file ディレクティブのコメントアウトし、/etc/nginx/usersファイルに（たとえばhtpasswdジェネレータを使って）ユーザーエントリを追加してください。Apacheをインストールしている場合は、既存のhtpasswdファイルを再利用することもできます。
auth_basic on ;
auth_basic_user_file / etc / nginx / users ;
ディレクティブのドキュメント：auth_basic、auth_basic_user_file
- SSL / TLSの完全な設定の一部であるクライアント証明書 詳細については、「NGINX Plus管理者ガイド」およびHTTP SSL / TLSモジュールのドキュメントを参照してください。
- ファイアウォール ファイアウォールを設定して、ダッシュボードのポートへの外部アクセスを禁止します（サンプル設定ファイルでは8080）。
- 監視したい各upstreamグループに、zoneディレクティブを含めます。ワーカープロセス間で共有されるグループの構成と実行時の状態を格納する共有メモリゾーンを定義します。
たとえば、Tomcatアプリケーションサーバーを監視するには、Tomcat upstreamグループにzoneディレクティブを追加します（アプリケーションヘルスチェックの設定の手順を終えている場合は、既にこの変更を行っています）。
# In the ‘http’ block
upstream tomcat {
zone tomcat 64k;
server 10.100.100.11:8080;
server 10.100.100.12:8080;
#…
}
ディレクティブのドキュメント：server、upstream、zone
- HTTPSトラフィックのserverブロック（HTTPおよびHTTPSトラフィック用の仮想サーバーの設定で作成）で、以下のstatus_zoneディレクティブを追加します。
# In the ‘server’ block for HTTPS traffic
status_zone tomcat;
ディレクティブのドキュメント： status_zone
たとえばnginx -s reloadコマンドを実行するなどしてNGINX Plus設定ファイルをリロードすると、NGINX Plusダッシュボードはhttp：// nginx-plus-server-address：8080ですぐに利用できるようになります。
upstreamグループのダイナミック・リコンフィギュレーションを有効化する
NGINX Plusでは、ドメインネームシステム（以下DNSと表記）またはR13で導入されたNGINX Plus APIのいずれかを使って、負荷分散されたサーバーグループ（HTTPとTCP / UDPの両方）を動的に再構成できます。DNSおよびAPIメソッドの詳細については、「NGINX Plus管理者ガイド」を参照してください。
APIメソッドの設定
Tomcatアプリケーションサーバーのupstreamグループをダイナミック・リコンフィグレーションできるようにするには、NGINX Plus APIにセキュリティ保護されたアクセスを許可する必要があります。APIを使ってサーバーを追加・削除したり、動的にその重みを変えたり、ステータスをprimary、backupまたはdownに設定することができます。
- Tomcat upstreamグループにzoneディレクティブを含めて、グループの構成と実行時の状態を格納する共有メモリゾーンを作成します。これにより、すべてのワーカープロセスが情報を利用できるようになります。（アプリケーションヘルスチェックまたはライブアクティビティのモニタリングを設定した場合は、既にこの変更が行われています）。
# In the ‘http’ block
upstream tomcat {
zone tomcat 64k;
server 192.168.33.11:8080;
server 192.168.33.12:8080;
# …
}
ディレクティブのドキュメント：server、upstream、zone
- HTTPSトラフィックのserverブロック（HTTPおよびHTTPSトラフィック用の仮想サーバーの設定で作成）で、NGINX Plus API用の新しいlocationブロックを追加します。これにより、動的な再構成に必要な機能が利用できるようになります。ここにはapiディレクティブが含まれています（apiは、ここで使用されているように、locationブロックの本来の名前でもあります）。
（status.confファイルをダウンロードしてライブアクティビティのモニタリングを設定している場合は、すでにこのブロックが含まれています。）
許可された管理者だけがNGINX Plus APIにアクセスできるように、この場所へのアクセスを制限することを強くお勧めします。次の例のallowおよび denyディレクティブは、ローカルホストアドレス（127.0.0.1）からのアクセスのみを許可しています。
# In the ‘server’ block for HTTPS traffic
location /api {
api write=on;
allow 127.0.0.1;
deny all;
}
ディレクティブのドキュメント：allowおよびdeny、api
DNSメソッドの設定
httpブロックに、DNSサーバーを指す追加resolverディレクティブを追加します。tomcat upstreamブロックで、resolveパラメーターをserverディレクティブに追加し、NGINX PlusがDNSに対し、ドメイン名（ここでは、example.com ）を定期的に再解決するよう指示します。
また、 upstreamグループの構成と実行時の状態を格納するための共有メモリゾーンを作成し、すべてのワーカープロセスで情報を利用できるようにするには、upstreamブロックにzoneディレクティブを含めます。（アプリケーションヘルスチェックまたはライブアクティビティのモニタリングを設定した場合は、既にこの変更が行われています）。
# In the ‘http’ block
resolver <IP-address-of-DNS-server>;
upstream tomcat {
zone tomcat 64k;
server example.com resolve;
}
ディレクティブおよびパラメーターのドキュメント：resolve、resolver、zone
NGINX Plus R9以降では、ポート番号など、SRV,DNS レコードの追加情報も使用できます。Serverディレクティブにresolveパラメーターと一緒に、serviceパラメーターを次のように含めます。
# In the ‘http’ block
resolver <IP-address-of-DNS-server>;
upstream tomcat {
zone tomcat 64k;
server example.com service=http resolve;
}
パラメーターのドキュメント： service
拡張ロードバランシングの全設定
参照用に、ロードバランシングを強化するための全設定を掲載しておきます。それはhttpコンテキストの中に入ります。完全なファイルは、NGINX,Inc.のWebサイトからダウンロードできます。
このドキュメントから直接テキストをコピーするのではなく、設定ファイルの作成と変更で説明されている方法を使用して、ご自身の設定にこれらのディレクティブを含めることをお勧めします。つまり、メインのnginx.confファイルのhttpコンテキストにincludeディレクティブを追加し、/etc/nginx/conf.d/tomcat-enhanced.confのコンテンツを読みこませます。
proxy_cache_path /tmp/NGINX_cache/ keys_zone=backcache:10m;
# WebSocket configuration
map $http_upgrade $connection_upgrade {
default upgrade;
” close;
}
# Extract the data after the final period (.) in the
# JSESSIONID cookie and store it in the $route_cookie variable.
map $cookie_jsessionid $route_cookie {
~.+\.(?P<route>w+)$ $route;
}
# Search the URL for a trailing jsessionid parameter, extract the
# data after the final period (.), and store it in
# the $route_uri variable.
map $request_uri $route_uri {
jsessionid=.+\.(?P<route>w+)$ $route;
}
# Application health checks
match tomcat_check {
status 200;
header Content-Type = text/html;
body ~ “Apache Tomcat/8″;
}
upstream tomcat {
# Shared memory zone for application health checks, live activity
# monitoring, and dynamic reconfiguration
zone tomcat 64k;
# List of Tomcat application servers
server 10.100.100.11:8080 slow_start=30s;
server 10.100.100.12:8080 slow_start=30s;
# Session persistence based on the jvmRoute value in
# the JSESSION ID cookie
sticky route $route_cookie $route_uri;
# Uncomment the following directive (and comment the preceding
# ‘sticky route’ and JSESSIONID ‘map’ directives) for session
# persistence based on the JSESSIONID
#sticky learn create=$upstream_cookie_JSESSIONID
# lookup=$cookie_JSESSIONID
# zone=client_sessions:1m;
}
server {
listen 80;
server_name example.com;
# Redirect all HTTP requests to HTTPS
location / {
return 301 https://$server_name$request_uri;
}
}
server {
listen 443 ssl http2;
server_name example.com;
# Required for live activity monitoring of HTTPS traffic
status_zone tomcat;
ssl_certificate /etc/nginx/ssl/example.com.crt;
ssl_certificate_key /etc/nginx/ssl/example.com.key;
ssl_session_cache shared:SSL:1m;
ssl_prefer_server_ciphers on;
# Load balance requests to /tomcat-app/ among Tomcat Server application servers
location /tomcat-app/ {
proxy_pass http://tomcat;
proxy_cache backcache;
# Active health checks
health_check interval=2s fails=1 passes=5 uri=/ match=tomcat_check;
}
# Return a 302 redirect to the /tomcat-app/ directory when user requests ‘/’
location = / {
return 302 /tomcat-app/;
}
# WebSocket configuration
location /wstunnel/ {
proxy_pass http://tomcat;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
# Secured access to the NGINX Plus API
location /api {
api write=on;
allow 127.0.0.1; # permit access from localhost
deny all; # deny access from everywhere else
}
}
リソース
改訂履歴
- バージョン4（2018年2月） – NGINX Plus API（NGINX Plus R14）のアップデート
- バージョン3（2017年4
- 月） – HTTP / 2サポートと動的モジュールに関するアップデート（NGINX Plus R11、コミュニティ版NGINX 1.11.5）
- バージョン2（2016年1月） – HTTP / 2サポートのアップデート（NGINX Plus R8、コミュニティ版NGINX1.9.9）
- バージョン1（2016年1月） – イニシャル・バージョン（NGINX Plus R7、コミュニティ版NGINX1.9.5）