しばやん雑記

Azure とメイドさんが大好きなフリーランスのプログラマーのブログ

Azure Managed Cache を今すぐ捨てて Azure Redis Cache に移行すべき 3 つの理由

Azure Redis Cache が日本のリージョンで使えるようになってからまだ 1 か月も経ってませんが、積極的に使っていきたいので理由をつらつらと書いてみます。

中の人に各方面からめっちゃお願いしたので「せっかくデプロイしたのに日本人全く使ってねーじゃねーか!!」とか思われたくないですし・・・。

容量が多くて安い、そして安定してる

現在 Azure Redis Cache はプレビューでの提供となっているので、料金は GA 時の 50-65% 引きとなっていますが、それでも容量と機能を考慮しても Managed Cache よりは十分安いと思います。

Pricing Details - Caching

一番安いプランを比較してみると容量と値段の両方で Redis Cache のが上回っています。

Managed Cache
Basic 128MB で 2,550 円
Redis Cache
Basic C0 250MB で 835 円

Managed Cache で高可用性の構成が必要な場合にはプレミアムしか選択肢として入りませんが、Redis Cache なら 250MB の C0 であっても HA 構成を実現出来るのもメリットですね。Redis Cache の GA 時には SLA も提供されるようですし。

以前、Managed Cache の Basic 128MB をサービスで実際に使っていたのですが、設定変更をポータルで行った瞬間に 5 分ほど強制的に接続を切られたり、原因不明の接続エラーが連続して発生したりと踏んだり蹴ったりでした。管理ポータルから確認できるメトリックが不定期に遅延するというのもマイナスでした。

当時はまだ Managed Cache は GA していなかったので、現在はひょっとしたら改善されているかもしれませんが、これまでの経験的に重要な場面では使えないサービスとして理解しています。

クライアントとプロバイダーの出来が良い

Managed Cache では SessionStateProvider と OutputCacheProvider の 2 つが標準で提供されていましたが、そもそもの AppFabric Caching が提供している DataCache クラスの出来が最高に悪いので、キャッシュクラスターにトラブルが発生して接続が切れた場合に例外を目いっぱい投げる仕様になっています。こいつ、リトライしてないみたいなんですよね。*1

正直 AppFabric Caching の DataCache クラスに関してはいくらでも文句を言えますが、さっさと捨ててしまった方が気分的にも楽です。

Redis Cache に関しては Azure SDK チームから StackExchange.Redis を使った SessionStateProvider と OutputCacheProvider が提供されているので、特に不都合はないと思います。

NuGet Gallery | RedisSessionStateProvider 0.4.0-Pre-121

NuGet Gallery | RedisOutputCacheProvider 0.4.0-Pre-121

使い方は簡単かつ、設定もシンプルなので初めての人でも使えると思います。

f:id:shiba-yan:20140906175902p:plain

NuGet でパッケージをインストールすると Web.config にテンプレート的な項目が追加されるので、後は host と accesskey を設定するぐらいで完了です。複数のアプリケーションで Redis Cache を使いまわす場合には databaseId や applicationName を設定しておいた方が安全でしょう。

参考までに Redis 用の SessionStateProvider と OutputCacheProvider を使った場合に、どのような形で Redis に格納されるのかを簡単に調べてみました。

******.redis.cache.windows.net:6379> keys *
1) "/_a2/default.aspx"
2) "/_5c3rbto4fewj02r5pv4ebq4j_Data"
3) "/_a2/default.aspxHQFCDE"
******.redis.cache.windows.net:6379> type "/_5c3rbto4fewj02r5pv4ebq4j_Data"
hash
******.redis.cache.windows.net:6379> hgetall "/_5c3rbto4fewj02r5pv4ebq4j_Data"
1) "hoge"
2) "\x00\x01\x00\x00\x00\xff\xff\xff\xff\x01\x00\x00\x00\x00\x00\x00\x00\x06\x01
\x00\x00\x00\bhogehoge\x0b"
******.redis.cache.windows.net:6379> type "/_a2/default.aspx"
string
******.redis.cache.windows.net:6379> get "/_a2/default.aspx"
"\x00\x01\x00\x00\x00\xff\xff\xff\xff\x01\x00\x00\x00\x00\x00\x00\x00\x0c\x02\x0
0\x00\x00MSystem.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f1
1d50a3a\x05\x01\x00\x00\x00\x1dSystem.Web.Caching.CachedVary\x06\x00\x00\x00\r_c
achedVaryId\x11_contentEncodings\b_headers\a_params\r_varyByCustom\x10_varyByAll
Params\x03\x06\x06\x06\x01\x00\x0bSystem.Guid\x01\x02\x00\x00\x00\x04\xfd\xff\xf
f\xff\x0bSystem.Guid\x0b\x00\x00\x00\x02_a\x02_b\x02_c\x02_d\x02_e\x02_f\x02_g\x
02_h\x02_i\x02_j\x02_k\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\b\a\a\x02\x02
\x02\x02\x02\x02\x02\x02\xe3!\x1d\xbff+\xf8@\x91.j?\x13\xa2\xe2\x17\n\n\n\n\x01\
x0b"

キーはセッション ID や URL になっています。そしてセッションは hash として、出力キャッシュは string でレンダリング結果がそのまま格納されるような仕組みになっています。文字列はバイナリシリアライズされているようです。

Managed Cache はディスコン

Azure Cache の FAQ にそう書いてあります。

–Redis を推奨するのであれば、推奨されないオプションであるマネージ Cache (キャッシュ) が引き続き含まれているのはなぜですか。
Velocity Cache (キャッシュ) に投資し、自身のアプリでそのキャッシュとの依存関係があるお客様を支援するため、および Redis cache (キャッシュ) に移行するために必要な時間を提供するためです。

Pricing Details - Caching

Velocity というのは AppFabric Caching のコードネームです。Azure Managed Cache は AppFabric Caching をワーカーロールとかで動かしているだけでしょう。Web サイトから使える共有キャッシュが Managed Cache しかなかったので仕方なく使っていましたが、もう Redis Cache を使った方が良いでしょうね。

Managed Cache を ASP.NET の SessionStateProvider としか使っていない場合には Web.config の修正を行うだけで済むので、Redis Cache への移行はとても簡単なはずです。DataCache クラスを直接使っていた場合には少し手間がかかりますが、サンプルコードが提供されているのでそこまで難しくはないはずです。

Azure Redis キャッシュ (プレビュー) でのデータのキャッシュ

あとは最近、ObjectCache と互換性のある RedisCache クラスを作ったので、それを人柱覚悟で使ってみるというのもありかなと。

StackExchange.Redis は Stack Overflow で実際に使われているライブラリなので、実際の信頼性は AppFabric Caching なんかとは比べ物にならないでしょう。

*1:DataCache 作成の負荷が高いからシングルトンにしろと言う割に、エラー時にはリトライせずに死ぬ