Windows Azureで考えるセッション問題

「セッション管理の問題は頭が痛い」

「どうして?」

「複数インスタンスにスケールアウトすると、インプロセスのセッション管理は破綻する」

「別インスタンスから同じデータにアクセスできないわけだね」

「ではどうすれば良いか。Azure Cacheを使ったソリューションが一番の基本ラインのようだ」

「アウトプロセスのストアにデータを保管しておけば、どのインスタンスからでもセッションの継続性が分かるわけだね」

「でもね。この方法はAzure Cacheの利用コストが加算されるので、それほど重要な意味をセッションに与えていないYamato Driveでは避けたい」

「ではどうすればいいの?」

「Azureのストレージに保管する方法がある。MSDN Blogにソースがあるからそれを探してきたら、利用しているストレージのライブラリのバージョンが古すぎて泣いた。仕方がないので、全部書き直したら、凄く遅くてしかも動作が不安定になった」

「なぜ不安定?」

「動作を理解していないソースを機械的に書き換えたからだろう。一部は1対1で置き換えられないから、まとまったコードを書いたけど、動作を理解しないで書いたからやばい」

「それは恐い」

「しかし問題はそれより遅いことだ」

「そっちが重要だってことだね」

「結局、セッションを確認するために、セッションに関係ないどうでもいいファイルへのアクセスまで全部セッション確認処理が走っているのが悪いのだろう……と分かった」

「じゃあ、どうすればいいんだ?」

「デフォルトではインプロセスのセッション管理が使用されているが、これは高速なので使わなくてもほとんど意識しなくて良い。しかし、Azureでやるなら、本当に必要とされているページ以外ではセッション管理をさせない等の配慮も必要だろう」

「理想的な状態ってなに?」

「それはね。100%セッションが無い状態だ。全てのページは独立していて、ブックマークしておくといつでもそれが見られる。そのページに到達するまでのコンテキストへの依存性が無い。あるいは、それはURLパラメータに全て反映されていて、同じ状態が再現されるのが理想像」

「でも理想は理想なのだね?」

「そう。現実のシステムは理想通りには行かない。脳内お花畑に住んでいる雲の上の人達が何を言ったところでセッションは0にできない。ただ0にできないことと、常にセッションは必要という主張は違う。実はセッションが必要無い場面も多いので、何もかもセッションを前提にすることも間違っている」

「分かった。だから、デフォルトのインプロセス管理から離れた時に、セッション管理を見直す意味があるわけだね」

「ってわけで、これからセッション管理を見直すよ」