ロードバランシング

Kubernetesによる負荷分散のための コミュニティ版NGINXおよびNGINX Plus Ingress Controller

この記事はNGINX,Inc.のブログ記事「NGINX and NGINX Plus Ingress Controllers for Kubernetes Load Balancing」を和訳した内容となります。

URL: https://www.nginx.com/blog/nginx-plus-ingress-controller-kubernetes-load-balancing/

マシンのクラスタ全体で、コンテナ内のマイクロサービスアプリケーションを実行して管理することは、困難な作業です。Kubernetesは、コンテナオーケストレーションのための強力なソリューションを提供することで、チャレンジを達成するのに役立ちます。フォールトトレランス、自動スケーリング、ローリングアップデート、ストレージ、サービスディスカバリ、ロードバランシングなどのいくつかの重要な機能が含まれています。

このブログ記事では、コミュニティ版NGINXまたはNGINX PlusIngressの使い方について説明します。Ingressは、HTTPトラフィック用のKubernetesロードバランシングフレームワークを内蔵しています。Ingressでは、Kubernetesクラスタ内のサービスへの外部トラフィックのルーティングを制御するルールを設定できます。Ingress Controllerは、クラスタに展開しKubernetesとロードバランサを統合するソフトウェアで、任意のロードバランサを選択できます。ここでは、Ingressを備えたマイクロサービスアプリケーションと、NGINX PlusおよびNGINX用で提供されているIngress Controllerのロードバランシングを設定する方法を説明します。

[編集者 – 以前はNGINXとNGINX Plus用に別々のControllerがありましたが、
現在両方のIngress Controllerに統合しました。]

このブログ記事では、KubernetesとIngressのHTTPロードバランシングのみを調査します。他のロードバランシングオプションの詳細については、ブログでLoad Balancing Kubernetes Services with NGINX Plusを参照してください。

注:このブログ記事で説明されている手順の詳細は、GitHubリポジトリを参照してください。この投稿はすべての必要なステップを追うものではなく、それらの指示へのリンクを提供します。

コミュニティ版NGINXおよびNGINX PlusのIngress Controllers

サンプルアプリケーションをデプロイしてロードバランシングを設定する前に、ロードバランサを選択し、対応するIngress Controllerをデプロイする必要があります。

Ingress Controllerは、特定のロードバランサとKubernetesを統合するソフトウェアです。私たちはコミュニティ版NGINXとNGINX Plusの両方のIngress Controllerを開発しました。GitHub リポジトリで利用できます。他にはサードパーティ製のものもあります。詳細については、KubernetesのGitHubリポジトリのIngress Controllersページを参照してください。

クラスタにNGINXまたはNGINX Plus Ingress Controllerを導入する方法の詳細については、GitHubリポジトリを参照してください。

サンプルマイクロサービスアプリケーション

サンプルアプリケーションは、それぞれが別々にデプロイされた複数のサービスで構成された典型的なマイクロサービス Webアプリケーションです。cafeと呼ばれるこのアプリケーションは、coffeeサービスを通じてteacoffeeを注文することができます。飲み物の好みをHTTPリクエストのURIで指定します。/ teaで終わるURIは、/ coffeeで終わるteaとURIで終わります。またアプリケーションへの接続はSSL / TLSで保護する必要があります。

以下の図は、NGINX Plusロードバランサがクライアントのリクエストを適切なサービスにルーティングする重要な役割を担い、SSL / TLSによるクライアント接続のセキュリティを確保しながら、アプリケーションを概念的に示しています。

クラスタにアプリケーションをデプロイするには、GitHubリポジトリの指示に従います。

IngressによるKubernetesロードバランシングの設定

私たちのcafeアプリでは、2つの機能を提供するためにロードバランサが必要です。

  • 要求URIに基づくルーティングパスベースルーティングとも呼ばれる)
  • SSL / TLSターミネーション

Ingressでロードバランシングを設定するには、Ingressリソースでルールを定義します。ルールは、外部トラフィックをクラスタ内のサービスにルーティングする方法を指定します。

リソースでは、それぞれ異なるドメイン名の複数の仮想サーバーを定義できます。仮想サーバーは、通常クラスタに展開された単一のマイクロサービスアプリケーションに対応しています。各サーバーについて、次のことができます。

  • 複数のパスベースのルールを指定します。リクエストURIに基づいて、
    アプリケーション内の異なるサービスにトラフィックが送信されます。
  • SSL / TLS証明書と鍵を参照してSSL / TLS終了を設定します。

Ingressの詳細については、Ingressのドキュメントページをご覧ください

cafeアプリ(cafe-ingress.yaml)のIngressリソースは次のとおりです。

1. apiVersion: extensions/v1beta1
2. kind: Ingress
3. metadata:
4.  name: cafe-ingress
5. spec:
6.  tls:
7.  – hosts:
8.    – cafe.example.com
9.    secretName: cafe-secret
10.  rules:
11.  – host: cafe.example.com
12.    http:
13.      paths:
14.      – path: /tea
15.        backend:
16.          serviceName: tea-svc
17.          servicePort: 80
18.      – path: /coffee
19.        backend:
20.          serviceName: coffee-svc
21.          servicePort: 80

行ごとに調べると、次のようになります。

  • 4行目では、リソースのcafe-ingressの名前を付けます。
  • 6-9行目で、SSL / TLS終了を設定します。
    • 9行目では、Secretリソースをその名前cafe-secretで参照しています。このリソースにはSSL / TLS証明書とキーが含まれており、Ingressリソースの前に展開する必要があります。
    • 8行目で証明書とキーをcafe.example.com仮想サーバーに適用します。
  • 11行目では、ドメイン名cafe.example.comを持つ仮想サーバーを定義します。
  • 13行目から21行目では、2つのパスベースのルールを定義しています。
    • 14-17行目で定義されているルールは、tea-svcという名前でデプロイされている、Tea Serviceのコンテナに/ tea URI とともにリクエストを分散するようにロードバランサに指示します。
    • 18行目〜21行目で定義されているルールは、クラスタ内にcoffee-svcという名前でデプロイされているCoffee Service
      コンテナに、/ coffee URI とともにリクエストを分散するようロードバランサに指示します。
    • どちらのルールも、対応するサービスのポート80に要求を分散するようにロードバランサに指示します。

IngressおよびSecretリソースをクラスタに導入する方法の詳細については、GitHubリポジトリを参照してください。

アプリケーションのテスト

NGINX Plus Ingress Controller、アプリケーション、Ingressリソース、およびSecretリソースを導入すると、アプリケーションをテストできます。

/ tea URIでteaをリクエストすると、ブラウザーにはTea Serviceによって生成されたページが表示されます。

teacoffeeのサービスが実際に飲み物を提供するだけではなく、これらサービスを
起動してコンテナやあなたのリクエストの詳細についての情報が欠損していないことが望ましいです。これらには、コンテナのホスト名とIPアドレス、要求URI、およびクライアントのIPアドレスが含まれます。ページを更新するたびに、別のコンテナから応答が返されます。

また、NGINX Plus ライブアクティビティモニタリングダッシュボードに接続して、NGINX Plusとアプリケーションの各コンテナからのリアルタイム負荷分散メトリックを参照することもできます。

Ingress Controllerの拡張

Ingressは、基本的なHTTPロードバランシング機能を提供します。ただし、アプリケーションのロードバランシング要件が複雑でIngressでサポートされていないことがよくあります。これらの要件の一部に対応するため、Ingressコントローラにいくつかの拡張機能を追加しました。このようにして、Kubernetesリソースを使用してロードバランサを構成すること(ロードバランサを直接構成するのではなく)もでき、かつ高度なロードバランシング機能を活用することもできます。

利用可能な拡張機能の完全なリストについては、GitHubリポジトリを参照してください。

さらに、Kubernetesのリソースを使用してConfig Mapsリソースまたは注釈を使用してNGINX設定カスタマイズするメカニズムを提供します。たとえば、proxy_connect_timeoutまたはproxy_read_timeoutディレクティブの値をカスタマイズすることができます。

ロードバランシングの要件がIngressおよび拡張機能でサポートされている要件がある場合は、Ingressコントローラを使用しないNGINX Plusをデプロイおよび設定するための方法を提案します。私たちのブログではNGINX Plusを使ってKubernetesサービスのロードバランシングを読むことができます。

ControllerによるNGINX Plusの利点

NGINX Plus Ingress ControllerはNGINXで得られるものに加えて、以下の利点を提供します。

  • 高度に動的な環境での安定性  – Ingressを介して公開されているサービスのPod数が変更されるたびに、Ingress Controllerは変更を反映するためにNGINXまたはNGINX Plusの設定を更新する必要があります。コミュニティ版のNGINXでは、設定ファイルを手動で変更して設定をリロードする必要があります。しかし、NGINX Plusを使用すると、オンザフライで再構成 APIを使用して、設定ファイルをリロードせずに設定を更新できます。これにより、構成リロードが頻繁に発生する場合に発生する可能性のあるメモリ使用量の増加やシステム全体のオーバーロードを防ぐことができます。
  • リアルタイム統計  – NGINX Plusは高度なリアルタイム統計を提供し、APIまたは内蔵ダッシュボードのいずれかにアクセスできます。これにより、NGINX Plusとアプリケーションがどのように実行されているかを知ることができます。
  • セッション・パーシステンス  – セッション・パーシステンスを有効にすると、NGINX Plusは同じクライアントからのすべての要求が常にスティッキクッキー方式を使用して同じバックエンドのコンテナに渡されるようにします。

概要

