コミュニティ版NGINXおよびNGINX Plusを使用したWildflyおよびJBossアプリケーションサーバのロードバランシング

この記事はNGINX,Inc.のデベロップメントガイド「Load Balancing JBoss and Wildfly Application Servers with NGINX OSS and NGINX Plus」を和訳した内容となります。

URL：https://docs.nginx.com/nginx/deployment-guides/jboss-load-balancing-nginx-plus/

このデプロイメントガイドでは、コミュニティ版NGINXとNGINX Plusを使い、Wildfly（JBoss）アプリケーションサーバー群でHTTPトラフィックとHTTPSトラフィックのロードバランシングを行う方法について説明します。必要に応じて、コミュニティ版NGINXまたはNGINX Plusを設定するための完全な手順を紹介します。

NGINXとNGINX Plusについて
WildflyとJBossについて
前提条件とシステム要件
クライアントトラフィックの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は、完全なアプリケーション配信プラットフォームであり、JBossアプリケーションサーバーの導入を強化し、大規模なWebアプリケーションを構築するために不可欠なエンタープライズ対応の機能群を備え、コミュニティ版NGINXの機能を拡張しています。

フル機能のHTTP、TCP、およびUDPロードバランシング（英語）
インテリジェントなセッション・パーシステンス（英語）
高性能リバースプロキシ（英語）
動的コンテンツと静的コンテンツのキャッシングとオフロード（英語）
任意のデバイスに音声や動画を配信する適応型ストリーミング（英語）
アプリケーション認識のヘルスチェックと高可用性（英語）
ダッシュボードまたはAPIを介した高度なアクティビティモニタリングの利用（英語）
DevOpsにやさしいツールによる管理とリアルタイム設定変更（英語）

WildflyとJBossについて

Wildflyは、2013年まではJBoss アプリケーションサーバーまたは単にJBossと呼ばれていたアプリケーションサーバーです。エンタープライズJavaアプリケーション、ポータル、Webアプリケーションおよびサービスの開発およびデプロイ用にJava Enterprise Edition 7 Platform（以前はJ2EEと呼ばれていたJava EE）を実装しています。Java EEは標準化されたモジュラーコンポーネントの使用を可能にし、Javaプラットフォームでプログラミングの多くの側面を自動的に処理できるようにします。Freeおよびオープンソースソフトウェアとして、WildflyはGNU Lesser General Public License（LGPL）バージョン2.1に基づいて配布されています。このガイドはWildfly 9で開発およびテストされました。

Wildflyソフトウェアの商用サポート版はRed Hat JBossエンタープライズアプリケーションプラットフォームであり、このガイドはそれと、その他の商用JBoss アプリケーションサーバーにも適用できます。

前提条件とシステム要件

物理システムまたは仮想システムにインストール、設定されたWildflyまたはJBossアプリケーションサーバー。
コミュニティ版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アドレスは192.168.33.11と192.168.33.12です。これらのアドレスを、ご自分のWildflyサーバーのIPアドレスに置き換えてください。サーバー数が2台で無い場合は、各サーバーを構成ブロックに記載してください。
読みやすくするために、複数行で表示されているコマンドがあります。ターミナルウィンドウにコピーして貼り付ける場合は、最初にテキストエディタにコピーして、ご自分の構成に合わせたオブジェクト名に置き換え、ブラウザが挿入する余計な書式設定文字を削除することをお勧めします。
このガイドの設定スニペットのテキストを設定ファイルにコピーすることはお勧めしません。設定ファイルを作成する推奨方法については、「設定ファイルの作成と変更」参照してください。

クライアントトラフィックのSSL / TLS証明書の設定

もし、コミュニティ版NGINXまたはNGINX PlusとWildflyアプリケーションのクライアント間で、トラフィックの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番目のオプションの手順を、順を追って掲載しています。

既に（Apache HTTPサーバーを実行しているシステムを含む）他のUNIXまたはLinuxシステム上にインストールされた、コミュニティ版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 2048
Generating RSA private key  
Enter pass phrase for private-key.pem:

