2018年 6月 の投稿一覧

ホワイトペーパーを公開しました!

本ブログサイトの”ホワイトペーパー一覧”ページにeBOOKを公開致しました。
https://nginx.sios.jp/white-paper#5reasons

内容は以下の通りです。
——————————————

<タイトル>

ロードバランシングをソフトウェアに切り替える 5つの理由

現在、企業のITシステムにおけるWebサービスの重要性が拡大し続け、ビジネスの競争力を握るといっても過言ではなくなっています。

ベアメタル、クラウド、コンテナなど様々な環境が混在するなか、急激なトラフィックの増加やアプリケーションの迅速な展開といった課題に頭を悩ますインフラ担当者の方は、多いのではないでしょうか?

この課題に対応するため、大規模なWebを活用する企業は、ソフトウェアベースのWebサーバーやロードバランサー、キャッシュサーバーを使っています。
ハードウェアベースのアプリケーション デリバリー コントローラー(ADC)は、高コストの第1世代Webサーバーを最大限に活用するためのソリューションとして20年前に開発されましたが、現在のITシステムが求める高い柔軟性やスピード、コストパフォーマンスを満たすことができないためです。 このeBOOKでは、IT責任者、ネットワーク担当者、アプリケーション開発者が、従来のハードウェアADCからソフトウェアソリューションに移行することで得られるメリットと優位性、ビジネスへの影響について、5つの観点から解説します。

コミュニティ版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の機能を拡張しています。

 

 

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形式の自己署名入りサーバー証明書を生成します。

  1. opensslソフトウェアがインストールされているマシンに、rootユーザーとしてログインします。
  2. キーペアを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ディレクトリにコピーまたは移動します。

 

証明書要求の生成

  1. opensslソフトウェアがインストールされているマシンに、rootユーザーとしてログインします。

  2. 証明書にパッケージ化する秘密鍵を作成します。

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で可能)に1つのファイル、拡張したロードバランシング用(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サーバーにリダイレクトされます。

 

  1. ポート443で受信したhttps://example.comへのリクエストをlistenするserverブロックを構成します。

     ssl_certificatessl_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;
}

ディレクティブのドキュメント:listenserverserver_namessl_certificatessl_certificate_keyssl_prefer_server_ciphersssl_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;
    }
}

ディレクティブのドキュメント:locationreturn

 

SSL / TLSの設定情報は、「NGINX Plus管理者ガイド(英語)」および「HTTP SSL / TLSモジュール(英語)」のリファレンスドキュメントを参照してください。

 

基本的なロードバランシングの設定

ロードバランシングを設定するには、まず、クライアントリクエストが送られるバックエンドサーバーをリストアップし、名前を付けたupstreamグループを作成します。その後、1つまたは複数のproxy_passディレクティブ内でupstreamグループを参照することで、コミュニティ版NGINXまたはNGINX Plusをリバースプロキシおよびロードバランサーとして設定します。

 

  1. 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;
}

ディレクティブのドキュメント:serverupstream

       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/;
}

ディレクティブのドキュメント:locationproxy_passreturn

 

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;
}

ディレクティブのドキュメント:locationmapproxy_http_versionproxy_passproxy_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ホストにサーバーレスポンスをキャッシュすることです。

 

  1. 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

 

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

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

 

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

ディレクティブのドキュメント:proxy_cacheproxy_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-plusnginx-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 ChromeFirefox用の「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ディレクティブを追加します。

 

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

 

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

ディレクティブのドキュメント:serverupstream

      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;
}
ディレクティブのドキュメント:serversticky learnupstream

 

    • 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ディレクティブを置くことで、アプリケーションごとに異なるヘルスチェックを有効にできます。

 

  1. パスが(基本的なロードバランシング設定で作成された)/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_checklocationproxy_cacheproxy_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;
    # ...
}

