Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン

Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。

しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。MySQLをバックエンドのストレージに利用し、なおかつmemcachedにホットなデータをキャッシュすることにより、データベースへの問い合わせを激減させることができるのである。

1:Nのレプリケーションでは、更新の負荷を分散することが出来ない。Webサイトの規模が大きくなると、更新の負荷も非常に高くなる。そこで次に用いられたのがShardingという技術である。Shardingとは、MySQLサーバーを複数用意し、アプリケーション側でデータを格納するべきサーバーを選択することである。

以上をまとめると、現在多くのWebサイトでは次のようなトポロジによって大規模なトラフィックを捌いている。

• レプリケーションによるスケールアウト
• memcachedによるデータベースへの問い合わせ抑制。
• Shardingによる更新の分散。

かくして、MySQL+memcachedという組み合わせは大規模Webサイトで用いられる典型的なデータストアとなったのである。

しかしながら、ユーザーが頻繁に更新を行うソーシャルメディア系のサイトでは、リアルタイムなコミュニケーションを行うため更新の負荷が非常に高く、このようなトポロジでは捌ききれないケースが増えて来る。さらに、Shardingを行うとアプリケーション側で作り込みも多くなるし、そもそも異なるサーバーに格納されたデータ同士をJOIN出来ないから、RDBMSを使わなくても良いという発想が生まれてくることになる。

そこで、そういったサイトの一部では非リレーショナルデータベースシステム（いわゆるNoSQL）への移行が行われるようになった。その辺のいきさつはPublickeyの「なぜTwitterやDiggはCassandraを採用したか？それはWrite性能が出ず、管理が複雑になるから。」などを参照して頂きたい。

技術的には上記3つの組み合わせでもトラフィックを捌くことは出来るのだが、運用コスト（特に人件費）がかさんでしまうというのがTwitterなどの主張だ。それぞれ異なる技術であるから運用が難しくなるという課題には納得できる。Twitterが選択したCassandraはそれ単体で上記3つの要件を満たすことが出来る。しかし、NoSQLへの移行は果たして正しい選択だったのだろうか？

いいや、彼らはもう一つの解決策を忘れている！そう、SPIDERストレージエンジンの存在を！！

SPIDER for MySQL
http://spiderformysql.com/

SPIDERストレージエンジンは、斯波健徳（しばけんとく）氏によって開発されているストレージエンジンであり、MySQLのパーティショニング機能を利用して、パーティションごとに異なるサーバーへデータを格納することが出来る。つまり、Shardingをデータベース（MySQL）側でやってくれるストレージエンジンであると言えよう。もちろんデータが格納されているサーバーが異なっていてもJOINが出来る！このような仕組みを実装出来るのは、MySQLのストレージエンジンという柔軟な構造があってのことであるが、斯波氏の開発センスには諸手を挙げて称賛したい。SPIDERの役割を模式的に表したのが次の図（上記のサイトより抜粋）である。

今回のエントリではSPIDERの使い方などについては割愛するが、SPIDERを用いた時の更新性能および参照性能には目を見張るものがあるので紹介したいと思う。以下はINSERTの性能を測定したもの（MySQL単体、SPIDERノード2台＋データノード2台、SPIDERノード4台＋データノード4台の比較）である。綺麗にスケールしているのがお分かり頂けるだろう。

次はSELECTの性能である。こちらも綺麗にスケールしている。

赤○で囲ってあるポイントは、ワーキングセットのサイズがメモリより大きくなる地点である。データサイズがメモリから溢れてしまうと性能が劣化するのはRDBMSの使命のようなものであるが、SPIDERを使ってデータを格納するノードを分ければ、各ノードでは別個のデータをキャッシュすることになり、メモリを効率的に利用出来るのである。あたかもまるで巨大なInnoDBバッファプールがあるような状態になるのである。

SPIDERを用いたときの性能の詳細については、斯波氏がスライドを公開しているので、そちらを参照して頂きたい。

Twitterの課題は、運用コストをかけずに参照と更新のスケールアウトをすることであった。特に既存の「レプリケーション＋Sharding＋memcached」が苦手とする更新性能の飛躍的な向上として、NoSQLを解決策として選択してしまったのである。しかし、そういったニーズはSPIDERストレージエンジンでも解決出来るのだ！

一般的に、memcachedやCassandraのようなKVS（Key Value Store）では次のような処理を解決することが出来ない。

• JOIN
• ソート（ORDER BY）
• 集計処理（GROUP BY）

KVSを用いた場合、これらの要求にはMapReduceで解決することが一般的であるが、RDBMSではSQL文ひとつ書けば済むような処理なので開発効率には圧倒的な差が出るだろう。このエントリは斯波氏の了承を得て書いたものであるが、そのやり取りの中での斯波氏の言葉が印象深いので抜粋させて頂く。

私は今のRDBの優れているところは、非常に柔軟で便利だというところだと思っています。Webサービスのように日に日に新しいサービスを追加していく開発形態では変化に耐えうる柔軟性は、競争力を高く保つ上で非常に重要な要素です。私は、shardingが必要な環境でも、そのRDBの柔軟で便利だという特徴を損なうことなく教授することを可能にするために、Spiderを開発しています。

尤もな話である。もしあなたがTwitterと同様の課題を抱えていたら、安易にNoSQLへ走らずに、まずはSPIDERストレージエンジンを検討されてみてはいかがだろうか。SPIDERの使い方については、また別のエントリで紹介する予定である。