ASP.NETのSessionといえば
- InProc(アプリけーションプロセス内のインメモリステート管理)
シリアライズコストも発生せず、同一プロセス内で言わばstatic Dictionary<string,object>の実装で最速。ただし、アプリけーションのリサイクルと同時にセッションが破棄されるのと複数プロセス間で共有できないです。 - StateServer(専用プロセスによるインメモリステート管理)
InProcの弱点である、アプリけーションのリサイクルによる破棄とプロセス間共有を実現出来るようにしたもの。プロセスをまたぐのでシリアライズコスト発生するけど、インメモリなのでInProcにつぐ速度を実現。ただし、シングルプロセスでの実装になるので、耐障害性という意味では弱い。ステートをホストしているマシンの障害や再起動などでセッションが破棄されてしまいます。 - SQLServer(ストーレジに保持するステート管理)
StateServerの弱点であり、耐障害性をクリアしたストレージ保存型でのセッション管理。シリアライズコスト＋DBサーバーのパフォーマンス次第で遅くもなるし早くもなる。 - Custom(SessionStateStoreProviderBaseを派生したカスタム実装)
キャッシュクラスタ(Velocity)を利用したり、EntityFrameworkを利用した実装(UniversalProvider)を使ったりSessionStateStoreに対してイロイロです。DBをSQLServer以外にする場合にも利用されてます。
選択肢多くていいですね。標準のものもそれぞれ優秀で素晴らしいです。SessionIDの生成や、クライアントとのやり取りは別の仕組みで実装されてるので、SessionStateStoreProviderのカスタムとは分離されてて安心です。
MongoDB ASP.NET Session State Store Provider | AdaTheDev
最近、すっかりMongoDBに心奪われてる身としては、SessionをMongoDBに入れてしまいたいという衝動にかられてます。あれやこれやの問題もあり、SQLServerだけにたよるソリューションだとよろしくないなというのもありまして。
MongoDB、大変優秀ですね。ReplicaSet(レプリケーション)による可用性の確保(自動フェールオーバー有り)と、Sharding(データのパーティショニング)によるパフォーマンスの確保、素晴らしいです。
いろいろ試して部分的に利用を始めてる段階で、まだまだ自信をもって使いまくるって言う状況ではないですが、ちょっとずつです。ちょっとずつ使っていってSQLServer＋MongoDBで行けるところまで行ってみようと企んでます。
まずはTraceListnerのMongoDB化。前回のエントリでそれっぽい感じのものを提示しましたが、これでサーバー群のトレース情報を低コストなストレージに保持出来るようになりますね。トレース情報くらいなら万が一情報欠落しても致命的になることも無いでしょう。しかし！セッションはそういうわけにはいきませんね。システムとして提供している表の機能に影響がでちゃいますからね。
そうなると、ReplicaSetの機能を利用することは必須となりましょう。そうするとFailoverの時の挙動を確認したりする必要も出てきますよね。そういうテストを繰り返してこそですよね。楽しい時間ですね。
先ずはReplicaSetでMongoDBを２つ起動。ArbitarっていうSQLServerでいうところのウィットネスサーバーを１台追加してないと投票結果が偶数とかになって次のPrimary決定時に困っちゃうことがあるので、３ノード起動します(詳しくはオフィシャルサイトでどーぞ)。
rem arbitar
start "arbitar" c:\mongo\bin\mongod.exe --port 27020 --replSet mongo --dbpath c:\mongo\dba
rem replicaset
start "mongo1" c:\mongo\bin\mongod.exe --rest --noauth --port 27031 --replSet mongo --oplogSize 20 --dbpath c:\mongo\dbr1
start "mongo2" c:\mongo\bin\mongod.exe --rest --noauth --port 27032 --replSet mongo --oplogSize 20 --dbpath c:\mongo\dbr2
これで起動してるので(c:\mongoに一式ある前提です)、まずは初期化。
27031のノードにMongoDB Shellで接続。
mongo localhost:27031
初期化コマンド順番に実行すればOKです。
rs.initiate()
rs.add("hostname:27031")
rs.add("hostname:27032")
rs.addArb("hostname:27020")
まずはこの状態で公開されてるソースを利用してSessionを使ってMongoDBにデータを入れてみましょう。
MVC4DPでアプリケーションを作り、Home/IndexアクションでSessionに値をいれて、Home/Indexビューで表示するだけのものです。
public ActionResult Index()
{
ViewBag.Message = "Modify this template to kick-start your ASP.NET MVC application.";
Session["message"] = ViewBag.Message;
return View();
}
<h2>from session:@Session["message"]</h2>
↑ここからソースを取得して、プロジェクトに追加。後はNuGetでMongoDB Official Driverを入れておきましょう。
コメントに従い、接続文字列を指定するとレプリカセットにならないので、今回起動したMongoDBを指すように接続文字列を変更。
connectionString="mongodb://localhost:27031,localhost:27032/"
ちゃんと出来てますね。
MongoVUEで27031(primary)データを確認。
入ってるねー。
続いて27032(Secondary)のデータを確認。
もちろん入ってますね。
ここで、ReplicaSetを入れ替えましょう！
MongoDB ShellでPrimaryにつないで rs.stepDown() で強制フェールオーバーを実行。
ちゃんと切り替わりました。
この状態で再度先ほどの起動したブラウザでF5でリロード。ちゃんと動くなら、これでFailoverしたほうを参照して、表示されるはず！
タターン！うまくいきました。内部ではSafeModeっていう書き込み確認モードで動作するようになってるので、手堅いです。
27032(SecondaryからPrimaryに変更したノード)でSessionsコレクション(テーブルですね)を確認して見つつブラウザのF5リロードを繰り返すと、ちゃんとLockIdがカウントアップしていくので、読み込みも書き込みもFailover後にちゃんとできてるのが確認できます。
だがしかし！ここで大問題が！！
パフォーマンスを測定しようとApache Benchでリクエストを投げまくってみると、最後まで完了せずにエラーで途中終了してしまいます。
Unable to connect to the primary member of the replica set: システムのバッファー領域が不足しているか、またはキューがいっぱいなため、ソケット操作を実行できませんでした。
なかなかの男気あふれる強気のエラーメッセージ。
どーしたんだMongoSessionStateStore！
これが精一杯なのかOfficial Driver！
長くなったのでつづく．．．。
