MongoDB Tokyo 2013で語られた、NoSQLを上手に使うためのポイントとは

オープンソースのNoSQLデータベースであるMongoDBのイベント「MongoDB Tokyo 2013」が12月12日、秋葉原にある富士ソフトアキバプラザにて開催された。

10月には1億5000万ドルもの資金調達を受け、NRIによるサポートサービスが12月から開始されるなど、活発な活動を続けるMongoDB。来日したスタッフによるセッションや、国内企業で使用しているヘビーユーザーからの利用事例の紹介など、充実した内容で行われた。

会場の様子（クリックで拡大）

Ian Daniel氏によるキーノート

MongoDB社のテクニカルサポートマネージャーであるIan Daniel氏によるキーノートでは、はじめに日本での活動として、ユーザーコミュニティの「MongoDB JP」に750人以上が登録していることや、「丸の内MongoDB勉強会」で約50名のエンジニアが日々研究していること、2014年にはオープンソースカンファレンス（OSC）への参加を予定していると話した。また、ワールドワイドではダウンロード数が500万を超えており、MongoDB Universityというオンライントレーニングには10万人強が登録、ユーザーコミュニティには2万人以上が参加していることも紹介された。

MongoDB社のIan Daniel氏（クリックで拡大）

NoSQLデータベースとMongoDBの動き

これまで、40年間にわたって使われているリレーショナル・データベースは過去50年間で最も成功したソフトウェアテクノロジーとDaniel氏は語る。これまで長きにわたってRDBは発展してきたが、ここ5年くらいでそれに対抗できるようなものが出てきた。

こうしたデータベースの歴史や、携帯電話など進化の著しい機器を紹介しながら、いつまでも古いツールを使い続けているのではなく、時代に合わせた新しいツールを使うことが重要だとDaniel氏は述べ、MongoDBの可能性をアピールした。

また、MongoDBの成功事例を2つ紹介。スケジューラのような機能を持つメールアプリの「Mailbox」では、プロトタイプの開発時より、MongoDBをデータストアとして利用している。このアプリはリード&ライトの負荷が高く、ダウンタイムも許されないものだが、MongoDBを使うことでスムーズな動作を実現している。
有名な大手保険会社のMetLifeでは、社内システムでMongoDBを使用している。RDBでデータを一元管理しようと苦労していたが、MongoDBを使うことで柔軟なデータモデルを構築することができたため、90日という短期間でプロトタイプを完成させることができ、本番環境に移行したという。

MetLifeの事例について語るDaniel氏（クリックで拡大）

Webサイト上でも、かなりの数のコンテンツが日本語に翻訳されている他、前述したMongoDB UNIVERSITYでは、「M101P」というPython向けのトレーニングコースを全て日本語で受けることができる。Daniel氏は積極的にコミュニティに参加したり、質問してほしいと話した。

会場には米国のスタッフも数多く参加しており、会場内で参加者の質問に答えるなど対応していた。

Yutaro Mori氏によるMongoDBの概要とアプリ作成のポイント

アメリカで生まれ育ち、ミシガン大学でコンピュータ・サイエンスを専攻したYutaro Mori氏は前職でMongoDBに触れ、その使いやすさとパフォーマンスに魅力を感じて同社に入社したという。普段はMongoDB社のNYオフィスで働いている。日本で過ごした期間は短いと言いながらも、丁寧な日本語でMongoDBとはどんなデータベースなのかということからセッションをスタートさせた。

MongoDB社のYutaro Mori氏（クリックで拡大）

MongoDBを使ったデータは、ほとんどの場合ドキュメントとして作成する。JSONによく似たデータ構造で　ディスクに保存される前に二元復号化され、BSON（バイナリ型JSONの略）と呼ばれる。
エンジニアが好むプログラミング言語でのデータ構造に変換することが可能で、Java Scriptの場合はBSONを複合化するのみ、PHPのArray、PythonのDict、RubyのHashに変換できる。

