いつもお世話になっているロードバランサーについて、ゆるい日本語でまとめる。
そもそもロードバランサーとは
ユーザーからアプリケーションサーバの間に立ち、負荷分散をするための装置や機構のこと。
サーバを複数用意して冗長化した場合に、よしなに処理を分担させて、システム全体の平和を保ってくれる存在。
上記の図は一例で、どのようによしなに分担させるかにも色々ある。
ロードバランサーの種類
ハードウェアロードバランサとソフトウェアロードバランサ
バランシング専用の機器を用意して、そいつで負荷分散をするのがハードウェアロードバランサ。
それ専用に用意されている機器なので、パフォーマンスはよいがとてもお金がかかる。
対して専用機ではないマシンでバランシング機能をソフトウェアで実現するのがソフトウェアロードバランサ。
アプリケーションサーバと同じような通常のサーバや仮想サーバで実現できる。
L4ロードバランサとL7ロードバランサ
ソフトウェアロードバランサの種類。
通信レイヤのどの層に設置されているのかで変わる。
それぞれできることが違うので、併用する場合もある。
L4ロードバランサ
通信レイヤの第4層（トランスポート層）で負荷分散をするロードバランサ。
セッション単位で負荷分散をする。
トランスポート層はリクエストの転送先に通信を届けるのが使命の層で、
どのようなリクエスト内容だとかまでは知らないため、セッション単位での振り分けしかできない。
その分やることが簡単なので、処理は早い。
L7ロードバランサ
通信レイヤの第7層（アプリケーション層）で負荷分散をするロードバランサ。
リクエスト単位で負荷分散をする。
この層ではURIやUAなど詳細なリクエスト内容を取り扱うので、それらに基づいた細かい負荷分散ができる。
このURIの場合だけあちらのサーバに渡す、このUAならばこちらに…みたいなこともできる。
高性能な分利用料が高くなったり、設定が複雑になることがある。
関連話：ロードバランサの機能あれこれ
Persistence 接続維持
同じリクエスト元からの処理は同じサーバーに流したいよ〜という話。
L4はそもそもセッション単位の負荷分散を行なうので、リクエスト元のIPで判断させれば容易に実現できる。
L7の場合はCookieを使うなどして、複数のリクエスト同士の繋がりを示すための工夫が必要。
ヘルスチェック
バランシングする対象のサーバ達が元気に生きているのかを管理する。
定期的に生きてる（アクティブ）か確認するアクティブヘルスチェックと、
リクエスト失敗という死を検知して切り離すだけのパッシブヘルスチェックがある。