memcachedを知り尽くす

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

2008年7月16日

前坂徹

memcached

キャッシュ, パフォーマンス, エンジン, バージョン, レコード, バイナリプロトコル

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のダウンロードページに載っています。

http://danga.com/memcached/download.bml

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

プロトコルのパケット形式は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バイト（2¹⁶)までのキーが扱えることになります。250文字以上のキーを扱うユースケースはそう頻繁にないでしょうが，バイナリプロトコルがリリースされると巨大なキーも扱うことが可能になります。

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

memcached

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

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

URL：http://torum.net/

memcachedを知り尽くす

このエントリのトラックバック URI

お名前
メールアドレス
タイトル
コメント

多数の情報処理技術者試験対策書籍の発行実績を誇る技術評論社がお届けする，資格試験合格サイト「めざせ！情報処理試験パスサポ」が開設されました。

サクセスストーリーに続く，快適サーバー運用管理のヒント！: データの増大，煩雑な管理，システムダウン，セキュリティなど，迫りくる課題からシステム管理者の負担を軽くするポイントを解説します。
gihyo.jp インフラエンジニア情報局: ネットワークやITにかかわるあらゆる業種で必要とされるインフラエンジニアに向けた技術情報や心構え，その魅力について多角的に紹介。
テストエンジニアステーション: いま，ITに関わるあらゆる開発業務で注目されつつあるテスト系エンジニアをターゲットにしたコンテンツサイトを展開します。

※検索はページ右上の検索ボックスをご利用ください。

オープンソースの知的財産権/暗号輸出の違反防止ツール「Black Duck Suite」ご紹介セミナー（3/5，12）
矢野りんさんに学ぶ、“使える”デザイン基礎知識（3/6, 13）
最新ソフトウェアプロテクションの導入方法（3/8～4/16）
第16回エンバカデロ・デベロッパーキャンプバーチャルエディション（3/11，12）
Adobe FLASH PLATFORM CAMP Tokyo（3/16）
「組込みデータベースを利用した開発のポイントとDeviceSQLのご紹介」セミナー（3/17）

2010年版SEO体得講座: 本連載では，いまや企業サイトの戦略の1つとして欠かすことのできないSEOについて，最新トレンドからすぐに使えるTipsまでを紹介します。
小型Linuxサーバの最高峰 OpenBlockS 600活用指南: 搭載メモリの増加，CPUクロックの向上など，あらゆる面が強化された期待の新モデルOpenBlockS 600。この記事ではOpenBlockS 600の紹介から，活用するためのさまざまなノウハウを紹介していきます。
はじめMath! Javaでコンピュータ数学: プログラミング言語入門者向けに，知っていると役立つ数学的トピックスを紹介します。簡単な演習問題と解説で，即活用できる知識を目指します。
教科書には載っていないネットワークエンジニアの実践技術: ネットワークエンジニア，インフラエンジニアのトラブル対応には，時には「教科書通りにいかない」テクニックが必要となります。資格試験では得られないこうした実践的な技術について，実例を元に紹介します。
Googleケータイ，世に現る: 2008年9月，Googleが中心となって開発されている「Android」を採用した携帯電話「T-Mobile G1」が発表されました。本連載ではT-Mobile G1を中心にGoogleケータイに迫ります。
モバゲーオープンプラットフォームに挑戦！――面白法人カヤック流モバゲーオープンプラットフォーム企画と開発のイロハ: 2010年1月にリリースとなったモバゲーオープンプラットフォーム。その制作企業であるカヤックが，アイデアを企画に落とし込み，開発までのノウハウを紹介します。
プロトタイピングツールSketchFlowを用いた，Silverlightアプリ開発: SketchFlowプロトタイプ作成からアプリケーション開発までをExpression Blend 3を使って実践的に解説します。
Ubuntu Weekly Recipe: Ubuntuの強力なデスクトップ機能を活用するための，いろいろなレシピをお届けします。