3．安全な場所に、キーファイルのバックアップを作成します。鍵を失った場合、証明書は使用できなくなります。

root# cp ~/private-key.pem <SECURE-DIR>/private-key.pem.backup

4.証明書を生成します。新しい自己署名証明書を作成するため、-newおよび-x509パラメータを含めます。オプションで-daysパラメータを含めると、キーの有効期間をデフォルトの30日から変更することができます（10950日は約30年です）。テスト環境に適した値でプロンプトに入力してください。

root# openssl req -new -x509 -key ~/private-key.pem -out ~/self-cert.pem -days 10950

5.証明書ファイルおよび関連するキーファイルを、コミュニティ版NGINXまたはNGINX Plusサーバーの/etc/nginx/sslディレクトリにコピーまたは移動します。

証明書要求の生成

opensslソフトウェアがインストールされているマシンに、rootユーザーとしてログインします。
証明書にパッケージ化する秘密鍵を作成します。

root# openssl genrsa -out ~/example.com.key 2048

3.安全な場所に、キーファイルのバックアップを作成します。鍵を失うと、証明書が使用できなくなります。

root# cp ~/example.com.key <SECURE-DIR>/example.com.key.backup

4.証明書署名要求（CSR）ファイルを作成します。

root# openssl req -new -sha256 -key ~/example.com.key -out ~/example.com.csr

5.CSRファイル（example.com.csr）を渡して、CAまたは組織内のセキュリティ管理グループに証明書を要求します。注意点として、プライベートキー（.keyファイル）を第三者と直接共有しないようにしてください。

証明書はWindows互換のPFX形式ではなく、PEM形式である必要があります。CAウェブサイトから証明書を要求する場合は、証明書を生成するサーバープラットフォームを選択するように求められたら、NGINXまたはApache（使用可能な場合）を選択します。

6.証明書ファイルと関連するキーファイルを、NGINX Plusサーバーの/etc/nginx/sslディレクトリにコピーまたは移動します。

設定ファイルの作成と変更

このガイドではエラーを減らすため、ディレクティブはテキストエディタに直接入力するのではなく、NGINX,Inc.が提供するファイルからご自身の設定ファイルにコピーします。次に、このガイドの「HTTPとHTTPSトラフィックのための仮想サーバーの設定」から始まるセクションから、ご自身の環境に合わせたディレクティブの変更方法について学習していきます。

ここで紹介されているように、基本的なロードバランシング用（コミュニティ版NGINX、NGINX Plusで可能）に１つのファイル、拡張したロードバランシング用（NGINX Plusで可能）に1つファイルがあります。新しいLinuxシステムにコミュニティ版NGINXまたはNGINX Plusをインストールして設定し、Wildflyトラフィックの負荷分散にのみ使用する場合は、提供しているファイルをメインの設定ファイルとして使用できます。これは、下記のように指定されています。

/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/jboss-basic.conf> jboss-basic.conf

拡張ロードバランシングのための完全な設定ファイルをダウンロードする方法

root＃cd /etc/nginx/conf.d
root＃curl https://www.nginx.com/resource/conf/jboss-enhanced.conf> jboss-enhanced.conf

（ブラウザで上記のURLにアクセスして、ファイルをダウンロードすることもできます）

従来の設定方法でセットアップするには、メインのnginx.confファイルに、もしまだ存在しなければhttpブロックを追加します。（標準的な場所は、グローバルディレクティブの下です）このincludeディレクティブを適切なファイル名で追加してください。

http {
    include conf.d/jboss-(basic|enhanced).conf;
}

ディレクティブのドキュメント： include

ワイルドカード表記で、適切なコンテキストブロック内の特定の機能またはトラフィックタイプに関連するすべてのファイルを参照することもできます。たとえば、すべての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つのWildflyサーバーの前に、ロードバランサーとしてコミュニティ版NGINXまたはNGINX Plus を設定する方法を説明します。最初の2つのセクションの手順は必須です。

