スティルハウスの書庫の書庫

はてなダイアリーで書いてた「スティルハウスの書庫」を移転してきました。

分散キャッシュはあくまでキャッシュ

先の@ITの記事では、memcachedなど、分散キャッシュとして使われているKVSについては取り上げていません。なぜなら、一般的にはそれらは「RDBの置き換え」としては使われておらず、「スケールしにくいDBをスケールさせる手段」として使われているからです。

こうした分散キャッシュ(複数のアプリケーションサーバやクライアントにDB内容をキャッシュするもの)は、80〜90年代からいろいろありました(とくにOODB分野)。

昔:

最近:

ただ単にAPサーバのメモリ上にキーバリューペアを保存するだけのものから、更新があったときには各ノードのキャッシュを破棄できるもの、トランザクショナルなもの、さらにはRACみたいにノード間で洗練された排他制御や協調処理ができるものまで、多種多様です。

私も7年くらい前に、あるISPシングルサインオンシステムを設計・実装したときに、RDB負荷を下げるための分散キャッシュとしてEJB 2.0のEntity Beanを使いました。Stateful Session BeanとEntity Beanを組み合わせ、APサーバ側で適切なキャッシュ制御(WebLogicのReadMostlyやJBossのoption Dだったかな?)を行うことで、以下のような特性を持つ分散キャッシュを安価(タダ)に構成できました。

  • トランザクショナルなキャッシュ(エラー時にはキャッシュ内容がロールバックされ、また楽観ロックでトランザクション排他されるJavaオブジェクト)
  • 複数のAPサーバ間でキャッシュの整合性を確保(更新処理時には他のAPサーバにキャッシュ破棄を指示)

これでSELECT文の発行を1/10くらいに減らせたのを覚えています。そんな構成が好きだったので、当時は「ステートフル派」(RDBはステートフルなキャッシュを使わないとスケールしないよ!派)でしたが、いまやApp EngineのDatastoreがあるのでステートレス派(或いは、俺はいまHttpSessionにデータを入れたと思っていたらいつのまにかDatastoreに入っていたから結局ステートレスだね!派)です。

11/15追記

Oracle Coherenceについて誤解してました。これは分散キャッシュ的使い方も可能ですが、むしろ「信頼性が保証されておりRDBを置き換えられるKVS」であり、キャッシュ以外にもたくさんの使い道があると思います。