ロードバランサー

🐾 猫で例えると？

並んで座る2匹を、順番におもちゃを渡される担当者に見立てましょう。2匹がバックエンドサーバー、どちらへ渡すかを決める飼い主がロードバランサーです。猫が2匹いるだけでは仕事は分散されません。振り分ける窓口と、各担当が同じ仕事を引き受けられる準備が必要です。

💻 インターネットとクラウドにおける「ロードバランサー」とは？

テレビ番組で紹介されたWebサイトや、人気のECサイトのセール開始直後など、短時間に数万～数百万人ものアクセスが一斉に集中することがあります。もし1台のWebサーバーだけでこれらすべての要求を受け止めようとすると、サーバーのCPUやメモリが即座に限界を迎え、画面が真っ白になってフリーズ（システムダウン）してしまいます。

この問題を解決するため、本番のシステムインフラでは同じ機能を持つサーバーを複数台並列に並べ、その手前に「ロードバランサー（LB）」を配置します。ユーザーからのアクセスはすべて一度ロードバランサーが窓口として受け止め、裏側にあるサーバー群の空き状況や負荷状況を見極めながら、「次は1号機へ」「その次は2号機へ」と機械的に通信を振り分けます。これにより、サイト全体の処理能力を何倍にも引き上げることが可能になります。

⚠️ ロードバランサーの仕組みと注意点

ロードバランサーは単にアクセスを散らすだけでなく、裏側のサーバーが正常に動いているかを常に監視する「ヘルスチェック」という超重要な機能を備えています。もし3号機が壊れて応答しなくなった場合、ロードバランサーは自動的に3号機への振り分けをストップし、生きている1号機と2号機だけで運用を継続させます（障害の局所化）。

代表的な振り分けアルゴリズム（ロジック）の例

以下は、ロードバランサーがクライアントからの接続リクエストを、どのようなルールに基づいてバックエンドサーバーへ割り振るかを示したイメージです。

ラウンドロビン：順番に振り分ける。件数が均等でも処理時間は同じとは限らない。
最小接続数：現在の接続が少ない相手を選ぶ。CPU負荷を直接測る方式ではない。
IPハッシュ：送信元IPを手がかりに選ぶ。複数人が同じIPを共有すると偏り得る。

カート情報を各サーバーのメモリだけに置くと、振り分け先の変更で状態を引き継げません。接続先を固定する方法のほか、共有ストアへ状態を保存して、どのサーバーでも処理できるようにする方法があります。固定先が故障したときの扱いも含めて選びます。

🛠️ ロードバランサーを賢く使うためのポイント

クラウド（AWSのALB/NLBなど）やオンプレミスインフラで分散ネットワークを設計・運用するエンジニアは、可用性を最大化するための構成構築に配慮する必要があります。

• ロードバランサー自体の冗長化（SPOFの排除）： すべてのアクセスを集約するロードバランサー自体が1台きりで壊れてしまっては元も子もありません。通常はActiveとStandbyの2台構成（あるいはクラスター化）にしておき、LBのダウンに備えます。
• TLS終端の場所を決める： LBでHTTPSを終端して証明書管理をまとめる構成があります。LBからバックエンドまでをHTTPにするか、再びTLSで暗号化するかは、ネットワークの信頼境界や要件に応じて決めます。
• 台数の増減に備える： 新しいサーバーは起動しただけでなく、処理の準備が整ったことを確認してから対象へ加えます。減らす際も処理中の接続をどう終えるかを決め、共通DBなど別のボトルネックも調べます。

2匹で場所を分け合うように、ロードバランサーは要求の送り先を振り分けます。ただし台数を増やすだけで無制限に処理できるわけではありません。送り先の稼働状態、セッションの扱い、共有するデータベースの負荷も確認しましょう。