ディレクティブのドキュメント:serverupstreamzone

 

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ステップ」を参照してください。

 

  1. 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_basicauth_basic_user_file

 

 

    • ファイアウォール  ファイアウォールを設定して、ダッシュボードのポートへの外部アクセスを禁止します(サンプル設定ファイルでは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を使ってサーバーを追加・削除したり、動的にその重みを変えたり、ステータスをprimarybackupまたはdownに設定することができます。

 

  1. 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およびdenyapi

 

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;
}

ディレクティブおよびパラメータのドキュメント:resolveresolverzone

 

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)

コミュニティ版NGINXまたはNGINX Plusを使ったApache Tomcatサーバーのロードバランシング

※本記事は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の機能を拡張しています。

 

 

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形式の自己署名入りサーバー証明書を生成します。

  1. opensslソフトウェアがインストールされているマシンに、rootユーザーとしてログインします。
  2. キーペアをPEM形式で生成します(デフォルト)。秘密鍵を暗号化するには、-des3パラメーターを含めます。(他の暗号化アルゴリズムも利用可能で、genrsaコマンドのマニュアルページに記載されています。)暗号化の基礎として使用されるパスフレーズの入力が求められます。
  3. root# openssl genrsa -des3 -out ~/private-key.pem 2048Generating RSA private key …Enter pass phrase for private-key.pem:
    1. 安全な場所に、キーファイルのバックアップを作成します。鍵を失った場合、証明書は使用できなくなります。

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

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

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

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

    証明書要求の生成

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

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

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

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

    1. 証明書署名要求(CSR)ファイルを作成します。

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

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

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

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

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

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

    ここで紹介されているように、基本的なロードバランシング用(コミュニティ版NGINX、NGINX Plusで可能)に1つのファイル、拡張したロードバランシング用(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サーバーにリダイレクトされます。

    1. ポート443で受信したhttps://example.comへのリクエストをlistenするserverブロックを構成します。

       ssl_certificatessl_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;

    }

      ディレクティブのドキュメント:listenserverserver_namessl_certificatessl_certificate_keyssl_prefer_server_ciphersssl_session_cache

    1. 前の手順で定義した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;

       }

    }

    ディレクティブのドキュメント:locationreturn

    SSL / TLSの設定情報は、「NGINX Plus管理者ガイド(英語)および「HTTP SSL / TLSモジュール」(英語)リファレンスドキュメントを参照してください。

    基本的なロードバランシングの設定

    ロードバランシングを設定するには、まずクライアントリクエストが送られるバックエンドサーバーをリストアップし、名前を付けたupstreamグループを作成します。その後、1つまたは複数のproxy_passディレクティブ内でupstreamグループを参照することで、コミュニティ版NGINXまたはNGINX Plusをリバースプロキシおよびロードバランサーとして設定します。

    1. 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;

    }

    ディレクティブのドキュメント:serverupstream

    1. 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/;

    }

    ディレクティブのドキュメント:locationproxy_passreturn

    これらのブロックは、標準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;

    }

    ディレクティブのドキュメント:locationmapproxy_http_versionproxy_passproxy_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で基本的なキャッシングを有効にするには、次の設定を追加します。

    1. 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

    1. パスが/tomcat-app/で始まるHTTPSリクエストと一致するlocationブロックで、前の手順で作成したキャッシュを参照するproxy_cacheディレクティブを含めます。

    # In the ‘server’ block for HTTPS traffic

     

    location /tomcat-app/ {

       proxy_pass http://tomcat;

       proxy_cache backcache;

    }

    ディレクティブのドキュメント:locationproxy_cacheproxy_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-plusnginx-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 ChromeFirefox用の「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の基本的なロードバランシング設定については他のサブセクションで説明しています)を、ここで説明する拡張機能と組み合わせることができます。

    次のセクションで説明する機能はすべてオプションです。

    完全な設定ファイルは、拡張ロードバランシングの全設定で入手できます。

    高度なセッション・パーシステンスの設定

    NGINX Plusは、コミュニティ版NGINXよりも洗練されたセッション・パーシステンスの手段を提供しています。これは、3つのstickyディレクティブの変形で実装されています。次の例では、Tomcatアプリケーションで設定されたjvmRoute属性にセッション・パーシステンスを設定するために、基本的なロードバランシング設定作成したupstreamグループにsticky routeディレクティブを追加します。

    1. 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

    1. バックエンドの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”>

    1. 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;

    }

    ディレクティブのドキュメント:mapserversticky 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. 上記の手順1のように、upstreamブロック内のip_hashディレクティブを削除またはコメントアウトします。
    1. 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;

    }

    ディレクティブのドキュメント:mapserversticky 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ディレクティブを置くことで、アプリケーションごとに異なるヘルスチェックを有効にできます。

    1. パスが(基本的なロードバランシング設定で作成された)/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_checklocationproxy_cacheproxy_pass

    1. この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

     

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

    # In the ‘http’ block

    upstream tomcat {

      zone tomcat 64k;

      

      server 10.100.100.11:8080;

      server 10.100.100.12:8080;

      # …

    }

    ディレクティブのドキュメント:serverupstreamzone

    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ステップ」を参照してください。

    1. status.confファイルをNGINX Plusサーバーにダウンロードします。

    #cd /etc/nginx/conf.d

    #curl https://www.nginx.com/resource/conf/status.conf> status.conf

    1. メインの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として捉えられます。

    1. status.confのコメントは、自分の環境向けにカスタマイズする必要のあるディレクティブを説明しています。特に、サンプル設定ファイルのデフォルト設定では、ネットワーク上の誰もがダッシュボードにアクセスできるようになっています。ダッシュボードへのアクセスを制限するには、次のいずれかの方法を使用することを強くお勧めします。
      • IPアドレスベースのアクセス制御リスト(ACL)サンプル設定ファイルで、allowおよびdenyディレクティブのコメントアウトし、管理ネットワークのアドレスを10.0.0.0/8に置き換えます。指定したネットワーク上のユーザーのみがステータスページにアクセスできます。

    allow 10.0.0.0/8;

    deny all;

    ディレクティブのドキュメント:allowdeny

      • 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_basicauth_basic_user_file

      • ファイアウォール ファイアウォールを設定して、ダッシュボードのポートへの外部アクセスを禁止します(サンプル設定ファイルでは8080)。
    1. 監視したい各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;

      #…

    }

    ディレクティブのドキュメント:serverupstreamzone

    1. 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を使ってサーバーを追加・削除したり、動的にその重みを変えたり、ステータスをprimarybackupまたはdownに設定することができます。

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

    # In the ‘http’ block

    upstream tomcat {

       zone tomcat 64k;

       server 192.168.33.11:8080;

       server 192.168.33.12:8080;

       # …

    }

    ディレクティブのドキュメント:serverupstreamzone

    1. 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およびdenyapi

    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;

    }

    ディレクティブおよびパラメーターのドキュメント:resolveresolverzone

    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)

