連載：ロードバランサの本質（1）
パケットフローから負荷分散の基本を理解する
〜NAT／コネクションテーブル／MAT〜

F5ネットワークス
上谷　一
今野　徹
2003/2/5

　負荷分散装置（ロードバランサ）のニーズは現在も高まる一方です。従来はWebサーバのみを主な対象としていましたが、現在ではルータ#1／アプリケーションサーバ／メールサーバ／SIPサーバ／ファイアウォール／VPNゲートウェイ／ウイルスゲートウェイ／IDSなど、多種多様の機器やプロトコルが負荷分散の対象となっています。それに応じてロードバランサも現在では非常に多機能となっていますが、本連載では、全3回に渡ってアプリケーションベースではなく、ネットワークベースの技術、基本となるパケットフローやサーバヘルスチェック、接続維持などの動作について紹介します。また、パフォーマンス測定についてもお話ししましょう。

#1　ルータはレイヤ3でインターネット回線のマルチホーミングとして機能する（＝複数のWAN回線を接続して、同時に通信させることで負荷分散し、必要な帯域を確保するし、回線の1つにトラブルが生じても別の回線でバックアップする）ことから負荷分散の手段として用いられている。

連載第1回は、ロードバランサの本質的動作であるNAT（Network Address Translation）／MAT（MAC Address Translation）時のパケットフローやコネクションテーブルとについて注視します。コネクションテーブルの情報に基づいてNATやMATを行う、という基本的な仕組みに変化はなく、今後も大きく変わることはないでしょう

サーバ負荷分散の基本構成と動作

　では、まずサーバ負荷分散の基本構成と、その上での基本動作を見ていきましょう。図1に示すのは、Webサーバ4台を負荷分散した場合の単純な構成図です。ロードバランサを利用することにより、サーバ1台で運用したときに比べて4倍の性能向上や、冗長性確保（ダウンしたサーバにはロードバランサがリクエストを割り振らない）を実現することができます。

図1　パケットの流れ（Src：ソースIP、Dst：Destination）

　インターネット上のWebクライアントがhttp://www.a.comにリクエストを出し、www.a.comが10.10.1.100に名前解決されると、クライアントはロードバランサ上に割り振られた仮想サーバ（Virtual Server）にアクセスすることになります。それを受けたロードバランサは、4台のサーバのうちで現在動作しているものの中から、設定された負荷分散アルゴリズムに従って最適なサーバ（例えば、192.168.20.1:80）を選択し、そのサーバに処理を割り振ります。クライアントから見ると、ロードバランサの背後のサーバとではなく、仮想サーバとだけ通信しているように見えます。

　また、利用可能なサーバ群の中から最適なサーバを選択する負荷分散アルゴリズムにはさまざまなものが存在します。例えば、順番にサーバが選択されるラウンドロビン方式や、処理しているコネクション数が最少のサーバを選択する最少接続方式、一番速く応答しているサーバを選択する最速方式などが一般的に使われる負荷分散アルゴリズムです。

　サーバに優先度を付け、優先度高のサーバで注文処理などを行い、それらサーバがすべていっぱいになったときに優先度低のサーバで“ただいま混雑しております。後ほどご接続ください”といったメッセージを表示させることも可能です。

サーバ負荷分散を司るNAT（ネットワークアドレス変換)

　もう少し詳しく、クライアント〜ロードバランサ〜サーバ間のパケットの流れを見てみます（図1）。クライアント（172.16.10.55）は自分の最終目的地である10.10.1.100の80番ポートに、ソースポート番号を4003としてアクセスしたとします（図1の（1））。

　ロードバランサは自分の仮想サーバあてのパケットであることを認識し、最適なサーバを選択し（192.168.20.1:80が選ばれたとします）、サーバにパケットを送出しますが、その際にクライアントのソースIPアドレスおよびポート番号はそのままで、あて先IPアドレスおよびポート番号をサーバのもの（192.168.20.1:80）に変換してパケットを送出します（図1の（2））。

　一方、サーバからクライアントへの戻りパケット（図2の（3））は、ロードバランサによってソースIPアドレス／ポート番号がサーバのものから仮想サーバのものに変換され、あて先IPアドレス／ポート番号はそのままでクライアントに到達します（図2の（4））。

図2　パケットの流れ（戻り）

　このように、ロードバランサは仮想サーバ〜実サーバ間の、ポート番号をも含めたNATを行うというのが根本的動作となります。ポート番号の変換も行いますので、例えば仮想サーバのポート番号は80でも実サーバのポート番号は8080といった運用をすることも可能です。

　なお、実サーバからの戻りパケットをロードバランサを通過させるために、実サーバのデフォルトゲートウェイはロードバランサ自身のアドレス（図では192.168.1.1）となっているのが一般的です。

L4スイッチ／L7スイッチでのパケットフローの違い

　ところで、ロードバランサのことをL4スイッチやL7スイッチと呼ぶことがあります。“L”は“Layer”を表し、“4”や“7”はOSI 7層モデルの階層でそれぞれ、トランスポート層（TCP/IPではTCPやUDP）およびアプリケーション層（TCP/IPではHTTPやSIPなど）を指します。現在の多くのロードバランサは設定によりL4、L7どちらのモードでも動作するようになっていますが、そのどちらであるかによってロードバランサを中心に見たパケットフローは大きく変わることになります（図3、図4）。

