memcachedのストレージにSSDを使うアイディア

memcached Night in Tokyo #1によれば、mixiはmemcachedサーバーを135台使っているらしい。多い！
話に依れば一番最初に足りなくなるのはメモリの容量（3GBほど割り当てられている）で、ネットワークやCPUはボトルネックになっていないらしい。

ではメモリの代わりにHDDを使うのはどうか。HDDのランダムアクセス時の遅延がかなり大きいので、影響が出るほど遅くなりそう。

そこでSSDを使うのはどうか。ランダムリードで700Mbpsくらい出るらしいので、スループットに関してはCPUの方が先に限界に来ると思う。遅延はどれくらいか良く分からないが、アプリケーション側でget_multiを使っていれば隠蔽できないか。
バイト単価はDRAMよりはずっと安い。

実装としては以下：

• 32GBくらいのSSD
• 2GBくらいのメモリ（多ければ多いほどキャッシュに載りやすいので、平均の遅延を小さくできる）
• ボトルネックにならない程度のCPU
• ストレージエンジンがモジューラブルになっている新しいmemcachedで、Tokyo Cabinetを使う（memcachedのストレージ層をmodularにしてみた）
• Tokyo Cabinetをチューニングする
• とにかくランダムアクセスが速いファイルシステムを選ぶ（ext2?）
• カーネルのIOスケジューラをチューニングする
• memcachedはマルチスレッド化する（SSDはランダムアクセスもシーケンシャルアクセスも速度が同じなので、並列度を上げてもオーバーヘッドが無い。ユーザーランド→カーネルバッファの遅延を隠蔽できる）

mixiでは100bytes周辺の非常に小さいデータが多いらしいので、データのサイズが小さい場合は固定長データベースを使い、大きい場合はハッシュデータベースを使うようにするといいかもしれない。SSDを使えばボトルネックは容量ではなくなるだろうから、多少空間効率が悪くなっても問題ない。（キーが自然数でないといけないという制約がクリアできれば）

これでどのくらいの性能が出るだろう。アプリケーション側の変更は不要。

これでもボトルネックが容量にあるとすれば、サーバーは 12台 まで減らせる…それはムリだとしても、サーバーが減れば電気代も減るし、管理も楽になる。SSDの空き容量をルートファイルシステムに使えばHDDを無くせるから、故障率も下がってイケてるんじゃないか。