はじめに

近い将来、単にコードを書くだけの作業は、AIが全部やってくれそう——。それならば、「もっと設計やインフラに近い領域を学ぼう！」

という背景で、GeminiやChatGPTを相棒に「高負荷サービスの設計」について学び始めました。学んだ内容をアウトプットとしてまとめていきます。

Stickey Sessionとは

Stickey Sessionとはロードバランサーで割り振る時、特定のクライアントを常に同じインスタンスへ振り分けるために使われる仕組み。

アプリケーションのセッション（開発者が扱う方）：
中身：user_id: 123, cart_items: [...] など
場所：サーバーのメモリ or Redis

Sticky Session用のCookie（LBが発行する方）：
中身：「あなたの転送先はサーバーA です」という識別子のみ
場所：ロードバランサーがブラウザに送り、ブラウザが保持する

サーバ内のデータを利用する場合、1回目のリクエストと2回目のリクエストがバラバラのサーバーに振られる可能性あり。ユーザがいきなりログアウトしてしまう現象が発生...
Stickey Sessionで同じサーバーにアクセスできるようになることで、サービスを使い続けることが可能になります

# Stickey Sessionがない場合
Request 1: Client → LB → Server A (Session Created ✅)

Request 2: Client → LB → Server B (No Session Data ❌ → Logout)

# Stickey Sessionがある場合
Request 1: Client → LB → Server A (Session Created ✅)

Request 2: Client → LB → Server A (Session Found ✅ → Stay Logged in)

さらに、ログアウトしたユーザが再ログインを試すので、負荷が別の生存サーバに集中し、次々とダウンする可能性あり(カスケード失敗)....

特定の重い処理をするユーザーが同じサーバーに固まると、特定のサーバだけ負荷が高くなります。

セッションを維持するためにサーバーを安易にシャットダウンできなくなるので、クラウドサーバの柔軟性が活かしきれない

セッションを外部に保存する改修に時間がかかる場合や、一時的なスケールアウト対応として利用される

今回はAIにまず問題を出してもらう、教えてもらう、再度問題を出してもらうという勉強を試してみました。
インプット後、すぐに問題を出して理解度の確認をしているのでいつもより早く定着してくれている感覚です。(2つのAIで勉強しているので、おそらく変な知識ではないはず...)
参考になれば幸いです