ステートフル

Stateful

Web開発

サーバーがクライアントの過去の通信履歴や現在の状態（セッション情報など）を記憶し、前後の文脈を維持しながら連続した処理を行う通信方式やシステム設計のこと。

🐾 猫で例えると？

寄り添う猫たちを「関係を覚えて次の行動につなげる」イメージに重ねます。ただし接続し続けることや物理的な距離が、状態保持そのものではありません。Webでは、一連のやり取りを識別するセッションIDに対応する情報を次の要求で読み出す、と考えると具体的です。

Webサービスにおいて、ユーザーが「ログインしてから買い物かごに商品を入れ、決済を完了する」といった一連の操作を行う場合、システムは「このユーザーは誰で、今何をしているのか」を覚えておく必要があります。このような、過去のやり取りを前提として次の処理を行う設計がステートフルです。

本来、Webの基本プロトコルであるHTTPは状態を持たない（ステートレス）ため、CookieやセッションIDといった技術を使って、擬似的にステートフルな通信を実現しています。これにより、ユーザーはページを移動するたびにパスワードを入力する手間から解放されます。

セッションには保存先、保持期限、失効、容量管理が必要です。必要最小限の情報を保存し、期限切れを削除します。全利用者の全履歴を永久にメモリへ保持することが、ステートフルの条件ではありません。

サーバー側で状態を持つ場合、複数のサーバーでシステムを運用する（スケールアウト）際に工夫が必要です。

// セッションの関係を示す模式図（認証コードではありません）
// ブラウザー：Cookieで推測困難なセッションIDを送る
// サーバー：IDをキーにセッションストアを調べる
// ストア：利用者ID、有効期限などを保持する
// 次のリクエストでも、保存済みの状態を利用する

プロセス内メモリだけにセッションを置くと、別サーバーはその状態を読めません。共有ストアや同じサーバーへ振り分ける方法を検討しますが、後者だけではそのサーバーが失われた場合の状態を守れません。Expressの標準MemoryStoreも本番向けではありません。

現代のシステム設計では、ステートフルとステートレスを適材適所で使い分けることが重要です。

状態を持つ範囲を最小限にする： サーバーのメモリを圧迫しないよう、記憶しておくべきセッションデータは必要最小限に留める。
外部化と永続化を区別： Redisなどへ移せば複数のアプリサーバーで共有できますが、障害時に残るかは保存・複製・復旧設定によります。外部に置くだけで消失しなくなるわけではありません。
認証方式は失効も含めて選ぶ： JWTを使うと検証に必要な情報をトークンへ持たせられますが、ログアウトや盗難時の失効などでサーバー側の状態が必要になることがあります。JWTを使うだけで全体がステートレスになるとは限りません。

寄り添う猫たちが直前のやり取りを覚えているように、ステートフルな処理は保持した状態を使います。運用では、その状態をどこに置き、期限切れやサーバー停止時にどう扱うかを決めることが、処理を引き継げるかどうかに関わります。