セッション情報の置き場所の設計 — サーバーに持たせるか外へ出すか

セッション情報をどこに置くかは、水平スケールの可否を左右する根本的な設計判断です。ローカル保持のまま台数を増やせばログインが切れ、すべてを外部ストアへ出せば単一障害点が生まれます。「何を外へ出し、何を持たせたままでよいか」という境界を最初に引くことが安定したスケールアウト構成の前提条件であり、障害時の挙動・有効期限・ファイルの逃がし先まで含めた設計判断の整理が求められます。

ローカル保持のまま台数を増やしてログインが切れる構造

ラウンドロビンが崩すセッション継続性

Webアプリケーションサーバーがセッション情報をローカルメモリに保持したまま複数台構成へ移行すると、ロードバランサーのラウンドロビン割り振りがセッション継続を壊します。1台目へのリクエストで認証済みセッションが生成されても、次のリクエストが2台目へ転送された時点で「セッションなし」として扱われ、ユーザーは再ログインを求められます。2台構成であれば発生確率は約50%ですが、10台構成では90%超に達するため、台数が増えるほど問題の頻度が上がります。この挙動は単一台の検証環境では完全に再現しないため、本番環境へのデプロイ後に初めて顕在化するケースが多く、原因特定に数時間を要することもあります。

スティッキーセッションが隠す本質的な問題

応急措置としてロードバランサーのスティッキーセッション（セッションアフィニティ）を有効にする対応は現場でよく見られますが、スケールアウトの効果を大幅に下げる設計です。特定のクライアントを同じサーバーへ固定することで見かけ上は問題が解消しますが、固定先のサーバーがメモリ不足やプロセスクラッシュで落ちると、そのサーバーに張り付いていたセッションが一斉に失われます。ローリングアップデートによるデプロイ時にも同様の問題が生じるため、深夜メンテナンスウィンドウに縛られた運用が継続します。スティッキーセッションは「問題を見えなくする設計」であって、解決策ではありません。

「スティッキー＋手動フェイルオーバー」が技術的負債になる理由

3〜5台構成のWebサーバーにスティッキーセッションを適用し、障害時は手動でセッションを切り捨てて再ログインを促す運用体制が、小規模な環境では根強く残っています。「今は動いている」という状態を「正しい設計」と混同した結果として定着しがちです。自動スケーリングを導入した時点でこの構成は機能しなくなります。オートスケールではインスタンスのIPアドレスが変動するため、スティッキーの固定先が消失するからです。初期から外部ストアを採用した場合と比較して、後からの設計見直しには2〜3倍以上の工数が掛かることがあり、長期にわたる技術的負債として蓄積されます。

外へ出すべき状態と持たせたままでよい状態の判断

外部化の判断軸は「複数プロセスが同じ値を必要とするか」

セッション情報を外部ストアへ移す必要があるかどうかは、「複数のプロセスまたはサーバーが同じ値を必要とするか」という一点で判断できます。認証状態・カートの中身・ページネーション位置・フォームの入力途中データなど、次のリクエストが別サーバーへ転送されても同じ値が必要になるものはすべて外部化の対象です。逆に、1回のリクエスト処理の中だけで完結する中間計算値や、サーバープロセス固有のインメモリキャッシュは外部化する必要がありません。この判断軸を持たずに設計を進めると、「全部外へ出せば安全」という過剰設計か、「全部ローカルでいい」という過小設計に偏ります。

ローカル保持が許容される条件

シングルサーバー構成で今後もスケールアウトの計画がない場合、ローカルメモリまたはファイルベースのセッション保持で十分です。ステートレス設計（JWTをクライアントサイドに持たせる方式）を採用する場合は、サーバーサイドのセッションストア自体が不要になります。ただしJWT方式は「発行済みトークンの即時無効化」が構造上難しいという別の制約を伴います。ローカル保持を選択できる条件は、単一インスタンス・デプロイ停止を許容できる運用・スケールアウト不要の3条件が揃っている場合に限定するのが妥当です。条件が一つでも欠けていれば、外部化を前提に設計する方が後の改修リスクを下げます。

混在設計が招く境界の曖昧さ

「認証セッションは外部ストアへ、一時データはローカルへ」という混在設計は一見合理的ですが、分類基準が曖昧になりやすい落とし穴があります。フォームの入力途中データや検索条件の保持は「一時的」に見えても複数リクエストにまたがるため、外部化が必要です。混在設計を採用する場合は、「このデータはどのリクエストまで生きるか」という観点で分類基準を文書化し、開発者全員が同じ基準で判断できる状態を維持する必要があります。基準が担当者によって異なると、ローカルに置かれた状態が少しずつ増殖し、設計の意図が失われます。