Kubernetesには、組み込みのHTTPロードバランシング機能があり、外部トラフィックをIngressでクラスタ内のサービスにルーティングします。コミュニティ版NGINXとNGINX Plusは、Kubernetesロードバランシングと統合され、Ingress機能を完全にサポートし、拡張ロードバランシング要件をサポートする拡張機能も提供します。

NGINX PlusとIngress Controllerを試すには、今すぐ無料の30日間のトライアル
開始するか、ライブデモをご連絡ください

***************************************************************************

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

***************************************************************************

NGINXで行うTCP / UDPロードバランシング

この記事はNGINX,Inc.のブログ記事「TCP/UDP Load Balancing with NGINX: Overview, Tips, and Tricks」を和訳した内容となります。

URL:https://www.nginx.com/blog/tcp-load-balancing-udp-load-balancing-nginx-tips-tricks/

この投稿は、nginx.conf 2016で発表されたNGINX,Inc.のKonstantin Pavlovによるプレゼンテーションを再構成しています。完全版のプレゼンテーションはYouTubeでご覧いただけます。

 

 

イントロダクション

1:00

TCPロードバランシング

1:53

UDPロードバランシング

3:31

TCP / UDPロードバランサーのチューニング

6:18

TCP / UDPアクティブヘルスチェック

8:53

アクセス制御と制限

9:43

クライアントのIPアドレスをバックエンドに渡す

11:46

TLSTermination

12:32

TLS再暗号化

13:05

TLSラッピング

13:20

ロギング

14:40

より良いロギング

16:25

変数

19:17

nginScriptを使用したTCP / UDPロードバランシングの拡張

20:45

nginScriptによるTCP / UDPペイロードのフィルタリング

29:26

TCP / UDP nginScript:パフォーマンス

31:48

TCP / UDPロードバランサーの将来

33:04

関連する記事

33:34

ありがとうございました

 

イントロダクション

Konstantin Pavlov:私の名前はKonstantin Pavlovです。私はNGINX,Inc.のシステムエンジニアで、プロフェッショナルサービス部門で働いています。このセッションでは、NGINXで使用しているTCPおよびUDPロードバランサーの機能について説明します。

 

streamモジュールは2年前、NGINX 1.9で導入されました。それ以来、NGINXのHTTPロードバランシングスタックに加わり、成熟して実績のあるソリューションとなっています。

 

これから、サポートされているロードバランシング方式、SSLおよびTLSサポートの概要をご説明し、アクティブヘルスチェックなど、NGINX Plusが提供する追加機能についてお話ししたいと思います。

 

また、いくつかの設定をお見せしたいと思いますが、最小限のものとそうでもないものです。単純なWebアプリケーションファイアウォールを構築する方法など、streamモジュールとnginScriptを使うためのコツをご紹介したいと思います。

 

1:00 TCPロードバランシング

さっそく設定に行きましょう。

TCPロードバランシングは、非常にシンプルです。ご覧のとおり、upstreamブロックを定義しています。まず、NGINXのメインコンフィギュレーションファイルでstreamブロックを定義し、ドメイン名に2つのMySQLバックエンドを持つupstreamブロックを定義しています。

 

その後にserverブロック内に、listenソケットを定義してTCPプロトコルをlistenし、私の定義したバックエンドへプロキシしています。とても簡単でシンプルですね。ご覧のとおり、NGINXのHTTP設定と非常によく似ています。

 

後のスライドでは、より洗練された構成をいくつか紹介します。

 

1:53 UDPロードバランシング

UDPロードバランシングも、NGINXに追加しました。主な用途として2つあり、それは
高可用性とUDPサービスのスケーリングに役立ちます。

 

UDPデータグラムがNGINXに入ると、NGINXはパッシブヘルスチェックでバックエンドサービスの健全性を監視しますが、NGINX Plusの場合は、アクティブヘルスチェックを使います。そして、データグラムの接続が生きているサーバーに転送します。

 

この構成で、いくつかのDNSロードバランシングを行ってみます。2つのバックエンドを持つupstreamブロックを定義しました。このlistenディレクティブはTCPの設定と似ていますが、ここではこのudpパラメータを使って、NGINXにこのポートのUDPをlistenするよう指示しています。

 

注意すべき点は、NGINX UDPロードバランシングが、バックエンドから1つ以上の応答を受けるよう構築されていることです。DNSの場合は、リクエストが1つ、レスポンスが1つです。

 

また、UDPロードバランサーからのログを調べられるように、エラーログを定義しました。

 

3:31 TCP / UDPロードバランサーのチューニング

もちろん、TCPとUDPロードバランサーを微調整することもできます。

 

前回のスライドでは、重み付きラウンドロビン(Weighted Round Robin)ロードバランシングアルゴリズムを使う、デフォルトのupstream設定のみをお見せしました。でも、他にも選択肢があります。リモートアドレスのハッシュに基づくロードバランシングは、たとえば、IPアドレスに基づいてセッション親和性(永続性)を有効にします。または、最小接続数(最小接続アルゴリズム)を使うこともできます。その場合、NGINXはUDPデータグラムまたはTCP接続を、アクティブ接続が最も少ないサーバーに転送します。

 

NGINX Plusでは、最小時間ロードバランシング方式も使用できます。接続時間、またはバックエンドから最初のbyte を受信する時間や、最後のbyte (つまり応答全体ということです)を受信するまでの時間をもとに、最も速いサーバーを選択することができます。スライドの右側には、そのメソッドを実装する設定方法を載せています。

 

HTTPロードバランサーと同様に、サーバーごとのパラメータを定義できます。たとえばweight、サーバーがダウンしているとみなす条件としての失敗した接続の最大数や、それらの失敗した接続が発生する時間範囲などです。また、サーバーを明示的にダウンまたはバックアップサーバーとしてマークすることもできます。

 

NGINX Plusでは、バックエンドへの最大接続数を設定することもできます。この例では、接続数が20を超えている場合、NGINX Plusは新しい接続を作成しません。このslow_startパラメータは、サーバーの重みを0から公称値まで徐々に移動させるようにNGINXに指示します。これは、バックエンドで何らかのウォーミングアップが必要な場合などに便利です。起動するとすぐ、多数の新しいリクエストが流されることはありません。

このserviceパラメータでDNS SRVレコードを照会することによって、アップストリームグループを設定することもできます。この場合、resolveパラメータも含める必要があります。この構成では、バックエンドサーバーのIPアドレスが変更された場合や、サービスのDNSに新しいエントリがある場合も、NGINXを再起動する必要がありません。

 

6:18 TCP / UDPアクティブヘルスチェック

前のスライドで触れたように、max_failsパラメータを使ってパッシブヘルスチェックを有効にしましたが、NGINX Plusでは、アクティブで非同期のヘルスチェックも利用できます。

 

複数のIMAPサーバーの前にロードバランサーがあるとします(スライドには1つしかありませんが、それ以上のものは適合しないためです)。今、IMAPサーバーがあるとして、IMAPサーバーのステータスは実際には組み込みのHTTPサーバーに公開されているとしましょう。

 

health_checkディレクティブのportパラメータを使用して、ヘルスチェックの送信時にNGINXが通常のIMAPポートではなく、別のポート(ここでは8080)に接続するよう指示します。このmatchブロックでは、NGINXが送信するリクエストと、受け取る特定のレスポンスを定義しています。ここでは、このホストのステータスコードを要求するだけですが、ヘルスチェックをパスするには、コードは200 OKである必要があります 。

 

またhealth_check_timeoutは低い値に設定していますが、これはヘルスチェックがタイムアウトしてサーバーをダウンとマークするまでに、長時間をかけたくないためです。

 

もちろん、TCPとUDPの世界では、通常、平文のプロトコルを使用することはありません。たとえば、DNSのヘルスチェックを実装する場合は、16進数でエンコードされたデータを送る必要があります。

 

この特定の構成では、nginx.orgの DNS Aレコードを要求するペイロードをサーバーに送信します。ヘルスチェックを成功させるには、サーバーはexpectディレクティブで指定された16進数のIPアドレスで応答する必要があります。

 

8:53アクセス制御と制限

streamモジュールは、いくつかの点でHTTPモジュールと非常によく似ています。このモジュールを使うと、仮想サーバーにアクセスするユーザーを制御し、リソースの使用を制限することができます。

 

設定は、HTTP serverブロックとほぼ同じです。denyallowディレクティブを使って、 特定のIPアドレスを持つ、または特定のネットワーク上のクライアントに、サービスへのアクセスを許可することができます。limit_connおよびlimit_conn_zoneを使用して、サーバーへの同時接続数を制限できます。また、必要があれば、バックエンドサーバーとの間でダウンロードとアップロードの速度を制限することもできます。

 

9:43クライアントのIPアドレスをバックエンドに渡す

TCPとUDPのロードバランサーを使うときの最大の課題の1つは、クライアントのIPアドレスを渡すことです。ビジネス要件ではそれが必要かもしれませんが、おそらくプロキシはその情報を持っていません。もちろん、HTTPには非常に簡単な方法があります。基本的にはX-Forwarded-Forヘッダーなどを挿入するだけです。でも、TCPロードバランサーでは何ができるでしょうか?

 

可能な解決策の1つは、HTTPベースのPROXYプロトコルを使用することです。バックエンド側でproxy_protocolディレクティブを有効にすれば可能です。NGINXは基本的に、クライアントのIPアドレスとメッセージを受信するプロトコルを含むPROXYプロトコルで着信接続をラップし、バックエンドに渡しています。

 

これはもちろん、プロキシが受け渡す先のバックエンドも、PROXYプロトコルを理解していなければならないということでもあります。これが主な欠点です。バックエンドがPROXYプロトコルを解することを確認する必要があります。

