サーバ、クライアント、プロキシ間でのネットワーク トラフィックの分散は、お客様の満足度を高め、インフラストラクチャを最適化する上で重要です。NGINX Plusの高パフォーマンスのロード バランシングにより、スケールアウトして冗長性を確保し、再始動を必要とせずにインフラストラクチャを動的に再設定し、Global Server Load Balancing (GSLB)、セッション パーシステンス、アクティブ ヘルス チェックを利用できます。NGINX PlusはHTTPトラフィックの他に、TCP、UDP、gRPCのロードバランシングも行います。
NGINX PlusはHTTPトラフィックのロードバランシング時に、各HTTP接続を終了し、各リクエストを別個に処理します。SSL/TLS暗号化を解除し、リクエストを検査して操作し、レート制限を使用してリクエストをキューに入れ、ロード バランシング ポリシーを選択することができます。
パフォーマンスを強化するために、NGINX Plusではさまざまな最適化をHTTPトランザクションに自動的に適用できます。最適化には、HTTPプロトコルのアップグレード、keepaliveの最適化、変換(コンテンツ圧縮や応答キャッシュなど)などがあります。
NGINX PlusではHTTPトラフィックのロード バランシングも簡単にできます。
http {
upstream my_upstream {
server server1.example.com;
server server2.example.com;
}
server {
listen 80;
location / {
proxy_set_header Host $host;
proxy_pass http://my_upstream;
}
}
}
最初にserver
ディレクティブを使用して仮想サーバを指定し、次にトラフィックをlisten
するポートを指定します。location
ブロックを使用してクライアント リクエストのURLを照合し、proxy_set_header
ディレクティブを使用してHost
ヘッダを設定し、リクエストをアップストリーム グループに転送するためにproxy_pass
ディレクティブを組み込みます(upstream
ブロックにより、NGINX Plusがトラフィックのロードバランシングを行うサーバが定義されます)。
詳しくは、NGINXとNGINX Plusを使用したロード バランシングの概要をご覧ください。
NGINX Plusでは、MySQLなどのTCPアプリケーションと、DNSやRADIUSなどのUDPアプリケーションのロード バランシングも実行できます。TCPアプリケーションの場合、NGINX PlusはTCP接続を終了してからバックエンドへの新しい接続を作成します。
stream {
upstream my_upstream {
server server1.example.com:1234;
server server2.example.com:2345;
}
server {
listen 1123 [udp];
proxy_pass my_upstream;
}
}
この設定はHTTPの設定に似ています。server
ディレクティブを使用して仮想サーバを指定し、ポートでトラフィックをlisten
し、リクエストをupstream
グループに転送(proxy_pass
)します。
TCPとUDPのロード バランシングについて詳しくは、NGINX Plus Admin Guideをご覧ください。
NGINX Plusでは、HTTP、TCP、UDPロード バランシングのためのさまざまなアプリケーション ロード バランシング手法がサポートされています。すべての手法では、必要に応じて各アップストリーム サーバに割り当てることができるweightが考慮されています。
NGINX PlusとアップストリームのHTTPサーバまたはTCPサーバの間で確立される接続の数、またはUDPサーバとのセッションの数を制限できます。サーバとの接続またはセッションの数が、定義されている制限を超えると、NGINX Plusは新しい接続またはセッションの確立を停止します。
以下の設定スニペットでは、webserver1の接続制限は250、webserver2の接続制限は150です。queue
ディレクティブで、NGINX Plusがオペレーティング システムのlistenキューに最大30秒間格納する超過接続の最大数を指定します。この数を超えるリクエストはドロップされます。
upstream backend {
zone backends 64k;
queue 750 timeout=30s;
server webserver1 max_conns=250;
server webserver2 max_conns=150;
}
サーバのアクティブな接続の数がこの制限を下回ると、NGINX Plusはキューからサーバに接続を送信します。トラフィックが急増する状況でも、接続制限により、クライアント リクエストが一貫して予測可能な方法で処理されるようになります。
ユーザ セッションを識別して1つのセッション内のすべてのリクエストを同一のアップストリーム サーバに送信するようにNGINX Plusを設定できます。これは、アプリケーション サーバに状態がローカルに保存される場合に重要です。進行中のユーザ セッションが別のサーバに送信されると致命的なエラーが発生するからです。セッション パーシステンスにより、1つのクラスタ内でアプリケーションが情報を共有することになり、パフォーマンスが向上する可能性があります。
NGINX Open Sourceでサポートされているハッシュベースのセッション パーシステンス(ハッシュおよびIPハッシュのロード バランシング方式を参照)の他に、NGINX PlusではCookieベースのセッション パーシステンス(sticky cookieなど)もサポートされています。NGINX Plusはアップストリーム グループから特定のクライアントへの最初の応答にセッションCookieを追加し、応答を生成したサーバを確実に識別します。後続のクライアント リクエストにはこのCookieが含まれ、NGINX PlusはこのCookieを使用してリクエストを同じアップストリーム サーバにルーティングします。
upstream backend {
server webserver1;
server webserver2;
sticky cookie srv_id expires=1h domain=.example.com path=/;
}
上記の例では、NGINX Plusは、リクエストを処理したサーバを示すsrv_idというCookieを最初のクライアント応答に挿入します。後続のリクエストに同じCookieが含まれている場合、NGINX Plusはそのリクエストを同じサーバに転送します。
NGINX Plusではスティッキー ラーンとスティッキー ルート パーシステンス方式もサポートされています。
注: Cookieベースのセッション パーシステンスは、NGINX Plusでのみ利用できます。
デフォルトではNGINXはアップストリーム サーバからの応答に対して基本的なチェックを実行し、可能であれば失敗したリクエストを再試行します。NGINX Plusでは、アウトオブバンド アプリケーション稼働状況チェック(合成トランザクションとも呼ばれます)と、新しいサーバや復元されたサーバをロード バランシングされたグループにグレースフルに追加するスロースタート機能が追加されています。
これらの機能により、NGINX Plusはさまざまな問題を検出、回避できるため、HTTPアプリケーションとTCP/UDPアプリケーションの信頼性が大きく向上します。
upstream my_upstream {
zone my_upstream 64k;
server server1.example.com slow_start=30s;
}
server {
# ...
location /health {
internal;
health_check interval=5s uri=/test.php match=statusok;
proxy_set_header Host www.example.com;
proxy_pass http://my_upstream
}
}
match statusok {
# Used for /test.php health check
status 200;
header Content-Type = text/html;
body ~ "Server[0-9]+ is alive";
}
上記の例ではNGINX Plusが/test.phpのリクエストを5秒間隔で送信します。match
ブロックで、アップストリーム サーバが正常であると判断されるために応答が満たす必要がある条件(ステータス コード200
OK
と、応答本文にServerN
is
alive
というテキストが含まれていること)が定義されます。
注: アクティブ ヘルス チェックはNGINX Plusでのみ利用できます。
デフォルトでは、NGINX Plusサーバは開始時にDNS名を解決し、解決した値を永続的にキャッシュします。server
ディレクティブとresolve
パラメータでアップストリーム サーバのグループを識別するときにexample.comのようなドメイン名を使用すると、NGINX Plusは定期的にドメイン名の解決を繰り返します。関連付けられているIPアドレスのリストが変更されると、NGINX Plusは即時に変更後のサーバ グループでロード バランスを開始します。
DNS SRV
レコードを使用するようにNGINX Plusを設定するには、resolver
ディレクティブと、server
ディレクティブのservice=http
パラメータを以下のように指定します。
resolver 127.0.0.11 valid=10s;
upstream service1 {
zone service1 64k;
server service1 service=http resolve;
}
上記の例では、NGINX Plusがドメイン名service1の解決を再試行するために127.0.0.11 (組み込みDocker DNSサーバ)に対するクエリを10秒間隔で実行します。
注: DNSを使用したサービス検出は、NGINX Plusでのみ利用できます。
NGINX Plusには、1つのAPIエンドポイントを持つRESTful APIが含まれています。NGINX Plus APIを使用すれば、アップストリーム設定やキー値ストアの更新をダウンタイムなしで実行中に行うことができます。
以下の設定スニペットでは、/apiエンドポイントへの読み取り/書き込みアクセスを有効にするapi
ディレクティブが指定されています。
upstream backend {
zone backends 64k;
server 10.10.10.2:220 max_conns=250;
server 10.10.10.4:220 max_conns=150;
}
server {
listen 80;
server_name www.example.org;
location /api {
api write=on;
}
}
上記の例のようにAPIを有効にすると、次のcurl
コマンドを使用して既存のアップストリーム グループに新しいサーバを追加できます。このコマンドはPOST
メソッドとJSONエンコーディングを使用してサーバのIPアドレスを192.168.78.66に設定し、そのweightを200に設定し、同時接続の最大数を150に設定します(version
は、参照ドキュメントに指定されているようにAPIの現行のバージョン番号に置き換えます)。
$ curl -iX POST -d '{"server":"192.168.78.66:80","weight":"200","max_conns":"150"}' http://localhost:80/api/version/http/upstreams/backend/servers/
すべてのbackendアップストリーム サーバの完全な設定をJSON形式で表示するには、次のコマンドを実行します。
$ curl -s http://localhost:80/api/version/http/upstreams/backend/servers/ | python -m json.tool
{
"backup": false,
"down": false,
"fail_timeout": "10s",
"id": 0,
"max_conns": 250,
"max_fails": 1,
"route": "",
"server": "10.10.10.2:220",
"slow_start": "0s",
"weight": 1
},
{
"backup": false,
"down": false,
"fail_timeout": "10s",
"id": 1,
"max_conns": 150,
"max_fails": 1,
"route": "",
"server": "10.10.10.4:220",
"slow_start": "0s",
"weight": 1
},
{
"backup": false,
"down": false,
"fail_timeout": "10s",
"id": 2,
"max_conns": 200,
"max_fails": 1,
"route": "",
"server": "192.168.78.66:80",
"slow_start": "0s",
"weight": 200
}
既存のアップストリーム サーバの設定を変更するには、内部IDを使用してサーバを指定します。内部IDは上記の出力のid
フィールドに示されています。次のコマンドではPATCH
メソッドを使用してサーバをID 2で再設定し、サーバのIPアドレスを設定し、ポートで192.168.78.55:80をリッスンし、weightを500に設定し、接続制限を350に設定します。
$ curl -iX PATCH -d '{"server":"192.168.78.55:80","weight":"500","max_conns":"350"}' http://localhost:80/api/version/http/upstreams/backend/servers/2
NGINX Plus APIのSwagger (OpenAPI仕様)ドキュメント全体にはhttps://demo.nginx.com/swagger-ui/からアクセスできます。
注: NGINX Plus APIはNGINX Plusでのみ利用できます。