比較表: ローカル保持 / スティッキー割り振り / 外部ストアの比較

方式	スケールアウト対応	障害時のセッション継続	デプロイ時の影響	運用の複雑さ	主な適用場面
ローカル保持	不可（別サーバーへ転送でセッション喪失）	サーバー落下で全セッション喪失	デプロイのたびにセッション消失	低（追加コンポーネント不要）	単一台・開発環境・ステートレス移行前の暫定
スティッキー割り振り	限定的（負荷分散が半減、オートスケール非対応）	固定先サーバーの障害でセッション喪失	ローリングアップデート時にセッション喪失	低〜中（LB設定のみ・ストア不要）	小規模固定台数・自動スケール未使用・暫定移行期間
外部ストア（Redis等）	可（任意台数・オートスケール対応）	ストア冗長化により継続可能	セッション継続・無停止デプロイが可能	中〜高（ストアの可用性設計と運用が必要）	複数台・自動スケール・無停止デプロイが求められる本番環境

アップロード・一時ファイルをどこに逃がすか

アップロードファイルのローカル保存が引き起こす分断

ユーザーがアップロードしたファイルをWebサーバーのローカルディスクに保存する構成は、セッション問題と同じ構造的欠陥を持ちます。アップロードを受け付けたサーバーのローカルにファイルが置かれるため、別のサーバーへリクエストが転送されるとファイルが見つからないという事態が発生します。画像投稿・帳票アップロード・CSVインポートといった機能でこの問題が表面化し、「ファイルが消えた」「アップロードしたのに表示されない」という障害報告の原因になります。問題の根本はストレージがサーバーに従属している点にあり、スケールアウト構成ではストレージをサーバーから切り離すことが前提条件になります。

共有ストレージへの移行判断と選択肢の分岐

アップロードファイルの置き先として、オブジェクトストレージ（S3互換）・共有NFS・分散ファイルシステムの3種類が主な候補です。オブジェクトストレージはHTTP経由でファイルを直接配信できるため、Webサーバーがファイルの仲介役になる必要がなく、処理負荷の低減にも寄与します。共有NFSはマウントポイントを統一すれば既存コードをほぼ変更せずに移行できますが、NFSサーバー自体の可用性設計が追加で必要になります。判断の分岐点は「ファイルをアプリを経由せずに外部から直接配信できるか」です。直接配信が可能ならオブジェクトストレージ、アクセス制御やストリーミング処理がアプリ側で必要ならNFSまたは分散FSを選びます。

一時ファイルと処理中データの配置判断

CSVインポートやバッチ処理の中間ファイルなど、処理が完了すれば不要になる一時ファイルは、条件次第でサーバーローカルに置くことが許容されます。「どのサーバーがその処理を担当するか」をジョブキューで固定できる構成であれば、ワーカーサーバーのローカルディスク上で生成・処理・削除のサイクルを完結させることができます。問題が生じるのは、一時ファイルが「このリクエストより長く生きる」設計になった場合です。有効期限を超えた一時ファイルの清掃機構と合わせて設計しないと、ディスク容量を静かに圧迫し続け、気づいたときにはディスクフルで障害になります。

有効期限と障害時の引き継ぎ挙動をどう決めるか

TTLはセキュリティ要件と利便性の交差点

セッションのTTL（有効期限）設計は、セキュリティ要件と利便性のバランスを取る意思決定です。金融・医療系のシステムでは無操作15〜30分でのセッション失効が求められるケースが多く、ECやコンテンツ系では数時間から数日の継続維持が求められます。外部ストアのTTLはキー単位で設定できるため、セッション更新のたびにTTLをリセットする「スライディングウィンドウ」方式と、初回ログインから一定時間で強制失効させる「絶対有効期限」方式を組み合わせる設計が一般的です。どちらの方式をいつ優先するかは、要件定義の段階でシステム要件と照合して合意しておく判断事項です。

障害時にセッションをどう扱うか

外部ストアが一時的に到達不能になった際にアプリケーションがどう振る舞うかを、設計として明示しておく必要があります。「セッションなし」として扱いログイン画面へ誘導する方式と、「直前の検証済み状態を短時間キャッシュとして保持する」フォールバック方式があります。前者はセキュリティが高い反面、障害時のUX影響が大きく、後者は利便性を保てる代わりに短時間だけ古いセッション状態を許容します。業務系・金融系では前者を、コンテンツ閲覧系・ECでは後者を選ぶ傾向があります。無設計のまま障害を迎えると場当たり的な対応に追われるため、挙動を設計として決めておくことが重要です。