クライアントのIPアドレスを渡す別の方法は、proxy_bindディレクティブとtransparentパラメータを使うことです。これはNGINXに、クライアントのIPアドレスを使用してバックエンドのソケットにバインドするように指示します。

 

残念なことに、この方法はNGINX側の設定だけでなく、Linux上でルーティングテーブルを設定し、IPテーブルを編集する必要もあります。一番大変なことは、ワーカープロセッサにスーパーユーザーまたはルートIDを使用させる必要があることです。セキュリティの観点から、これは最も避けたいことです。

 

11:46 TLS Termination

セキュリティに関して言えば、NGINXがStreamモジュールでTLS暗号化を処理する方法はいくつかあります。

 

最初の動作モードの1つはTLS Terminationです。listenディレクティブにsslパラメータを含めて構成し、HTTPロードバランサーと同じように、SSL証明書とキーを指定します。

 

proxy_sslディレクティブを使うと、NGINXはTLSを取り除いて(復号化して)、バックエンドに暗号化されていない接続を転送します。これは、たとえば非TLSアプリケーションにTLSサポートを追加するために使用できます。

 

12:32 TLS再暗号化

もう1つのモードは、接続を再暗号化することです。

 

基本的に、NGINXは特定のソケットをlistenし、着信リクエストを復号化し、バックエンドに送信する前に再暗号化します。

 

やり方は以下のとおりです。proxy_ssl onディレクティブを使ってバックエンドに対するTLS暗号化を有効にし、proxy_ssl_verify onでバックエンドを確認する必要があることを指定し、proxy_ssl_trusted_certificateで証明書の場所を指定します。 

 

13:05 TLSラッピング

もちろん、NGINXでTLSを使う別の方法は、TLS以外のポートでプレーンテキストのリクエストをlistenしている際、バックエンドへの接続を暗号化することです。

 

13:20ロギング

そして皆さん、ロードバランサーで何が起こっているのかを監視し、分析する必要があることと思います。

 

現在のリリース [注:この話の時点ではNGINX 1.11.3とNGINX Plus Release 10]では、予備的なログが用意されています。ログは上記で示された形で利用できますが、エラーログだけです。クライアントのIPアドレスとポート、およびサーバーが待機しているIPアドレスとポートが表示されます。

 

2つのケースそれぞれで、サーバーがバックエンドの1つに接続され、セッションが終了したことがわかります。クライアントとの間、およびアップストリームとの間で一定量のバイトを転送したことがわかります。UDPの場合とほとんど同じです。

 

ここで課題の1つは、NGINXのエラーログのログ形式を設定できなかったことです。私たちはNGINX Streamモジュールで何らかの変数をサポートする前にロギングを追加しました。そのため、非常に簡潔ですが、実際に拡張することができません。

 

14:40より良いロギング

幸いにも、私たちは最近Streamモジュールのアクセスログを有効にする機能を追加しました。現在のバージョンのNGINXとNGINX Plusでは、任意の方法でログを再構成できます。[注 – この機能は、この話の後の週にNGINX 1.11.4でリリースされたStream Logモジュールで実装されました。10月下旬にリリースされたNGINX Plus Release 11には含まれています] この方法で、監視またはログソフトウェアで最適に動作するよう設定ができます。これはデフォルトでは有効になっていませんが、NGINX stream設定ブロックでaccess_logディレクティブを指定するだけで済みます。

 

デフォルトでは、ログエントリはスライドの最後の行のように見えます。HTTPロギングと非常によく似ています。お使いのHTTPログ解析ツールで、それを解析できるものさえあるかもしれません。クライアントのIPアドレス、ローカル時刻、およびプロトコル(TCPまたはUDPのいずれか)が提供されます。接続ステータスについては、HTTPからステータスコードを再利用することにしました。HTTPでNGINXを使っていた人なら、皆さんそれらに精通しているからです。(ここで200は成功したTCP応答を示します。)

 

次に、クライアント[158]に送信され、クライアント[90]から受信したバイト数を記録します。最後に、セッションに要した全体の時間と、接続に使われたバックエンドのIPアドレスとポートであるアップストリームアドレスを取得します。

 

もちろん、自分で必要なログフォーマットを定義し、NGINXで使用可能な変数を再利用することができます。

 

16:25変数

変数といえば、最近、streamモジュールで変数を作成することが可能になりました。これにより多くの方法で設定をプログラムできるようになり、streamモジュールの可能性が大幅に広がります。

 

Mapモジュールを使うと、他の変数に基づいて変数を構築できます。これは、HTTPブロックとほぼ同じです。Geoモジュールを使えば、クライアントのIPアドレスまたはネットワークに基づいて変数を作成することができます。

 

また、MaxMind GeoIP地理データを使って、変数を設定できます。クライアント分割してA / Bテストを行えますが、基本的には、リクエストを送る際は異なるバックエンドを定義しています。そしてもちろん、変数を設定し、後からnginScriptとjs_setディレクティブで使用できます。これについては後で説明します。

 

こちらが、変数を使った単純なエコーサーバーの例です。

 

NGINXに、localhost port 2007上のTCPトラフィックと、同じポート上でIPv6上のUDPトラフィックをlistenするように指示します。NGINXには、クライアントのIPアドレスを$remote_addr変数で返させます。

 

続いて私のラップトップでnetcatを使って、NGINXサーバーに接続します。ご覧のように、クライアントのアドレスを返しています。

TCPロードバランサーのstreamモジュールで変数を使う別の方法は、GeoIPです。

 

GeoIPモジュールは、特定の変数に投入されます。GeoIPモジュールまたはproxy_passディレクティブで接続を制限することが出来ます。

 

私は今、リモートアドレスに基づいてクライアントを分割しています。したがって、接続の半分が「機能テスト」バックエンドに送られます。そうすれば、機能がうまく動作しているかどうかを確認できます。残りはプロダクションバックエンドに送られます。

 

変数のその他の使用例としてこれに限られているわけでは無いですが、前にご紹介したproxy_bind も挙げられます。またproxy_ssl_nameディレクティブで使えます。

NGINXに、バックエンドへのTLS SNI接続にサーバー名を設定するよう指示します。

あとはもちろん、以前のスライドでご紹介したアクセスログもですね。

 

19:17 nginScriptを使用したTCP / UDPロードバランシングの拡張

nginScriptを使用すると、この設定スニペットは他のスライドとほとんど同じです。レスポンスには、クライアントのリモートアドレスが表示されます。

 

このnginx.confでは、ダイナミックストリームのnginScriptモジュールを読み込みます。streamブロックでは、特別なjs_includeディレクティブを使います。これはNGINXをstream.jsにアクセスさせますが、ここには私たちが使用するすべてのJavaScriptコードが含まれています。

 

このserverブロックでは、js_setディレクティブを使用して$foo変数の値を設定します。これは、JavaScript関数の戻り値です。

 

最後に、TCP接続のその値をクライアントに返します。

 

stream.jsに、foo()と呼ばれる関数を定義します。「s」はデフォルトでは、その関数をパススルーするセッションオブジェクトです。何か起こっているかどうかを見るためにちょっとロギングをしてみましょう。ストリームオブジェクト内の組み込み変数[s.remoteAddress] として利用可能なリモートアドレスを返しています。

 

20:45 nginScriptによるTCP / UDPペイロードのフィルタリング

 

前のスライドで紹介した内容は、かなりシンプルでした。それとは別に、NGINXは、近々ペイロードのフィルタリングができるようになる予定です。ロードバランシングに処理されるデータを実際に調べて判断し、それに応じてトラフィックを変更することができるようになります。ペイロードを変更することができます。

 

nginScriptを使って、単純なWebアプリケーションファイアウォールを実装する方法を、簡単なデモでお見せします。ここで設定とJavaScriptを確認いただけます。

 

では、デモを見てみましょう。

 

注: 下のビデオは、デモの最初の部分を21:50にスキップしています。

 

[埋め込みビデオのデモ]

29:26 TCP / UDP nginScript:パフォーマンス

JavaScriptで何らかの処理を行っている場合、パフォーマンスが低下します。

ここではNGINXでワーカープロセスを1つ使いましたが、HTTPバックエンドがロードバランサーで処理される典型的なシナリオでは、1秒あたりのリクエストでパフォーマンス低下を観測しました。最初の2行はベースラインシナリオです。

 

ご覧のとおり、JavaScriptを有効にするだけで、パフォーマンスが約10%低下しました。NOOPはJavaScriptのマシンに関数ハンドラを渡しているものの、実際には何もしていないことを意味します。単純に関数から戻ります。JavaScriptコードを呼び出していますが、何もしません。これだけで、すでに約10%のパフォーマンス低下が生じています。

 

正規表現を使用すると状況が悪化し、結果、パフォーマンスが30%低下します。Webアプリケーションのファイアウォールは整備されたフィルタリングを行っていますが、それらは遅いです。ある程度予測されることではありますが、それにしても本当に遅いですね。

 

これらの数値は2010年のXeonサーバーの数値ですので、おそらく皆さんの状況とはだいぶ異なるでしょうが、全体の割合は似るはずです。

 

31:48 TCP / UDPロードバランサーの将来

 

スライド内  「streamモジュールはかなり新しいので、フィードバックや、皆さんの用途で価値があると思われる機能のリクエストをお待ちしています」

将来的に、NGINX streamモジュールとUDP / TCPロードバランシングに何を期待されますか?

 

