負荷分散：サーバーが変わると、ログインが消える？

アプリを2台に増やしたとき、メモリ内のセッションに何が起きるか。共有ストアとスティッキーセッションの違いを追う。

台数が増えると、毎回同じ台とは限らない

アプリをAとBの2台で動かし、入口にロードバランサーを置きます。利用者には一つの入口に見えていても、その後ろでは複数の対象がリクエストを処理します。

この作品ではA、Bと交互に振り分ける例を使います。実際の選択方法は製品や設定によって異なり、接続数や処理中のリクエストなどを考慮する方式もあります。

考えたいのは、ログイン後の次のリクエストが、別の台に届いても動くかです。AWS ALB：ターゲットグループの属性

利用者がAでログインし、Aがメモリ内に abc → 利用者情報 を保存したとします。ブラウザにはセッション識別子 sid=abc をCookieとして渡します。

この例のCookieは、セッション本体そのものではありません。後のリクエストでsidを受け取ったアプリが、対応する情報を保存先から探します。

Aのメモリだけを使う設計なら、Aが処理している間は動くかもしれません。しかし、Bは独立したプロセスです。Aに変数を追加しても、Bに自動で同じ内容が現れるわけではありません。

次のリクエストはBに振り分けられました。ブラウザは同じ sid=abc を送りますが、Bのメモリには対応するセッションがありません。

アプリの実装によっては、ログアウトしたように見える、処理を拒否する、といった結果になります。Cookieが消えたことと、Cookieの識別子に対応する状態が見つからないことは別の問題です。

入口を一つにしたことは、メモリを一つにしたことではありません。 リクエストの経路と、情報の置き場を分けて描くと、原因が見えます。

AとBが共通のセッションストアを参照する構成に変えます。どちらも sid=abc で同じ情報を検索できれば、振り分け先が変わってもログイン状態を扱えます。

これにはデータベースや、要件に合ったセッション用ストアを使えます。共有先の可用性、期限切れ、失効、同時更新の扱いも設計が必要です。共有場所を一つ描いただけで障害対策まで完成するわけではありません。

この図はセッション識別子を使う方式です。署名付きトークンを検証する方式には別の利点と失効設計がありますが、今回は混ぜずに追います。

Bがsidを共有ストアで検索し、対応する情報を得ました。利用者の操作を、Aのときと同じ状態から続けられます。

ここでの「アプリをステートレスに近づける」とは、システム全体から状態を消すという意味ではありません。交換されるアプリのメモリだけに、継続に必要な情報を閉じ込めないという設計です。

セッション以外にも、カート、アップロード途中の情報、バックグラウンド処理の進行などが対象になり得ます。複数台が使える場所に置く必要がある状態を、個別に決めます。

スティッキーセッションは、一定の利用者やセッションを同じ対象へ寄せる仕組みです。AWS ALBではCookieを使う方式があります。対象の選び方や継続時間は設定によります。

ただし、Aが停止してBへ切り替わったとき、AのメモリがBへ引き継がれるわけではありません。同じ台へ寄せることと、状態を失わずに復旧することは別です。

スティッキーが役立つ用途もあります。障害時やデプロイ時に何が起こるかを含めて判断します。AWS：スティッキーセッション

最初に見るのは、振り分け規則、状態の置き場、台が交換されたときの動きです。利用者が毎回同じ台へ届くことを、根拠なく前提にしないようにします。

ヘルスチェックで対象の状態を確認することも大切ですが、検知の遅れや製品ごとの障害時の挙動があります。「壊れた台へ絶対に届かない」とは置かず、失敗時の処理も考えます。

図のAを一度消してみて、それでも続けるためにどの情報が必要かを考えてください。その情報をどこへ置くかが、負荷分散を導入するときの大きな設計ポイントです。