次に、MongoDBの基本機能である、レプリケーションとシャーディングを紹介。レプリケーションは、冗長性を得るために多くのプロダクション環境で導入されている。マスターノードがスレーブノードと同期しているため、マスターノードにダメージが起きてもデータロスを防ぎ、サービス停止時間を最小限にすることができる。その上、レプリケーションを使用することで読み取りの負荷をノード間で分散させることができる。負荷のほとんどが読み取りで占められるアプリケーションの場合、その負荷をスレーブに分担させることでシステムのスケールが可能になる。
シャーディングは、MongoDBを水平スケーリングさせる。データを複数のサーバーに分散させることで、CPUはI/Oの負荷を分散させることができる。性能に直結するため十分なサイズのメモリが必要だが、メモリやディスクモジュールが大きいほど価格の上昇幅が大きくなるため、高コスト、高機能なサーバー1台より、複数のサーバーにデータを分散させる方がコストパフォーマンス向上につながる。

RDB的な使い勝手を持ちつつ、高速パフォーマンスを実現する

ここ数年CPUとメモリの値段が下がっている一方、データとWebのアクセス量が増加している。処理能力が高く、大量のデータを扱うには、RDBでは性能に限界があり、NoSQLを使うことでシステムを補おうという考えがある。

中でも代表的なmemchachedは、KeyとValueのハッシュ形式でデータを持ち、基本的なKeyでの検索に限られた高速なデータストアだが、MongoDBではこういった高速パフォーマンスを保持しつつ、RDBのような機能をバランス良く組み込むデータベースを目指している。
そのため、JoinのようにRDBには存在するがMongoDBが採用を見送った機能もある。この機能は場合によってコスト高やパフォーマンス劣化を招く原因と判断されたが、embeddedを使うなどして、RDBと同じように扱うことができる。

MongoDBでは、RDBのように検索クエリでCRUD操作が可能となっている。一般的なNoSQLのデータベースでは、SQLでいうGROUP BYやSumなどの集計機能がないが、MongoDBでは、NoSQLのパフォーマンスを維持しつつ、こういったSQLが持つような機能を開発している。集計フレームワーク（Aggregation Framework）はその1つで、クエリと同様にGROUP BYやSumが使用できる。

MongoDBの特徴的な機能を紹介（クリックで拡大）

一貫性を保ち、レプリケーションやシャーディングを使用していても、いつでも正確なデータを返すことができる他、ドキュメント指向データベースのため、スキーマを定義しなくても良いといったMongoDBの特長をひと通り説明。後半ではMongoDBを使ったアプリ開発のポイントをスライドで紹介した。

アメーバのWebサービスを支えるMongoDB

株式会社サイバーエージェントの桑野章弘氏によるセッションでは、「CyberAgentにおけるMongoDB」と題して、PC向けのサービス「ピグライフ」と、11月にリリースされたスマートフォン向けアプリ「なぞってピグキッチン」をメインに、サービスの成長に合わせて発生した課題をどう解決してきたか、といったユーザーサイドからの視点で紹介された。

サイバーエージェントの桑野氏（左）とピグライフの画面（右）（クリックで拡大）

PC向けサービスはユーザー数100万～300万以上で、ピークタイムの同時接続数は10万以上にも上る。アプリケーション・サーバーはNode.JSとNginx、データストアサーバーにMongoDBを使用している。リリースされたばかりのスマートフォン向け「なぞってピグキッチン」はAWSで構築している。

ピグライフでは、リリース後3週間で100万ユーザーを突破する好調な状態で、サーバーもこれに合わせて当初より1シャード追加。特に負荷が高かったNode.JSのサーバーを一時的に大量追加するなどの対応を行った。その後、9月にはユーザー数が200万人を突破。ユーザー増加による負荷増に対応するため、最終的に23シャード、81台を追加。Staticサーバー、Node.JSサーバーは2系統ずつ用意し、リリースと構築を切り替えながら運用しているとのこと。

