カテゴリJの締めくくりへ
前回のJ-09では、画像やPDFの本体はオブジェクトストレージへ、DBにはその場所だけを保存する、という置き場の分け方を学びました。今回はさらに一歩進んで、サーバー自身がログイン中の情報などの状態を抱えるべきかを考えます。ここはカテゴリJの締めくくりであると同時に、公開後のカテゴリRやSで直面する問題の伏線でもあります。サーバーの中身を読む力の、最後の部品を手に入れましょう。
このスライドのポイント
- 前回J-09: ファイル本体はオブジェクトストレージ、DBには場所だけ、という置き場の分け方
- 今回: サーバー自身がログイン中の情報などの状態を抱えるべきか
- カテゴリJの締めくくりであり、公開後（カテゴリR・S）で直面する問題の伏線
3つの用語の定義
用語を定義します。ステートフルとは、サーバーのメモリにリクエスト間の状態、たとえばログイン中の情報などを持たせる設計です。メモリはB-03で見た、電源が切れると消える一時的な置き場でした。ステートレスとは、サーバー自身は状態を持たず、必要な状態は毎回リクエストに載せるか、DBなどの外部に置く設計です。リクエストに載せる手段は、D-07で学んだCookieやトークンでした。そして、利用者ごとの継続した状態のことをセッションと呼びます。現代のWebでは、このステートレスが定石とされています。
このスライドのポイント
- ステートフル: サーバーのメモリ（B-03）にリクエスト間の状態を持つ設計
- ステートレス: サーバー自身は状態を持たず、状態は毎回リクエストに載せる（D-07のCookie/トークン）か外部（DB等）に置く設計
- セッション: 利用者ごとの継続した状態のこと
- 現代のWebはステートレスが定石
なぜ「持たない」が定石なのか
この違いを知らないと、公開後に原因の読めない不具合に出会います。代表例が、利用者が増えたのでサーバーを2台に増やしたら、なぜかログインが頻繁に切れる、という現象です。ステートフル設計では、ログイン状態が1台目のメモリにしかないため、次のリクエストが2台目に届くと、そのサーバーは利用者を知りません。さらに、サーバーを再起動しただけでメモリの状態は消えます。原因を部品の言葉で説明できないと、この種の問題は延々と直せないのです。
このスライドのポイント
- ステートフルだと、サーバーを2台に増やしたときログインが切れる
- 状態が1台目のメモリにしかない → 2台目は利用者を知らない
- サーバーを再起動しただけでもメモリの状態は消える
- 原因を部品の言葉で説明できないと、この種の問題は直せない
対比で見る全体像
全体像を対比図で見ます。ステートフルの側では、状態はサーバー内のメモリに置かれます。そのため、サーバーを増設したり再起動したりすると状態が失われ、どのサーバーに届くかで応答が変わってしまいます。ステートレスの側では、状態はDBなどの外部に出されています。どのサーバーも同じ外部を参照するので、何台に増えても、どれに届いても同じ応答を返せます。図の要点は、状態をサーバーの外へ出したかどうか、この一点にあります。
このスライドのポイント
- ステートフル: 状態はサーバー内のメモリ → 増設・再起動で消える／届く先で応答が変わる
- ステートレス: 状態は外部（DB等） → どのサーバーでも同じ応答
- 図の要点は「状態をサーバーの外へ出したか」の一点
ログイン状態を追う
具体例として、ログイン状態を追ってみます。ステートレス設計では、あなたが誰であるかは、サーバーのメモリではなく、毎回のリクエストに載ったCookieやトークンと、DBの情報から判断されます。ログインボタンを押すと、サーバーは本人確認をし、あなたを示す印をCookieやトークンとしてD-07のしくみで返します。次からのリクエストはその印を持って届き、サーバーはどこにも状態を溜めずに、その都度あなたを判定します。だからサーバーが再起動しても、別のサーバーに届いても、ログインは切れないのです。
このスライドのポイント
- ステートレスでは「あなたが誰か」は毎回のCookie/トークン（D-07）とDBで判断
- ログイン時にサーバーが本人確認し、印をCookie/トークンで返す
- 次からのリクエストはその印を持って届く → サーバーは状態を溜めない
- だから再起動しても、別のサーバーに届いてもログインは切れない
技術サンプルカード
サンプルを見ます。種別は構成図で、目的はサーバーが2台になったときの成否を比較することです。上のステートフルでは、状態が1台目のメモリにしかないため、2台目に届いたリクエストは失敗します。下のステートレスでは、状態を外部に出しているので、両方のサーバーが同じ場所を参照し、どちらに届いても成功します。読み方の要点は、増やせる設計とは、状態を外に出した設計のことだ、という一行に尽きます。
混同しやすい概念
混同しやすい点を整理します。アプリに状態があること自体は、まったく問題ではありません。ログイン情報も、カートの中身も、どこかに保存されなければアプリは成り立ちません。避けたいのは、その状態をサーバーのメモリに持つ、つまりステートフルにすることです。DBやCookieに置くのは当然で、むしろ推奨されます。これは状態の置き場所の問題であって、状態の有無ではない、と覚えてください。
このスライドのポイント
- 「アプリに状態がある」＝当然ある（DBやCookieに置く。むしろ推奨）
- 「サーバーのメモリに状態を持つ」＝ステートフル。これを避ける
- 状態の置き場所の問題であって、状態の有無ではない
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIが、メモリ上の変数に利用者ごとのデータを溜めていくコードを書いたら注意が必要です。それは再起動で消え、複数台に増やすと壊れる、ステートフルな設計だからです。生成されたサーバーコードに対しては、この状態はどこに保存されますか、と必ず確認しましょう。答えがサーバーのメモリであれば、DBや外部への置き換えを検討する合図です。
このスライドのポイント
- AIが「メモリ上の変数に利用者データを溜めるコード」を書いたら要注意
- 再起動で消える・複数台で壊れる、ステートフルな設計
- 生成コードには「この状態はどこに保存されますか」を必ず確認
- 答えが「サーバーのメモリ」なら、DBや外部への置き換えを検討する合図
まとめと次回
最後に一問一答です。サーバーを増やしても壊れないのは、ステートレスとステートフルのどちらの設計でしょうか。……答えは、ステートレスです。状態を外部に置くため、何台に増えても、どれに届いても同じ応答を返せます。30秒でまとめます。ステートフルはサーバーのメモリに状態を持つ設計、ステートレスは状態を外部に出す設計で、現代のWebは増やせる・落ちても平気なステートレスが定石でした。これでカテゴリJは修了です。リクエストを受けたサーバーの中身を、責務や層や検証やルールの言葉で読めるようになりました。次回からはカテゴリK、システム同士をつなぐAPIへ進みます。関連資料は「Webアプリ構成図入門」と「アプリ運用チェックリスト」です。
このスライドのポイント
- 一問一答: サーバーを増やしても壊れないのはどちらの設計か
- 30秒まとめ: ステートフル＝メモリに状態／ステートレス＝状態を外部へ／定石はステートレス
- カテゴリJ 修了 → 次回カテゴリK: システム同士をつなぐAPIへ
- 関連資料: 「Webアプリ構成図入門」「アプリ運用チェックリスト」