HTTPおよびHTTPSトラフィック用の仮想サーバーの設定
基本的なロードバランシングの設定

残りのセクションの手順は、アプリケーション要件に応じたオプションです。

基本的なセッション・パーシステンスの設定
WebSocketトラフィックのプロキシ設定
コンテンツキャッシュの設定
HTTP / 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

2.前の手順で定義した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をリバースプロキシおよびロードバランサーとして設定します。

jbossと呼ぶupstreamグループを設定し、2つのWildflyアプリケーションサーバーで構成します。ポート8080で、IPアドレスはそれぞれ、10.100.100.11および10.100.100.12とします。

# In the 'http' block
upstream jboss {
    server 192.168.33.11:8080;
    server 192.168.33.12:8080;
}

ディレクティブのドキュメント：server、upstream

2.HTTPおよびHTTPSトラフィック用の仮想サーバーの設定で作成したHTTPSトラフィックのserverブロックに、次の2つのlocationブロックを含めます。

- 最初のものは、パスが/webapp/で始まるHTTPSリクエストに一致し、前の手順で作成したjboss upstreamグループにプロキシします。
- 2番目のものは、http://example.com/のすべてのリクエストを一時的にリダイレクトすることで、最初のlocationブロックにすべてのトラフィックを集めます。

# In the 'server' block for HTTPS traffic
location /webapp/ {
    proxy_pass http://jboss;
}
location = / {
    return 302 /webapp/;
}

ディレクティブのドキュメント：location、proxy_pass、return

WebSocketトラフィックの負荷を分散する場合は、「WebSocketトラフィックのプロキシ設定」の説明に従って、別のlocationブロックを追加する必要があります。

デフォルトでは、コミュニティ版NGINXとNGINX Plusはサーバー間の負荷分散にラウンドロビンアルゴリズムを使用します。ロードバランサーは、 upstream グループ内のサーバーのリストを順番に実行し、新しいリクエストを次のサーバーに転送します。この例では、最初のリクエストは192.168.33.11に、2番目のリクエストは192.168.33.12に、3番目は192.168.33.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 jboss {
    ip_hash;
    server 192.168.33.11:8080;
    server 192.168.33.12:8080;
}

ディレクティブのドキュメント： ip_hash

また、指定したテキストとNGINX変数の任意の組み合わせに基づいたハッシュを使って、セッション・パーシステンスにハッシュロードバランシングメソッドを使用することもできます。たとえば、次の設定でフル（4オクテット）のクライアントIPアドレスをハッシュできます。

# In the 'http' block
upstream jboss {
    hash $remote_addr;
    server 192.168.33.11:8080;
    server 192.168.33.12:8080;
}

ディレクティブのドキュメント： hash

WebSocketトラフィックのプロキシ設定

WebSocketプロトコル（RFC 6455で定義されています）は、クライアントとサーバー間で単一のTCP接続を介し、同時双方向通信を可能にします。両サイドから、互いに独立してデータを送ることができます。WebSocket接続を開始するために、クライアントはハンドシェイクをサーバーに送信し、リクエストを標準HTTPからWebSocketにアップグレードします。ハンドシェイクが正当性チェックを通り、サーバーがリクエストを受け入れると、接続が確立されます。WebSocket接続が作成されると、ブラウザクライアントはそのサーバーからデータを受信しながら、同時にデータを送信できます。

WebSocketプロトコルは、Wildflyアプリケーションサーバー上でそのまま使用できるため、Wildflyの追加設定は必要ありません。コミュニティ版NGINXまたはNGINX PlusでWildflyアプリケーションサーバーへの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://jboss;
    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リクエストヘッダーはホップバイホップ方式であるため、最初のproxy_set_headerディレクティブが必要です。つまり、HTTP仕様では、プロキシの転送を明示的に禁止しています。このディレクティブは、禁止を無効にします。