NGINXおよびNGINX Plus Webサーバーのパフォーマンステスト

※本記事はNGINX,Inc.のブログ記事「Testing the Performance of NGINX  and NGINX Plus Web Servers」を和訳したものです。

 

Webサイトを成功させるには、パフォーマンスが非常に重要です。低速のサイトを使いたい人なんていませんから。

2004年のオープンソースのリリース以来、NGINXは高性能Webサイトの代名詞となっています。世界のトップ100,000サイトの63%、そして世界中の4億900万サイトがNGINXで動いています。でも、実際NGINXはどのくらいうまく機能していますか?リーズナブルな価格で最高のパフォーマンスを発揮するハードウェア構成は何でしょうか?

これらの質問に答えるため、リバースプロキシとWebサーバーという2つの構成について、ラボでパフォーマンステストを行いました。リバースプロキシのパフォーマンスの数値は、「ベアメタルサーバー用のNGINX Plusサイジングガイド」(英語)に掲載し、Nginx社のブログ「NGINX Plusサイジングガイド(英語):どのようにテストしたか」でテストの詳細を説明しています。

これらの記事を公開してから、基礎となるテスト結果に関するより具体的な情報に対して多くのリクエストを頂きました。この記事では、ライブHTTP接続とHTTPS接続の1秒あたりの要求数(以後RPSと表記)と1秒あたりの接続数(以後CPSと表記)の詳細なパフォーマンス数値をご紹介します。また、Webサーバーとして動作するNGINX用の50個の専用チャネルのHTTPスループットを公開します。この結果は、コミュニティー版のNGINXソフトウェアとNGINX Plusの両方にあてはまります。

