sticky-session
あるクライアントからのリクエストを必ず同じサーバーに送るようにするHTTPロードバランサーの機能
cookieを食わせてルーティングする
リクエスト元のIPアドレスから毎回hashを計算し、接続先サーバーを決めるという方法ではない
socket.io-redisでサーバーをcluster化する時などに使う
socket.ioは接続時の最初の数回はhttp pollingでhandshakeしようとする
同じnodeプロセスにリクエストが行かないとhandshake失敗してしまう
session-affinityと呼ばれるfeatureを使う
有効にする
$ heroku features:enable http-session-affinityすると、こういうhttp headerを返すようになる
Set-Cookie: heroku-session-affinity=(長いHASH); Version=1; Expires=Tue, 15-Nov-2016 11:51:24 GMT; Max-Age=86400; Domain=staging.scrapbox.io; Path=/; HttpOnly expireは24時間後
dynoを増やしても既存clientは24時間新しいdynoにルーティングされないという罠がある
routerは
heroku-session-affinity の値を見て、毎回同じdynoにルーティングする捨てた
herokuのscale機能でサーバーを増やしても、既存のクライアントは元のサーバーに集中したままになる
アクセスが増えてからサーバーを増やしても、sticky-sessionのせいで新しいサーバーにforwardされなくなる
scaleを減らした場合はsticky-sessionも変わる
サーバー側でstateのある処理をしているクライアントは異常動作するかもしれない