サーバー負荷分散技術

　「WebサーバーのURLなど、ユーザーがアクセスするときに使うあて先を変えずに，複数サーバーに処理を分散させる」。これが，サーバー負荷分散技術の目的だ。
　サーバー負荷分散技術は，クライアントからのアクセスを，複数台のサーバーに振り分けて処理を分散する。実際の負荷分散の方法は，DNSに問い合わせたクライアントに対して，異なるWebサーバーのIPアドレスを返答する方法や，専用製品を利用してアクセスを様々な方法で分配する方法などがある。いずれも，１台のサーバーでは限界がある処理能力を複数台のサーバーで分担することで，処理性能を向上させるのが狙いだ。

図　Webサイトの安定運用を実現するサーバー負荷分散技術

　サーバー負荷分散技術は，電子商取引（EC）の台頭で一躍注目を集めた。ECサイトを運営する事業者にとっては，インフラとなるWebサーバーなどのシステムがスローダウンすることは許されない。応答性の低下はそのまま収益に響くからだ。
　Webサーバーの負荷分散の場合，「1台のサーバーが受けるHTTPリクエストの同時処理数が300に近づいたら検討するユーザーが多い」。データ容量の大きいストリーム・データなどを扱う場合はそれよりもさらに少ないリクエスト数でも負荷分散が必要になる。
　処理性能の向上のほかにも，サーバー負荷分散技術は二つのメリットをもたらす。一つは，耐障害性が高められること。もう一つは，サーバーの拡張が容易になることだ。１台のサーバーがダウンしても，残りのサーバーが処理を引き継ぐことで耐障害性は向上する。サイトそのものを止めずに，サーバーを切り離したメンテナンスも容易だ。
　さらに，サイトの運用を始めた後も，サービスを止めずに継続的にサーバーを増設することで拡張性も高められる。サイト開設時からそれほどのアクセスを見込めなくても，クライアントの増加と共にサーバーを増設すれば良い。そのため，「多くのサイトが開設時から先の拡張を見越して複数サーバーで運用する」。
　サーバー負荷分散技術は，①どのサーバーがアクセスを処理するかを決めるアルゴリズム，②実際にパケットを振り分ける方法，③アプリケーション・レベルでアクセスを同一サーバーに固定するためのセッション管理，④サーバーの障害検知の４種類の技術で構成する（図１）。

図１　サーバー負荷分散に要素技術は４種類

　①のサーバー決定アルゴリズムは，クライアントから受け取ったデータ・パケットをどのサーバーが実際に処理するかを決めるもの。サーバー群に事前に優先順位を設定して順番にアクセスを振り分ける方法や，サーバー同士で負荷状況などの情報をリアルタイムに交換しながら処理サーバーを決定する方法などがある。
　アクセス先のサーバーが決定したら，②により，該当するサーバーヘパケットを振り分ける。負荷分散の形態により，実際に処理するサーバーヘ向けて様々な方法でパケットを送る。
　複数のサーバーで処理を分散する一方で，同じクライアントからのアクセスを意図的に同一サーバーに固定したい場合がある。この時に必要となるのが，③のセッション管理だ。特に，ECサイトでクライアント情報を管理する場合などに不可欠。サーバーの稼働状況を監視する④の技術も，サーバー負荷分散技術には必要な要素となる。
　クライアントからのアクセスに対して，サーバー負荷分散技術がまず判断するのは，「アクセスをどのサーバーに振り分けるか」という点。最適なサーバーを決定するには，様々な情報を参照する。具体的には，，①ラウンドロビン，②重み付けラウンドロビン，③優先順位，④最小接続数，⑤最速応答時間，⑥CPU負荷といったアルゴリズムが代表的である（図２）。

図２　負荷分散装置の多様な振り分けアルゴリズム

