データストアの新たなカタチとしてNoSQLがブームになっていますが，その中で異彩を放っているのがドキュメント指向データベースである「MongoDB」です。サイバーエージェントでは，このMongoDBを比較的早い段階から実サービスで活用しています。そこで今回はMongoDBの使いどころや利用時の注意点について，サイバーエージェントの3人の技術者にお話を伺いました。

分散処理のしくみを最初から備えるMongoDB

リレーショナルデータベース（以下RDB）ほど煩雑ではなく，分散KVS（Key-Value Store）ほどシンプル過ぎない第三のデータストアの1つとして，ドキュメント指向型データベースである「MongoDB」が挙げられます。GNU AGPLv3を採用したオープンソースソフトウェアであり，パフォーマンスが高くスケーラビリティにも優れているという特徴があります。また，JSON（JavaScript Object Notation）をベースとしたスキーマレスなデータモデルであることも魅力の1つでしょう。

このMongoDBの魅力にいち早く気付き，実際のサービスで活用しているのがサイバーエージェントです。MongoDBを使い始めた理由について，同社の名村卓氏は分散処理機構であるシャーディング（sharding）のメリットを挙げます。

「実際にMongoDBを使ったのは，アメーバピグのアメリカ版であるAmeba Picoでデータストアとして利用したのが最初になります。日本のアメーバピグはもともと自社開発の分散DBを使って運用していましたが，それをメンテナンスするのも大変だということでMySQLに切り替えました。さらにハードウェアとして高速なSSD（Solid State Drive）であるFusion-io社のioDriveを利用することで，パフォーマンス面での問題を解決しています。ただ，Ameba PicoはAmazon EC2を使ってサービスを提供しているので，特別なハードウェアを入れることができません。そこで負荷を水平分散できるデータストアを探していたところ見つけたのが，そのしくみを最初から備えているMongoDBでした」（⁠名村氏）

もちろん，RDBの世界においても複数台のマシンに処理を分散させるしくみへの取り組みは行われていますが，そもそもRDBは原理的に分散化が容易ではありません。たとえば，オープンソースのRDBとして広く使われているMySQLにおいても分散化のためのプロダクトがいくつかありますが，「⁠現状では，MySQLにおいて“⁠これ⁠”という決定打となる選択肢はない」（⁠名村氏）のが実情です。

スキーマレスで柔軟な運用が可能

別の観点からMongoDBの導入に踏み切ったというのは，モバイルゲームの開発に携わる山田元基氏です。もともとMySQLを検討していたとのことですが，新しい機能などを加えた際にRDBに対してカラムの追加が発生したり，あるいはインデックスを張り直す必要が生じた場合にも，Amebaで月に1度か2度実施される定期メンテナンスまで待たないと作業や新機能のリリースができないという課題があったとのこと。

「そこでメンテナンスフリーで柔軟に運用できるKVSをいくつか検討しました。ただ，RDBのような処理を行うにはアプリケーション側で実装しなければならないことがネックでした。そこでRDBとKVSの中間的な存在はないかと検討したところ，MongoDBがベストではないかという話になりました」（⁠山田氏）

用途の向き／不向き

一方でサイバーエージェントにおいて，MongoDBの導入を見合わせたケースもあったようです。Amebaのトップページである「マイページ」を改修する際に，MongoDBの導入を検討しつつ最終的には見送った経緯について，津田智光氏は次のように話します。

「マイページを改修する際，各サービスのさまざまなデータを集約して表示したいという話が出てきました。Amebaにはさまざまなサービスがあり，集約すべきデータの型も数多くあります。また，集約するデータの容量も莫大です。こうした用途にマッチしたデータストアとして，スキーマレスでありデータの分散も可能，さらに聞いた話ではパフォーマンスも悪くなさそうだったので，MongoDBを検討することになりました」（⁠津田氏）

こうして検証した結果，最終的に採用を見送ることになった理由はパフォーマンス不足だったと言います。

「マイページはデータの更新頻度が非常に高く，MongoDBではパフォーマンスを担保しきれないと判断しました。ただ，そもそも要求する水準が極めて高かったので，しかたのない部分があるのかなとも思います。実際，MongoDBの代わりに導入したKVSのKyoto Tycoonに，SSDであるioDriveを組み合わせてやっと対応できるかどうかというレベルなので」（⁠津田氏）

こうした経緯も踏まえ，MongoDBに向く用途として名村氏は「ソーシャルゲーム」を挙げます。その理由としては，一部のドキュメントのその一部だけを更新するといったことを簡単に実装できて，データを更新するためのロジックを作り込む必要がないことなどが挙げられました。

逆にMongoDBが向かない用途として津田氏が挙げたのは，完全なACID（※）を必要とする用途です。

「MongoDBではトランザクションの機能を持っていません。完全なACIDを保証していない（一部のAtomic処理は対応している）ため，たとえば課金系情報を保存するなどの用途には向いていません」（⁠津田氏）

このようにお話を伺っていくと，やはりMongoDBにおいても向き不向きがあり，用途に合わせてRDB，あるいは分散KVSと使い分けることが重要であることがわかります。

※）

トランザクション処理を行うために必要とされる機能をまとめた略称で，それぞれAtomicity（原子性⁠）⁠，Consistency（一貫性⁠）⁠， Isolation（分離性⁠）⁠，Durability（持続性）を表します。