この情報が、予算とパフォーマンス要件を考慮しつつ、現在から将来を見据えてWebアプリケーションのトラフィックを処理するために必要なハードウェア仕様を決めるときに、お役に立てば幸いです。

テストの概要

使用したテスト設定は、クライアントとWebサーバーの間にリバースプロキシがないことを除けば、前述の「NGINX Plusサイジングガイド:どのようにテストしたか(英語)」

の設定とほぼ同じです。シンプルでフラットなレイヤ2ネットワークのデュアルポート 40-GbEリンクで接続された2つの別々のマシンを使用して、すべてのテストを行いました。

テストで異なる数のCPUをシミュレートするために、NGINXワーカープロセスの数を変更しました。デフォルトでは、実行を開始するNGINXワーカープロセスの数は、NGINXが実行されているマシンで使用可能なCPUの数と同じです。/etc/nginx/nginx.confファイル内のworker_processesディレクティブの値を変更し、NGINXサービスを再起動することによって、実行中のNGINXワーカープロセスの数を変更できます。

クライアントトラフィックがHTTPSで保護されているテストでは、次の暗号化パラメータを使用しました。

  • ECDHE-RSA-AES256-GCM-SHA384暗号
  • 2,048ビットRSAキー
  • 暗号のECDHEで示されている完全なforward secrecy
  • OpenSSL 1.0.1f

使用ハードウェア

クライアントマシンとWebサーバーマシンの両方のテストで、以下のハードウェアを使用しました。

  • CPU:2xインテル(R)Xeon(R)CPU E5-2699 v3 @ 2.30GHz、36(72 HT)コア
  • ネットワークアダプター:インテルXL710 デュアルポート 40GbE QSFP +(rev 01)
  • メモリー:16 GB

使用ソフトウェア

テストには次のソフトウェアを使用しました。

  • クライアントマシン上で実行するバージョン4.0.0 のwrkは、NGINXがプロキシしたトラフィックを生成します。インストールは、これらの手順に従って行いました。
  • コミュニティー版のNGINXソフトウェアのバージョン1.9.7がWebサーバーマシン上で動作します。インストールは、これらの指示に従って、nginx.orgの公式リポジトリから行いました。
  • Ubuntu Linux 14.04.1は、クライアントマシンとWebサーバーマシンの両方で動作します。

 

パフォーマンス計測と分析

テストから得られた、パフォーマンスの数値は下記の通りです。

1秒あたりのリクエスト数

1秒あたりの要求数(RPS)は、HTTPリクエストを処理する能力を測定します。それぞれのリクエストは、クライアントマシンからNGINX Webサーバーに送信されます。テストは、暗号化されていないHTTPと、暗号化されたHTTPSトラフィックの両方に対して行いました。

パフォーマンステストの一般的な習慣に従って、4つの標準ファイルサイズを使用しています。

  • 0 KBは、302エラーコードなどのデータを伴わない「空の」HTTPリクエストまたはレスポンスをシミュレートします。
  • 1 KBは、小さなCSSやJavaScriptファイルのサイズ、または小さなアイコンなどの非常に小さいイメージのサイズです。
  • 10 KBは、大きなコードファイル、大きなアイコン、小さな画像ファイルに近いものです。
  • 100 KBは大きなコードファイルと他の大きなファイルを表します。

