元ネタ
Cookieを利用したセッション維持(Sticky)の問題点
http://itpro.nikkeibp.co.jp/article/Watcher/20080728/311618/
直近に違和感を感じたのは、この文章。
IE(Internet Explorer)のCookieサイズはおおよそ4〜5kbyteなようです(他のWEBブラウザーもほぼそのくらいなようです)。最近はこの容量制限をオーバーするケースが非常に増えてきたように思います。この制限をオーバーすると当然のことながらCookieを利用したセッション維持に失敗します。
ではなぜ最近容量制限をオーバーするケースが増えたのか。それはタブブラウザの普及が原因なようです。他のブラウザはよく知りませんが、IE7では全てのタブでCookie情報を共有するようです。これは1つのタブでログインしておけば他のタブでもログイン状態が続くので便利という側面もあるのですが、わずか4〜5KBしかないCookieサイズを1つのブラウザで共有するのでタブを開けば開くほど限られたCookie容量がひっ迫してくることになります。
えと…「なんでタブ開くたびにCookieが増えるよ？」とかいう突っ込みになるわけなのですが。
よくよく冷静に読んでみると。ヒントはここ。
ロードバランサーの機能のうち、セッション維持は重要な役割な一つです。
なるほどねこれか。
で、解説。
元文章には、重大な「不足部分」があるです。
前提条件は…ここがいいかな。
第4回 ロードバランスクラスタの実装
http://www.atmarkit.co.jp/flinux/rensai/cluster04/cluster04.html
内にある
■http CookieによるSticky
プロキシ経由では同じソースIPアドレスになってしまうため、ロードバランス装置の中でクライアントごとに異なるCookieを生成します。その Cookieをクライアントに送ることでクライアントを識別し、ノードに分散させると同時にセッション維持のためのキーとして利用します。
つまり。前提条件として
わけです。
…うん斜めに読むと、ロードバランサの部分さらりと読み飛ばしておいちゃん一瞬びっくりしたよ orz
で、おいちゃん的(或いは我留流的)回答。
「ンな重い事ロードバランサにやらすんな」。
各種異論はあろうかと思いますが。最終的に横ちょに広げるときに、ボトルネックは出来るだけ作りたくない主義なので。それを考えると「ロードバランサ使って１ユーザを１マシンに紐づける」よりも「全部DBでセッションもってあとはフリー」のほうが圧倒的に楽なわけです。
DBはやり方次第で「かなり無限に近い量まで横ちょに増やせる」やり口があるので。
それにしても…うんもう少しちゃんと前提条件書かないと、わからない人っつか気づかない人とか誤解する人多いんじゃないかなぁ？
