読者です 読者をやめる 読者になる 読者になる

Key Value Store勉強会に行ってきました by kumofsのひと

分散Key-Valueストア「kumofs」を公開しました!


先日開催されたKey Value Store勉強会に行ってきました。私の発表資料は↓ここからダウンロードできます。


合わせて読むと理解が深まるかもしれない:


再掲困った:

  • 再配置するときに大規模なトラフィックが発生してしまう
  • 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 TyrantFlareが正解でしょう。
しかしネットワークの歴史は集中と分散の繰り返しと言われます。memcached+オンメモリによる分散システムから、何か+SSDによる集中システムに移行し、その次に訪れるハードウェアの革新*1によってまた分散システムが台頭するかも知れません。


kumofsの立ち位置としては…マスター・スレーブ並に運用が簡単ならP2Pでもいいよね ;-)

*1:個人的に予想しているのはEthernet+ソフトウェアTCP/IPに代わる超低遅延ネットワーク。CPUやSSDの性能向上が頭打ちになる一方で、通信のオーバーヘッドが極端に低下することによって分散システムの設計がマルチスレッドプログラミング並の常識になり、スケールアウトすることで処理性能が飛躍的に向上する。その結果分散ストレージに求められる性能が増大する、とか! キーワードは10GbE、TOE、PCI-Express External Cabling、RDMA、SDPなど。