現時点では、私たちは実際可能性を模索している最中です。あなたが実現したいと思うアイデアや機能があれば、ぜひ一緒に議論させていただきたいと思います。

 

直近でお約束できるものは以下の通りです。クライアントからのTLS SNIを解析し、ご利用いただける変数、たとえば、proxy_pass内にTLS接続の内容を確認できるようにするものなど、をいくつか用意します。SNIでは、要求されたサーバーのサーバー名を受け取ります。要望があれば、それを特定のバックエンドに転送することができます。

 

その次は、リスニング側でのPROXYプロトコルのサポートです。PROXYプロトコルのリモートアドレスのような変数も設定します。それらは近い将来に追加される予定です。

 

現在または今後予定されているストリームロードバランサーの機能では、カバーされていない特定のユースケースがある場合には、ぜひ私たちにお知らせください。

 

33:04関連する記事

TCPとUDPロードバランシングについては、当社のウェブサイトにいくつかのリソースがあります。管理者ガイド、ブログ記事がいくつか、またこれからも追加される予定です。

 

nginScriptのドキュメントについては、ソースコードとREADMEファイルを確認してください。 [注- README ファイルは、標準的なリファレンスドキュメントと一連のブログ記事に置き代わりました。]

 

33:34ありがとうございました

すべての設定スニペットとこれらのスライドをGithub入手できます。

 

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

本ブログサイトの”ホワイトペーパー一覧”ページに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 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日間のトライアルをお試しください。

F5 BIG-IP LTMからNGINX Plusへのロードバランサー構成の移行

※本記事はNGINX,Inc.のブログ記事「Migrating Load Balancer Configuration from F5 BIG-IP LTM to NGINX Plus」を和訳した内容となります。
【URL】
https://docs.nginx.com/nginx/deployment-guides/f5-configuration-migrating-nginx-plus/

NGINX Plusなら、従来のハードウェアベースのアプリケーション デリバリー コントローラー(以下ADCと表記)を柔軟に置き換えられます。NGINX Plusは、ベアメタル、仮想マシン、コンテナ、オンプレミスに、パブリック/プライベート/ハイブリッドクラウドなど、およそどこにでもインストール可能な小さなソフトウェア・パッケージですが、旧来のADCと同レベルのアプリケーション配信、高可用性、そしてセキュリティーを実現します。このガイドでは、F5 BIG-IPローカルトラフィックマネージャ(以下LTMと表記)の設定を、NGINX Plusソフトウェア・アプリケーション配信プラットフォームに移行する方法を説明し、迅速な移行を実現するのに、最も一般的に使われている機能と設定をお伝えします。

 

NGINX PlusとBIG-IP LTMはどちらも、完全なリバースプロキシとロードバランサーとして機能するため、クライアントはアプリケーションとしてロードバランサーを認識し、バックエンドサーバーはクライアントとしてロードバランサーを認識します。これにより、トラフィックの優れた制御ときめ細かな取り扱いが可能になります。このガイドでは、基本的な負荷分散に重点を置いています。レイヤ7ロジックとスクリプトを使用した設定の拡張については、NGINXブログのレイヤ7ロジックの移行(英語)に関する記事を参照してください。コンテンツの切り替えやリクエストのルーティング、書き換え、リダイレクトなどの機能について取り上げています。

 

  • コミュニティ版NGINXとNGINX Plusについて
  • NGINX Plusデプロイメント・シナリオ
  • 前提条件
  • BIG-IP LTMのネットワーク概念をNGINX Plusにマッピングする
  • F5 BIG-IP LTMロードバランサー設定からNGINX Plusへの変換
    • 仮想サーバー
    • SSL / TLSオフロード(ターミネーションおよびプロキシ)
    • セッションの永続性
    • Keepalive接続
    • モニター(ヘルスチェック)
  • 変換されたロードバランサー構成のまとめ

コミュニティ版のNGINXとNGINX Plusについて

コミュニティ版のNGINXは、オープンソースのWebサーバー、リバースプロキシ、およびロードバランサーで、近年そのスケーラビリティにより普及してきています。当初、C10K問題(クライアント1万台問題:単一のWebサーバー上で10,000の同時接続を処理することができない問題)を解決するために作られましたが、その機能と性能で、多くの高性能サイトが頼る解決策となっています。今や、NGINXは世界で最もアクセスされている10万ウェブサイトの大部分で利用されています。(英語)

NGINX Plusは、コミュニティ版NGINXの商用サポート版です。完全なソフトウェア・ロードバランサー兼アプリケーション配信プラットフォームで、大規模なウェブアプリケーションの構築には欠かせない多くのエンタープライズ対応機能があり、コミュニティ版NGINXの能力を拡張しています。

 

 

NGINX Plusデプロイメント・シナリオ

構造的に言えば、NGINX Plusは設置場所と機能の点で、従来のADCとは異なります。一般的なハードウェアベースのADCは、通常ネットワークエッジに配置され、すべてのアプリケーショントラフィックのフロントドア・エントリーポイントとして機能します。ネットワークに入ってくるトラフィックの100%を処理するという大きな負担を想定して、大規模なハードウェアADCがパブリックDMZとプライベートDMZにまたいで置かれることは珍しくありません。またこの環境下で、ADCがすべてのアプリケーション(セキュリティー、可用性、最適化、認証など)トラフィックにかかわる、すべての機能を担っていることもよくありますが、これには非常に大きく強力なハードウェアアプライアンスが必要になります。このモデルの欠点は、ADCが常にネットワークの「フロントドア」に固定されてしまっていることです。

 

インフラストラクチャーの更新や、アプリケーション配信に取り組む時、多くの企業がハードウェアのエッジに置かれたADCの機能を削ぎ落とし、より分散したアプリケーションモデルに移行しています。旧来のハードウェアADCはすでにネットワークエッジに位置しているため、すべての入力トラフィック管理を引き続き処理し、アプリケーショントラフィックを種類ごとに適切なNGINX Plusインスタンスに誘導できます。NGINX Plusは各アプリケーションタイプのトラフィックを処理して、オンプレミスでもオフプレミスでもネットワーク全体に対し、アプリケーション中心のロードバランシングと高可用性を実現します。NGINX Plusはアプリケーションの近くに配置され、各アプリケーションタイプに固有のすべてのトラフィックを管理できます。

NGINX PlusはBIG-IP LTMの後ろで稼働し、アプリケーショントラフィックを処理します

また、ネットワークエッジに固定された、ハードウェアADCアプライアンスを完全にNGINX Plusに置き換え、そこで同レベルのアプリケーション配信を実現した企業もあります。


NGINX Plus
でハードウェアADCを完全に置き換え、ネットワークに入るすべてのトラフィックを処理することができます

前提条件

このガイドは、F5 BIG-IP LTMの概念とCLI設定コマンドを知っていることを前提としています。基本的なNGINXソフトウェアの概念とディレクティブの知識に役立ちます。各ドキュメンテーションへのリンクは以下の通りですが、そのガイドではNGINX Plusについて詳細な説明はしていません。

 

F5 BIG-IP LTMのネットワーク概念をNGINX Plusにマッピングする

ネットワーク・アーキテクチャー

F5 BIG-IP LTMネットワーキングとロードバランサーの設定をNGINX Plusに移行するとき、F5のコンセプトやコマンドを、NGINX Plusの構文に直接変換してみたくなるかもしれません。しかし、大概は不満な結果に陥ります。理由としては、この2製品はどのようにネットワークやアプリケーショントラフィックを捉え、処理するかという点で、いくつかの領域であまり一致していないからです。相違点を理解し、移行を行う際にはその点を覚えておくことが重要です。

 

F5は、ネットワークを2つの部分に分割します。つまり、管理ネットワーク(管理プレーンまたは制御プレーンと呼ばれます)とアプリケーショントラフィック・ネットワークデータプレーンと呼ばれます)です。従来のアーキテクチャーでは、管理ネットワークはトラフィックネットワークから分離され、別の内部ネットワークを介してアクセス可能であり、アプリケーションネットワークは公衆ネットワーク(または別のアプリケーションネットワーク)に接続されます。これには、2種類のトラフィックのそれぞれに別々のネットワーク構成が必要です。

 

BIG-IP LTMアプライアンスはデュアルプロキシ環境であり、データプレーントラフィックも2つの異なるネットワークに分かれていることを意味します。つまり、クライアントリクエストがBIG-IP LTMに入ってくるクライアント側のネットワークと、リクエストがアプリケーションサーバーに送信されるサーバー側のネットワークです。BIG-IP LTMには通常、各ネットワークを処理するために2つのネットワークインターフェースカード(以下NICと表記)が必要です。

 

しかし、BIG-IP LTMのアプライアンスで、データプレーンをシングルスタックプロキシアーキテクチャに結合し、1つのNIC上にクライアントとサーバーのネットワークをまとめることは可能です。これは、トラフィックがBIG-IP LTMデータプレーンに入り、同じ仮想NICを介して出てくるクラウド環境では、非常に典型的なアーキテクチャーです。ネットワーク・アーキテクチャーにかかわらず、ロードバランシングと同じ基本原理が適用され、以下で説明する構成はどちらのアーキテクチャーレイアウトでも機能します。

 

NGINX Plusは、以下の2つの似たアーキテクチャーで機能することができます。ホストデバイスで使用可能な1つのNICに複数のIPサブネット(「/(プレフィックス)」 または「VLAN」で分割)をバインドする方法か、複数のNICをインストールし、それぞれを固有のクライアントおよびサーバーネットワークに使う、または複数のクライアントネットワークと複数のサーバー側のネットワークをインストールする方法です。これは本質的に、BIG-IP LTMアプライアンスがどのように機能するかと同じです。通常、仮想NICにトランク接続またはバインドできる複数のNICが搭載されています。

 

