人気のあるWebサイトやSNSに、世界中から一斉にアクセスが集中したとき、たった1台のサーバーですべてを処理しようとすれば、すぐにパンクしてサイトが停止してしまいます。
これを防ぎ、複数のサーバーにアクセスを効率よく振り分ける「司令塔」の役割を果たすのが、ロードバランサー（Load Balancer：負荷分散装置）です。今回は、第27回で解説した「DMZ（非武装地帯）」内に配置されることも多いこの装置の仕組みと、システムを安定させるための戦略を深掘りします。
ロードバランサーの基本役割：交通整理と安定稼働
ロードバランサーの役割は、文字通り「負荷（Load）」を「均衡（Balance）」させることです。
外部から届いたリクエスト（アクセス）を、背後に控えている複数の「実サーバー（リアルサーバー）」へ適切に分配します。これにより、主に以下の2つの価値を生み出します。
- スケーラビリティ（拡張性）： アクセスが増えても、サーバーの台数を横に増やす（スケールアウト）ことで、サービス全体の処理能力を向上させられます。
- 可用性（アベイラビリティ）： 1台のサーバーが故障しても、他のサーバーが処理を肩代わりするため、ユーザーからはサービスが止まっていないように見えます。
振り分けのアルゴリズム（分配方式）
ロードバランサーが「次はどのサーバーに送るか」を決める方法には、いくつかの代表的なアルゴリズムがあります。
| 方式名 | 特徴 | 適したケース |
| ラウンドロビン | サーバーに順番に1つずつ割り振る | サーバーのスペックがすべて同じ場合 |
| 重み付けラウンドロビン | 性能の高いサーバーに多く割り振る | スペックの異なる新旧サーバーが混在する場合 |
| 最小接続数 (Least Connections) | 現在の接続（セッション）数が最も少ないサーバーを選ぶ | 一つひとつの処理時間がバラバラな場合 |
ヘルスチェック：故障サーバーの自動切り離し
ロードバランサーの最も重要な機能の一つが「ヘルスチェック」です。これは、背後のサーバーが正常に動作しているかを定期的に確認する監視機能です。
もし応答がない、あるいはエラーを返すサーバー（死んでいるサーバー）を検知すると、ロードバランサーは即座にそのサーバーを配信リストから除外します（切り離し）。そして、サーバーが復旧したことを確認できれば、再び自動的にリストに戻します（組み込み）。この仕組みにより、24時間365日のサービス継続が可能になります。
セッション維持（パーシステンス）とCookie
第1回で学んだ「Cookie（クッキー）」によるセッション管理を行っている場合、ロードバランサーによる「振り分け」が問題になることがあります。
例えば、サーバーAでログイン処理をしたのに、次のページ遷移でロードバランサーがサーバーBに飛ばしてしまうと、サーバーBはログイン情報を知らないため「未ログイン」扱いになってしまいます。
これを防ぐのが「セッション維持（スティッキーセッション）」です。Cookieや送信元IPアドレスを利用して、特定のユーザーからのアクセスは一定期間、必ず同じサーバーへ送るように制御します。
L4ロードバランサーとL7ロードバランサーの違い
ロードバランサーには、OSI参照モデルのどの階層で判断するかによって、大きく2つのタイプがあります。
L4ロードバランサー（L4スイッチ）
第5回で学んだ「ポート番号」やIPアドレスなどのトランスポート層までの情報で判断します。
- メリット： データの中身を深く解析しないため、非常に高速に処理できます。
- デメリット： 「URLのパス」や「Cookieの中身」に応じた細かな振り分けはできません。
L7ロードバランサー（L7スイッチ）
HTTPヘッダーやURL、Cookieなどのアプリケーション層（L7）の内容を見て判断します。
- メリット： 「画像ファイルへのアクセスは画像専用サーバーへ」といった高度な振り分けが可能です。また、SSLの複合処理（SSLアクセラレーション）も担当できます。
- デメリット： パケットの解析が必要なため、L4に比べると処理負荷が高くなります。
まとめ
ロードバランサーは、現代のクラウドや大規模Webサービスにおいて、決して欠かすことのできない「縁の下の力持ち」です。
- 負荷分散によってサーバーのパンクを防ぎ、ヘルスチェックで可用性を高める。
- DMZの背後に配置され、外部からの窓口として機能する。
- セッションを維持するためにCookieなどの知識とセットで運用される。
インフラエンジニアは、これらの特性を理解した上で、トラフィックの性質に合わせた最適なアルゴリズムや構成を選択する必要があります。
コメント