少量のHTTPリクエストを発行すると、1秒あたりのリクエスト数が増え、総スループットが低下します。大量のHTTPリクエストを発行すると、1回のリクエストで大量のファイル転送が開始されるため、完了までにかなりの時間がかかり、1秒あたりのリクエスト数とスループットが低下します。

HTTP要求のRPS

以下の表とグラフは、HTTPリクエストの数を、異なるCPU数とリクエストサイズごとにキロバイト(KB)単位で示しています。

大規模なHTTPリクエスト(テストでは10および100 KBサイズのもの)は断片化され、処理に時間がかかります。その結果、大きいサイズのリクエストになればなるほど、グラフ内の線はより傾きが平坦になっています。

予算とパフォーマンスの選択肢を検討するとき、CPU数が16を超えると、線の傾きが変化することに注意してください。32個のCPUを搭載したサーバーは、1 KBおよび10 KBのリクエストサイズの場合、36個のCPUを搭載したサーバーと同等以上の性能を発揮しました。最終的には、リソースの競合がCPUの追加によるプラスの影響を上回ります。これは、HTTPトラフィック向けの一般的な4〜8コアのサーバー構成では、CPUを合計16個に増やすことがもっとも効果的かもしれず、32個の使用だとそこまでではなく、36個に増やすメリットはさらに少ないか、ほとんどないということを示唆しています。とはいえテストでの事実が、あなたにとっての有用性とは違うかもしれないのは、いつものことですが。

HTTPS要求のRPS

HTTPS RPSは、同じプロビジョニングされたベアメタルハードウェアのHTTP RPSよりも低くなります。これは、マシン間で送信されるデータを保護するために必要なデータの暗号化と復号化の計算コストが高いためです。

上記状況にも関わらず、プロセッサーの高速化とメモリー管理の向上を実現したIntelアーキテクチャーの進歩のおかげで、専用のハードウェア暗号化デバイスと比べ、CPUによる暗号化タスクのソフトウェア性能は絶え間なく向上しています。

16CPUの場合、HTTPSの1秒あたりの接続数は、HTTPの約4分の1減程度ですが、いわば「問題にハードウェアを投げ込んで」CPUを追加するなら、HTTPよりも効果的です・・・最大36CPUまでは、より一般的に使用されるファイルサイズのため。

1秒あたりの接続数

1秒あたりの接続数(以後CPSと表記)は、リクエストを行ったクライアントに対し、新しいTCP接続を行うNGINXの能力を測定します。クライアントは一連のHTTPまたはHTTPSリクエストを、それぞれ新しい接続で送信します。NGINXはリクエストを解析し、各リクエストに対して0バイトの応答を返します。リクエストが満たされた後、接続は閉じられます。

注:このテストのHTTPSの変形は、SSLトランザクション/秒 (SSL TPS)と呼ばれることがよくあります。

HTTPリクエストの1秒あたりの接続数

以下の表とグラフは、異なるCPU数でのHTTPリクエストに対するCPSを示しています。

HTTPS要求に対する1秒あたりの接続数

以下の表とグラフは、HTTPSリクエストのCPSを示しています。
タイミングの制約のため、32CPUではテストを行っていません。

スループット

以下のテストでは、NGINXが180秒間を超えて持続できるHTTPリクエスト(Gbps単位)のスループットを測定します。

雑記

テストと結果に関して、何点かメモをしておきます。

  • 本テストCPUでは、ハイパースレッディングが利用できました。つまり、ハイパースレッディングCPUの全容量を使用するため、追加のNGINXワーカープロセスを実行できたということです。ここで報告したテストではハイパースレッディングは有効にしませんでしたが、別のテストで使用すると、パフォーマンスが向上しました。ハイパースレッディングによって、SSL TPSが約50%も改善したことは特筆すべき点です。
  • ここに示した数字はOpenSSL 1.0.1です。また、OpenSSL 1.0.2でテストし、2倍のパフォーマンス向上を確認しました。OpenSSL 1.0.1は、まだ幅広く使用されていますが、より良いセキュリティとより良いパフォーマンスのために、OpenSSL 1.0.2に移行することをお勧めします。
  • 楕円曲線暗号(ECC)もテストしましたが、ここで示した結果はRSAを使用しています。暗号化の場合、ECCは消費電力の効率化が必要なモバイル向けに展開されることが多く、RSAはECCよりもはるかに広く使用されています。標準的なRSA証明書と比較して、ECCでは2倍から3倍のパフォーマンス向上が見られたため、EECの実装を検討することをお勧めします。