2番目のproxy_set_headerディレクティブは、mapブロック内のテストに依存する値にConnectionヘッダーを設定します。リクエストにUpgradeヘッダーがある場合、Connectionヘッダーはupgradeに設定されます。それ以外の場合は、closeに設定されます。

WebSocketトラフィックのプロキシの詳細については、「WebSocketプロキシ」と「WebSocketプロキシとしてのNGINX」を参照してください。

コンテンツキャッシュの設定

適格な応答はサーバー上で再生成されるのではなく、キャッシュから即座に提供されるため、Wildflyアプリケーションサーバーからの応答をキャッシュすることで、クライアントへの応答時間が短縮されてサーバー負荷が軽減されます。キャッシングの動作を微調整するには、さまざまな便利なディレクティブが使えます。詳細については、「NGINXとNGINX Plusによるキャッシングガイド」を参照してください。

キャッシュの選択肢の1つは、Red Hatによって開発されたオープンソースの分散キャッシュとKey-Value NoSQLデータストアであるInfinispanです。（WildflyやJBossを含む）Javaアプリケーションサーバーはライブラリとして組み込んだり、サービスとして使用することができ、Java以外のアプリケーションであればTCP / IPを介してリモートサービスとして使用できます。

もう1つの選択肢は、以下の設定をすることで、コミュニティ版NGINXホストにサーバーレスポンスをキャッシュすることです。

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

パスが/webapp /で始まるHTTPSリクエストと一致するlocationブロックで、前の手順

　　で作成したキャッシュを参照するproxy_cacheディレクティブを含めます。

# In the 'server' block for HTTPS traffic
location /webapp/ {
    proxy_pass http://jboss;
    proxy_cache backcache;
}

ディレクティブのドキュメント：proxy_cache, proxy_pass