ネットワーキングの概念の定義

基本的なF5 BIG-IP LTMネットワーク構成では、管理およびデータプレーンのIPアドレスを指定するだけで済みますが、BIG-IP LTMアプライアンスを含むより複雑なネットワーク環境を管理するには、いくつかの追加の概念が必要です。これらのコンセプトはすべて

簡単に簡略化が出来、NGINX Plusインスタンスにマッピングできます。BIG-IP LTMの主なネットワーキング概念で、NGINX Plusと関連するものは以下のとおりです。

 

  • Self IPアドレス– 特定のVLAN上の着信クライアント側データプレーントラフィックをlistenするプライマリインターフェース。これは、そのVLANまたはVLANグループに関連付けられた特定のNIC上の特定のIPアドレスまたはサブネットです。

 

NGINX Plusでは、Self IPアドレスがプライマリホストインターフェースに最も直接的にマップしますが、これはNGINX Plusがトラフィックプレーンのアプリケーションデータを管理するために使われるものです。一般的には、NGINX Plusは管理とデータトラフィック制御に基盤となるOSネットワーキングを利用しているため、Self IPアドレスはNGINX Plusデプロイメントで必要な概念ではありません。

 

  • 管理IPアドレス:ポートペア– BIG-IP LTMアプライアンスのIPアドレス:ポートの組み合わせは、GUIに加え、またはリモートSSHアクセスを介して管理するために使用されます。NGINX Plusに相当するのは、LinuxホストのIPアドレスで、通常はプライマリホストインターフェースです。アプリケーショントラフィックからリモートアクセスを分離する必要がある場合は、NGINX Plusが実行されているLinuxホストへの管理アクセスに別々のIPアドレスやNICを使用することは可能ですが、必須ではありません。

 

  • 仮想サーバー– BIG-IP LTMが、負荷分散されたアプリケーションのパブリック送信先IPアドレスとして使用するIPアドレス:ポートの組み合わせ。これは、例えばフロントエンド・アプリケーションのドメイン名と関連付けられている仮想サーバーのIPアドレス部分と、サービスに関連付けられているポート(HTTPアプリケーションの場合はポート80など)です。このアドレスは、クライアントリクエストと、フェールオーバーの際にはプライマリデバイスからセカンダリデバイスへのシフトを処理します。

 

NGINX Plusの仮想サーバーは、serverブロックを使用して設定されます。serverブロック内のlistenディレクティブは、クライアントトラフィックのIPアドレスとポートを指定します。

 

  • プールノードリスト– プールは、それぞれが同じアプリケーションまたはサービスをホストするバックエンドノードの集合であり、相互に入ってくる接続の負荷分散が行われます。プールは仮想サーバーに割り当てられているため、新しいリクエストが仮想サーバーに入ってくると、BIG-IP LTMは使用するバックエンドアプリケーションを認識できます。さらに、BIG-IP LTMはノードリストという用語で、異なるサービスの配列を指しますが、これはすべて同じトラフィックプロトコルを使用し、同じIPアドレスでホストされているが、異なるポート番号でlistenするものです(たとえば、168.10.10:8100,192.168.10.10:8200、および192.168.10.10:8300で3つのHTTPサービスなど)。

NGINX Plusは、BIG-IP LTMプールおよびノー​​ドリストの概念を、upstream構成ブロックに表示することで記述を統一しました。またそこで、バックエンドサーバーのグループにトラフィックを転送する、仮想サーバーのロードバランシングとセッションパーシスタンス(永続性)の方法も定義しています。NGINX Plusはノードリストの概念を必要としません。標準的なupstreamブロック設定は、同一IPアドレス上の複数サービスにとても簡単に対応できるためです。

 

これらのネットワーキングの概念に加えて、BIG-IP LTMからNGINX Plus に移行する際、考慮すべき2つの重要な技術カテゴリがあります。

 

  • iRules– iRulesは、独自のイベント駆動型のコンテンツスイッチング、およびトラフィック操作エンジン(TCLベース)で、BIG-IP LTMがデータプレーントラフィックのあらゆる面を制御するのに使います。iRulesは仮想サーバーに接続されており、URIに基づいたプールの選択、ヘッダーの挿入、JSESSIONIDとの親和性の確立など、あらゆるタイプのコンテンツの切り替えに必要です。iRulesはイベント駆動型で、新しいHTTPリクエストが仮想サーバーに送信されたり、サーバーがクライアントに応答を送信したりといった特定の基準が満たされたときに、新しい接続に対して起動するよう設定されています。

 

NGINX Plusは、コンテンツの切り替えやHTTPセッションの操作をネイティブに処理するため、ほとんどのコンテキストベースのiRulesとヘッダー操作などのHTTPトランザクションを処理するものを明示的に移行する必要はありません。ほとんどのコンテキストベースのiRulesは、serverおよびlocationブロックに変換することができ、NGINX Plusディレクティブおよびコンフィグレーションブロックで複製できない、より複雑なiRulesは、LuaまたはJavaScriptモジュールで実装できます。iRulesをNGINX Plusのコンテンツルールに変換する方法についての詳細は、NGINXブログのF5 iRulesおよびCitrixポリシーからNGINXおよびNGINX Plusへのレイヤ7ロジックの移行(英語)を参照してください。

 

  • 高可用性(ハイアベイラビリティ)– 概念的には、BIG-IP LTMとNGINX Plusは同じようにハイアベイラビリティ(以下HAと表記)を実現します。Active-Passiveロードバランサーの各組み合わせは、現在アクティブなインスタンスにマップされるフローティング “仮想” IPアドレス(以下VIPと表記)を共有します。アクティブなインスタンスに障害が発生すると、パッシブなインスタンスが肩代わりし、VIPを引き継ぎます。

 

BIG-IP LTMは、組み込まれたHAの仕組みを使い、フェールオーバーを行います。

 

オンプレミス構成では、NGINX Plusは別のソフトウェア・パッケージであるnginx-HA-keepalivedを使って、 VIPとNGINX Plusサーバーのアクティブ-パッシブのペアのフェールオーバープロセスを処理します。このパッケージはVIPを処理するVRRPプロトコルを実装しています。nginx-ha-keepalivedパッケージでは、限られたActive-Activeシナリオも可能です。

 

以下のように、クラウド環境でのNGINX Plusの高可用性ソリューションもあります。

 

(英語)

 

F5 BIG-IP LTMロードバランサー構成からNGINX Plusへの変換

 

 

F5 BIG-IP LTMには3つの設定方法があります。

  • GUI
  • CLI(カスタムのオンボックス トラフィック管理シェル[TMSH]ツール)
  • iControl API

 

最終的に、GUIまたはAPIを介して行うすべての変更はTMSH CLIコマンドに変換されるため、このガイドではTMSH CLIコマンドを使用します。また、(tmos.ltm)ロケーションからデバイスを設定していると仮定して、すべてのTMSHコマンドから、汎用コマンド変数であるltmを省略しています。

 

NGINX Plusを使用すると、設定は簡単なテキストファイルに保存されます。このファイルには、従来のオンボックスツールや設定管理、AnsibleChefPuppetなどのオーケストレーションツールを使って、直接アクセスまたは管理できます。

 

このガイドの例では、仮想サーバーを識別するのにIPアドレスだけを使っていますが、リクエストを処理する適切なserverブロックを選択する際、NGINX Plusは、listenするIPアドレスとポートの組み合わせに加え、Hostヘッダーを使用することもできます。ブロックにserver_nameディレクティブを含めて、Hostヘッダー内で一致する値を指定します。

 

server_nameディレクティブへのパラメーターのリストには、複数のホスト名、ワイルドカード、および正規表現を含めることができます。NGINX Plus の1つのserverブロックに、複数のserver_nameディレクティブと複数のリスニングIPアドレスとポートの組み合わせを含めることが可能です。IPアドレスの代わりにHost、およびserver_nameディレクティブを使う方法については、nginx.orgのサーバー名の項目をご覧ください。

 

注:このガイドのすべてのIPアドレスとオブジェクト名(upstreamブロック、仮想サーバー、プールなど)は単なる例ですので、代わりに、BIG-IP LTM設定の値を入力してください。

 

仮想サーバー

上記のように、仮想サーバーはBIG-IP LTMとNGINX Plus のプライマリーリスナーですが、それらを定義するための構成構文は全く異なります。ここでは、192.168.10.10の仮想サーバーがポート80でHTTPトラフィックをlistenし、test_pool上流グループにリストされている2つのバックエンドアプリケーションサーバー間で着信トラフィックを配信します。

 

BIG-IP LTM

#create pool test_pool members add {10.10.10.10:80 10.10.10.20:80}

#create virtual test_virtual { destination 192.168.10.10:80 pool test_pool source-address-translation { type automap } ip-protocol tcp profiles add { http } }

#save sys config

 

NGINX Plus

http {

upstream test_pool {

server 10.10.10.10:80;

server 10.10.10.20:80;

}

 

server {

listen 192.168.10.10:80;

location / {

proxy_pass http://test_pool;

}

#…

}

}

 

ディレクティブのドキュメント(英語):listenlocationproxy_passserver(仮想)server(アップストリーム)upstream

 

SSL / TLSオフロード(ターミネーションおよびプロキシ)

 

