Facebookの事例を紹介した同社Vice President of TechnologyのJeff Rothschild氏

従来は、Webサーバから直接MySQLに対して接続し、読み書きを行なうことが一般的だった。大多数のWebアプリケーションでは読み取りの方が書き込みよりも圧倒的に多い(8:2かそれ以上)ので、読み取りはスレーブに、書き込みとリアルタイム性の求められる読み取りはマスターに対して行う構成になった(MySQLのレプリケーションは非同期)。

しかし、この構成には非効率な点がある。特に大きいのは、キャッシュを有効活用できていないという点だろう。同じユーザが更新しないで同じ結果セットを繰り返し取るようなことは頻繁に起こりうるので、SQL文をいちいち実行するようなことなく、即座に結果を返せるようなキャッシュ領域がほしいところである。MySQLではクエリキャッシュという仕組みがあるのだが、クエリキャッシュはテーブルが更新されると消えてしまうので、関係ないユーザーから同じテーブルが更新されてもキャッシュは消えてしまい、結果としてキャッシュミスが多くなる。

クエリキャッシュがきかなくても、InnoDBバッファプールやファイルシステムキャッシュ上などのキャッシュは効くが、これらの領域にアクセスするにはSQL文を実行しなければならならず、オーバーヘッドは大きい。

また、スレーブはロードバランサーを使って負荷を散らすことが多いのだが、異なるMySQLサーバ間ではキャッシュが共有されないので、やはりキャッシュミスが多くなってしまう。このような点から、大多数のユーザを扱うアプリケーションでは効率的とは言えなかった。

そこで、WebサーバとMySQLサーバとは別に、キャッシュ専用のサーバを配置するテクニックが広がった。MySQLに対してレコードを都度取りに行くのではなく、表示に必要なオブジェクトをキャッシュサーバに置いておくのである。もちろん、更新の際はMySQL側だけでなくキャッシュサーバも更新する。

ヒット率を上げるために、すべてのWebサーバからキャッシュを共有できるようにする必要がある。またキャッシュサーバ1台ではメモリが足りなくなるので、複数台のキャッシュサーバを透過的に扱える必要がある。このようなことができるキャッシュサーバとして最も高い人気があるのは、言うまでもなくmemcachedである。キャッシュサーバという追加のサーバが増えると、サーバ台数が増えて管理がしづらくなるという人がいるかもしれない。しかし、memcachedのヒット率が高くなれば、それだけDBサーバへの読み取り要求の回数が減るので、スレーブ台数を減らすことができる。これは非常に大きなメリットと言えるだろう。

Facebookをはじめ、今回のMySQLカンファレンスで発表された大規模事例の多くが、このWebサーバ - キャッシュサーバ(memcached) - MySQLの構成を採用していた。