sticky-session

あるクライアントからのリクエストを必ず同じサーバーに送るようにするHTTPロードバランサーの機能

cookieを食わせてルーティングする

リクエスト元のIPアドレスから毎回hashを計算し、接続先サーバーを決めるという方法ではない

socket.io-redisでサーバーをcluster化する時などに使う

socket.ioは接続時の最初の数回はhttp pollingでhandshakeしようとする

同じnodeプロセスにリクエストが行かないとhandshake失敗してしまう

Heroku Routerの場合

session-affinityと呼ばれるfeatureを使う

Session Affinity | Heroku Dev Center

有効にする

$ 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にルーティングされないという罠があるshokai.icon

routerはheroku-session-affinityの値を見て、毎回同じdynoにルーティングする

捨てたshokai.icon

heroku session-affinityをdisableにし、socket.ioのpollingを切ってwebsocket onlyにした

herokuのscale機能でサーバーを増やしても、既存のクライアントは元のサーバーに集中したままになる

アクセスが増えてからサーバーを増やしても、sticky-sessionのせいで新しいサーバーにforwardされなくなる

scaleを減らした場合はsticky-sessionも変わる

サーバー側でstateのある処理をしているクライアントは異常動作するかもしれない