ASP.NET 4.7.1 に関する情報がブログに公開されてました。Package-First なアプローチらしいです。
要するに ASP.NET の新機能と .NET Framework のアップデートのタイミングが別々になるということでしょう。最近はこの方式を採用しているケースが多いですね。
既にいろいろと紹介されている Configuration Builder が大部分を占めていますが、最後にひっそりと Cosmos DB を使ったセッションプロバイダーが載っていました。
バージョンは 1.0.0 ですが .NET 4.6.2 から対応した Async SessionState に対応しています。
Async SessionState に関しては、去年 NuGet でモジュールがリリースされています。
セッションプロバイダーを書いたことがある人ならわかると思いますが、これまでの SessionState は非同期とか全く考えられていない時に作られたものなので、基本的に全て同期処理されるようになってます。
なので、最近の新しいストレージを使う場合には、わざわざ Task が使われている部分を Wait や Result で待つ実装が必要でしたが、これが地味に大変。
話がずれたので Cosmos DB のセッションプロバイダーに戻ります。例によって NuGet でインストールするだけの簡単セットアップなので、特に紹介することはないです。
インストールすると Web.config に必要な設定が追加されるので、少し弄るだけで使えるようになってます。
Endpoint と AccessKey は appSettings にキーが追加されているので、正しい値をセットしておきます。
DatabaseId と CollectionId はダミー文字列なので適当に名前を決めて設定しておきます。存在しない場合には offerThroughput の値で新規に作成されます。デフォルトは 5000 RU なので少し注意。
パーティションキーの指定とか、優先的に使うリージョンの設定も出来るみたいですが、もうちょっとドキュメントと検証が必要な感じです。
適当に ASP.NET 側でセッションに値をセットすると、ちゃんと Cosmos DB にドキュメントとしてデータが保存されていました。ID がそのままセッション ID になっている、非常にわかりやすい実装です。
データ自体はいつも通り BinarySeiralizer でシリアライズされているみたいで、そして多分ロックなしの実装です。Redis も同じように Async SessionState で実装されると嬉しいですね。
特徴としては Cosmos DB の TTL 機能が使われているので、勝手に期限切れのデータが消えてくれるのが便利です。timeout を 60 分に設定したところ、ちゃんと ttl は 3600 秒になってます。
セッションプロバイダーとして Cosmos DB を使うことで、高い可用性と低いレイテンシ、そしてジオレプリケーションなど Cosmos DB の利点を全て得ることが出来ますね。
しかし RU の関係もあり、セッションに何でもかんでも入れるような実装では、一瞬で RU が足りなくなって高額になってしまいそうですし、設計時点で考慮する必要があるでしょう。
