Webサーバーの冗長化とは？ セッション共有・フェールオーバー・DBトランザクションを図解で理解する

01｜予約ボタンを押した瞬間にサーバーが止まったら

例えば、予約サイトで日時と人数を選び、「予約する」を押す場面を考えてください。画面はNext.js、認証はSupabase Auth、予約データはPostgresという構成が一例です。押した直後に処理担当のサーバーが停止すると、通信が失敗したり、結果が分からなくなったりします。

02｜まずWebサーバーとデータベースの役割を分けます

Webアプリは一つの箱に見えますが、画面を提供する部分、リクエストを処理する部分、状態を保存する部分に分かれています。これらを分けておくと、障害時に何が残り、何が失われるかを考えやすくなります。

03｜「ログイン中」はどこに保存されていますか

HTTP（Hypertext Transfer Protocol）は、基本的に個々のリクエストを独立して扱います。ユーザーがログインしているか、買い物カゴに何を入れたかを扱うために、Cookieやトークン、サーバー側セッションなどの仕組みを使います。

サーバーAだけのメモリに「予約の第2画面まで進んだ」という情報を持っていると、次のリクエストがサーバーBへ届いても、Bはその情報を知りません。これがセッションを共有しない構成の問題です。

04｜可用性と信頼性は何を意味しますか

可用性（Availability）は必要なときにサービスを使える度合いです。信頼性（Reliability）は一定条件のもとで正しく動作し続ける性質を指します。Webサービスでは、故障しても別の装置へ切り替えられるように設計することが重要です。

05｜コールド・ウォーム・ホットスタンバイの違い

「予備がある」だけでは切替え速度を判断できません。コールドスタンバイは予備機の起動や初期化が必要になりやすく、ウォームスタンバイは一部準備済み、ホットスタンバイはすぐ引き継げる状態を維持する設計です。ただし用語の厳密な運用は製品ごとに異なります。

06｜ロードバランサーは何をするのですか

LB（Load Balancer、ロードバランサー）は、正常なサーバーへリクエストを振り分けます。ヘルスチェックで故障を検出し、送信先から外す仕組みを組み合わせます。ただし、すでに実行中の処理をそのまま移動させるわけではありません。

07｜セッションを共有すると何が変わりますか

AとBの両方が共通のセッションストアへアクセスできれば、「入力を何段階進めたか」「一時的な選択内容」などをBが参照できます。セッション共有は、利用者が別サーバーへ移った後の操作の継続を助けます。

08｜セッション維持とDBトランザクションは別物です

DBトランザクション（Transaction）は、予約レコードの書込みなど複数のDB操作を、一つの整合した処理単位にまとめます。原子性（Atomicity）により、COMMIT前に異常終了した場合は変更がロールバックされるのが基本です。

09｜Supabaseを使った予約アプリならどう設計しますか

Supabase Authでは認証状態を扱い、Postgresに予約データを保存できます。画面表示を担当するWebサーバーが入れ替わっても予約情報を参照できるよう、確定情報を特定サーバーのメモリだけに置かないのが大切です。

// ブラウザ: 認証済みのユーザーとして予約要求を送信します
POST /api/reservations
{
  "timeSlot": "2026-10-20T18:00:00+09:00",
  "requestId": "reservation-attempt-001"
}

// Web API側の責務（設計イメージ）
// 1. Supabase Authでユーザーを検証します。
// 2. DBで requestId の重複を確認・制約で保護します。
// 3. 在庫確認と予約登録をDBの単一トランザクションで扱います。
// 4. 既に成功済みの requestId なら同じ結果を返します。

複数のDB操作を一つのトランザクションにまとめたい場合は、Postgresの関数などDB側で処理を完結させる設計が考えられます。上記は設計方針を示した擬似コードで、そのまま動くSupabase API実装ではありません。

10｜二重予約を防ぐには冪等性が重要です

処理完了後、応答だけが届かないことがあります。利用者がもう一度「予約」を押すと、同じ処理が二重に実行されるおそれがあります。そこで冪等性（Idempotency、べきとうせい）を使います。同じリクエストIDの再送で結果が二重に増えないようにする設計です。

実装では一意制約、原子的なINSERT、適切なトランザクション境界、要求IDの保存などを組み合わせます。「同じデータのSELECT結果になる」だけでは二重登録の防止にはなりません。

11｜フェールオーバーとフェールソフト・フォールトトレランス

関連する用語も整理しておきます。フェールオーバーは系の切替えです。フォールトトレランス（Fault Tolerance、耐障害性）は障害下でも処理を続けられる性質を表します。フェールソフト（Fail-soft）は機能や性能を落としてもサービスの一部を提供し続ける考え方です。

12｜可用性・MTBF・MTTR・RTO・RPOを区別します

可用性を数値で考える場合は、稼働時間と修復時間が重要です。MTBF（Mean Time Between Failures、平均故障間隔）、MTTR（Mean Time To Repair、平均修復時間）を使う単純なモデルでは、稼働率 A は次の式で表せます。

A = MTBF / (MTBF + MTTR)
例：MTBF = 990時間、MTTR = 10時間
A = 990 / 1000 = 0.99（99%）

RTO（Recovery Time Objective、目標復旧時間）は停止から復旧するまでの目標、RPO（Recovery Point Objective、目標復旧時点）は障害前のどこまでデータを復元できればよいかの目標です。可用性が高いことと、失われるデータ量が少ないことは別々に考えます。

13｜アプリの冗長化だけでは不十分な理由

Webサーバーを2台にしても、両方が同じ単一DBへ依存し、そのDBが停止すれば予約処理は止まります。LB、セッションストア、DB、ネットワーク、認証基盤など、複数の依存先を考えなければなりません。

14｜ラボ：サーバーAを停止して違いを確かめましょう

次のシミュレーターでは「コールドスタンバイ」「クラスタ・セッション非共有」「クラスタ・セッション共有」を切り替えられます。ログイン・入力・予約要求・障害を順番に試し、状態がどこに残るのか観察してください。DB側はWebサーバーと独立した学習モデルです。

15｜まとめ：守りたい状態を分けて設計します

複数サーバーを用意することは、可用性向上の出発点です。しかし、セッションがAのメモリにしかなければ、Bへ切り替えたあとに操作状態を失います。さらに、共有セッションがあってもDBトランザクションの自動継続まで保証されるわけではありません。

Webの構成、利用者状態、DBでの確定処理、再送時の冪等性を別々に設計することが、実際のシステムを堅牢にする近道です。