デプロイ時のセッション引き継ぎ設計

ローリングデプロイやブルーグリーンデプロイ時、旧バージョンと新バージョンが並走する時間帯に、セッションが両方の環境で有効である必要があります。外部ストアにセッションを置いていれば、旧サーバーで生成されたセッションを新サーバーがそのまま読み取れるため、デプロイ中のログアウトが発生しません。ただし、セッションのデータ構造を変更するマイグレーションを伴う場合は、新旧両方のスキーマを解釈できる移行期間を設ける必要があります。並走期間は最低でも1デプロイサイクル分、多くの場合10〜30分は確保する設計が求められます。この期間の設計を含めていないと、デプロイの瞬間に全ユーザーのセッションが壊れます。

外部ストアに寄せて単一障害点を作る境界

Redisをセッションストアにした場合の可用性設計

Redisはセッションストアとして広く採用されていますが、シングルインスタンス構成のRedisはセッション管理の単一障害点になります。Redisが落ちると全ユーザーのセッションが一斉に失われ、同時ログインが集中するため認証サーバーやデータベースへの負荷が急増します。本番環境でRedisをセッションストアに採用する場合、Redis SentinelまたはRedis Clusterによる冗長化が前提条件です。Sentinelは1マスター＋2スレーブの3ノード構成が最小推奨とされており、フェイルオーバー時間は通常10〜30秒程度です。この切り替え時間中にセッション読み取りが失敗する挙動を、アプリケーション側でどう吸収するかも合わせて設計する必要があります。

RDBMSをセッションストアにする場合の境界

RDBMSのセッションテーブルをストアとして使う構成は、インフラに追加コンポーネントを増やさずに済む利点がありますが、セッションアクセスがデータベース負荷として積み重なるリスクがあります。同時セッション数が数千を超える環境では、セッションの読み書きがDB負荷全体の10〜20%を占めるケースがあります。また、セッションテーブルのレコード数は急増しやすいため、期限切れセッションの定期削除ジョブを設計に含める必要があります。DBをセッションストアにする判断は、「既存DBの余力がある」「同時セッション数が数百以内」「追加コンポーネントを管理したくない」という3条件が揃う場合に限定するのが適切です。

影響範囲の局所化とストア分割の境界

セッションストアの冗長化は必要ですが、過剰に分散させると構成の複雑さが別のリスクになります。判断の基準は「ストアの障害がどのサービス範囲に影響するか」です。すべてのサービスが同一ストアを参照する構成では、ストア障害がシステム全体に波及します。サービスの性質でストアを分割する（認証セッションは高可用Redis Cluster、カートデータは別クラスタとする等）設計は、障害の影響範囲を局所化できます。ただしストアが増えるほど運用管理の複雑さも増すため、「分割することで得られる可用性向上」と「管理コストの増加」を天秤にかける判断が必要です。管理するサービス数が5を超えない環境での分割は、過剰設計になりやすいです。

ステート配置設計チェックフレーム

設計フェーズで以下の項目を確認し、未決のまま実装に入ることを避けます。各項目に対して「決定済み／未決」を明示することで、後工程での手戻りを防ぎます。

1. データの参照範囲：このデータは複数のサーバープロセスから同じ値として参照されるか。Yesなら外部ストアが必須です。
2. スケールアウト計画：台数増加またはオートスケールの計画があるか。Yesなら外部ストアを前提に設計します。
3. アップロードファイルの参照範囲：ファイルが複数台から参照されるか。Yesなら共有ストレージ（オブジェクトストレージまたはNFS）へ移行します。
4. TTL方式の決定：セッションの有効期限方式（スライディングウィンドウ／絶対有効期限）はセキュリティ要件と照合済みか。未決なら要件定義に差し戻します。
5. 外部ストアの冗長化：Redis等の外部ストアは冗長化構成になっているか。シングルインスタンスのまま本番運用しないことが原則です。
6. 障害時の挙動：外部ストア障害時のフォールバック挙動（ログアウト誘導 or 短時間キャッシュ継続）は決定済みか。無設計での本番稼働を避けます。
7. デプロイ時スキーマ互換：セッションデータ構造が変更される場合、並走期間のスキーマ互換は確保されているか。未確認なら事前にマイグレーション設計を行います。
8. 一時ファイル清掃：一時ファイルの有効期限と清掃機構は設計済みか。無制限蓄積によるディスクフル障害を防ぎます。
9. ストア障害の影響範囲：複数サービスが同一ストアを参照している場合、障害時の影響範囲は許容できるか。過大であればストア分割による局所化を検討します。