ロードバランサ（LB）が2台のWebサーバーにリクエストを振り分けているとします。
このとき、サーバーAには test.html が存在し、サーバーBには存在しない場合、
クライアントからアクセスすると test.html はどう見えるのでしょうか？
実際の挙動
結論からいうと「表示されたり、404エラーになったりする」 です。
ロードバランサは「どのサーバーに処理を振るか」を決めるだけで、
コンテンツの存在までは気にしません。
そのため、
- サーバーAに振られた場合 →
test.htmlが返る - サーバーBに振られた場合 →
404 Not Foundが返る
という挙動になります。
振り分け方式による違い
もう少し正確に説明すると、ロードバランサのアルゴリズムによって、挙動は変わります。
ラウンドロビン
リクエストごとにA → B → A → Bと順番に振り分ける
→ test.html の結果は交互に「表示」「404」になる
最小コネクション方式
空いている方のサーバーに振る
→ 負荷状況によって表示されたい、表示されなかったりする
スティッキーセッション（同じクライアントは同じサーバーへ）
最初にAを引けばずっと表示できる、Bを引けばずっと404になる
このように「サーバーごとにファイルの有無が違う」状態は、ロードバランシング構成においては危険です。
ユーザー体験が不安定になるだけでなく、
「テストでは動いたのに本番では動かない」といった不具合の温床にもなります。
しかも、本番環境ではWebサーバーが2台あるのに、IT環境や検証環境ではサーバーが1台だけ、なんてケースも珍しくありません。
💡なぜIT企業は、開発環境のこういう部分をケチってしまうんでしょうね。
解決策
1. 全サーバーに同じファイルをデプロイする
- 一番シンプルで確実な方法
- CI/CD パイプラインでデプロイを自動化しておくのがベスト
2. 共有ストレージを利用する
- NFS や AWS EFS をマウントして、どのサーバーからも同じファイルを参照できるようにする
- 静的コンテンツの一元管理に向いている
3. セッション固定を使う（暫定策）
- Sticky session を有効化して、同じユーザーを同じサーバーに固定
- ただしスケーラビリティが下がるので推奨はされない
まとめ
ロードバランサ配下のWebサーバーでは、コンテンツを揃えておくことが大前提です。
片方にしかファイルがないと、ユーザー視点では「表示されたりされなかったりする」という不安定な体験になります。
負荷分散環境では、単に「サーバーを増やせば安心！」ではなく、
ファイル配置やセッションの扱いまで含めた設計が必要です。
シンプルな test.html の例でも、意外とシステム設計の奥深さが見えてきますね。