OpenSSL 1.0.2への移行とECCへの移行の組み合わせで、非常に強力なパフォーマンス改善をもたらすかもしれません。さらに現在、4CPUまたは8CPUサーバーを使用していて、16CPU(または、SSL用に32CPU)に移行した場合、ここでのテスト結果が示すように、非常に劇的な改善を達成することができるかもしれません。

結論

ライブHTTPおよびHTTPS接続でのRPSおよびCPSのパフォーマンステスト結果と、50の専用チャネルでのHTTPスループットを分析しました。予算とパフォーマンスのニーズに合わせ、現在と将来を見越したトラフィックを処理するために必要なハードウェアの仕様決定に、ぜひこのブログの情報をお役立てください。

nginx 1.15.0 リリース

2018年6月5日にコミュニティ版ホームページ(nginx.org)で1.15.0が公開されました。
nginx 1.15.0ではsslディレクティブの仕様変更、streamモジュールの機能追加、また構築に関わる不具合修正をメインにリリースされた内容となっています。

以下にリリース内容の参考訳を記載します。

nginx 1.15.0 リリース内容

<変更点>
1.sslディレクティブを廃止。今後はlistenディレクティブ内にsslパラメーターを定義する必要があります。

2. “listen”ディレクティブの “ssl”パラメータを使用しているときに設定テスト中に欠落しているSSL証明書を検出します。

 

<機能>
1.単一セッション内でのクライアントからのデータグラムをstreamモジュールにより
複数の着信UDPを処理出来るようになりました。

 

<不具合修正>

1.”proxy_cache_valid”ディレクティブ内で不正な応答コードを指定出来ました。

2.ggin 8.1でnginxを構築できませんでした。

3.ローカルIPアドレスの変更でsyslogへのロギングが停止されました。

4.CUDA SDKがインストールされた状態でnginxを構築することはできませんでした。(1.13.8から発生)

5.Fedora 28 Linuxではnginxを構築できませんでした。

6.FreeBSD上でUNIXドメイン listen socketを使用している場合、バイナリアップグレード中に
“getsockopt(TCP_FASTOPEN)…失敗”メッセージが表示され、ログに記録されていました。

7. “limit_req”ディレクティブを使用したとき、リクエスト処理速度が設定された速度を
超える場合がありました。

8.Linux上でデータグラムを処理するunix domain listenソケットを使っているときの
クライアントアドレスのハンドリング処理を修正しました。

9.メモリー割り当てエラーハンドリング処理を修正しました。

 

*) Change: the “ssl” directive is deprecated; the “ssl” parameter of the “listen” directive should be used instead.
*) Change: now nginx detects missing SSL certificates during configuration testing when using the “ssl” parameter of the “listen” directive.
*) Feature: now the stream module can handle multiple incoming UDP datagrams from a client within a single session.
*) Bugfix: it was possible to specify an incorrect response code in the “proxy_cache_valid” directive.
*) Bugfix: nginx could not be built by gcc 8.1.
*) Bugfix: logging to syslog stopped on local IP address changes.
*) Bugfix: nginx could not be built by clang with CUDA SDK installed; the bug had appeared in 1.13.8.
*) Bugfix: “getsockopt(TCP_FASTOPEN) … failed” messages might appear in logs during binary upgrade when using unix domain listen sockets on FreeBSD.
*) Bugfix: nginx could not be built on Fedora 28 Linux.
*) Bugfix: request processing rate might exceed configured rate when using the “limit_req” directive.
*) Bugfix: in handling of client addresses when using unix domain listen sockets to work with datagrams on Linux.
*) Bugfix: in memory allocation error handling.

