【すてぃっきーせっしょん】

スティッキーセッションとは？

最終更新: 2026年10月1日

💡 関連するリクエストを、同じサーバーへ寄せる

ロードバランサーがCookieやIPなどを手がかりに、関連するリクエストを同じサーバーへ振り分ける仕組み。維持の条件や期限があり、状態の複製や障害時の引き継ぎまで保証するものではありません。

📌 このページのポイント

リクエストの振り分け例で、応答は省略しています。同じサーバーはほかの利用者も処理します。Cookie等は本人認証とは別で、状態の保存・共有・復旧も別に設計します。

ひよこ

なぜ同じサーバーへ寄せるの？

ペンギン先生

ログイン状態やカートなどを各サーバー内だけに持つアプリでは、次のリクエストが別のサーバーへ行くと状態を読めない場合がある。そのため、振り分け先を関連付けるんだ。状態を複製する機能とは違うよ。

ひよこ

同じユーザーだとどう判断するの？

ペンギン先生

Cookieを手がかりにする製品や、送信元IPを使う方式がある。例えばAWS ALBはCookieを使い、NGINXにはip_hashがあるよ。ただしCookieはログイン本人確認とは別。複数人が同じIPを使う場合もあるので、IPを一人のユーザーと同一視しないようにしよう。

ひよこ

一度決まればずっと同じサーバー？

ペンギン先生

条件によるよ。例えばALBでは期限切れや、Cookieの参照先が異常・登録解除になった場合などに別のターゲットを選ぶ。同じサーバーを使っている間も、そのサーバーを一人専用にするわけではないんだ。

ひよこ

セッションを共有すれば不要？

ペンギン先生

必要な状態を全サーバーで共有できれば、固定を避ける設計を検討できるよ。ただしRedisを置くだけで解決とは限らない。共有するデータ、更新の整合性、接続やサーバー内の状態など、アプリの条件を確かめよう。

ひよこ

WebSocketにも必ず必要なの？

ペンギン先生

接続中の通信と、複数のHTTPリクエストの固定は分けよう。ALBではWebSocketへアップグレードした接続は同じターゲットを使い、その後Cookieによる固定は使わない。切断後の再接続や、別のHTTP通信に必要な状態は別に設計するよ。

もっと詳しく知りたい人へ

障害時にカートやログイン状態も引き継げる？

固定の仕組みは通常、アプリの状態を別サーバーへ複製しません。振り分け先が変わっても利用を続けたい場合には、必要な状態の保存・共有・復旧を設計し、その動作を確認します。

NATやプロキシの背後にいる複数の利用者は、ロードバランサーから同じ送信元IPに見える場合があります。NGINXのip_hashはIPv4の先頭3オクテットなどをキーにするため、IPが異なるだけで均等に振り分けられるとも限りません。

まとめ：ざっくりこれだけ覚えればOK！

「スティッキーセッション」って出てきたら「関連するリクエストを同じサーバーへ寄せる仕組み」と思えばだいたいOK！

📖 おまけ：英語の意味

「Sticky Session」＝粘着するセッション

💬 Sticky は「べたっとくっつく」という意味で、クライアントが特定サーバに貼り付いたように通信し続けることからきているよ