【認証設計】「セッション」の保存先について

ローカルストレージに保存する。

最近出てきたCognitoやAuth0などのトークン認証はこの方式がメインです。

「サーバーのメモリ」に保存する。

デフォルトの設定だとこれです。

メリット

• デフォルトなので、学習コストはない。
• DBにアクセスする必要がないのでパフォーマンスも良い。

この構成だとWebサーバのロードバランサ構成ができない場合がある。

AWSのELBなどは普通に片方のサーバーにだけ振り分ける設定もあります。

ただ、その場合は、片方のサーバーがダウンした際にセッション情報が損なわれてしまうのでデメリットです。（例えば、ショッピングカートの情報が丸々なくなります。）

ユースケース

• セッション再生攻撃をされても大きなリスクがない場合に採用するべき。
• セキュリティを強固に気にするようなアプリ以外はこの設定で良さそう。

セッションをDBに格納する。

メリット

データが永続化される。

容量を気にせず保存できる。

Webサーバをロードバランサ構成にすることが可能です。

デメリット

パフォーマンスが悪くなります。RDBは大量のI/Oに弱いためです。アクセスが増えると一気にパンクしてしまいます。しかもスケールしずらいです。

セッションをRedisに保存する。

メリット

• メモリ上に格納するのでパフォーマンスが良い。
• クライアントにはidしか送信しないので、セキュリティリスクが低い。
• Webサーバのメモリ負荷が減る。

別サーバーでセッション管理するのでWebサーバーのロードバランサ構成を楽々行える。

ただ、AWSのロードバランサ（ELB）は、同一セッションのアクセスに関しては同一サーバーに振り分ける設定があるようなので、普通に問題なくセッション維持はできるようだが。

ただ、片方のサーバーに障害が発生した場合でも問題なくセッションの保持ができるのはクッキー保持方式に比べた際の強みになる。なので、要件に「サーバーがダウンしたとしてもセッションを切らしたくない」というものがあった場合はこちらしか選択肢がなくなるでしょう。「サーバーがダウンする」と記述した場合めったにないことのように思えますが、仮にメンテナンスをする場合に置き換えても同じことでしょう。

デメリット

• メモリを使い果たすと書き込みが全てエラーになる。
• Redisサーバー再起動でセッションが消える。
• 実装コストが必要
• ElasticCacheなどのサービスを使うことになるのが普通なので費用がかかる。