NGINX Plusを使用した3つのクラウドアーキテクチャー

※本記事はNGINX,Inc.のブログ記事「3 Cloud Architectures with NGINX Plus」を和訳した内容となります。
【URL】
https://www.nginx.com/blog/cloud-architectures/

クラウドへの移行をご検討中でしょうか?クラウドへの移行には、多くのメリットと同時に、いくつかデメリットもあります。一部の企業では、会社のファイアウォール外にデータをホストすることは契約違反です。でも、ほとんどの場合では、自分のハードウェアを管理する必要がないという利点の重みは、絶対的なコントロールを失うといった欠点をはるかに上回っています。最近の調査によると、このことはIT責任者にとって、ますます明らかになりつつあるようです。今後2年間で、エンタープライズのIT支出の3分の1ががクラウドに向かうことが予測されている(英語ページ)のです。

クラウドへの移行を検討している場合、またはそうでない場合でも、今はアプリケーションのアーキテクチャーについて考え始めるのによい時期です。よく知られた問題を抱えたまま、盲目的にアプリケーションをクラウドに移行させるよりは、この新しいタイプの環境でよりスムーズに動作するよう、アプリケーションスタックを更新してはどうでしょうか?アプリケーション・デリバリー戦略は、再評価プロセスを開始するのに最適なスタート地点です。優れたアプリケーション配信は、あなたに忠実なお客様を得るか、競合他社の新しいお客様にしてしまうかの違いを生むのです。

オンプレミスでアプリケーションをホストする場合、ハードウェアのアプリケーション デリバリー コントローラー(以下ADCと表記)を使う可能性が高いはずです。ハードウェアADCはオンプレミス環境ではうまくいくかもしれませんが、クラウドにハードウェアを置くことはできません。
従来のハードウェアADCベンダーのほとんどは、自社製品の仮想バージョンを持っていますが、
クラウドに移行するなら、クラウドを念頭に置いて作られた最新のADCを試してみてはいかがでしょうか。

NGINX Plusは、現代のWebから誕生した、エンタープライズグレードのソフトウェアのADCです。NGINX Plusは軽量で、アプリケーションを完璧に届けるために必要なすべての機能を備え、
使いもしない機能にコストを強いることもありません。NGINX PlusはハードウェアADCのコストのほんの一部分で利用でき、機能を遅くする帯域幅やSSLの制限はありません。

クラウドコンピューティングの調査を始めるための参考に、NGINX Plusの機能を活用した、
いくつかのクラウドアーキテクチャーをご紹介します。

シンプルクラウドバースト

一度にすべてをクラウドに移行することが危険すぎるようであれば、より混乱しにくい方法として
ハイブリッド展開を考えてみてください。このタイプの構成では、オンプレミスとクラウドサービスの両方を使って、アプリケーションを提供します。

NGINX Plusの最小時間ロードバランシング・アルゴリズム(英語ページ)を使用すると、すべての
オンプレミスサーバーがビジー状態のときに、トラフィックがクラウドに送信される
「クラウドバースト」構成を構築できます。

 

ローカルサーバーがすべてビジー状態のとき、NGINX Plusはクラウドにトラフィックを送信します。

最小時間アルゴリズムでは、NGINX Plusは、各サーバーに対して2つの数値(現在のアクティブな接続数と、過去のリクエストに対する加重平均した応答時間)を数学的に結合し、最小値だったサーバーにリクエストを送ります。
最小時間だと、ローカルサーバーの応答が速いため、そちらに多くのリクエストを送信する傾向が
あります。ローカルサーバーにリクエストを送り続けて、ネットワークの余分なレイテンシーの分を含めてもなお、クラウドサーバーがローカルサーバーよりも迅速に応答する点まで行くと、
NGINX Plusはクラウドサーバーへリクエストを振り向け始めます。ローカルサーバーの負荷が
再び
小さくなると、NGINX Plusは、ほとんどのリクエストの振り向け先をローカルサーバーに戻します。

 