キャッシングの詳細については、「NGINX Plus管理者ガイド」およびHTTP プロキシモジュールのリファレンスドキュメントを参照してください。

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 jboss {  
    # Use IP Hash for session persistence  
    ip_hash;
    # List of Wildfly application servers  
    server 192.168.33.11:8080;  
    server 192.168.33.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/<certificate-name>;  
    ssl_certificate_key /etc/nginx/ssl/<private-key>;
    ssl_session_cache   shared:SSL:1m;  
    ssl_prefer_server_ciphers on;
    # Load balance requests for /webapp/ across Wildfly application servers  
    location /webapp/ {  
        proxy_pass http://jboss;  
        proxy_cache backcache;  
    }
    # Return a temporary redirect to the /webapp/ directory when user requests '/'  
    location = / {  
        return 302 /webapp/;  
    }
    # WebSocket configuration  
    location /wstunnel/ { 
        proxy_pass https://jboss;  
        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ディレクティブの変形で実装されています。次の例では、基本的なロードバランシング設定で作成したupstreamグループにsticky　learnディレクティブを追加します。

ip_hashディレクティブを削除またはコメントアウトし、serverディレクティブのみを残します。

# In the 'http' block
upstream jboss {
    #ip_hash;
    server 192.168.33.11:8080;
    server 192.168.33.12:8080;
}

ディレクティブのドキュメント：server、upstream

2.sticky learnディレクティブを使用してセッション・パーシステンスを設定すると、Wildflyアプリケーションがセッション識別子として作成するJSESSIONIDクッキーを参照できます。

# In the 'http' block
upstream jboss {
    server 192.168.33.11:8080;
    server 192.168.33.12:8080;
    sticky learn create=$upstream_cookie_JSESSIONID lookup=$cookie_JSESSIONID
                 zone=client_sessions:1m;
}
ディレクティブのドキュメント：server、sticky learn、upstream

- createおよびlookupパラメータは、どのように新しいセッションが作られ、それに伴い、どのように既存のセッションが検索されるかを指定します。新しいセッションの場合、NGINX Plusはセッション識別子を$upstream_cookie_JSESSIONID変数の値に設定します。この識別子は、Wildflyアプリケーションサーバーから送信されたJSESSIONID　cookie を取得します。既存のセッションをチェックするとき、セッション識別子としてクライアントが送信したJSESSIONID cookie （$cookie_JSESSIONID変数）を使用します。

両方のパラメータを複数回指定することができます（それぞれ異なる変数を使用するたびに）、NGINX Plusは最初に空でない変数を使用します。

- このzone引数は、セッションに関する情報を格納する共有メモリゾーンを作成します。割り当てられるメモリの量（ここでは1 MB）は、一度に格納できるセッションの数を決定します（数はプラットフォームによって異なります）。ゾーンに割り当てられた名前（ここでは、client_sessions）は、各stickyディレクティブごとに一意でなければなりません。

セッション・パーシステンスの詳細については、「NGINX Plus管理者ガイド」を参照してください。

アプリケーションヘルスチェックの設定

ヘルスチェックは、決まった間隔でサーバーに送信される帯域外 HTTPリクエストです。これらは、クライアントから実際のリクエストは行なわずに、サーバーが応答して正しく機能するかどうかを判断するために使用されます。

locationブロック内にhealth_checkディレクティブを置くことで、アプリケーションごとに異なるヘルスチェックを有効にできます。

パスが（基本的なロードバランシング設定で作成された）/webapp/で始まるHTTPSリクエストに一致するlocationブロックで、health_checkディレクティブを追加します。

ここではNGINX Plusを設定して、jboss upstreamグループの各サーバーに対し、最上位URI /（スラッシュ）の帯域外リクエストを5秒ごと（デフォルトのURIかつ間隔）に送信するようにします。サーバーが正しく応答しない場合はマークダウンされ、連続したヘルスチェックが渡されるまで、NGINX Plusはリクエストの送信を停止します。デフォルト以外のヘルスチェックテスト一式を定義するよう、matchパラメータを含めています（定義は次のステップで行います）。

# In the 'server' block for HTTPS traffic
location /webapp/ {
    proxy_pass http://jboss;
    proxy_cache backcache;
    health_check match=jboss_check;
}

ディレクティブのドキュメント：health_check、location、proxy_cache、proxy_pass

2.このhttpコンテキストではmatchディレクティブを含め、サーバーが機能しているとみなされるために渡さなければならないテストを定義しています。この例では、ステータスコード200を返す必要があり、Content-Typeレスポンスヘッダーはtext/htmlでなければなりません。レスポンスのbodyは指定された正規表現と一致する必要があります。

# In the 'http' block
match jboss_check {
    status 200;
    header Content-Type = text/html;
    body ~ "Your WildFly 9 is running";
}

ディレクティブのドキュメント： match

3.JBossのupstreamグループにzoneディレクティブを含め、グループの構成およびワーカープロセス間で共有されているランタイム状態を格納する、共有メモリ領域を定義します。

# In the 'http' block
upstream jboss {
    zone jboss 64k;
    server 192.168.33.11:8080;
    server 192.168.33.12:8080;
    # ...
}

ディレクティブのドキュメント：server、upstream、zone

NGINX Plusにはスロースタート機能もあり、ヘルスチェックの補助機能として役立ちます。障害が発生したサーバーが回復するか、または新しいサーバーがupstreamグループに追加されると、NGINX Plusは定義された時間をかけて、ゆっくりそれらのサーバーへのトラフィックを増やしていきます。これにより、起動時に処理できる以上の接続に圧倒されないよう、サーバーに「ウォームアップ」時間を与えることができます。詳細については、「NGINX Plus管理者ガイド」を参照してください。

たとえば、Wildflyアプリケーションサーバーのスロースタート時間を30秒に設定するには、そのserverディレクティブにslow_startパラメータを含めます。

# In the 'upstream' block
server 192.168.33.11:8080 slow_start=30s;
server 192.168.33.12:8080 slow_start=30s;

パラメータドキュメント： slow_start

ヘルスチェックのカスタマイズについては、「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

2.メインの設定ファイル（/etc/nginx/nginx.conf）のhttpコンテキストにファイルを含めます。

# In the 'http' block in nginx.conf
include conf.d/status.conf;

ディレクティブのドキュメント： include

3.ファイル内のコメントで指定されたご自身の環境用のファイルをカスタマイズします。特に、ファイルのデフォルト設定では、あらゆるネットワーク上の誰でもがダッシュボードにアクセスできます。以下の方法の1つ以上を使用して、NGINX Plus APIへのアクセスを制限することを強くお勧めします。

- IPアドレスベースのアクセス制御リスト（ACL）サンプル設定ファイルで、allowおよびdenyディレクティブのコメントアウトを外し、管理ネットワークのアドレスを10.0.0.0/8に置き換えます。指定したネットワーク上のユーザーのみがステータスページにアクセスできます。

allow 10.0.0.0/8;
deny all;

ディレクティブのドキュメント：allow,deny

- HTTP 基本認証　サンプル設定ファイルで、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）。

4.監視したい各upstreamグループに、zoneディレクティブを含めます。ワーカープロセス間で共有されるグループの構成と実行時の状態を格納する共有メモリゾーンを定義します。

たとえば、Wildflyアプリケーションサーバーを監視するには、jbossアップストリームグループにzoneディレクティブを追加します（アプリケーションヘルスチェックの設定の手順を終えている場合は、既にこの変更を行っています）。

# In the 'http' block
upstream jboss {
    zone jboss 64k;
    server 192.168.33.11:8080;
    server 192.168.33.12:8080;
    # ...
}

ディレクティブのドキュメント： zone

5.HTTPSトラフィックのserverブロック（HTTPおよびHTTPSトラフィック用の仮想サーバーの設定で作成）で、以下のstatus_zoneディレクティブを追加します。

# In the 'server' block for HTTPS traffic
status_zone jboss;

ディレクティブのドキュメント： 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メソッドの設定

Wildfly アプリケーションサーバーのupstreamグループをダイナミック・リコンフィグレーションできるようにするには、NGINX Plus APIにセキュリティ保護されたアクセスを許可する必要があります。APIを使ってサーバーを追加・削除したり、動的にその重みを変えたり、ステータスをprimary、backupまたはdownに設定することができます。

jboss upstreamグループにzoneディレクティブを含めて、グループの構成と実行時の状態を格納する共有メモリゾーンを作成します。これにより、すべてのワーカープロセスが情報を利用できるようになります。（アプリケーションヘルスチェックまたはライブアクティビティのモニタリングを設定した場合は、既にこの変更が行われています）。

# In the 'http' block
upstream jboss {
    zone jboss 64k;
    server 192.168.33.11:8080;
    server 192.168.33.12:8080;
    # ...
}

ディレクティブのドキュメント： zone

2.HTTPSトラフィックのserverブロック（HTTPおよびHTTPSトラフィック用の仮想サーバーの設定で作成）で、NGINX Plus API用の新しいlocationブロックを追加します。これにより、ダイナミック・リコンフィグレーションに必要な機能が利用できるようになります。ここにはapiディレクティブが含まれています（apiは、ここで使用されているように、ディレクティブの本来の名前でもあります）。

（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ディレクティブを追加します。 JBoss upstreamブロックで、resolveパラメータをserverディレクティブに追加し、NGINX PlusがDNSに対し、ドメイン名（ここでは、example.com ）を定期的に再解決するよう指示します。

また、 upstreamグループの構成と実行時の状態を格納するための共有メモリゾーンを作成し、すべてのワーカープロセスで情報を利用できるようにするには、upstreamブロックにzoneディレクティブを含めます。（アプリケーションヘルスチェックまたはライブアクティビティのモニタリングを設定した場合は、既にこの変更が行われています）。

# In the 'http' block
resolver <IP-address-of-DNS-server>;
upstream jboss {
    zone jboss 64k;
    server example.com resolve;
}

ディレクティブおよびパラメータのドキュメント：resolve、resolver、zone

NGINX Plusリリース9以降では、ポート番号など、SRV DNS レコードの追加情報も使用できます。serverディレクティブにresolveパラメータと一緒に、serviceパラメータを次のように含めます。

# In the 'http' block
resolver <IP-address-of-DNS-server>;
upstream jboss {
    zone jboss 64k;
    server example.com service=http resolve;
}

パラメータのドキュメント： service

拡張ロードバランシングの全設定

参照用に、ロードバランシングを強化するための完全な設定を掲載しておきます。それはhttpコンテキストの中に入ります。完全なファイルは、NGINX,Inc.のWebサイトからダウンロードできます。

このドキュメントから直接テキストをコピーするのではなく、設定ファイルの作成と変更で説明されている方法を使用して、ご自身の設定にこれらのディレクティブを含めることをお勧めします。つまり、メインのnginx.confファイルのhttpコンテキストにincludeディレクティブを追加し、/etc/nginx/conf.d/tomcat-enhanced.confを読みこませます。

注：この設定サマリーのapiブロックとダウンロード可能な jboss-enhanced.confファイルは、ダイナミック・リコンフィグレーションのAPIメソッド用です。代わりにDNSメソッドを使用する場合は、同ブロックを適切に変更してください。（この場合、NGINX Plus APIのディレクティブを削除またはコメントアウトすることもできますが、DNSメソッドの使用と競合はせず、ダイナミック・リコンフィグレーション以外の機能を有効にします）。

proxy_cache_path /tmp/NGINX_cache/ keys_zone=backcache:10m;
# WebSocket configuration  
map $http_upgrade $connection_upgrade { 
    default upgrade;  
    ''      close;  
}
# Application health checks  
match jboss_check {  
    status 200;  
    header Content-Type = text/html;  
    body ~ "Your WildFly 9 is running";  
}
upstream jboss {  
    # Shared memory zone for application health checks, live activity monitoring,  
    # and dynamic reconfiguration  
    zone jboss 64k;
    # List of Wildfly application servers  
    server 192.168.33.11:8080 slow_start=30s;  
    server 192.168.33.12:8080 slow_start=30s;
    # Session persistence based on 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 jboss;
    ssl_certificate            /etc/nginx/ssl/<certificate-name>;  
    ssl_certificate_key        /etc/nginx/ssl/<private-key>;
    ssl_session_cache          shared:SSL:1m;  
    ssl_prefer_server_ciphers  on;
    # Load balance requests to /webapp/ among Wildfly application servers  
    location /webapp/ {  
        proxy_pass http://jboss;  
        proxy_cache backcache;
        
        # Active health checks  
        health_check match=jboss_check;  
    }
    # Return a 302 redirect to the /webapp/ directory when user requests '/'  
    location = / {  
        return 302 /webapp/;  
    }
    # WebSocket configuration  
    location /wstunnel/ {  
        proxy_pass http://jboss;  
        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  
    } 
}

リソース

改訂履歴

バージョン5（2018年4月） – Wildflyへの名前の変更、およびNGINX Plus APIによるメトリック収集に関する情報
バージョン4（2017年12月） – 動的な再構成のDNSメソッド用の指示を追加する（NGINX Plus R14）
バージョン3（2017年4月） – HTTP / 2サポートのアップデート（NGINX Plus R11）
バージョン2（2016年1月） – HTTP / 2サポートのアップデート（NGINX Plus R8、コミュニティ版NGINX1.9.9）
バージョン1（2015年12月） – イニシャル・バージョン（NGINX Plus R7、コミュニティ版NGINX1.9.5）

タグ: JBoss, Wildfly, ロードバランシング

NGINX Blog

コミュニティ版NGINXおよびNGINX Plusを使用したWildflyおよびJBossアプリケーションサーバのロードバランシング

コメントを残すコメントをキャンセル

NGINX Blog

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル