DBMS導入事例：MySQLmixiの生みの親“バタラ氏”が語るMySQLの意外な利用法

　そこでmixiは、サービス開始から半年ほどで「データクラスタ」へ移行している。まず、もともとは日記／メッセージなどのサービス別に分かれていたテーブルを1つのデータベースに格納していたが、それをサービスごと水平に分割し、複数のDBサーバへ分散させた。ユーザーIDなどで垂直に分割すると、データベース全体に影響が及び、データ移行も複雑になるという判断からだった。

　分割運用のためのロジックはPerlスクリプト（アプリケーション）の中に記述し、「mod_perl」（Perlスクリプトを高速実行するApacheのモジュール）で実行。どのテーブルがどのDBサーバに格納されているかを示す「分割マップ」は小規模で静的なため、MySQLの設定ファイルの中に収めた。当時のMySQL（バージョン5.0以前）では、異なるDBサーバへ分散したテーブル同士をJOINできなくなるという問題もあったが、アプリケーション側で対応している。

水平・垂直でテーブル細分化

　しかしこの対応策も、トラフィック急増の下では半年と持たなかった（mixiはサービス開始から1年4カ月でユーザー数が100万人を突破している）。

　そこで2005年春ごろから第2段階の分割へと進む。それは、サービスごとで水平に分割されたテーブルを、さらに各種ID別で垂直に分割するというものだ。例えば、日記なら日記のテーブルを特定のユーザーIDグループで分割し、DBサーバへ格納したのだ。第1段階と第2段階を掛け合わせるとテーブルを細分化でき、かなりの負荷分散が可能となった。つまり、「日記クラスタ」「メッセージクラスタ」のように、サービス別のクラスタグループを設けたのだ。

　しかし問題は続く。分割マップが複雑で巨大なものとなり、各種IDも日ごとに増え続けるため、MySQLの設定ファイルでは管理できなくなったのだ。そこで用いたのが、「マネージャベースド」「アルゴリズムベースド」という2つのマッピング手法だ。

　マネージャベースドは、分割マップを格納する専用DBサーバを立て、DBアクセスの前にテーブルの所在を確かめるクエリを投げるというもの。余分なクエリが発生するが、「DBサーバを追加してテーブルを再分割しても、それに合わせた分割マップの変更が容易」という。一方のアルゴリズムベースドは、パラメータからテーブルの所在を自動計算するアルゴリズムをPerlで書き、アプリケーション内で処理するというもの。管理は難しいが、余分なクエリは発生しない。この2つの方法を組み合わせ、テーブルの細分割を実践したのだ。

　もちろん、これだけ細分化されたテーブル（DBサーバ）へ逐一コネクションを張っていては負荷が重くなる。その点は、キャッシュ技術をフルに活用した。メモリキャッシュを可能にするデーモンプログラム「memcached」をWebサーバへインストールし、各Webサーバの空きメモリを“キャッシュサーバ”として、DBアクセスを極力減らしたのだ。Webサーバだけで数百台はあるのだから、キャッシュ容量も相当なものになる。

　さらに、画像系は画像系で別の負荷分散の仕組み（イメージクラスタ）が考えられた。MySQLで画像データのメタデータを管理・分析することで、参照頻度に応じた配信サーバへの振り分けを行っているのだ。具体的には、コミュニティーロゴなどの参照頻度が高い画像は、OSSのプロキシサーバ「Squid」を使った自社のキャッシュサーバや外部事業者のコンテンツ配信サーバから。古い日記の写真など参照頻度が低い画像は、コストを抑えるため、比較的低速なストレージ（ファイルサーバ）から配信するという2段構えだ。バタラ氏は「（2007年7月より全ユーザーに向けて始まった）動画共有サービス「mixi動画」にも、実績のあるイメージクラスタの仕組みが応用できます」と話す。

MySQLの代替も検討課題に

　3年半でユーザー数が1000万人を超えたmixiのサービスは、このような超負荷分散の仕組みの上で成り立っている。スケールアウトシステムの見本のようなものだ。

　ただ、これはMySQL自体がスケールアウトしているわけではない。バタラ氏は次のように指摘する。「“JOIN”などもアプリケーション側で行っており、パーティションやクラスタの選択、フェイルオーバーの機能もアプリケーション側に持たせています。実は、MySQLのリレーショナル機能を使っていません。RDBMSといっても実態は、ほとんどDBMSとして使っています」

　こうしたシステムアーキテクチャのため、「使っていない機能のオーバーヘッドはムダになるので、もっと軽量なDBMSでもよい」と代替ソリューションも研究している。例えば、オープンソースの「QDBM」が候補の1つだ。QDBMは、キーと値の組からなるレコードをファイルに保存し、検索する「ハッシュDB」を構築するためのライブラリ。データ構造がシンプルなため高速なDBが構築できる。実際、これまでmixiでは全文検索エンジンにgooを使ってきたが（MySQLの全文検索機能が日本語対応で実用水準に達していないため）、2007年7月からQDBMをベースとした「Hyper Estraier」へと切り替えた。Hyper Estraierは、辞書DBにない単語や口語調で書かれることが多い日記などの文字列も、高精度に検索できるという。

　余談になるが、QDBMを開発した平林 幹雄氏は現在、ミクシィのエンジニアである。同氏は、情報処理推進機構が実施した「2004年度 第2回『未踏ソフトウェア創造事業』」においてHyper Estraierを開発し、「スーパークリエータ」にも認定されている。スタッフ数十名ほどの開発部に平林氏のようなエキスパートが多数いることも、ミクシィの強みの源泉だろう。

　話を戻すと、mixiのシステムにおいて現状、MySQLは絶対不可欠なコンポーネントではない。それでもバタラ氏は次のように話す。「技術的には、今でもQDBMで高速なハッシュDBを開発し、適用することは可能ですが、MySQLレベルに信頼性を高めるには時間がかかります。オーバーヘッドが多少高くても、扱いやすさと信頼性のバランスを考えると、やはり今のところMySQLかなと思います」

　実際、これだけ多数のDBサーバを運用しながら、「MySQLの問題でサーバがダウンしたことは数えるほどしかない」という。トラフィックが急増する中でも、mixiの応答性能に対するユーザーの評判はおおむねよいが、その背景には、自社開発した負荷分散の仕組みとともにMySQLの安定性も貢献していると思われる。もちろん、MySQL ABのトップアーキテクトから定期的にコンサルティングを受けるなど、ミクシィが持つMySQLの運用ノウハウも並みではないだろう。

ミクシィの挑戦はまだまだ続く

　mixiのユーザー数増加に合わせて伸びる広告収入により、ミクシィは事業全体を急成長させている。直近の2008年度第1四半期は売上高が前年同月比で2.4倍の21.5億円、営業利益は2倍の9.1億円である。

　mixiでは、性別、年齢、居住区でユーザー属性に応じたターゲティングを行うことが可能な「ブランディングバナー」、化粧品サイトやIT情報サイトなどとの協業による「ビヘイビア広告」を始めており、マーケティング媒体としての可能性にも挑戦している。「mixiはメタデータ付きのデータを大量に蓄積しています。一般のサーチエンジンで検索できるのは単なる文字列でしかありませんが、mixiの場合、どのような人が何に書いたものかも分かります。これは、サービス面でもビジネス面でも、いろいろな可能性を秘めていると考えています」とバタラ氏。

　これまでmixiのシステムは、多様なサービスを実現し、効率よくデータを更新／参照することに重きを置いてきたが、今後は蓄積したデータをどう活用するかも、重要テーマとなってきそうだ。