memcachedを知り尽くす

第3回　memcachedの消去メカニズムと今後の動向

memcached

この記事を読むのに必要な時間：およそ 4 分

memcachedはキャッシュなので，特定のデータが常にサーバに存在しないことが前提でシステムに導入されます。今回はmemcachedのデータ削除メカニズム，そしてmemcachedの最新動向であるバイナリプロトコルと外部エンジンサポートをご紹介いたします。

memcachedはデータ削除もリソースを有効活用する

memcachedから実際にデータは消えない

前回の記事で紹介させていただきましたが，memcachedは確保したメモリを解放しません。レコードはtimeoutが過ぎたらクライエントから見えなくなる（invisible・透明になる）だけで，その領域は再利用される仕組みです。

Lazy Expiration

memcachedは内部的にレコードがexpireしたかの監視を行いません。替わりにgetする際にレコードのtimestampを見ることで，そのレコードがexpireしたかをチェックします。このテクニックをlazy（なまけた）expirationと呼びます。したがって，memcachedはexpireの監視にCPUタイムを消費しません。

LRU: 有効的にキャッシュからデータが消える仕組み

memcached はtimeoutしたレコードの領域を優先的に再利用しますが，それでも新しいレコードを追加する領域がなかった場合はLeast Recently Used（LRU）という仕組みを使って，領域を確保します。LRUはその名の通り，「⁠最近もっとも使っていない」レコードを削除対象にする仕組みです。したがってmemcachedがメモリ不足になった場合（slab classから領域を取れなかった場合⁠）⁠，最近参照されていないレコードを検索して，その領域を新しいレコードに割り当てます。キャッシュの実用性の観点から見てこのモデルは理想的ではないでしょうか。

ユースケースによっては，LRUの仕組みが邪魔になることもあり得ます。そういった場合のために，memcachedにはスタートアップでLRUを無効化する“⁠-M⁠”オプションがあります。以下が起動例です：

$ memcached -M -m 1024

スタートアップ時に気をつけないといけない点は，小文字の“⁠-m⁠”オプションは最大メモリサイズの指定だということです。値が指定されていなければデフォルトの64MBで起動します。

“-M⁠”オプションでスタートアップしてメモリを使い切ったら，memcachedはエラーを返します。ただ，やはりmemcachedはストレージではなくキャッシュなので，LRUを使うことがコミュニティから推奨されています。

memcachedの最新動向

現在，memcachedのロードマップには二つ大きな目標があります。一つはバイナリプロトコルの使用策定と実装，そしてもう一つは外部エンジンのロード機能です。

バイナリプロトコルに関して

バイナリプロトコルを採用した理由は，テキストプロトコルのパース処理を省き，既に高速なmemcachedのパフォーマンスをさらに向上させることが狙いです。また，テキストプロトコルならではの脆弱性を減らす目的もあります。実装は実はかなりできていて，開発レポジトリが既にウェブに公開されています。レポジトリへのリンクはmemcachedのダウンロードページに載っています。

バイナリプロトコルの形式

プロトコルのパケット形式は24バイトの固定長フレーム，そしてその後ろにキーと値のUnstructured Dataが続きます。実際の形式は以下になります（プロトコル仕様書から引用⁠）⁠：

 Byte/     0       |       1       |       2       |       3       |   
    /              |               |               |               |   
   |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
   +---------------+---------------+---------------+---------------+
  0/ HEADER                                                        /   
   /                                                               /   
   /                                                               /   
   /                                                               /   
   +---------------+---------------+---------------+---------------+
 24/ COMMAND-SPECIFIC EXTRAS (as needed)                           /   
  +/  (note length in th extras length header field)               /   
   +---------------+---------------+---------------+---------------+
  m/ Key (as needed)                                               /   
  +/  (note length in key length header field)                     /   
   +---------------+---------------+---------------+---------------+
  n/ Value (as needed)                                             /   
  +/  (note length is total body length header field, minus        /   
  +/   sum of the extras and key length body fields)               /   
   +---------------+---------------+---------------+---------------+
  Total 24 bytes

ご覧の通り，パケット形式はかなり簡素な仕様となっています。この形式で気になる，16バイトも占領しているHEADERですが，HEADERはRequest用とResponse用の2種類が存在します。HEADERにはパケットの有効性を示すマジックバイト，コマンドの種類，キーの長さ，値の長さなどの情報が含まれ，以下の形式になっています：

Request Header

 Byte/     0       |       1       |       2       |       3       |
    /              |               |               |               |
   |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
   +---------------+---------------+---------------+---------------+
  0| Magic         | Opcode        | Key length                    |
   +---------------+---------------+---------------+---------------+
  4| Extras length | Data type     | Reserved                      |
   +---------------+---------------+---------------+---------------+
  8| Total body length                                             |
   +---------------+---------------+---------------+---------------+
 12| Opaque                                                        |
   +---------------+---------------+---------------+---------------+
 16| CAS                                                           |
   |                                                               |
   +---------------+---------------+---------------+---------------+

Response Header

 Byte/     0       |       1       |       2       |       3       |
    /              |               |               |               |
   |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
   +---------------+---------------+---------------+---------------+
  0| Magic         | Opcode        | Key Length                    |
   +---------------+---------------+---------------+---------------+
  4| Extras length | Data type     | Status                        |
   +---------------+---------------+---------------+---------------+
  8| Total body length                                             |
   +---------------+---------------+---------------+---------------+
 12| Opaque                                                        |
   +---------------+---------------+---------------+---------------+
 16| CAS                                                           |
   |                                                               |
   +---------------+---------------+---------------+---------------+

各々の要素に関して詳しく知りたい場合は，memcachedのバイナリプロトコルの開発ツリーをチェックアウトしてdocsフォルダ内のprotocol_binary.txtという仕様書をご覧ください。

HEADERを見て気になる点

HEADERの形式を見て私が思ったことは，キーの限界値が巨大！ということです。現在のmemcachedの仕様ではキーの長さは250バイトまでという制限がありますが，バイナリプロトコルではキーのサイズが2バイトで表現される仕様になっています。したがって，理論上，最大65536バイト（216)までのキーが扱えることになります。250文字以上のキーを扱うユースケースはそう頻繁にないでしょうが，バイナリプロトコルがリリースされると巨大なキーも扱うことが可能になります。

バイナリプロトコルは次世代の1.3シリーズからサポートされます。

memcached

著者プロフィール

前坂徹（まえさか とおる）

株式会社ミクシィ 研究開発グループにて，オープンソース技術の開発・検証を担当しています。memcachedの開発コミュニティのメンバーでもあり，現在は1.3シリーズの開発に携わっています。

URL：http://torum.net/