HTTPのセッションをRedisのようなバックエンドに持たせて毎回参照するような構成と、それに加えてローカルオンメモリキャッシュとSticky sessionでさらにnear cache挟んで高速化するの、どっちがベターか論争みたいなのって過去にあるのかな

— Takayoshi Kimura (@nekop) November 17, 2014

Javaだとローカルオンメモリキャッシュ簡単だけど、マルチプロセスモデルなスクリプト言語とかだとローカルキャッシュ共有面倒だからバックエンド一択というのが多数派になる

— Takayoshi Kimura (@nekop) November 17, 2014

このへん見てて考えたことのメモ｡

実際､Java のシングルサーバーからスケールアウトさせる場合は｢sticky session によるオンメモリキャッシュ → redis かなにかのバックエンド｣に保存という形にするのはありだお思うのだけど､僕らのケースにはマッチしないように思った｡

これは以下の理由による

• 基本的にサービスを提供するサーバーは2台以上からスタートする
• app server にローカルキャッシュを持つと GC 対象になる
• できるだけ request をまたいだデータは持ちたくない
• session データは長期間保持することになるので､､
• そもそもうちのサービス規模だと local cache にヒットする確率が少なそう
• ローカルキャッシュを蓄えれば高速化は可能だと思うけど､実際 DB とかのほうが遅いので､あまり頑張る意味がなさそう

すでにやってたりミドルウェアでサポートされてるならありだけど､自分たちで今から考慮する必要はないかなあ､という感じ｡