🦭
ELBのスティッキーセッションをオフにして弾力性を高める？
AWS のセッション管理について整理する。とくに ALB,ElastiCache について。
そもそもセッションとは、みたいなところを中心とする。
cookie のおさらい
- 任意の Key Value をリクエストごとに送信できる
セッションのおさらい
- セッションとは通信において始まりから終わりまでのこと
- セッションは概念なので、実現方法はそれぞれ。
- セッション管理に cookie を使うという一つの方式
- ログインして買い物をするとき、サーバーはだれからのリクエストかを覚えたいので、セッションを用いる
シーケンス例
セッションストア
- EC サイトでクライアント間共有のカート機能をつくりたいとき、カートの中身を保存する必要がある
- cookie はサイズが限られているし、改ざん可能なので適していない
- サーバー側で session_id をキーとして保存する
- php ではデフォルトでローカルファイルに保存している
- リクエストごとに LB の接続先サーバーが変わるとデータが取得できない
- スケーリングに課題がある
- php ではデフォルトでローカルファイルに保存している
ALB のスティッキーセッション
- 通常はルールに従ってリクエストごとにルーティングするが、ユーザーとターゲットを紐付ける機能
- リクエストごとに有効期限をリセットされる
- WebSocket では cookie ベースではなく固定される
アプリケーションベース
- ALB の設定で使用する cookie 名を決める
- 当該 cookie の値を見て ALB がルーティングを行う
期間ベース
- ALB が
AWSALBという key の cookie を生成する。 - クライアントは当該 cookie を用いる
- その値を ALB が判断し、指定された 1 秒から 7 日の期間同じターゲットにルーティングする
ElastiCache でのセッション管理
- サーバー内にセッションデータを保存せず、ElastiCache に保存する
- ElastiCache はある程度スケーリングできるので、スケーリング課題を解決できる
- このとき、どのサーバーにアクセスされてもよいので、スティッキーセッションは必要ない
参考
Discussion