SSL/ TLSターミネーションの処理は、ADCロードバランサーの一般的な使用例です。F5 BIG-IP LTMは独自のSSL / TLS実装をしています。NGINX Plusはシステムライブラリに依存しているため、OpenSSLのバージョンはOSによって規定されています。BIG-IP LTMでは、各SSL / TLSキーと証明書の組合せでのプロファイルを仮想サーバーに対して発行(クライアント着信/発信のトラフィックを暗号化するためのクライアントプロファイルか 、バックエンドのトラフィックを暗号化するためのサーバープロファイルのいずれか、または両方)されています。NGINX Plusでは、ssl_certificateおよび、 ssl_certificate_keyディレクティブは仮想サーバーのserverブロックに含まれています。

 

ロードバランサーインスタンス上でSSL / TLSトラフィック処理を行ったり、ターミネーションやプロキシするには、以下の2つの方法があります。

 

  • SSL / TLSターミネーションを用いたロードバランサーとクライアントでは暗号化されたHTTPSセッションで通信します。銀行のオンライン取引サイトのような、セキュアなアプリケーションがSSL / TLS証明書でクライアントの暗号化を行うのと同じ方法です。ロードバランサーは、クライアントメッセージを復号化した後(安全な接続を実質的に終了する)、平文(暗号化されていない)のHTTP接続を介してメッセージをバックエンドサーバーに転送します。逆方向では、ロードバランサーはクライアントに送信する前にサーバー応答を暗号化します。SSL / TLSターミネーションは、ロードバランサーとバックエンドサーバーがセキュリティー保護されたネットワーク上にある場合、すなわち外部のエージェントが平文のバックエンドトラフィックを傍受して読み取る危険性がなく、またアップストリームアプリケーションのパフォーマンスが最優先の場合には良い選択肢です。
  • SSL / TLSプロキシアーキテクチャーでは、ロードバランサーはターミネーションモデルと同じように、クライアント側トラフィックを復号化します。ただその後、バックエンドサーバーに転送する前に再暗号化します。これは、サーバー側のネットワークが安全でない場合、またはバックエンドサーバーがSSL / TLSの暗号化・復号化に伴うコンピューティング負荷を処理できる場合には適しています。

 

BIG-IP LTM

  • SSL / TLSのターミネーションとプロキシ:SSL / TLS仮想サーバーとプールメンバーの作成

# create pool ssl_test_pool members add { 10.10.10.10:443 10.10.10.20:443 }

# create virtual test_ssl_virtual { destination 192.168.10.10:443 pool ssl_test_pool source-address-translation { type automap } ip-protocol tcp profiles add { http } }

# save /sys config

 

  • SSL / TLSターミネーション:クライアントSSL / TLSプロファイルの作成

 

  • # create profile client-ssl test_ssl_client_profile cert test.crt key test.key
  • # modify virtual test_ssl_virtual profiles add { test_ssl_client_profile }
  • # save /sys config

 

  • SSL / TLSプロキシ:サーバーSSL / TLSプロファイルの作成

 

# create profile server-ssl test_ssl_server_profile cert test.crt key test.key

# modify virtual test_ssl_virtual profiles add { test_ssl_server_profile }

# save /sys config

 

NGINX Plus

  • SSL / TLSターミネーション

upstream ssl_test_pool {

server 10.10.10.10:443;

server 10.10.10.20:443;

}

 

server {

listen 192.168.10.10:443 ssl;

ssl_certificate     /etc/nginx/ssl/test.crt;

ssl_certificate_key /etc/nginx/ssl/test.key;

 

location / {

proxy_pass http://ssl_test_pool;

}

}

 

  • SSL / TLSプロキシ

upstream ssl_test_pool {

server 10.10.10.10:443;

}

 

server {

listen 192.168.10.10:443 ssl;

ssl_certificate     /etc/nginx/ssl/test.crt;

ssl_certificate_key /etc/nginx/ssl/test.key;

 

location / {

proxy_pass https://ssl_test_pool;

proxy_ssl_certificate /etc/nginx/ssl/client.pem;

proxy_ssl_certificate_key /etc/nginx/ssl/client.key;

proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

proxy_ssl_ciphers HIGH:!aNULL:!MD5;

proxy_ssl_trusted_certificate /etc/nginx/ssl/trusted_ca_cert.crt;

proxy_ssl_verify on;

proxy_ssl_verify_depth 2;

}

}

 

ディレクティブのドキュメント(英語):listenlocationproxy_passproxy_ssl*server(仮想)server(アップストリーム)ssl_certificateおよびssl_certificate_keyupstream

 

セッション・パーシステンス(永続性)

F5 BIG-IP LTMとNGINX Plus は、アップストリームサーバー(BIG-IP LTMプールまたはNGINX Plus upstreamブロック)で、いずれもセッション永続性(親和性とも呼ばれます)を似たような方法で処理し、同等レベルの設定ができます。どちらも複数の形態のパーシステンスをサポートします。セッション・パーシステンスは、セッション状態を保持するアプリケーションには重要で、継続的デリバリーの用途に役立ちます 。

Cookieベースのセッション・パーシステンス

アプリケーションと互換性がある場合、NGINX Plusのフェールオーバーを簡単に設定して処理する方法の1つに、スティッキークッキーがあります。これはBIG-IP LTMのCookie Insertメソッドと同じように機能します。つまり、ロードバランサーはサーバーを表すクッキーを作成し、クライアントは各リクエストにクッキーを含め、ロードバランサー自体からセッショントラッキングを効果的に負荷軽減します 。

 

  • BIG-IP LTM:HTTP クッキー・パーシステンス

# create persistence cookie test_bigip_cookie cookie-name BIGIP_COOKIE_PERSIST expiration 1:0:0

# modify virtual test_virtual { persist replace-all-with { test_bigip_cookie } }

# save /sys config

 

  • BIG-IP LTM:HTTPSクッキー・パーシステンス

# create persistence cookie test_bigip_cookie cookie-name BIGIP_COOKIE_PERSIST expiration 1:0:0

# modify virtual test_ssl_virtual { persist replace-all-with { test_bigip_cookie } }

# save /sys config

 

 

  • NGINX Plus:HTTP クッキー・パーシステンス

upstream test_pool {

server 10.10.10.10:80;

server 10.10.10.20:80;

sticky cookie mysession expires=1h;

}

 

  • NGINX Plus:HTTPS クッキー・パーシステンス

upstream ssl_test_pool {

server 10.10.10.10:443;

server 10.10.10.20:443;

sticky cookie mysession expires=1h;

}

 

ディレクティブのドキュメント(英語):serversticky cookieupstream

送信元IPアドレスベースのセッション・パーシステンス

セッション・パーシステンスの別の形態は、リクエストパケットに記録されている送信元IPアドレス(リクエストしているクライアントのIPアドレス)に基づいています。ロードバランサーはリクエストごとにIPアドレスでハッシュを計算し、そのハッシュに関連付けられているバックエンドサーバーにリクエストを送信します。特定のIPアドレスのハッシュは常に同じなので、同じハッシュのリクエストはすべて同じサーバーに送られます。(NGINX Plusの実装の詳細については、ブログでNGINX Plusの負荷分散手法選択する(英語)を参照してください)。

 

  • BIG-IP LTM

#modify virtual test_virtual {persist replace-all-with {source_addr}}

#save / sys設定

  • NGINX Plus

upstream test_pool {

ip_hash;

server 10.10.10.10:80;

server 10.10.10.20:80;

}

ディレクティブのドキュメント(英語):ip_hashserverupstream

 

トークンベースのセッション・パーシステンス

セッション・パーシステンスのもう1つの方法は、バックエンドサーバーがセッション内で生成するCookieやjsessionidといった他のトークンを利用します。Jsessionidの作成や追跡を管理するために、NGINX Plusは特定のバックエンドサーバーとCookie値を照合してメモリー内にテーブルを作成します。

 

  • BIG-IP LTM

BIG-IP LTMは、高度なiRuleを作成しない限り、学習した(またはユニバーサルな)パーシステンスプロファイルをネイティブでサポートしていませんので、本ドキュメントでは対象としません。

 

  • NGINX Plus

upstream test_pool {

server 10.10.10.10:80;

server 10.10.10.20:80;

sticky learn create=$upstream_cookie_jsessionid

lookup=$cookie_jsessionid

zone=client_sessions:1m;

}

ディレクティブのドキュメント(英語):serversticky learnupstream

 

keepalive接続

通常、別のHTTPセッションが作成され、接続ごとに破棄されます。Webサーバーから少量のコンテンツを要求するなど、短時間の接続では問題無いかもしれませんが、長時間の接続ではとても非効率になりえます。セッションや接続を絶え間なく作成・破棄していると、アプリケーションサーバーとクライアントの両方に負荷が掛かってページの読み込みが遅くなり、Webサイトやアプリケーションのパフォーマンスに対する全体的な印象が損なわれる可能性があります。ロードバランサーに対し、セッション用の接続を開いたままにするよう指示するHTTP keepalive接続は、Webページをより高速にロードするためには必要なパフォーマンス機能です。

 

BIG-IP LTM

# modify virtual test_virtual profiles add { oneconnect }

# modify virtual test_ssl_virtual profiles add { oneconnect }

# save /sys config

 

NGINX Plus

upstream test_pool {

server 10.10.10.10:80;

server 10.10.10.20:80;

keepalive 32;

}

ディレクティブのドキュメント(英語):keepaliveserverupstream

モニター(ヘルスチェック)

F5 BIG-IP LTMはモニターという用語で、サーバーが正常に機能していることを確認するプロセスを指しますが、NGINX Plusではヘルスチェックという用語を使います。BIG-IP LTM構成では、モニターはプールに直接関連付けられ、プール内の各ノードに割り当てられますが、NGINX Plusではlocationブロックにヘルスチェックを配置します。

 

