株式会社ミクシィの前坂です。第1回でmemcached 1.4の簡単な紹介をしました。今回は新しく正式導入されたバイナリプロトコルの扱い方をご紹介いたします。
バイナリプロトコルの扱い
バイナリプロトコルを扱うには、アプリケーションのプログラミング言語に合ったバイナリプロトコル対応のクライアントライブラリが必要です。バイナリプロトコルは最近導入されたこともあり、ネイティブ対応していると報告されているクライアントライブラリはC言語のlibmemcachedとJavaのspymemcachedだけです(2009年8月時点)。ただし、世の中にはlibmemcachedをwrapした、さまざまの言語で記述されたクライアントライブラリがいくつかあり、それらを使ってバイナリプロトコルを扱うことが可能です。
今回の記事ではそれらのクライアントも含めて, C、Java、Python、PHPでのデモコードを紹介いたします。
バイナリプロトコルを扱うデモコード
バイナリプロトコルを扱うにはバイナリモードに適応するというコードを1行追加するだけで, ほとんどの場合は従来のテキストプロトコルと扱いは変わりません。以下が今回の検証に使ったクライアントライブラリ集です。
デモコードはmemcachedがlocalhostのデフォルトポート(11211)に立ち上がっている事を想定しており、単純に1つのレコードをSET/GETします。
バイナリプロトコル仕様
プロトコルには「要求」と「返答」という概念が存在し、プロトコル設計においてこれらの形式を明記する必要があります。memcachedのバイナリプロトコルではヘッダ(通信の内容や情報が含まれるデータ)がリクエスト用とレスポンス用に2種類存在します。どちらも24バイトの固定長ヘッダであり、固定長なゆえにmemcachedのバイナリプロトコルハンドラは高速な処理を施すことが可能です。
バイナリプロトコルの詳細な話に関しては以前執筆させていただいた、「memcachedの削除メカニズムと今後の動向」にて解説しましたので、ご興味のある方はそちらをご覧ください。
バイナリプロトコルとコネクション制約
memcachedは1つのコネクションに対して、テキストかバイナリの1つのプロトコルしか扱えないという制限があります。これはmemcachedがコネクションとプロトコルハンドラを内部的に固定するからです。したがって、1つのコネクションでテキストとバイナリプロトコルを両方処理する事はできません。
ライブラリ移行における運用面の注意点
memcachedのクライアントライブラリは世の中に多数存在しますが、今までアプリケーションで使ってきたクライアントライブラリを安易に変更してはいけません。その理由はクライアントライブラリの分散アルゴリズムが違った場合に多数のキャッシュミスが発生し、システムのインフラに多大な負荷をかけてしまうからです。
クライアントライブラリの移行を考えている場合は新しいライブラリの動作を調査し、必要に応じてサーバ群をウォームアップ(キャッシュサーバにデータを予め蓄積する)などの戦略を練る必要があります。
気になる性能
プロトコルの違いによるスループットの差をlibmemcached付属のmemslapというベンチマークツールで測定してみました。今回のベンチマークは10万レコードをキャッシュしているサーバに対して、全レコードを各々のスレッドが並走してGETするものです。クライアントとサーバは同じスイッチに繋がっている別々の物理サーバです。
並走度 | バイナリプロトコル | テキストプロトコル |
1 | 14.228秒 | 14.367秒 |
2 | 15.047秒 | 15.984秒 |
4 | 17.310秒 | 17.794秒 |
8 | 22.073秒 | 23.097秒 |
16 | 23.783秒 | 25.342秒 |
上記の結果を見る以上、バイナリプロトコルの方が若干スループットが高いという傾向が見られます。誤差にすら見える結果ですが、実運用で何千ものコネクションを同時に処理することを想定すれば、差は広がると仮定できます。もっと本格的な負荷をエミュレートしたいところですが、私の手持ちのハードウェアでは16以上の並走度は信頼性に欠けると判断し、検証は16スレッドまでとしました。
次回予告
今回はC言語、Java、Python、PHPを用いたバイナリプロトコルの使用例や簡単な性能検証を紹介しました。次回はmemcached 1.4から強化された統計システムや、新しく得られる統計情報を紹介いたします。