　このうち，最も一般的な方式がラウンドロビンだ。クライアントから受けたアクセスを，負荷分散するサーバー群に順番に処理を振り分ける、（図２の①－Ａ）。「振り分けるWebサーバーの処理性能に違いがない時は，ラウンドロビンで負荷分散する場合が多い」。
　処理を受け持つ個々のサーバーの性能が異なる場合は，重み付けで差を調整する（図２の①－Ｂ）。処理性能の高いサーバーには他よりもアクセスを多く振り分けるように設定する。この方式は，「処理能力の違うサーバーで負荷分散する場合に特に効果的」。
　処理能力の差を調整する点では，優先順位方式も有効である。具体的には，各サーバーの優先順位を決めておき，一定のアクセス数を割り当てたら次の優先順位のサーバーに処理を振り分ける（図２の①－Ｃ）。
　ラウンドロビン，重み付け，優先順位の３方式は，振り分け先のサーバーの負荷状況に関係なく，事前に設定した順番でアクセスを振り分ける。いわば“静的”な方法だ。時には，処理負荷の重いサーバーに続けてアクセスが割り振られることもある。
　一方で，個々のサーバーの状況を定期的に監視して，その都度最適なサーバーに処理を“動的”に振り分けるのが，最小接続数，最速応答時間，CPU負荷の３種類の方法だ。
　最小接続数は，クライアントとの間に張ったセッション数が最も少ないサーバーを選ぶ方法（図２の②－Ａ）。ただし，セッション数は同じでも，実際にやり取りするデータ量が違う場合もある。専用の負荷分散装置が測定用パケットを送信し，応答時間が最短のサーバーに処理を振り分ける方法なら，状況をより正確に把握できる（図２の②－Ｂ）。
　CPUの負荷状況を監視して，負荷の低いサーバーへ処理を分配する方法もある（図２の②－Ｃ）。ただし，実際はCPUの処理負荷だけではサーバーの負荷状況を完全には把握できない。このため，「他の方式と組み合わせて利用するケースが多い」。
　これらのアルゴリズム以外にも，送信元IPアドレスやTCP/UDPのポート番号を指定して，振り分けるサーバーを決めておく方法もある。この方法を使うと，特定の企業やインターネット接続事業者（プロバイダ）のユーザーからのアクセスを同一のサーバーに振り分けたり，WebアクセスとFTPを別のサーバーで処理させるなどの操作が可能になる。
　クライアントのアクセス処理を受け持つサーバーが決定したら，次は実際に該当するサーバーに処理を振り分ける。その方法には，DNSを使うケースと，専用製品を使う場合の２通りがあるが，最も初期から利用されているのが，DNSを使った仕組みだ。
　DNSを使う方法では，処理を受け持つWebサーバーに個別のIPアドレスを割り当てておき，アドレスの問い合わせがあるたびに異なるIPアドレスを順番に返す（図３）。

図３　DNSサーバーのラウンドロビンによる負荷分散

IPアドレスを返信するアルゴリズムには，ラウンドロビンやランダム・ラウンドロビンなどの方式がある。DNSサーバーがクライアントを順次違うサーバーに誘導することで，処理を分散できる。
　DNSを使った負荷分散は，DNSの設定だけで比較的簡単に利用できる。さらに，専用の負荷分散装置と組み合わせることで，地域的に離れた複数のサイトを連携させた高度な負荷分散を実現することも可能である（別掲記事を参照）。
　一方，サーバー負荷分散の専用製品の場合，アクセスを処理するサーバーにパケットを振り分ける形態は２種類ある。クライアントからのアクセス要求をすべてのサーバーが受ける「サーバー・サイド型」と，サーバー群の前に設置した負荷分散装置がアクセスを振り分ける「フロントエンド型」だ（図４）。

図４　Webサーバーの負荷分散は２種類の形態がある

　フロントエンド型の負荷分散形態は，専用製品が受け付けたクライアントのアクセスをWebサーバーに効率的に振り分ける。専用製品は，負荷分散のアルゴリズムに基づいて特定のサーバーに処理が集中しないようにバランスを取る。中には，Webサーバーにソフトを実装して負荷状況を定期的に通知させ，アクセスを分配する製品もある。
　一方のサーバー・サイド型の負荷分散製品はすべて，負荷分散に利用するサーバーに専用ソフトをインストールする形態。このソフトが，各種アルゴリズムを使って処理するサーバーを決定し，そのサーバーとクライアントの間で通信を実行する（図４の上）。
　サーバー・サイド型の負荷分散は，製品導入の際に現状のネットワーク構成を特に変更する必要はない。このため比較的導入が容易である。
　サーバー・サイド型の負荷分散の実現方法について，詳しく見てみよう。
　アクセスを受けたサーバーが，実際にパケットを受信するかどうかは，レイヤー２とレイヤー３の間にインストールした負荷分散ソフトの専用ドライバが判断する（図５）。

