アプリケーション・サーバのセッションの保存先の話 - プログラマでありたい

Webシステムの方式設計をする際に、わりと悩むのがアプリケーション・サーバのセッション（session）の保存先です。アプリケーションサーバとは、TomcatやJBoss,IISやRuby on Railsなどで利用するUnicornやPassengerなどです。そもそもHTTPの基本仕様がステートレスな為、状態を保持する為にはどこかに状態を保持する必要があります。その解決策がセッションになります。そこでセッションの保存戦略を考える必要があるのですが、アプリケーションサーバやサイトの用途や性格、扱うデータの気密性・重要性によっても変わってきます。 それ以前にセッションの保存先のことの呼び方の定番が何かすら解らなかったりします。セッション・ストアとかセッション・ストレージとか、はたまたセッション・マネージャーとか。今回は、セッション・ストアで統一します。 主なセッションストアの種類と保存戦略

[morioka]

REST的視点でいえば(RESTfulでなく)素直なのはクッキーストアなのかも。

[tmatsuu]

スティッキーはAPサーバが落ちたときのユーザ側に発生する挙動がやはりよくない。クッキーストアって保持できる情報量に限界があるよね。結局共有セッションストアに落ち着くしかないと個人的には思う

[thrakt]

クッキーストアって実質的に完全にステートレス、という理解で正しいんだろうか。でないならサーバ側も別で考えないといかんような・・・ / アプリ上の一時的なデータとセッションはまた別じゃないかとか

[lepton9]

session

[kuenishi]

共有型のセッションストア、データが増えて運用難しいってことみたいだけどRiakとかCouchBase使えばそんなことないよ...

[derby]

セッションに何を乗せるかという設計と絡めて考えるとそんな容量ないはずなのでCookieも選択肢になる気がする。

[rochefort]

facebook cookie storeだったのか。

[Jxck]

Cookie は容量が小さい、localstorage とかで容量は増えるけど、デバイスをまたげるように作らないといけないからなぁ

[oppara]

アプリケーション・サーバのセッションの保存先の話 - プログラマになりたい

[tkawa]

セッションに見えてはいけないデータや大量のデータが入ってしまうようなら、その設計に問題がある。CookieStoreでうまくいくようにシステムを設計するのがいいと思う

[JULY]

セッションサーバをスケールアウトすること自体は、難易度は高いかもしれないけど、それほど特異な話でも無いと思うなぁ。

[akahigeg]

クッキーストアは手軽なようでいて要領とかセキュリティとか取り扱いに慎重を要するので、ある意味面倒だったりする。

[ikeike443]

容量少なすぎだしダメでしょ。

[ab_sn]

べんきょーになりますなー

[animalmother]

アプリケーション・サーバのセッションの保存先の話 - プログラマになりたい

[yamkazu]

え、今ってクッキー使う流れなの

[arakash]

セッションの保存先のまとめ

[YarmUI]

下手なこと考えずRedis使っとけと思う

[nemoba]

クライアントがステートフルになればHTTPSessionに入れる情報が減る。認証状況と機密情報ぐらいに。最も圧迫するビューの一時的な情報はクライアントが保持。セッションがミニマムになるとRailsみたいな方法に実用性

[uzuki-first]

memo

[paulownia]

クッキーストアってrails以外でもつかってるのかな？

[honeybe]

クッキーストアはデメリットに目が行きがちになるのでちょっと。共用セッションストアが良い感じかもだけどローカル+同期で済ますことが多い。あとで考えよう。

[kimutansk]

共有セッションストアに現状落ち着くんじゃないですかねぇ。シャーディングでスケールアウトは出来ますし。最近のだとレプリケーションもある。

[at_yasu]

CookieStoreとかあるのか。ほぉ / cacheサーバにセッション入れちゃだめよ。勝手に消えちゃう。

[harumaki_net]

取捨選択の話。悩みは尽きない…

[ktakemoto]

良いお話。