はじめに
近い将来、単にコードを書くだけの作業は、AIが全部やってくれそう——。 それならば、「もっと設計やインフラに近い領域を学ぼう！」
という背景で、GeminiやChatGPTを相棒に「高負荷サービスの設計」について学び始めました。 学んだ内容をアウトプットとしてまとめていきます。
Stickey Sessionとは 
Stickey Sessionとはロードバランサーで割り振る時、特定のクライアントを常に同じインスタンスへ振り分けるために使われる仕組み。
2種類の「セッション」の役割：
アプリケーションのセッション（開発者が扱う方）：
中身：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)
弱点
1. サーバがダウンすると、そのサーバーに接続していたユーザがみんなログアウトする
さらに、ログアウトしたユーザが再ログインを試すので、負荷が別の生存サーバに集中し、次々とダウンする可能性あり(カスケード失敗).... 
2. 特定のサーバーに負荷が集中する可能性がある
特定の重い処理をするユーザーが同じサーバーに固まると、特定のサーバだけ負荷が高くなります。
3. オートスケーリングの妨げ
セッションを維持するためにサーバーを安易にシャットダウンできなくなるので、クラウドサーバの柔軟性が活かしきれない 
結論
セッションを外部に保存する改修に時間がかかる場合や、一時的なスケールアウト対応として利用される
おわりに
今回はAIにまず問題を出してもらう、教えてもらう、再度問題を出してもらうという勉強を試してみました。
インプット後、すぐに問題を出して理解度の確認をしているのでいつもより早く定着してくれている感覚です。(2つのAIで勉強しているので、おそらく変な知識ではないはず...)
参考になれば幸いです 