AppFabric Caching Released...というわけで
Windows Azure AppFabric Caching Service Released] というわけで、少し前につぶやいていた WCF ベースのリモートオブジェクトによる状態管理とかは時代遅れ感が。ツイートと一部かぶりますが、FAQ から数項目および「日曜大工ソリューションとの比較表」を引用すると、
- キャッシュ容量で月額課金
- 新しいオブジェクトを格納するのに十分な空き容量がない場合、もっとも使用されていないオブジェクトから捨てていく
- オブジェクトはリモート化と保管のためにシリアライズされる
- シリアライズ後のサイズが 8MB を超えるオブジェクトはキャッシュされない
| _ | AppFabric Caching | Do-it-Yourself |
|---|---|---|
| Dedicated memory | AppFabric Caching では、要求されたキャッシュサイズに必要なメモリが常時確保されていることを保証します。 | 通常のメモリ要求に従って、OS や稼働中のアプリケーション等のプロセスとインスタンスのメモリを奪い合います。 |
| Ease of use | AppFabric Caching は必要なすべての機能が提供され、ただそれを使うだけでよい。 | 設定可能な構造を作ってインストール手順も用意して、そして自分でサービスの稼働状況を管理したり、メンテナンスまで行わなければならない |
| Distributed | AppFabric Caching は分散されていて、スケーラブルになっているため、ポータルサイトでサイズ設定を変更するだけでよい。 | コンピュートインスタンスに依存した範囲でのスケーラビリティしか得られない。 キャッシュ容量の実現のためだけにインスタンスを追加することになるやもしれません。 |
| SLA | 稼働率を SLA に準拠させます。 | 日曜大工のSLAはだれが保障しますか？ |
こんなかんじらしい。訳はちょーーーいいかげんなので、きっと意図がかわっているところもあるかもしれません。
メモリ空間が保障されることと、ローカル キャッシュの外側のサービス部分がテーブルストレージ等と同様の負荷分散が行われる部分が、日曜大工的には解決が難しいところでしょうか。ちなみに、前述の WCF による ASP.NET セッションマネージャでは、
- セッションが初めて生成された時、それを受け付けたコンピュート インスタンスがセッション オブジェクトを保持する
- 保持していないセッションを含んだリクエストが発生した場合、WCF で保持しているインスタンスへ接続し、セッション オブジェクトをリモート操作する。
- インスタンスが停止した場合、保持しているオブジェクトはすべてキューに投げる
- この仕組みに参加している各インスタンスはキューを監視しており、キューから取得したオブジェクトを保持する
といったかんじになっておりました。小規模ならこんな程度でもなんとか動と思われるのですが、それなりの実装量にはなります。メモリ消費量の問題もありますが、もうちょっときちんと制御しないと、せっせとデキューしまくる暇な WorkerRole にオブジェクトが貯まってしまったり、それがダウンするとキューがあふれるとか、キュー上にあるセッションに対するリクエストが発生したら……などなど、実運用には耐えないでしょうね。