ローカル・ロードバランシング

多くのパブリッククラウドベンダーは、世界中に地域ごとのデータセンターを持ち、そのいずれか、またはすべてにアプリケーションをホストすることができます。たとえば、Amazon Web Services、北米、南米、ヨーロッパ、アジアに9つのデータセンターあります。
フォールトトレランスのために、クラウドベンダーは各地域のデータセンターに「可用性ゾーン」を設定しています。可用性ゾーンには、独立した電源、ネットワーキング、冷却装置などを備え、物理​​的に分離されたハードウェアのラックがあります。たとえば電力を失うなどして、ある可用性ゾーンに障害が発生した場合、稼働中の可用性ゾーンが代わりを務めることができます。
可用性ゾーンをまたいでアプリケーションを複製することで、アプリケーションの可用性を
高めることが可能です。
可用性ゾーンをまたいでアプリケーションを複製することにより、高可用性を実現

上記のクラウドアーキテクチャ図では、クラウドベンダーのネイティブなロードバランサー
(Amazon Web Servicesの
ELB、Google Cloud Platformのロードバランサー、またはMicrosoft AzureのAzure Traffic Manager)がトラフィックをさまざまな可用性ゾーンに分散しています。
それぞれの可用性ゾーン内で、NGINX Plusはアプリケーションサーバーへの負荷分散を行います。NGINX Plusの背後にあるアプリケーションは、モノリスでも、マイクロサービスベースの
アプリケーション、またはそれらの中間のものでも構いません。

 

グローバル・ロードバランシング

アプリケーションを複数の可用性ゾーンにまたがって複製することで、地域内での高可用性が
実現します。次のステップは、複数の地域でアプリケーションをホストすることです。
アプリケーションをユーザーの近くに移動すると、ネットワークのレイテンシーの
影響が軽減され、全体的なユーザーエクスペリエンスが向上します。グローバルに分散されたアプリケーションを構築するには多くの方法があります。
一般的な方法の一つは、地理的な位置情報ベースのDNS(GeoDNS)ソリューションを使うことです。GeoDNSソリューションを使うと、ドメインの権威DNSサーバーがクライアントの応答を形成するとき、クライアントの位置を考慮して、最も近いデータセンターにクライアントを送信します。

NGINX PlusとGeoDNSは、グローバルに分散したアプリケーションを構成します

AmazonのRoute 53など、利用可能なGeoDNSソリューションはたくさんあります。
それらをNGINX Plusと組み合わせることで、グローバルに分散した、スケーラブルな
アプリケーションを作成できます。
上記の図では、GeoDNSはカリフォルニアのユーザーを
米国西部データセンターに誘導し、
ニューヨークのユーザーは
米国東部データセンターに誘導しています。各データセンター内で、
NGINX Plusは入ってくるトラフィックをアプリケーションサーバーに分散します。

 

結論

クラウドへの移行を検討している場合は、アプリケーション・デリバリー戦略も再考することが
理にかなっています。ハードウェアADCは、オンプレミス構成ではうまくいくかもしれませんが、
クラウドアーキテクチャの一部にすることはできません。大部分のハードウェアADCベンダーは
自社アプライアンスの仮想バージョンを提供していますが、不必要に高価で、クラウドでは
必要のない機能にコストを支払うことになります。さらに、仮想バージョンは通常、一部の
クラウドしかサポートされませんが、NGINX Plusなら、クラウドを選ばず実行できます。

NGINX Plusは、クラウド上で動作するように設計されたソフトウェアADCです。
仮想ハードウェアADCのコストのほんの一部で利用できますが、実際に必要とされるすべての機能を備えています。

クラウドアーキテクチャでNGINX Plusがどう最適なのか、ご自分で確認されたいですか?
すぐに
無料の30日間のトライアルをお試しください。