アクセスを1台のサーバに集中させると、その1台が限界になったり壊れたりすると全滅します。ロードバランサは、利用者からは1つの窓口（仮想IP）に見せておき、裏側の複数の実サーバに振り分けます。故障したサーバはヘルスチェックで自動的に外す。だから増やせる・止まらない、が成立します。
利用者は実サーバのIPを知りません。接続先は仮想IP（窓口）だけ。ロードバランサがその裏で「今どの実サーバに渡すか」を決めて転送します。実サーバの増減や故障は窓口の内側の話で、利用者からは見えません。
振り分けの流れ
振り分け方式は「順番に（ラウンドロビン）」「今いちばん空いている所へ（最少接続）」など。ヘルスチェックで応答しないサーバは振り分け先から外れるので、1台落ちても窓口は生き続けます。
動きで見る
利用者は窓口（ロードバランサ）しか見えず、その裏で健全なサーバへ振り分けられ、次の要求は別のサーバへ分散される様子を追えます。（図は横スクロールできます）
ポイントは「窓口（仮想IP）と実サーバの分離」＋「健全な所だけに配る」。設問では「なぜ1台故障しても継続できるか（＝ヘルスチェックで外す）」「同じ利用者を同じサーバに寄せる必要（＝セッション維持）」「増設で処理能力を上げられる理由」が問われます。利用者は窓口しか見ていないと掴むと、増減・故障の設計が追えます。
ログイン状態などのセッション情報を各サーバが自分の中だけに持つと、次の要求が別サーバに振り分けられた瞬間に「ログインが切れた」ことになります。だから同じ利用者を同じサーバへ固定する（セッション維持）か、セッションを共有の置き場に持つ必要があります。「分散したら状態が壊れる」を見落とさないのが急所。
SC向け：終端・維持・追跡で問われる
ロードバランサは通信の通り道の要にいるので、SC/NW午後では「暗号をどこで解くか」「本当の利用者は誰か」「状態をどう保つか」が設計・検査の論点になります。
攻撃・リスク
- TLS終端で内部が平文：ロードバランサでTLSを終端（復号）すると内部区間が平文になり、そこが保護されていないと盗聴・改ざんの余地になる。検査点＝終端位置なので、終端の外側は見えない。
- 送信元IPの消失：背後のサーバから見た送信元がロードバランサになり、本来のクライアントIPが消える。X-Forwarded-For等のヘッダは詐称可能で、そのままアクセス制御やログの根拠にすると偽装される。
- セッション維持方式の穴：スティッキー用のCookie固定・偽装や、送信元IPベースの維持がNAT配下で崩れるなど、維持方式ごとに弱点がある。
効く対策
- 内部区間の保護：終端後にバックエンドへ再暗号化する、または区間の信頼を物理・論理で確保する。検査（WAF/IDS）は終端位置に置いて可視化する。
- 信頼境界を意識したIP補完：X-Forwarded-For等で本来のクライアントIPを補うが、信頼できる自組織のロードバランサが付けた値だけを採用し、上流由来の値は破棄する。
- 状態設計とヘルスチェック：状態を持つアプリは維持方式を明示（Cookie／送信元IP等）し、共有の置き場に持たせる。ヘルスチェックで落ちたサーバへ振らず可用性を保つ。
午後では「TLSをどこで終端し、どこで検査するか」「本当のクライアントIPをどう扱い、どこまで信頼するか」が判断軸として問われます。