今年出てきそうなサービスというか、お話、第４話は、
２つ以上のサーバの共有セッション
たとえば、クラウドなどで、２つ以上のサービスにおいて、セッションを共有したい（ユーザーには見せたくないデータだが、サーバー間では共有する必要があるデータがあるときなど）場合とか、
たとえば、ＤＮＳラウンドロビンで簡易ロードバランスをしてしまい、ロードバランスするサーバー間で同じセッションデータを共有したい時（セッションによってサーバーを選ぶ形式ではなく）とか、
クラウドのように外部サーバーでも、ロードバランサーのように、内部サーバー間でもいいんだけど、２つ以上のサーバーで、セッションを共有したい場合が、今でもあり得るし、クラウドがはやれば、もっとあり得る。そういうとき、どうするか。
たとえば、サーバーＡ，サーバーＢの２つのサーバーでセッションを共有したいとする。
この場合、理論的には、以下の３つが考えられる。
（１）サーバーＡ、あるいはサーバーＢのどちらかのセッションに、２つのサーバーの
データを入れておく。
たとえば、サーバーＡに両方のセッションにいれたいデータを入れておいた場合、
セッションＢで、データが必要な時は、セッションＡに、データ取り出し請求をし、
書き変わったら、データＡに書き換え要求を出す。
（２）サーバーＡ、サーバーＢとは別のサーバーＣに、セッションデータを入れておき、
データが必要な時には、サーバーＣにアクセスする
（３）サーバーＡ、サーバーＢで、共有のハードディスク、データベースなどを用意しておき、
それを参照、書き換えする。
ロードバランサーで利用する場合、（１）は、まず、ない。かならず、Ａをアクセスするのであれば、Ａのアクセス回数は減らない（というか、増える）。（２）は、クラウドなどのときにありえる（認証したときの返り値に、セッションデータを返すとか）。（３）は、ロードバランサーでＬＡＮなどで利用するとき、あり得る。
（２）、（３）とも、１ブラウザごとに（たとえば１台で３つのブラウザを起動していたら、その１ブラウザごとに）、セッションを作る必要がある。
なので、ブラウザがセッションスタート、セッション終了を行ったほうが、やりやすいかもしれない。そして、各ブラウザごと、セッションをスタートしたら、そのセッションのＩＤ（セッションＩＤそのままだと、セッションハイジャックされる可能性があるから、暗号化するか、あるいはＨＴＴＰＳでＰＯＳＴで送るか）をブラウザが受取、各サービスに渡すかんじかなあ・・
で、（２）、（３）とも、セッションデータを保存しておかないといけない。
（２）の場合は、サーバーＣのセッション内という話もありえる。それ以外には、あるいは（３）の場合には、理論的には、２つのケースが考えられ得る。
（あ）セッションデータをデータベースにいれる
（い）セッションデータをファイルにいれる
（セッションＩＤなど、一意になるものをファイル名として）
（あ）の場合は、大量データの場合、問題がある。データベースはログを残す。セッションデータは、多くのデータをちょくちょく更新するので、その分、ログがガンガン書き出されてしまう（しかし、そのログは不要である）。
そーいうことから考えると、（い）のファイルのほうが無難か？
障害などを考えると、ＤＲＤＢでミラーリング？
（いまどきのネタだと、ミラーリングはバックアップにはならない）
まとめると、
クラウドで２サーバー間でセッションデータ共有したい場合、
セッションデータ管理用サーバーをおき、
そのサーバーのセッション、ないしファイルシステムでデータを読み書き
簡易ロードバランサーのような、社内サーバー間でデータ共有したい場合、
共有ファイルシステムでデータの読み書き
とくに、ＤＲＤＢとか使うかんじのが、クラウドや冗長性がはやると、でてきそうですね。
アクセス
トータル
ランキング