図3　L4スイッチ

　ロードバランサをL4スイッチとして動作させるときはTCP/UDPの情報までを基にスイッチングを行います。具体的にはポート番号の情報のみで行き先のサーバを決定できるので、10.10.1.100あてにあて先ポート番号80のパケットが来た瞬間（図3のSYNパケット）に、選択したサーバへパケットを送出することができます。

図4　L7スイッチ

　一方、L7スイッチ時はこれに比べて多少複雑になります。L7スイッチの例としては次回に紹介するCookieパーシステンス（Cookieを使用して接続維持を行う機能 ）の使用時や、HTTPヘッダのUser-Agent:を見て携帯向けとブラウザ向けで接続先サーバ群を分ける場合、あるいはSOAPメッセージ内のトランザクションIDをベースに接続サーバを決定する場合などが挙げられます。

　こういった場合は、ロードバランサはCookieなどのHTTPヘッダ、あるいはHTTPボディ部まで見なければ行き先のサーバを決定できないため、それらの情報が得られるまで、サーバの代理でクライアントからの要求に答えます（図4）。

　図4のaにおいて、ロードバランサは必要とするL7の情報が取得できるまでTCP 3-WAYハンドシェークにサーバの代理で応答し、またHTTP要求の中で必要な情報が受け取れるまでサーバの代理でACK（確認応答）パケットを送出します。必要な情報が取得でき、接続サーバを決定できた後は、bにおいてロードバランサからサーバに3-WAYハンドシェークおよびクライアントからのHTTP要求が送出されることになります。

コネクションテーブルで同一サーバにパケットを送る

　ここまでの説明において、以下のような疑問を持たれた方がいらっしゃるのではないかと思います。「図3のSYNパケットを受け接続先サーバを決定後、その後のクライアントからのACKパケットやHTTP要求をどうして同じサーバに振ることができるのだろう」。もちろん、接続要求のためのSYNパケットを送ったサーバと別のサーバにその後のHTTP要求などを送出しても、そのサーバは認識することができません。同一コネクション中のパケットは同一のサーバに送る必要があり、それを実現する仕組みがコネクションテーブルです。

　あるロードバランサ上でトラフィックを処理中にコネクションテーブルの1つのエントリを表示すると以下のような出力になります。

client side client address: 172.16.10.55:1407 client side server address: 10.10.1.100:80 server side client address: 172.16.10.55:1407 server side server address: 192.168.20.1:80 virtual address: 10.10.1.100:80 node address: 192.168.20.1:80 protocol: tcp sequence number from client: 4119024709 sequence number from server: 1293413027

　クライアントからロードバランサに初めのパケットが到着すると、ロードバランサに上のようなコネクションテーブルエントリが作成されます。クライアントからの後続パケットは過去のコネクションテーブルにマッチするか否か判断され、同一コネクションであればエントリ内のサーバに接続します。

　TCPの場合はシーケンス番号まで見て同一コネクションか否か判断されますが、UDPの場合はソースIP／ポート番号が同じであれば一定期間は同一コネクションと判断されます。TCPの場合はFIN（終了処理要求）、ACK、FIN、ACKの4-wayクローズが観察された場合や、RSTパケットによりコネクションテーブルのエントリが消去されます。また、オープン状態のままのエントリは一定期間後に刈り取られます。

　コネクションテーブルのエントリ作成や検索、削除はロードバランサの動作の中心といえるほど本質的なものです。

ルータ負荷分散でのMAT (MACアドレス変換）

　　サーバ負荷分散時にNATが行われることを紹介しましたが、インターネット接続のマルチホーミング（ルータ負荷分散）時やファイアウォールの負荷分散時にはNATではなくMATが行われます。図5はインターネット接続のマルチホーミング時の構成で、IPアドレスがy.y.y.1（MACアドレスaa:aa:aa:aa:aa:aa）のルータとz.z.z.1（MACアドレスbb:bb:bb:bb:bb:bb）のルータ2台をロードバランサで負荷分散しています。

図5　MAT

　クライアント10.10.10.10からインターネット上のx.x.x.x:80へのアクセスを受けたロードバランサがNATを行い、あて先IPアドレスをy.y.y.1やz.z.z.1に変換してしまうと、クライアントからのアクセスはルータまでで止まってしまいます。

　そこで、あて先IPアドレスはそのままであて先MACアドレスをbb:bb:bb:bb:bb:bbといったものに変換することにより、接続する機器を選択する動作がMATです。MATの場合もコネクションテーブルの情報を基に、同一コネクションの間は同一のルータやファイアウォールにパケットを送出し続けます。

　なお、インターネット接続のマルチホーミング時には、パケットを送出したISPと同じISPにパケットが戻ってくるように、あて先MACアドレスの変換に加えて、ソースIPアドレスの変換（図5ではz.z.z.100に変換）も行われますが、ファイアウォール負荷分散時にはこの動作は行われません。

---

次回予告 パケットフローからロードバランサの基本的な概念はご理解いただけましたでしょうか。次回は、サーバヘルスチェック方法やサーバ接続維持方法を中心にご説明します。

ダウンサーバを回避して接続を維持する

関連リンク
	連載：ルータの仕組みを学ぼう 集中連載：DNSの仕組みと運用 連載：基礎から学ぶネットワーク構築「あなたのLANは健康ですか」

「Master of IP Network総合インデックス」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）