以下のBIG-IP LTM createコマンドに対するInterval引数は、5秒ごとにサーバーをチェックするようにBIG-IP LTMを設定します。これはNGINX Plusの初期設定でのチェック頻度に相当します。NGINX Plusは、intervalおよびfailsパラメーターを使用してタイムアウト機能を実装するため、BIG-IP LTM timeoutパラメーターは必要ありません。

注:このBIG-IP LTM設定はHTTP用です。HTTPSの場合は、createとmodifyコマンドの両方でtest_ssl_monitorをtest_monitorに置き換えてください。同じNGINX Plus設定は、HTTPとHTTPSの両方で機能します。

 

BIG-IP LTM

# create monitor http test_monitor defaults-from http send “GET /index.html HTTP/1.0\r\n\r\n” interval 5 timeout 20

# modify pool test_pool monitor test_monitor

# save /sys config

NGINX Plus

upstream test_pool {

# …

zone test_pool_zone 64k;

}

 

server {

# …

location / {

proxy_pass http://test_pool;

health_check interval=5 fails=2;

}

}

ディレクティブのドキュメント(英語):health_checklocationproxy_passserverupstreamzone

 

変換されたロードバランサー構成のまとめ

ここでは、構成要素をまとめて基本的なF5 BIG-IP LTM環境を構築するために必要な構成と

NGINX Plusに移行するための同じ設定方法の詳細を記載します。

 

BIG-IP LTM

# create pool test_pool members add { 10.10.10.10:80 10.10.10.20:80 }

# create virtual test_virtual { destination 192.168.10.10:80 pool test_pool source-address-translation { type automap } ip-protocol tcp profiles add { http } }

# create pool ssl_test_pool members add { 10.10.10.10:443 10.10.10.20:443 }

# create virtual test_ssl_virtual { destination 192.168.10.10:443 pool ssl_test_pool source-address-translation { type automap } ip-protocol tcp profiles add { http } }

# create profile client-ssl test_ssl_client_profile cert test.crt key test.key

# modify virtual test_ssl_virtual profiles add { test_ssl_client_profile }

# create profile server-ssl test_ssl_server_profile cert test.crt key test.key

# modify virtual test_ssl_virtual profiles add { test_ssl_server_profile }

# create persistence cookie test_bigip_cookie cookie-name BIGIP_COOKIE_PERSIST expiration 1:0:0

# modify virtual test_virtual { persist replace-all-with { test_bigip_cookie } }

# modify virtual test_ssl_virtual { persist replace-all-with { test_bigip_cookie } }

# modify virtual test_virtual profiles add { oneconnect }

# modify virtual test_ssl_virtual profiles add { oneconnect }

# create monitor http test_monitor defaults-from http send “GET /index.html HTTP/1.0\r\n\r\n” interval 5 timeout 20

# modify pool test_pool monitor test_monitor

# create monitor https test_ssl_monitor defaults-from https send “GET /index.html HTTP/1.0\r\n\r\n” interval 5 timeout 20

# modify pool ssl_test_pool monitor test_ssl_monitor

# save /sys config

 

 

NGINX Plus

以下の構成には、これまで説明していなかった3つの追加ディレクティブが含まれています。トラフィックを

プロキシするときは、これらを追加することがベストプラクティスです。

 

  • proxy_set_headerHost $hostディレクティブは、クライアントから受信したHostヘッダーがリクエストとともにバックエンドサーバーに送信されるようにします。
  • proxy_http_versionディレクティブは、バックエンドサーバーへの接続用にHTTPバージョンを1に設定します。
  • proxy_set_header Connection “”ディレクティブは、NGINX Plusがアップストリームサーバーへの暗号化されたkeepalive接続を維持できるように、Connectionヘッダーをクリアします。

 

また、最後のserverブロックでライブアクティビティのモニタリングも可能にしています。ライブアクティビティのモニタリングは、NGINX Plus APIモジュールで実装される、NGINX Plus限定の機能です。APIがレポートする幅広い統計情報は、組み込みダッシュボードに表示され、JSON形式のメッセージを理解するすべてのアプリケーションパフォーマンス管理(APM)または監視ツールにエクスポートすることができます。ロギングとモニタリングの詳細については、「NGINX Plus管理者ガイド」(英語)を参照してください。

 

upstream test_pool {

zone test_pool_zone 64k;

server 10.10.10.10:80;

server 10.10.10.20:80;

sticky cookie mysession expires=1h;

keepalive 32;

}

 

upstream ssl_test_pool {

zone ssl_test_pool_zone 64k;

server 10.10.10.10:443;

server 10.10.10.20:443;

sticky cookie mysession expires=1h;

keepalive 32;

}

 

server {

listen 192.168.10.10:80 default_server;

proxy_set_header Host $host;

 

location / {

proxy_pass http://test_pool;

health_check;

proxy_http_version 1.1;

}

 

location ~ /favicon.ico {

root /usr/share/nginx/images;

}

}

 

server {

listen 192.168.10.10:443 ssl default_server;

ssl_certificate     test.crt;

ssl_certificate_key test.key;

proxy_set_header    Host $host;

 

location / {

proxy_pass https://ssl_test_pool;

proxy_http_version 1.1;

proxy_set_header Connection “”;

health_check;

}

 

location ~ /favicon.ico {

root /usr/share/nginx/images;

}

}

 

server {

listen 8080;

status_zone status-page;

root /usr/share/nginx/html;

 

location /api {

api write=on;

# directives controlling access, such as ‘allow’ and ‘deny’

}

 

location = /dashboard.html {

root /usr/share/nginx/html;

}

 

# Redirect requests made to the old (pre-R14) dashboard

location = /status.html {

return 301 /dashboard.html;

}

 

location ~ /favicon.ico {

root /usr/share/nginx/images;

}

}

改訂履歴

  • バージョン2(2018年4月) – 高可用性とNGINX Plus APIに関する情報(NGINX Plus R13、NGINX Open Source 1.13.4)
  • バージョン1(2017年2月) – イニシャル・バージョン(NGINX Plus R11、NGINXオープンソース11.5)

高可用性AWSロードバランサーとして、NGINX Plusを導入する

※本記事はNGINX,Inc.のブログ記事「Deploying NGINX Plus as a Highly Available AWS Load Balancer」を和訳した内容となります。
【URL】
https://www.nginx.com/blog/nginx-plus-highly-available-aws-load-balancer/

ロードバランサーは、多くの場合Webアプリケーションへの単一の入口として機能し、アプリケーション配信基盤の重要なコンポーネントとなります。 つまり、ロードバランサーのダウンタイムは、アプリケーションのダウンタイムを意味します。 ダウンタイムとそれに伴う利用者の不満を最小限に抑えるために、ロードバランサーを高可用性(以下HAと表記)を担保して展開する必要があります。

 

このブログ記事では、AWS用ロードバランサーとしてNGINX Plus の高可用性を実現するために使えるいくつかの方法を比較します。オンプレミス展開で提供するkeepalivedベースの高可用性ソリューションは、すでに精通されているかもしれません。ただし、一般的なAWSやクラウド環境では、ネットワーク制限により、クラウド上でkeepalivedベースのソリューションを使用できません。とはいうものの、AWSではNGINX Plusの高可用性を実現するための他のオプションを提供しています。たとえば、導入ガイドに記載されているように、オンプレミスのkeepalivedソリューションをAWSで動作するように変更することができます。

 

高可用Active – Active構成のNGINX PlusとAWS ネットワークロードバランサー(以下NLBと表記)を組み合わせたソリューションもあります。 この記事で論じる方法は、コミュニティ版のNGINXとNGINX Plusの両方に当てはまりますが、簡潔にするために、以下、ブログではNGINX Plusだけ取りあげます。 以下の表では、この記事で説明する4つの方法をまとめています。

  • このブログ記事は、NGINX PlusのAWSロードバランサーとしての側面、NGINX Plusの高可用性を実現することに重点を置いています。他のAWSのトピックスの詳細については、以下を参照してください。
  • AmazonEC2にNGINX Plus AMIをインストールする(英語)
  • AWS上のNGINX PlusとAmazon Elastic Load Balancing(英語)
  • Amazonで正しいロードバランサーを選択する:AWSアプリケーションロードバランサー(英語)
  • NGINX Plus with AWS Cloudクイックスタート(英語)
  • NGINX Plusを使用したAWS Auto Scalingグループのロードバランシング(英語)
  • AWSパフォーマンスをもっと早くするための5つのヒント(英語)

ELBを使用したNGINX Plusの高可用性

AWSの基本的な組み込みロードバランサであるELB(Elastic Load Balancer、正式にはクラシックロードバランサと呼ばれています)は、機能は限られていますが、高可用性を実現します。このため、図に示すように、ELBを活用してNGINX Plusの可用性を高めることができます。

すべてのNGINX Plusインスタンス間でトラフィックを負荷分散するようにELBを設定します(アプリケーションインスタンスへのトラフィックをロードバランシングします)。NGINX Plusインスタンスの1つに障害が発生すると、ELBはそれを検出し、障害インスタンスへのトラフィック送信を中止します。ELBがNGINX Plusインスタンスの障害を迅速に検出できるようにするには、ELBヘルスチェックを構成することが重要です。

ELBはActive-Activeの高可用構成を提供します。つまり、すべてのNGINX Plusインスタンスが稼働し、共有するトラフィックを受信することを意味します。StandbyのNGINX Plusインスタンスをデプロイしないことで、全体的なコストが削減されます。 ただし、HTTPロードバランサーとして配置されたELBは、HTTP / 2またはWebSocketプロトコルをサポートしていません。

