こんにちは！コンビニで売ってるマテ茶が好きすぎて毎日買ってしまいます。
中薗と申します_(:3」∠)_

あまりに買いすぎてて、コンビニの店員さんに変なあだ名をつけられて
いるんじゃないかと心配でなりません。
さて、今回は「ロードバランサ」についての話をさせていただきます。

サーバが複数台ある場合に、そのサーバ資源をフルに使うための装置。
それがロードバランサの役割です。

ロードバランサを使用した場合の、処理の流れを見ていきましょう。
クライアントからリクエストがあった際に、
ロードバランサはその全ての要求をいったん受け取ります。

そして、受け取った処理を一定の規則に従って後続のサーバに対してリレーします。

その規則は様々なものを設定出来るのですが、
例えば「ロードバランサとのコネクション数が最も少ないサーバに対してリレーする」
という設定をしていた場合には、
上図の例ですとWebサーバ②、③よりもWebサーバ①の方がコネクション数が少なければ
ロードバランサはWebサーバ①に対して仕事を割り振ります。

このような仕組みを取ることで、前回までのサーバ構成では不可能だった
「全てのサーバを無駄なく使う」ということが実現できています。
しかし、ロードバランサの仕事はこれで全てではありません。
この機能に加えて、「サーバヘルスチェックとサーバ接続維持」という
重要な機能が存在しています。

まずはサーバヘルスチェックについて。
これは、正常に応答を返さないサーバにユーザのリクエストを割り振らないように
ロードバランサが常時行っている作業です。

接続確認の方法としては、以下のようなものがあります。
1.ICMP監視
サーバに対してICMP echoリクエストを送付し、echoリプライが返ってくるかどうかをチェック。最も負荷が軽いが、特定のプロセスがダウンしている場合（tomcatが停止しているなど）は検知することが出来ない。
2.ポート監視
TCPによる接続を試み、接続出来るかどうかをチェック。
Webサービスがダウンしたことは検知できるが、過負荷状態で応答出来なくなっていたり、
エラーを返していることは検知できない。
3.サービス監視
サーバに対して実際にHTTPリクエストなどを発行し、正常な応答が返ってくるかをチェック。ほとんどの異常を検知できるが、場合によってはヘルスチェック自体がサーバに負荷をかけてしまう。

次に、サーバ接続維持についてです。
これは、同一クライアントからの“複数のコネクション”を
同一のサーバに割り振り続けるための機能です。

例えばショッピングサイトで買い物をし、「本」と「CD」を購入したとします。
その際に、「本をカートに入れる」という処理と「CDをカートに入れる」という処理が
別々のサーバに割り振られてしまうと、後者のサーバはユーザーが先に入力した情報を知らないため、正常な処理を行うことが出来なくなってしまいます。

そうした事態を防ぐために、“同一ユーザーからのリクエスト”を
“同一サーバによって処理”するための仕組みが必要になります。
それがサーバ接続維持の機能です。

接続維持の方法としては、以下のようなものがあります。

1. ソースIPアドレス
クライアントのIPアドレスが同じであれば、一定期間同じサーバにリクエストを割り振り続ける方式。
Proxyサーバが負荷分散されている環境などで、リクエストごとにクライアントのIPアドレスが変化する環境では使用することが出来ない。
また、多数のリクエストが同一のアドレスで来る場合は、リクエストが割り振られるサーバに偏りが生じてしまう。
2. SSLセッションID
SSLセッションIDが同一の間は同一のサーバに割り振る方式。
SSL通信の場合にしか使用することが出来ない。
最近のブラウザではセッションIDが一定時間ごとに変更されてしまうため、
現在はあまり使用されない。
3. Cookie
Cookieの中に前回アクセスしたサーバの情報を埋め込み、
次回のクライアントリクエスト時にロードバランサでその情報を読み取って
同一サーバにリクエストを割り振る方法。
現在非常に多くのサイトで使用されている。

ロードバランサについての解説は以上となります。

 

【関連記事】
サーバの冗長化について①
サーバの冗長化について②
負荷試験について