リリースから3ヶ月で、サーバーの規模は8倍、トラフィックは1.3Gbps、総コネクションは18万に増加したという。

リリース時（左）と現在の構成（右）（クリックで拡大）

サービスの成長速度を支えたMongoDB

ピグライフの構成図と、基本的なスキーマレス、冗長化、アベイラビリティ、およびレプリカセット、シャーディングを紹介。MongoDBを使うことでユーザー情報なども柔軟に持つことができ、機能追加時などが比較的楽になる。例えば、DBでカラムを追加・変更したい時に、DBを止めることなく、アプリケーション側の構成変更で行えることなどがあげられる。

レプリカセットは、相互死活監視と投票によって冗長性を保つことができる。最小単位はプライマリ1台とセカンダリ2台の計3台。プライマリが死んでしまった際にいずれかのセカンダリから投票でプライマリを決めて移行する。ユーザーはプライマリの死を意識することなく、サービスを継続できるメリットがある。
データを複数のサーバーに分散させ、負荷分散を行うシャーディングは、データをChunk（チャンク）という単位に分けて、どのサーバーがどのChunkを受け持つかを決めて分散させ、それぞれレプリカセットで冗長性を確保している。

これらの基本機能によって、アプリ側の実装コストが軽く、9台から100台への大幅な変更でもDB接続部分の変更点がほとんどないことから、スケーラビリティを保ったままシンプルなサービス構成を実現することができたと桑野氏は語る。

次に、MongoDBが得意とするユースケースとして、データ量が極端に大きすぎないことや、読み込みに対して書き込みが多すぎないこと、単位時間あたりの処理データが各シャードのメモリ量を超えない処理が得意であると延べ、ゲーム系Webアプリケーションや一時的なログ解析基盤を挙げた。
反対に、データ量が爆発的に増えるもの、常に全データへのアクセスを行うといった、ホットデータがないデータの使い方は苦手だとし、例としてソーシャル系Webアプリや継続的または統合的ログ解析基盤をあげた。

このように、NoSQLはできることとできないことがはっきりしており、NoSQLを使う場合はこのできる部分を伸ばす必要があると述べた。

MongoDBを運用する上で発生しやすい注意点も紹介された。1つは、必要なデータを一気にインポートした場合やOplogデータ量の範囲を超えてレプリケーションが停止してしまうクラスターのスローダウン。一部シャード設定のし忘れによって、たまったデータを処理しきれなくなって発生するパフォーマンスダウン、そして、データが肥大化することおよびその対策など。これらは一部オペレーションミスに近いものも含まれるが、実際にMongoDBを使っている立場からの貴重なアドバイスといえる。

他にも、ハードウェア選択のポイントやmongodumpを使ったバックアップ、MongoDB Management Servece（MMS）などを紹介。最後にまとめとして、MongoDBを使うことによって運用の安定、構成を変えずにスケーラビリティを確保できることや、JSONを直接扱えることで開発スピードを早くできる点が大きいと語った。ただし、NoSQL全般に言えることとして、ここで挙げたような注意点もあるため、まずはスモールスタートで使いながらノウハウをためてみては、と話しセッションを結んだ。

ここで紹介した他にも、シャーディングやセキュリティ、パフォーマンスチューニングなどに関する合計15のセッションが実施され、会場では熱心に話を聞く参加者の姿が見られた。クロージングセッションでは、数ヶ月以内に発表される予定の次期バージョン2.6やその先のアップデートについての展望が語られた。

平日を1日使って行われた今回のイベントに約200名の参加者が集まったことで、国内においてもその注目度が感じられるMongoDB。NoSQLの旗手として今後の発展を期待したい。

【関連リンク】

• MongoDB
• MongoDB.org
• MongoDB University

リンク先最終アクセス（2013.12）