タイトルの通り、まだプレビューの Windows Azure Cache Service を Web サイトで、しかも本番環境で使っているので何か書きます。
Cache Service の概要と簡単な使い方は、安心と信頼の抱かれたい男 No.1 のブログを参照してください。
Windows Azure Cache Serviceとか « ブチザッキ
Windows Azure Cache Service (Preview)を使ってみる « ブチザッキ
何故 Cache Service をプレビューなのに本番に突っ込んだかと言うと、あなたの知らない Windows Azure Web サイトの世界 - しばやん雑記 の最後にも書いたように Web サイトって月に 1 回ぐらいは標準でもインスタンスが変わってしまうんですよね。
なので、セッションを InProc で使っていたり、キャッシュを HttpContext.Cache に突っ込んでいると、気が付かないうちに消滅してることもあり得ます。
セッションに関しては「Universal Provider 使って SQL Azure に保存するようにすればいいじゃない」と思われると思うんですが、SQL Azure にテーブル作るのはめんどくさいし、性能面で多少難ありそうだしと積極的に使える気分じゃなかったです。キャッシュに関しては諦めるしかないですしね。
長々と書いてしまいましたので、とりあえず本番環境でセッションと共有キャッシュとして使っている場合の Cache Service メトリックはこんな感じです。
Cache Service のメトリックは約 20 分遅れなので、そこだけ注意。キャッシュミス率が高いのは、高くなるような使い方をしているからなので気にしないでください。
一応ピークタイムのメトリックなのですが、それでもメモリは 1% も使っていないので、普通にセッションで軽く使う分には Basic の 128MB で十分だと感じました。インストール自体も、NuGet でパッケージをインストールして、アクセスキーを設定するだけで使えるので便利でした。
以下、実際に使ってみてハマった点をまとめときます。
Expiry Policy の設定に気を付ける
デフォルトでは Expiry Policy は Absolute になっているのですが、Absolute のままだと DataCache.Put メソッドを使った時、既存エントリの有効期限が上書きされない気がしました。
有効期限を上書きしたい場合には Sliding に設定しておいた方がいいかもしれません。
実行中に設定を変えると、既存コネクションが死ぬ
先程の有効期限が延長されないんじゃないかと言う件に伴って、Expiry Policy を Absolute から Sliding に変更した時に 3 分ほど Cache Service に接続できない現象が発生しました。
その場合、DataCache クラスの各メソッドで例外が投げられるので、そのあたりのハンドリングをきっちりしておくことと、設定は稼働中に弄らない方が良いと思いました。
メトリックが遅れる、止まる
通常はメトリックは約 20 分遅れていますが、何らかの原因で数時間反映されない時がありました。
メトリックの更新がされていなくても Cache Service 自体は正常に動作していたので、特別心配する必要はないようですが気になりますね。
とまあ、数点書いてみましたが、まだ Cache Service は Preview で現在半額大バーゲン中なのもあるので、生暖かく見守りたいと思います。使い勝手は圧倒的に良いので、これからも Preview の間にちょいちょい使っていく予定です。
