Key Value Store勉強会に行ってきました by kumofsのひと
※分散Key-Valueストア「kumofs」を公開しました！
先日開催されたKey Value Store勉強会に行ってきました。私の発表資料は↓ここからダウンロードできます。
合わせて読むと理解が深まるかもしれない：
- スマートな分散で快適キャッシュライフ - mixi Engineer's Blog：Consistent Hashについて
- バイナリシリアライズ形式「MessagePack」：kumofsのプロトコル。高速なストリームバッファとストリームデシリアライザの実装も含まれています。
- Protocol Buffersは遅い：MessagePackのベンチマークとProtocol Buffersとの比較。タイトルは釣り。
- memstored：IOアーキテクチャのプロトタイピング
- マルチコア時代の高並列性IOアーキテクチャ Wavy
- memcached binary protocol：Gatewayの実装で困っているところ
- P2P分散ストレージ「Cagra」
再掲困った：
- 再配置するときに大規模なトラフィックが発生してしまう
- 2台で冗長化したManagerがネットワーク障害などで分断されると、両方がマスターだと思い込んで不整合が発生してしまう。何か解決策や良さそうな運用方法は無いか？
- Gatewayでmemcachedプロトコルを中継しているためクライアントが重い。何とかして軽くできないか？
- バックエンドのTokyo Cabinetがキャッシュに収まらなくなると性能が落ちる。SSDで何とかなる？圧縮すると良い？何か良い手立ては？
集中と分散の歴史は繰り返すか
Key Value Store勉強会で印象的だったのが、平林さんの「ハードウェアの性能が良くなってサーバー1台でも大量のリクエストを捌けるから分散しなくても大丈夫」という（ように私が理解した趣旨の）一言でした。
kumofsが指向しているような「小さいデータを大量に保存するkey-valueストレージ」はサーバーにかかるネットワーク・CPU負荷はかなり低いため、1台でも6万QPS以上の性能を発揮することができます。（私の持っているハードウェアの場合）
私の発表資料の中にあるスループット性能はサーバー1台をクライアント4台×32スレッドでタコ殴りにして測ったものなのですが、それでもサーバーのCPUを使い切れていません。
key-valueストレージで目立ったボトルネックになるのはHDDのシーク速度ですが、それもSSDの登場によってケタ違いに性能が向上しようとしつつある + メモリ格安時代でオンメモリで大量にキャッシュできるために、従来なら数十台のサーバーを用意して分散しなければ得られなかった性能が1台で実現できてしまうかもしれません。
そして分散は要らなくなった 〜 デュアルマスタ or master-slave+障害時昇格 でレプリケーションする感じで。単純で速いし、実装楽だし、運用楽だし、性能十分だし、それが現状の回答だよねってなりそう。frsyuki@twitter
master-slaveでは書き込み性能が足りないケースもあるでしょうが、かなり希ではないでしょうか。（ただその希なケースではkumofsのように動的にサーバーを足してスケールアウトするのは便利）
「今」key-valueストレージが必要であれば、おそらくTokyo TyrantやFlareが正解でしょう。
しかしネットワークの歴史は集中と分散の繰り返しと言われます。memcached+オンメモリによる分散システムから、何か+SSDによる集中システムに移行し、その次に訪れるハードウェアの革新*1によってまた分散システムが台頭するかも知れません。
kumofsの立ち位置としては…マスター･スレーブ並に運用が簡単ならP2Pでもいいよね ;-)