図５　サーバー・サイド型の負荷分散の仕組み

　各サーバーにインストールしたドライバは，専用のプロトコルを使って，定期的に互いのCPU稼働率や処理中のセッション数などの情報をやり取りし，保持する。こうした情報から各サーバーの稼働状況を見比べ，パケットを受け取るサーバーを決める。事前にIPアドレスやTCP/UDPのポート番号を基に処理を担当するサーバーを設定することもできる。パケットを受け取るサーバーが決定した時点で，ほかのサーバーはパケットを破棄する。
　サーバー・サイド型の負荷分散の特徴は，すべてのサーバーがアクセスを受け付ける点。Windows2000のサーバー製品にサーバー・サイド型の負荷分散機能を持たせたマイクロソフトは，「１カ所でアクセスを受けてパケットを転送するフロントエンド型に比べて，個別のサーバーで不要なパケットをフィルクリングするので処理が速く，ボトルネックが発生しにくい」）という。
　サーバー・サイド型は，すべてのサーバーがクライアントからのデータ・パケットを受け取る必要がある。そのため，個々のサーバーには，あて先が共通の仮想IPアドレスを割り当てる。レイヤー２（MAC層）でも，受け取ったイーサネット・フレームをすべてのサーバーにブロードキャスト（同報）する必要があるため，サーバー群のフロントエンドには，ハブかレイヤースイッチを設置する。
　レイヤー２スイッチの場合は，サーバーからクライアントに送信するパケットの送信元MACアドレスをマスクするなどして，スイッチのアドレス学習機能を停止させる必要がある。こうすることで，スイッチがMACアドレスとLANポートを対応付けることを防ぎ，すべてのサーバーにパケットをブロードキャストする。
　専用製品が一手に受けたアクセスを振り分けるフロントエンド型は，仮想IPアドレスで受けたパケットのアドレス情報を，実際に処理するサーバーのアドレスに書き換えて送り出す。

図６　負荷分散装置のアドレス変換処理は２通り

　このアドレス変換処理には，IPアドレスとMACアドレスを書き換える方法と，MACアドレスだけを書き換える方法の２通りがある。 IPアドレスとMACアドレスの書き換え処理は以下のようになる（図６の上）。クライアントが送信したデータ・パケットは，負荷分散装置に集まる。負荷分散装置は個々のIPパケットのあて先IPアドレスを，実際に分配するサーバーの実IPアドレスに変換する。反対に，サーバー側からのパケットについては送信元IPアドレスを負荷分散装置内で仮想IPアドレスに変換する。
　この変換処理により，クライアントから受けるサイトのIPアドレスは一つで済む。クライアントからは，あたかも仮想IPアドレスのサーバー１台と通信しているように見える仕組みだ。
　ただし，この変換処理方法を取る場合，クライアントとサーバーを往復するパケットは，必ず負荷分散装置を経由する。「ストリーム・データなどの大容量のファイルを送信する場合や，同時アクセスが想像以上に多い時は，負荷分散装置自身がボトルネックとなりダウンする可能性もある」。
　そのため，クライアントからWebサーバーにアクセスする時にだけ負荷分散装置で変換処理をして，サーバーからクライアントへは直接データを送る方法もある。MACアドレスだけを書き換える方法である。
　具体的には，次のような方法で実現する。負荷分散装置は，クライアントから受けたIPパケットのアドレス情報には変更を加えずに，イーサネットフレームのあて先MACアドレスだけをWebサーバーのものに付け替える。こうすることで，サーバーからクライアントヘの応答は，負荷分散装置を経由せずに済む（図６の下）。
　この方法ではサーバーからクライアントヘ直接データを送信するため，送信元のIPアドレスがクライアント側に残る。Webサーバー個々のアドレスがそのまま残ってしまうと，それ以降はクライアントが個々のWebサーバーあてにアクセスするようになり，負荷分散がうまく機能しなくなる。
　そのため，各サーバ㌻には，実IPアドレスとは別に，負荷分散装置の仮想IPアドレスをループバック・アドレスとして設定しておく。こうすることで，Webサーバーがクライアントに返信する送信元アドレスは，負荷分散装置の仮想IPアドレスになり，各サーバーの実IPアドレスがクライアントに保持されるという問題を回避できる。
　また，MACアドレスだけを書き換えるため，負荷分散するサーバー群は同じサブネットにつなぐ必要がある。
　サーバー負荷分散技術を使えば，クライアントからのアクセスは，負荷分散製品に設定したアルゴリズムに基づいて複数のサーバーに効率的に振り分けられる。
　しかし，TCPの一連の処理では，データは複数のIPパケットに分割されているケースが一般的。つまり，一つのTCPセッション中のデータが，複数のパケットに分割されてサーバーに送信されてくる。分割されたパケットは，受け付けるサーバーが同じでなければTCP処理を継続できない。
　そのため，フロントエンド型の負荷分散装置はデータ・パケットのIPヘッダーやTCP/UDPヘッダー情報を組み合わせて，振り分け先のサーバーを識別する（図７）。