これらのプロトコルをNGINX Plusで使用する必要がある場合は、ELBをTCP(HTTPではなく)ロードバランサーとして配置する必要があります。

このケースでクライアントのIPアドレスをELBからNGINX Plusに渡す必要がある場合は、ELBとNGINX Plusの両方でプロキシプロトコルも設定する必要があります。

NGINX Plusの高可用構成にELBを使用する場合、いくつかの欠点があります。

  • ELBは静的IPアドレスを公開しませんが、これは、一部のアプリケーションにとって重要な要件です。
  • ELBはロードバランシングを一段追加するので、複雑さとコストを増加
    させます。
  • ELBはUDPをサポートしていないため、UDPトラフィックの負荷分散にNGINX Plusを使用することはできません。
  • ELBはすぐに拡張できないため、トラフィックが急増すると、トラフィックが落ちる可能性があります。
  • ELBのIPアドレスはDNS CNAMEレコードを使用して公開されます。

つまり、すべてのDNSをRoute 53に委任しない限り、ルートドメイン(example.comなど)をCNAMEにマップすることはできません。

 

新しいネイティブのAWSロードバランサー、Application Load Balancer(ALB)も同様の方法で使用できます。ELBよりも多くの機能と柔軟性がありますが、上記の欠点も同じくあてはまります。

Route53を使用したNGINX Plusの高可用性

ELB同様、Route 53も図に示すように、 Active-Active構成のNGINX Plus導入を可能にします。

ELB同様、Route 53も図※に示すように、 Active-Active構成のNGINX Plus導入を可能にします。 ホストされたゾーンを作成し、レコードを追加して、すべてのNGINX Plusインスタンスにトラフィックをルーティングできるようにします。NGINX Plusインスタンスに対する、Route 53 のヘルスチェック設定を確認してください。NGINX Plusインスタンスの1つが停止した場合、Route 53はそのインスタンスに関連付けられたレコードをDNSクエリへの応答から除外します。ただし、クライアントと中間DNSサーバーは、正式なDNSサーバーによって設定された各レコードの有効期間(TTL)値に従ってレコードをキャッシュします。TTLの有効期限が切れるまではレコードを更新しないので、権限のあるサーバーが応答からNGINX Plusインスタンスのレコードを削除したときにも、すぐには通知しません。この問題を回避するには、NGINX Plusレコードには、最小TTL値を設定する必要があります。

詳細な手順については Route 53 導入ガイド(英語)を参照してください。

Active-Active構成に加えて、Route 53では、AWS ドキュメンテーションで説明されているように、Active-Passive構成またはさらに複雑なフェールオーバーの組み合わせを作成できます。 また、このブログの記事で説明されている他の方法を用いて、Route 53を使用することも可能です。 

ELBまたはRoute53を使わないNGINX Plusの高可用性

いくつかの理由から、NGINX Plusの高可用性を実現するために、ELBまたはRoute 53に頼りたくないかもしれません。1つの代替案は、Active-Passive構成でNGINX Plusを導入し、AWSのElastic IPアドレス機能を使用することです。ここでは、NGINX Plusの固定IPアドレスを公開し、プライマリ(ActiveまたはMaster)NGINX Plusインスタンスに関連付けます。スタンバイモードまたはバックアップモードの2番目のNGINX Plusインスタンスはトラフィックを処理しませんが、マスターNGINX Plusインスタンスに障害が発生したときには、引き継ぐ準備ができています。引継ぎ(フェイルオーバー)の間、Elastic IPアドレスは第2のインスタンスに再度割り当てられ、第2のインスタンスがマスターとみなされます。

Elastic IPアドレス方式の弱点は次の通りです。

  • バックアップインスタンスは、ほとんどの時間使用されていないため、導入コストが増加します。
  • 一般的なオンプレミス構成とは対照的に、固定IPアドレスの再関連付けは即時ではありません。テストでは、IPアドレスを新しいマスターインスタンスに再関連付けするまでに最大6秒かかりました。
  • この構成は、マスターのNGINX Plusインスタンスの正常性を監視し、マスター障害時にElastic IPアドレスを再関連付けするためのソフトウェアをインストールして、適切に構成する必要があるため、ELBまたはRoute 53の方法よりも複雑です。

 

NGINX, Inc.は、Elastic IPアドレスを使用する2つのソリューションを提供しており、それらはマスターNGINX Plusインスタンスの状態を監視する方法と、Elastic IPアドレスを再関連付けする方法で異なります。

  • keepalivedベースのソリューション

導入ガイドで説明しているように、keepalivedベースのソリューションをオンプレミス展開に変更し、AWSでElastic IPアドレスの再関連付けをサポートすることができます。オンプレミスのHA構成と同様、バックアップのNGINX Plusインスタンス上のkeepalivedデーモンは、マスターインスタンスの正常性を監視します。オンプレミスのソリューションとの違いは、マスター障害時にkeepalivedがカスタムスクリプトを起動して、Elastic IPアドレスを再関連付けするAWS APIを呼び出すことです。このソリューションは、NGINX Plusサポート契約の対象外であることにご注意ください。

  • AWS Lambdaベースのソリューション

Lamba機能を使用してNGINX Plusマスターインスタンスの正常性を監視し、マスター障害時にはElastic IPアドレスを再関連付けします。
このソリューションに関しては、NGINXのプロフェッショナル・サービスチームによるソリューションの導入、設定、さらにサポートをご提供しています。
また、高可用性Active-Active構成のNGINX Plusと AWS Network Load Balancer (NLB)を組み合わせたソリューションもあります。

まとめ

高可用性は、AWSロードバランサーには非常に重要です。このブログ記事で説明してきたように、AWSではNGINX Plusの高可用性を実現するための方法を複数用意しています。 ELBまたはRoute 53に基づく方法はよい出発点です。固定IPアドレスが必要な場合は、keepalivedまたはAWS Lambdaに基づくElastic IPを使う方法をご利用ください。

AWS上でNGINX Plusを使うのは初めてですか? ぜひ、30日間無料でお試しください。利用可能なAMIへのリンクについては、Amazon EC2上でのNGINX PlusAMIのインストールを参照して下さい。

NGINX PlusとAWSネットワークロードバランサーで実現する、All Active構成での高可用性ソリューション

※本記事はNGINX,Inc.のブログ記事「Deploying NGINX Plus and AWS Network Load Balancer in an All-Active, Highly Available Solution」を和訳した内容となります。
【URL】
https://www.nginx.com/blog/deploying-nginx-plus-and-aws-network-load-balancer-in-an-all-active-highly-available-solution/

NGINXは、Amazon Web Services(以下AWS)向けに、新たに推奨の高可用性(HA)ソリューションを発表しました。このソリューションでは、新しいAWSネットワークロードバランサー(AWS NLB)を利用して、AWS上のWebアプリケーションのパフォーマンス、信頼性、スケーラビリティーを向上させます。

AWSのアプリケーション展開の規模は急速に拡大しています。以下は、Amazonの主要な
リソースです。:

 

また、NGINXでも、AWSに関する幅広いリソースを準備しています。

AWS NLBは、基本的なレイヤ4ロードバランシングに、迅速で効果的なソリューションを提供します。 NGINXは、AWSの新機能とNGINX Plusとの統合性に対し、またAWS上でNGINX Plusの可用性を大きく高めてくれる推奨ソリューションとして、とても感銘を受けています。 このインテグレーション事例の紹介として、AWS NLBとNGINX Plusを組み合わせるための導入ガイドを以下に公開しています。

 参考:導入ガイド 

このリソースは、AWSの大規模な導入は始めての方にも、経験豊かなプロの方にも非常に役立ちます。導入ガイドの手順に沿って利用すると、さまざまなアプリケーション導入の課題を処理するソリューションを作成できます。

  • 新しいAWS NLBによるレイヤ4の高速ロードバランシング
  • AWS Elastic IPアドレスのサポート
  • NGINX Plusインスタンスでの高可用、All-Activeのレイヤ7ロードバランシング。 NGINX Plusは、コンテンツベースのルーティング、高度なロードバランシングアルゴリズム、キャッシング、リアルタイムの設定変更、セッション・パーシステンス(セッション永続性)、アプリケーション認識のヘルスチェックをサポート。
  • アプリケーションコードを効率的に実行するために、オープンソースのNGINXソフトウェアを実行する複数のサーバーインスタンス。
  • AWSオートスケーリング、サーキットブレーカーパターンなどのサポート。

このAWS上の新しいロードバランシングソリューションは、NGINX Plusを使って、パワーと高度な機能を提供します。AWS NLBに従い、基本的なレイヤ4ロードバランシングを処理します。残りのソリューションにNGINX Plusを活用することで、比較的安価に、堅牢なロードバランシングソリューションをAWS上に作成できます。

 

このソリューションは、オンプレミス(ベアメタル、コンテナ、または仮想マシン)およびその他のクラウド環境に展開され、高可用性を誇る一連のNGINX Plusロードバランシングソリューションに加わるものです。そのアーキテクチャは、Google Cloud Engine(GCE)向けに all-activeかつ高い可用性を実現している、NGINX Plusベースのロードバランシングアーキテクチャに似ています。またGCEではレイヤ4ロードバランシングにGoogle Cloud Engine(GCE)ネットワークロードバランサを使っています。 NGINX Plusをお試しいたいただくには、今すぐ無料の30日間のトライアルを開始するか、当社までご連絡ください。それから、導入ガイドのステップバイステップの手順に従って、AWS NLBとNGINX Plusを設定してください。