19
は 、要 求 は backend1にルーティングされる場合があり、URIパラメータに特定の値 が
使 用 さ れ て い る 場 合 、要 求 は backend2に ル ー テ ィ ン グ さ れ ま す 。こ の 例 は Java共通
セッションIDに 基 づ い て い ま す が 、同 じ こ と が phpsessionid、ま た は 、ア プ リ ケ ー シ ョ ン
がセッションIDに生 成する保証された一意の識別子のような他のセッションテクノロ
ジーにも当てはまります。
解説
場合によっては、もう少しきめ細かい制御を利用して、トラフィックを特定のサーバー
に転 送したいことがあります。stickyディレクティブへの routeパ ラ メ ー タ は 、こ の 目 標
を達 成するために作成されています。スティッキールートは、ジェネリックハッシュロー
ドバランシングアルゴリズムとは異なり、より優れた制御、実際の追跡、Stickinessを提
供します。クライアントは 指定されたルートに 基づき、まず、アップストリームサーバー
に ル ー ティン グ され 、次 に 、後 続 の 要 求 は ル ー ティング 情 報を CookieまたはURIに含
みます。スティッキールートは 、評 価 に 利 用できる位 置を示すパラメータをとります。
空でない最初の変数は、サーバーへのルーティングに使用されます。マップブロックを
使 用して、変 数 を 選 択 的 に 解 析し 、ル ー ティン グ で 使 用 するそ の 他 の 変 数として保 存
できます。sticky routeディレクティブ は NGINX Plusの 共 有メモリゾーン 内 にセッション
を作成します。これはアップストリームサーバのためにあなたが 指定したクライアント
セッションの識別子を追跡するためであり、また一貫してセッションの識 別子を持っ
たリクエ ストを同じアップストリームサーバに元 のリクエストとして転 送するためです。
2.8 NGINX Plusを使 用した接 続のドレイン
問題
NGINX Plusとのセッションを提供しながら、メンテナンスまたはその他の理由でサー
バーを適 切 に削 除 する必 要があります。
解決法
NGINX Plus APIを 介してdrainパラメー タ を 使 用して NGINXにまだ追跡されていない
新しい接続を送信するのを停止するよう指示します。（詳細な説明は第5章を 参 照 。）
$ curl -X POST -d '{"drain":true}'
'http://nginx.local/api/3/http/upstreams/backend/servers/0'
{
"id":0,
"server":"172.17.0.3:80",
"weight":1,
"max_conns":0,
"max_fails":1,
"fail_timeout":
"10s","slow_start":
2.8 NGINX Plusを使用した接続のドレイン |
20
"0s",
"route":"",
"backup":false,
"down":false,
"drain":true
}
解説
セッション状態がサーバーにローカルに保存されている場合、サーバーをプールから削
除する前に、接続と永続セッションをドレインする必要があります。ドレイン接続はサー
バーをアップストリームプールから削 除 する前にサーバーへのセッションをネイティブに
期限切れにする方法のプロセスです。特定のサーバーのドレインはserverディレクティ
ブにdrain パラメータを追加することで構成できます。drainパラメータが 設 定されると
NGINX Plusは 新しいセッションをこのサーバーに送るのを停止しますが 現在のセッション
がセッション中は継続を許可します。この構成はdrainパラメータをアップストリームサー
バー のディレクティブに 追 加し 、NGINX Plus構 成 をリロードすることで 変 更できます。
2.9 パッシブヘルスチェック
問題
アップストリームサーバーの正常性を受動的（パッシブ）にチェックする必 要があります。
解決法
NIGNXヘルスチェックをロードバランシングと一 緒に使 用して、健 全なアップストリー
ムサーバーのみが利用されるようにします：
upstream backend {
server backend1.example.com:1234 max_fails=3 fail_timeout=3s;
server backend2.example.com:1234 max_fails=3 fail_timeout=3s;
}
この 構成は 、アップストリームサーバーに向けられたクライアント要求の応 答 を監視す
ることにより、アップストリームの状 態をパッシブに監視します。この 例では、max_fails
ディレクティブ を3に 、そ し て fail_timeoutを3秒 に 設 定 し ま す 。こ れ ら の デ ィ レ ク テ ィ ブ
パ ラ メ ー タ は 、ス ト リ ー ム サ ー バ ー と HTTPサーバーの両 方で同じように 機能します。
解説
パッシブヘ ルスチェックは 、オープ ンソース バージョン の NGINXで 利 用できます。HTTP、
TCP、お よ び UDPロードバランシングのサーバーパラメータを使用して構成されます。パッ
シブモニタリングは、クライアントの要求に応じてNGINXを 通 過 す る 時 に 、接 続 の 失 敗 ま
たはタイムアウトを監視します。パッシブヘルスチェックは、デフォルトで有効で、ここに記
載されているパラメータを 使 用すると、動 作を微 調 整 できます。デフォルトの max_fails 値
は1、デ フ ォ ル ト の fail_timeout値は10sで す 。ヘ ル ス モ ニ タ リ ン グ は 、ユ ー ザ ー エ ク ス ペ リ
| 第2章：ハイパフォーマンスロードバランシング
21
エンスの観点からだけでなく、ビジネス継続性の観点からも、すべてのタイプのロードバ
ランシングで重 要です。NGINXは 、ア ッ プ ス ト リ ー ム の HTTP、TCP、お よ び UDPサーバーを
パッシブに監視して、それらが正常で実行されていることを確認します。
関連項目
HTTPヘルスチェック管 理 者ガイド
TCPヘルスチェック 管 理 者ガイド
UDP ヘルス チェック 管理者 ガイド
2.10 NGINX Plusのアクティブヘルスチェック
問題
NGINX Plusを 使 用 し て 、ア ッ プ ス ト リ ー ム サ ー バ ー の 正 常 性 を 積 極 的（ ア ク テ ィ ブ ）に
チェックする 必 要 があります。
解決法
HTTPの場合は、health_checkディレクティブを以下のロケーションブロックで使用
します：
http {
server {
# ...
location / {
proxy_pass http://backend;
health_check interval=2s
fails=2
passes=5
uri=/
match=welcome;
}
}
# status is 200, content type is "text/html",
# and body contains "Welcome to nginx!"
match welcome {
status 200;
header Content-Type = text/html;
body ~ "Welcome to nginx!";
}
}
このHTTPサーバーのヘルスチェック構成は、2秒ごとにURI '/' に 対して HTTPGET要求
を行うことにより、アップストリームサーバーのヘルスをチェックします。他の方法がバッ
クエンドシステムの状態を変更する可能性があるため、HTTPメソッドをヘルスチェック
用にGETリクエ ストのみを実 行するように 定 義することは できません 。アップストリー
ムサーバーが正常と見なされるためには 、5回 連 続してヘ ルスチェックに合 格 する 必 要
があります。2回連続してチェックに失敗した場合、それらは不健全であると見なされま
2.10 NGINX Plusのアクティブヘルスチェック |
22
す。アップストリームサーバーからの応答は、次のように定義する定義済みの一致ブロ
ックと一致する必要があります：ステータスコード200、ヘ ッ ダ ー Content-Type を'text/
h t m l'、応答本文で文字列"Welcome to nginx!"。HTTP matchブロックには3つのディレ
クティブがあります: status、header、body。こ れ ら 3つ の デ ィレ ク テ ィ ブ に は す べ て 、比
較 フラ グも 利 用しています。
TCP/UDPサービスのストリームヘルスチェックは非常に似ています：
stream {
# ...
server {
listen 1234;
proxy_pass stream_backend;
health_check interval=10s
passes=2
fails=3;
health_check_timeout 5s;
}
# ...
}
この例では、TCPサーバーはポート1234をリッスンし、アクティブヘルスチェックを実行
するupstreamサーバーセットにプロキシするよう構成されます。ストリームhealth_check
ディレクティブ は HTTPと同じパラメータを使用します（例外はuri）が 、ス ト リ ー ム バ ー
ジョンにはチェックプロトコルをudpに変 更するためのパラメータがあります。この例で
は 、間 隔 は 10秒に設定されていて、健全であると認められるためには2つの連 続するチェッ
クをパスする必要があり、3回失敗すると不健全であるとみなされます。アクティブス
トリームヘルスチェックは、アップストリームサーバーからの応 答も検証できます。しか
し 、ス ト リ ー ム サ ー バ ー の matchブロックにはsendとexpectの2つの ディレ クティブしか
ありません 。sendディレクティブは生データを送信し、expectは完全一致の応答また
は一 致する正 規表 現です。
解説
NGINX Plusでは、パッシブまたはアクティブヘルスチェックはソースサーバーを監視す
るために使用できます。これらのヘルスチェックは応答コード以上のものを計測できま
す。NGINX Plusで は 、ア ク テ ィ ブ HTTPヘルスチェックモニターはアップストリームサーバー
への応答受け入れ条件の正常応答回数に基づいています。アップストリームサーバーが
チェックされる頻度、サーバーが正常であると認められるためには何度チェックをパス
する必要があるか、何回までなら異常と認められずに失敗できるか、期待される結果はな
にかなどをモニターするためにアクティブヘルスチェックを構 成 できます。より複 雑なロ
ジックでは、matchブロックへのrequireデ ィレ ク テ ィ ブ が 変 数 の 使 用 を 可 能 に し ま す 。変
数の値はemptyまたはゼロには設定できません。matchパラメータは応 答の受け入れ 基 準
を定義するmatchブロックを指します。matchブロックは、TCP/UDPのストリームコンテキ
ストで 使 用されるときにアップストリームサーバーに 送 信 するデータも定 義します。これら
の機能はNGINXがアップストリームサーバーの健全性を常に保証できるようにします。
| 第2章：ハイパフォーマンスロードバランシング
23
関連項目
HTTPヘルスチェック管 理 者ガイド
TCPヘルスチェック 管 理 者ガイド
UDP ヘルス チェック 管理者 ガイド
2.11 NGINX Plusのスロースタート
問題
使用しているアプリケーションは本番トラフィックのすべてを受け付ける前に段階的に
動 作を開 始する必 要があります。
解決法
serverディレクティブに slow_startパラメータを使用して、指定された時間内に接続
の数を徐々に増やしながら、サーバーをアップストリームロードバランシングプールに
再 度 導入して いきます：
upstream {
zone backend 64k;
server server1.example.com slow_start=20s;
server server2.example.com slow_start=15s;
}
このserverディレクティブの構成はアップストリームサーバーを再 導入後、トラフィッ
ク をゆ っくりと 増 加 させ て いきます。server1は20秒、server2は15秒かけて接続の数
を増やします。
解説
Slow start は、サーバーにプロキシされる要求の数を一定期間にわたってゆっくりと増
加させるという考え方です。スロースタートを使用すると、アプリケーションは起動直
後に接続に圧倒されることなく、キャッシュにデータを入 力してウォームアップし、
データベース接続を開始できます。この機能は、ヘルスチェックにいったん失敗したサ
ーバーが再びヘルスチェックに合格してロードバランシングプールに再び加わる際に
有 効 に な り ま す 。ま た 、こ の 機 能 は NGINX Plusで の み 使 用 で き ま す 。ス ロ ース タ ー ト は
hash、ip_hash、randomロードバランシング方法では使用できません。
2.11 NGINX Plusのスロースタート |
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.