今回は、ロードバランシング（Loadbalancing）とクラスタリング（Clustering）について見ていこう思います。
ロードバランシング（Loadbalancing）とは
ロードバランシングとは負荷分散のために仮想（Virtual）IPをとうして複数のサーバに接続できるように分散する機能を言います。簡単に言うと負荷分散の機能ですね。
- １つのインターネットサービスが発生するトラフィックが多い時に複数のサーバが分散処理してサーバのロード率を増加、負荷量、速度低下などを考慮して適切に分散処理してくれるサービスです。
- ロードバランシングは一つのサービスを一つ以上のノードが処理を行う仕組みです。
- ロードバランシングを利用すると一つのサーバーが落ちても他のサーバがサービスを続けることでユーザーは問題を認知できないようにすることができます。
- リクエスト処理のアルゴリズムには以下のようなものがあります。
- ランダム
- ラウンドロビン
- CPUやメモリ使用率による分散
- ロードバランシングを行なってくれるSW（ソフトウェア）またはHW（ハードウェア）のことをロードバランサーと言います。
- ロードバランサーの目的は同時に届く数多くのコネクションを処理し、該当コネクションがリクエストノードの中で１つに届けられるようにすることです。
ロードバランシングの種類
- L2
- Macアドレスを基盤にロードバランシングを行う。
- L3
- IPアドレスを基盤にロードバランシングを行う。
- L4
- Transport Layer（IPとPort）Levelでロードバランシングを行う。
- TCP、UDP
- L7
- Application Layer（ユーザーのリクエスト）Levelでロードバランシングを行う。
- HTTP、HTTPS、FTP
ロードバランシング障害の対策
- 複数のロードバランサーをクラスタリングできるように設けます。（今回は２つを例とする。）
- ２つのロードバランサーはお互いにHealth Checkを行います。
- ロードバランサーをMaterサーバとStandbyサーバ構成し、Masterサーバが落ちたらStandyサーバが自動的にMasterサーバの役割を行います。
- Standbyサーバーは普段は待機しつつMasterサーバーが落ちた時だけ動きます。
上記の構成を「Fail Over」と言います。
※クラスタリング：複数のサーバーを一つの作業を行われるように作ること。一つのサーバーで障害が発生しても残りのサーバーが代わりに作業を行えます。
ロードバランシングのデメリット
- ロードバランサーの使用時に課題はセッションデーターを管理することです。
- クライアントの接続情報（ログイン情報）を保存するセッションがロードバランシングを通じて一つのサーバー（Aサーバー）に保存される場合、次に接続時に他のサーバー（Bサーバー）にロードバランシングされたらセッション情報が維持できない問題があります。
つまり、先ログインしたのにまたログインしてくれとログイン画面へ遷移かエラーが発生するかもしれないです。
ロードバランシングのデメリットの対策
対策としては大きく以下の２つがあります。
- セッションを固定する。（Session Sticky）
- セッションクラスタリングを使用する。
Session Sticky
- 最初のリクエストに対してレスポンスしたサーバーを固定すること
- 特定セッションのリクエストは最初に処理したサーバーだけにすること
Session Stickyのデメリット
- 特定サーバーだけ過負荷になる可能性があります。
- 固定されているサーバーが落ちたときにセッション情報を失う可能性があります。
- このようなデメリットのためにセッションクラスタリング方式が登場しまた。
セッションクラスタリング（Session Clustering）
- 複数のサーバー（WAS）のセッションを同一セッションとして管理することです。
- 一つのサーバー（WAS）が落ちても落ちたサーバーが保存していたセッションは他のサーバーに移動され、そのサーバーがセッションを管理します。
- セッションクラスタリングの種類は以下となります。（詳細は次回に）
- WAS構成
- セッションサーバー構成
- セッションデータグリッド構成
- Scale out観点から見てみるとSession Server（Redisなど）を利用して管理した方がいいです。
Redisを使ってセッションクラスタリングをする
Javaではありますが、Redisを使ってセッションクラスタリングを行うコードはこちらを参考してくださ。
諦めなければできる - Anveloper 