DBMS導入事例：MySQL

mixiの生みの親“バタラ氏”が語るMySQLの意外な利用法

サービス開始から3年余りで会員数が1000万人を超えたSNSの「mixi」。そのシステムはOSSで構築されており、データベース管理システム（DBMS）には「MySQL」を使う。急増するトラフィックをさばくために負荷分散を重ねた結果、現在ではサーバ1000台以上が連なる超分散システムへ。その中でMySQLが果たす役割とは。

[石田己津人]

日記だけで4億件のデータ

　ミクシィが運営するSNS「mixi」は、2007年7月末段階でユーザー数が1110万人。人が12人集まれば、1人はmixiユーザーというわけだ。ユーザーのアクティブ率（ログイン間隔が3日以内）は約62％と高く、2007年4月から6月の月間平均ページビューは117.5億に達した。日記だけでも4億件以上に上るなど、蓄積するデータ量も莫大。2004年3月のサービス開始から、わずか3年半で現在の巨大コミュニティーへと発展したのだ。

　ミクシィは、「LAMP（OSのLinux、WebサーバのApache、DBMSのMySQL、開発言語のPerl、PHP、Python）」と呼ばれるWebシステム向けの標準的なオープンソースソフトウェア（以下、OSS）でシステムを自社開発し、安価なPCサーバを1000台以上連ねる超分散構成でmixiのサービスを支えている（広告配信など周辺機能では、パッケージ製品を採用している部分もある）。このmixiのケースは、MySQLを採用するWebシステムとして、間違いなく世界有数の規模といえる。

株式会社ミクシィ取締役最高技術責任者衛藤バタラ氏

　mixiの生みの親――事業企画をミクシィへ提案、当初は1人でシステムを構築していた――ともいえる取締役最高技術責任者の衛藤バタラ氏は、MySQL採用のいきさつを次のように振り返る。「当時は、SNSがビジネスとして成り立つかどうかも分からなかったので、コストが掛かる商用DBは頭にありませんでした。OSSとしてはPostgreSQLという選択肢もありましたが、MySQLは当時からレプリケーション機能が標準で付き、ユーザー事例などのドキュメントも豊富。サポート会社のMySQL ABも存在していたので安心でした」

　もちろん開発当初は、誰もが現在のような急展開を想定できるわけがなく、この3年半、急激に増え続けるトラフィックへどのように対応するのか、バタラ氏をはじめ開発スタッフの苦労は並々ならぬものがあった。特に、MySQLのスケールを高めるのに苦労したという。

標準機能では負荷分散できず

　mixiはサービスを開始してから2カ月後には、ユーザー数が1万人を突破した。早くもWebサーバとDBサーバが各1台という初期構成では負荷に耐えられなくなったが、Webサーバには「DNSラウンドロビン」（1つのホスト名に複数のIPアドレス＝Webサーバを割り当て）という負荷分散技術があり、サーバを増設してスケールアウトすることで、容易に対応できた。そして、MySQL標準のレプリケーション機能を使い複数のDBサーバをマスター－スレーブ構成（マスターからスレーブのデータを非同期更新）とすることで、マスターは更新専用、スレーブは参照専用として負荷分散も行った。

　普通のWebサイトであれば、トラフィックの大半は参照処理のため、たとえトラフィックが増加しても参照専用のスレーブの追加で十分にスケールアウトするだろう。しかしmixiの場合、サービスの特性上、更新処理の多さが際立った。トラフィックの増加に伴い、更新処理が集中するマスターが過負荷になったほか、マスターで発生した更新を各スレーブが複製する際のオーバーヘッドで、参照処理にまで影響が出始めたのだ。

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