実例から学ぶmemcachedベストプラクティス(WEB+DB PRESS vol.47)

WEB+DB PRESS Vol.47

ネタがないので、覚書でお茶を濁す。
けど各社でもやっぱり使い方が違うのねーとのは見てよかった。大体は社内でマグナムさんが発表した内容だったので知ってた。マグナムさんゴイスーだね。そろそろブログがどこにあるのか教えてくれてもいいと思う。

■特徴

• 揮発性
• キーと値で格納
• LRU(Least Recently Used) ・・・格納サイズが一杯になると、使われてないものから破棄されてく。
• 有効期限を持たせられる

■memcachedの将来

• 1.3シリーズと1.4シリーズがある。
• 1.3はバイナリプロトコルをサポートするらしい。
• バイナリプロトコルなると、現在テキストプロトコルで行われてるテキストパースのコストが削減できるので高速になるらしい。
• 1.4はmemcachedのプラガブルストレージ化
• 簡単に言うと、利用者自身が自由にmemcachedの拡張を行えるようなAPIを提供するっぽい。現状で各社それぞれで独自の拡張が(memcasherやrepcachedとか)あるのでこれは良いですね。

■ 各社の使い方

• Webサーバ同一のサーバにあるmemcached→ローカルmemcached
• 別のサーバにあるmemcached→リモートmemcached
• mixi → 150台のmemcachedサーバをConsitent-Hashingで一つの巨大なmemcachedプールとして利用する。アプリ側からは特に利用に際して、どのサーバにつなぐかは意識する必要がないので、運用のコストは低い
• ニコニコ動画 → 用途別にmemcachedプロセスを立ち上げているので、個別のプロセスでmemcachedのチューニングを施してるっぽい。
• Livedoor → ローカルと、リモートを適宜使い分けてるらしい。
• memcachedは、CPUをそれほど切迫しないので、お下がりのマシンができたらmemcached用のサーバにしてみっか位のノリでいいっぽい。

■ うちの場合

• あんまり詳しくは書けないどさらっと、ローカルmemcachedを複数台のWebサーバでレプリケーション(repcached)とっているので、どのサーバにとりに行くみたいな事を普段は意識してない。運用負荷は低いけど、Webサーバに同居しているので、あまり大きなサイズの容量をmemcached用には確保できてない。また、レプリケーションをとってるとはいえ、ある瞬間ではタイムラグが発生するので、その中ではデータの整合性が取れていない瞬間があるかもしれない。