サーバヘルスチェック
ダウンサーバーにユーザーリクエストを割り振らない
この3回の連載では、ロードバランサの仕組みを分かりやすく解説しています。第1回「パケットフローから負荷分散の基本を理解する〜NAT／コネクションテーブル／MAT〜」では、ロードバランサの本質的動作をNAT（Network Address Translation）／MAT（MAC Address Translation）時のパケットフローやコネクションテーブルなどを取りあげて解説しました。
続く今回の第2回では、サーバヘルスチェックとサーバ接続維持についてご紹介します。サーバヘルスチェックは、正常に応答を返さないサーバにユーザーリクエストを割り振らないようにロードバランサが常時行っている作業です。また、サーバ接続維持機能はクレジットカード決済やアンケート受け付けなど、クライアントからの入力を受け付けるサイトではロードバランサに必須な機能となっています。
ロードバランサはダウンしているサーバにリクエストを振らないように、通常すべてのサーバへヘルスチェックを行います（図1）。ヘルスチェックの結果ダウンと判断されたサーバ（図1では192.168.20.3:80）にはユーザーリクエストを割り振りません。
ヘルスチェックの方法としては主に以下の4方式があります。
1. pingチェック（IP・例：ICMP echoリクエストなど）
ICMP echoリクエストを送付し、echoリプライが返ってくるかどうかをチェックします。IPレベルでのチェックになります。
2. ポートチェック（TCP/UDP・例：SYNパケットに対するACKパケットチェックなど
サーバのポートに対して、TCPであればSYNパケット（接続要求）を送付し、それに対するACKパケット（確認応答）が返ってくるかどうかをチェックします。TCP／UDPレベルでのチェックになります。
3. コンテンツチェック（HTTP（S）・例：GET、POSTリクエストに対する応答コンテンツチェックなど）
ロードバランサがHTTP（S）のGETやPOSTリクエストを送付し、それに対してサーバが正常なコンテンツ（文字列）を返しているかどうかをチェックします。HTTP（S）サーバが正常に動作しているかどうかをチェックすることができます。
4. アプリケーションチェック（さまざまなアプリケーション・例：SIPのREGISTERに対する応答メッセージチェックなど）
ロードバランサがさまざまなアプリケーションプロトコルの仮想クライアントとなり、アプリケーションレベルでの動作チェックを行います。例えば、SIPのREGISTERメッセージを送付し成功を伝えるメッセージ（例：200 OK）が返ってくるかどうかをチェックしたり、RADIUS（分散型クライアント／サーバ システムで、不正なアクセスからネットワークを保護）のアクセスリクエストに対してアクセプト（ユーザIDの認証）が返ってくるかどうか、といったチェックを行います。
pingやSYNに応答してもアプリケーションが応答しないという障害は起こり得るため、コンテンツチェックやアプリケーションチェックの方が確実なヘルスチェックとなります。複数のヘルスチェックをandでまとめ、すべてのチェックが成功したときにのみサーバにリクエストを割り振ったり、サーバのコネクション数のリミットを設定しそれ以上であればリクエストを割り振らない、といった機能もあります。
また、アプリケーション側からロードバランサに対してあるサーバにリクエストを割り振らない／リクエスト数を減らすように指示を出すことが可能なロードバランサもあります。
サーバ接続維持
同一コネクション中のパケットを同一のサーバに送る
連載第1回で、ロードバランサは同一コネクション中の複数パケットを同一サーバに割り振ることを紹介しました。サーバ接続維持機能は、これに加えて、同一クライアントからの“複数のコネクション”を同一のサーバに割り振り続けるためのものです（図2）。
この機能は、ユーザーからクレジットカード番号やアンケート入力を受け付ける商業サイトなどで多く使われています。そういったサイトでは、ユーザーから受け取った情報をサーバ内のメモリやローカルディスク上で処理・保存しておき、ユーザーから次のリクエストが来たときにカードの処理結果やアンケート入力確認画面を表示します。ロードバランサが同一ユーザーからの次リクエストを別のサーバに割り振ってしまうと、そのサーバはユーザーが先に入力した情報を知らないため、サーバ側で正常な処理を行うことができません。
サーバ接続維持を実現するためには“同一ユーザーからのリクエスト”であることをどのように判別するかによって以下のような方法があります。
1. ソースIPアドレス
クライアントのIPアドレスが同じであれば一定期間同じサーバにリクエストを割り振り続ける方式です。ネットマスクを設定し、同一ネットワークアドレスに属するクライアントを同じサーバに振ることもできます。Proxyサーバが負荷分散されている環境などで、リクエストごとにクライアントのIPアドレスが変化する環境では使用することができません。また、多数のリクエストが同一のアドレスで来る場合はリクエストが割り振られるサーバに偏りが生じることになります。
2. SSLセッションID
SSLセッションID（連載：携帯通信トレンド第4回SSL／TLS（Part3-2を参照））が同一の間は同一のサーバに割り振る方式です。SSL通信の場合にしか使用することができません。また、最近のブラウザではセッションIDが一定時間ごとに変更されてしまうため、この方法を使っているサイトはあまりないようです。
3. Cookie
Cookieの中に前回アクセスしたサーバの情報を埋め込み、次回のクライアントリクエスト時にロードバランサでその情報を読み取って同一サーバにリクエストを割り振る方法で、現在非常に多くのサイトで使用されています。図3はCookieによる接続維持の1つの例です。ユーザーからの1回目のリクエスト時にはサーバ情報の入ったCookieがないため、その時点で負荷の少ないサーバにリクエストを割り振ります。
サーバからのHTTPレスポンスを受け取ったロードバランサはそのサーバのIPアドレス・ポート情報を埋め込んだCookieを挿入します。ユーザーの2回目のリクエスト時にはそのCookieが送られてくるため、ロードバランサで同一サーバにリクエストを割り振ることができます。
なお、ロードバランサでCookieを挿入するのではなく、サーバ側でサーバ情報を挿入して送る方法や、サーバ側で特定のCookieを挿入するとロードバランサがそれをサーバ情報に書き換える、などといった方法を利用できるロードバランサもあります。
Cookieの情報も暗号化されて送付されるHTTPSでは使用できない方法ですが、ロードバランサの前段やロードバランサ自身にSSLアクセラレータが存在する環境ではこの方法を使用することができます。
4. サーバIDやユーザーIDなど、接続サーバやクライアントを識別できる情報
Cookieに対応していない携帯端末向けサイトなどでは、前回接続したサーバの情報（サーバID）をサーバ側でURLに埋め込み、その情報をロードバランサで読み込むことにより接続維持を実現できます（シスコ、Alteon、ファウンダリ、redwareなど主要ベンダー製品*1）。また、URLなどの中にクライアントを識別できるユーザーIDや端末固体識別情報などが存在する場合は、その情報のハッシュ値により接続維持を実現できるロードバランサ（現在はF5ネットワークスBIG-IPのみ*2）もあります。
以上に挙げた4つの方法のうち、1、2、4（ユーザーID）はロードバランサ上のメモリに「このクライアント（ソースIPやSSLセッションID、ユーザーID）はこのサーバに接続している」という情報を保持します。それに対して、3のCookieや4（サーバID）はCookieやURL中に埋め込まれたサーバ情報を基にL7スイッチを行う動作であり、ロードバランサ上のメモリは消費しません。
*1：http://www.f5networks.co.jp/ja/solution/whitepaper/wp05_03.html
*2：http://www.f5networks.co.jp/ja/solution/technology/te01a_01.html
次回予告
サーバヘルスチェックとサーバ接続維持の方法から仕組みをご理解いただけましたか？ 次回の最終回はロードバランサのパフォーマンス測定や冗長構成の動作などについてご紹介します。
Copyright © ITmedia, Inc. All Rights Reserved.