ASP.NET Core でSession Replication (Sessionを外部で管理して、複数台で動かしても、また再起動したあともSessionデータを利用できるようにする)をやろうと考えた時のお話です。まだ確信をもっているわけではないのですが、調べたことをまとめるのも兼ねて記事にしました。
まずASP.NET Core でのアプリケーションの状態管理（リクエストの間だけ有効とかSessionとか）についてはこちらのページに記述があります。
Managing Application State — ASP.NET documentation
この項に記述がありますが、IDistributedCacheというインターフェースを通してDI経由で分散キャッシュの仕組みを容易に導入することができます。また導入しておくと、セッションもこのキャッシュを利用して保存される仕組みになるようです。ASP.NET チームの実装としては現在SQLServerとRedisが利用可能になっていました。
NuGet Gallery | Packages matching Microsoft.Extensions.Caching
ただ、Redisについては.NET Standardには対応しておらず、別の方の実装が利用可能です。
で、ここまでを使えば、.NET Core on RHEL な環境でもRedisを使って分散キャッシュでSessionを管理できます。が、問題はここからで、これだけだと再起動後にマシンが変わる、具体的にはContainerを利用していてデプロイのたびにContainer を作り直すような環境では再デプロイのたびにSessionが新規に発行されます。この理由を実装を追い掛けながら確認していたのですが、どうやらクライアントから送信されているCookieの値をSessionIdと関連付ける部分にマシン固有で生成している値を利用しています。この部分については「Data Protection」という名前で解説されています。
Configuring Data Protection — ASP.NET documentation
この実装を見る限り、Linuxから使うためには、複数マシンにNFSをマウントする、などのファイル共有を利用する必要がありそうです。
RedisだけでなくNFSの利用も必要なのがいまいちな感じなので、roadmapとあわせて調べていく予定です。
