（図1）。
図1
それでは、DNSラウンドロビンで返したIPアドレスを持っているサーバーがアクセスできない状態になったらどうなるのでしょうか？
この問題に関しては、ブラウザ側で実装をしてくれています。
複数のIPアドレスを返された場合、接続できるまでアクセスをトライし続けてくれるようになっています。
そのため片方のサーバーが落ちてしまった際も、アクセスができなくなってしまうということは起きません。
しかし、1台だけサービスから外してシステムのメンテナンスを行う際はやはり手間になってまいます。DNSのレコードを 書き換えて、反映をまってという流れになるので、手軽にメンテナンスができる環境とは言い難いでしょう。
バランシングの基本、L4ロードバランサを利用する
さて、サーバー毎のアクセス分散において本命の技術です。ロードバランサ（負荷分散装置）をつかって、サーバーに対してのアクセスを振り分けます。
ここで紹介するのはL4ロードバランサで、OSI階層モデルで言われる第4層（トランスポート層）のレイヤーでアクセスを分散させる装置です。
アクセスをするためのグローバルIPアドレスはロードバランサが保持しています。各サーバーはローカルIPアドレスを保持していて、NATさせてアクセスを分散させます（図2）。
図2
分散の方法は様々な方法を選択することができますが、Least Connectionと呼ばれる方法が一般的です。
これは各サーバーのセッション数を調べ、セッション数がもっとも少ないサーバーに対してアクセスを分散させる方式です。
片方のサーバーだけアクセスを分散させない状態にすることもでき、システムのメンテナンスもやりやすいと思います。
サーバーの障害時もロードバランサに検知させることができます。
ロードバランサからWebサーバーに対して、サービスを可能かどうかチェックをします。
その時、サービスができない状態であれば分散の対象から外してしまい、ほぼサービスを停止させずにすませることができます。
ロードバランサは高価なアプライアンス製品もありますが、Linuxで構築することも可能です。
LVS（Linux Virtual Server）と呼ばれる技術で、ここ最近で注目も高まってきています。
またロードバランサ自体も、VRRPDを使うことで冗長化することができますので、ロードバランサが落ちてしまったときもFailoverをしてサービスを稼働し続けることが可能です。
より柔軟な、L7ロードバランサを利用する
すでにロードバランサの仕組みは紹介していますが、上記の方法では分散できない方法があります。
http://foobar.com/show/ と http://foobar.com/register/ の様に、同一のドメイン内でアクセスを分散させようとした場合です。
上記のURLでアクセスさせるサーバーを振り分けようとしても、L4のバランシングではそれぞれ別のサーバーに分散させることはできません。そのときに活躍する技術がL7バランシングです（図3）。
図3
L7バランシングとは名前の通り、第7層（アプリケーション層）の情報でアクセスを分散させる方法です。
L4バランシングとはまた別の情報をみてアクセスの分散を行うため、より柔軟な設定を行うことができます。
こちらもアプライアンス製品で実現することもできますが、apacheで構築することもできます。apacheに標準で付属している、mod_proxyとmod_rewriteというモジュールを組み合わせて使えばL7のバランシングを実現することができます。
便利に見えるL7のバランシングですが、1点だけ注意しておかなければならないことがあります。
L7で動作するため、CPUリソースを使用しやすいという点です。この点に注意した上で、導入をするようにしましょう。
セッション情報の管理をどうするか
さて、様々な分散方法を紹介してきましたがログインなどをさせるサイトになってくるとユーザーのセッション情報を保持させなくてはなりません。
単一のサーバーでサービスを行っている場合は特に問題にはなりませんが、複数のサーバーでアクセスをうけるとなるとセッションの情報は共通で持っておく必要があります。
Tomcatの場合ですと、Applicationサーバー同士でセッションレプリケーションを行うことができるので問題ありませんが、PHP等の言語をつかっているとこの問題に直面してきます。
この場合、セッション情報はLocalで保存される形式を使用するのではなく外部に保存するようにしましょう。
外部の保存する場所には、memcachedを使用することでより高速に処理を行うことができます。
負荷分散時に注意すべきこと
今回は主にアクセスの分散についての話をしてきました。
しかし、1台でうけていたサービスを複数のサーバーでうけるようになると、思わぬ部分でアプリケーションの誤動作がおきることがあります。
そのためにも、最初の設計段階から分散を視野にいれた設計をするようにしましょう。特にローカルで開発をしている場合は気がつかないことが多いので、負荷分散が行われている環境でテストを行うのが理想的です。
最後に
全3回にわたって、負荷測定の方法から様々なスケールアウトの方法を紹介してきました。
もちろん、ここで紹介している技術はごく一部のものです。スケールアウトに使うことができる技術は他にも様々なものがあります。
低コストでスケールアウトができて、なおかつ保守・運用が楽にできるものはそう簡単にみつけることはできません。
そのためにも、システムを構築する際には、段階を追って増強ができるシステムということを考えるようにしておきましょう。
システムの負荷が原因で、ビジネスチャンスを逃さないためにも。