図７　負荷分散装置が振り分けに参照する情報

　さらに，一つのTCPセッション中のデータのあて先を固定するだけでなく，TCPセッションが一度切断された後も，再び同じサーバーに接続する仕組みを備える負荷分散製品もある。この機能がセッション管理機能である。
　特にECサイトなどで，あるクライアントからの通信を同一サーバーに固定する時に使う。ショッピング・カート機能では，クライアントが複数のページにまたがった買い物をしている途中で，別のサーバーに処理を振り分けてしまうと，ユーザーのステータスに矛盾が出る可能性があるからだ。
　セッション管理は，負荷分散装置が上位レイヤーの情報を参照して，“目印”付けておき，切断された後は再びその目印を参照して同一サーバーに固定することで実現する。
　目印とする情報は通常，送信元のIPアドレスを使う。同じ送信元IPアドレスを同一サーバーに振り分ければ，セッションは固定できる。しかし，プロキシてサーバーを使う企業からのアクセスなど，同じ送信元IPアドレスから多数のアクセスが来ると，処理するサーバーが偏ってしまい，負荷分散がうまく機能しない。
　そのため，現在は「Webサーバーからクライアントに何らかの識別情報を与えて確認する方式が一般的」）だ。代表的な識別情報が　SSLセッションIDとCookie（図８）。

図８　Cookie情報を基にアクセスを同一サーバーに固定する

ただし，SSLセッションIDの場合，Webブラウザによっては定期的にIDが書き換わるため，通常のECサイトでは「セッション管理にはCookieを利用するケースが多い」。
　しかし，Cookeを利用する際も，SSLでデータが暗号化されていると，識別には利用できない。その場合は，内部でSSLデータを処理して，暗号化されたCookieを読み取る機能を持つサーバー負荷分散装置が必要になる。
　負荷分散装置はセッション管理のほかに，サーバーの状態を監視する「へルス・チェック」機能を備える。稼働状況を常にチェックして，振り分け可能なサーバーや異常の発生を把握する（図９）。

図９　サーバーの障害通知は３段階で実施する

　ヘルス・チェック機能は，多くの製品が３段階のレベルで実施する。最も多いのが，レイヤー３で実現するpingコマンドを使った稼働状況のチェックだ。ただし，pingに対するレスボンスだけではTCP/IPの通信機能が正常に機能しているかどうかまでしか分からない。上位層のアプリケーションの稼働状況を調べるために，負荷分散装置の方からレイヤー４レベルでTCPコネクション要求を出し，ポート単位で実際にコネクションが張れるかどうかまでチェックする製品も多い。
　これにより，例えばポート番号80のHTTPサービスと，ポート番号20/21を使うFTPサービスなどの状況を個別にチェックできる。「ポートごとに細かくチェックすることで，より正確に振り分け可能なサーバーの状況を把握し，効率的に負荷分散できる」。
　さらに，レイヤー５以上のアプリケーションの動作状況を調べられる製品もある。例えば，HTTPの手順であるGETリクエストにデータベース検索プログラムやファイル要求プログラムを記述することで，Webサーバーのバックエンドにあるデータベース・サーバーや，アプリケーション・サーバーなどのヘルス・チェックも可能となる。

トップページへ