2011/03/02 増田謙一
                     Mongo Tokyo のレポート


概要:
 Mongo Tokyo とは、NoSQL のなかでも昨今注目を浴びている MongoDB に関するカンフ
       1)
ァレンスである 。 カンファレンスでは、10gen の開発者である Roger Bodamer の講演や、
㈱芸者東京エンターテインメントや㈱サイバーエージェント等で導入された事例が紹介さ
れ、MongoDB の仕組みとケーススタディを伺うことができた。このレポートの目的は、その
情報を共有することにある。


MongoDB とは:
                                                 2)
 昨今 NoSQL が注目を浴びており、昨年行われた NoSQL afternoon in Japan での事例か
らも分かるように国内外含め多くの NoSQL が開発されてきている。そのなかでも、現在
MongoDB は月 12 万のダウンロードがなされ、非常に注目を浴びている NoSQL の一つで
ある。上述した NoSQL afternoon のときには、 9 万ダウンロードと説明されていたため、
                              月
ここ 3 ヶ月でもダウンロード数を着実に伸ばしてきており、非常に注目されていることが分
  2)
かる 。導入事例も 1000 プロダクトを超え、国内でも導入例が増えており、これからも更な
る伸びが期待される NoSQL と言えるだろう。


MongoDB の仕組み:
 MongoDB は極めて簡単なコマンドでデータの挿入、検索を行うことができる。ここでは
NoSQL afternoon で発表された資料も交えて説明していく。 1 図はブログの記事を、
                                   第            タグ
をつけてそのまま挿入するコマンドである。




                            3)
 第 1 図:MongoDB におけるデータの挿入




                             1
MongoDB は BSON と呼ばれる JSON をバイナリ化した形式でデータを扱っているが、
表面的には JSON と変わらない形で操作することができ、上記の例でも JSON とほぼ同じ
形で「p」に代入されているのが分かる。次に検索を見てみよう。




                        3)
 第 2 図:MongoDB における検索


 第 2 図では、タグが存在する記事、著者名が k から始まる記事、著者名が roger の記事、を
検索する例が描かれている。MongoDB のみならず NoSQL の利点としてスキーマフリーと
いう点が挙げられ、そのために正規表現や自由な記述によってデータを検索しやすくなっ
ている。したがって、多くのデータをできるだけ取り込み、必要に応じて、必要なデータを検
索するのに極めて向いた仕組みとも言えるだろう。逆を言えば、そういった側面を強調して
いるため、合計値を取るなど複数のデータを合わせて何かを行うということがしにくいと
いう側面もある。


MongoDB の位置づけ:
 このようにスキーマフリーでデータを自由に扱える MongoDB であるが、Roger は KVS
とも RDBMS とも異なった位置づけを行っている。(資料があがってないので、ここはあと
で…)




MongoDB ケーススタディ:
 今回の MongoDB Conference では、㈱芸者東京エンターテインメント、㈱サイバーエージ
ェント、 Preferred Infrastructure、
    ㈱                         関心空間の事例が紹介された。そのなかでも、㈱芸者東
京エンターテインメント、㈱サイバーエージェントに注目して、紹介する。


                             2
㈱芸者東京エンターテインメントに関しては、@doryokujin さんが発表を行った。実例と
しては、「おみせやさん」というソーシャルアプリでログ解析のバックエンドとし て
MongoDB を使っているというものであった。




                                   4)
 第 3 図:おみせやさんのバックエンド側のアーキテクチャ


「中心的なデータサーバ(As a Central Data Server)」と書かれているように、あらゆる
ログが MongoDB に流し込まれる。データ量は、圧縮した状態でアクセスログ一日 15GB、行
動ログ一日 5GB となっている。そして、MongoDB に入ったこのログを更に MongoDB 側で
グループ集計を行い、フロントへと提供を行う。




                          4)
 第 4 図:おみせやさんのフロント側の UI


                               3
このようにおみせやさんでは、過去一日分のデータを MongoDB 上で様々な操作を行い、
整形した上でフロントに提供することを行っている。MongoDB は自身でも map や reduce
ができ、hadoop 含め分散環境にも対応しているので、過去のログを集計する例として行っ
たのがこのおみせやさんの例と言えるだろう。


 次にみるのは、@snamura さんが発表されたアメーバピコでの MongoDB の導入事例で
ある。MongoDB 自体は半年ほど前からピコで導入されているようだが、今回の発表ではピ
コの環境下で行われるできごとをリアルタイムでフロント側に返す際のケーススタディに
ついて紹介がなされた。ただ開発中かつ管理用のツールであるため、ユーザにも渡すような
データの扱いはしていないことは留意すべきだろう。




                                 5)
 第 5 図:アメーバピコの解析システムのためのサーバ構成


 この図から分かるようにサーバサイドに node.js を用い非同期通信で処理をさせ、そのデ
ータを MongoDB に流しこむということを行っている。そして、現在開発されている管理側
のフロントが以下のようになっている。




                         4
5)
 第 6 図:ピグ?のフロント側レポートシステム


 この図の中心部にあるリアルタイム販売データは現在ピコで販売されたデータが、即時
に反映されてすぐ更新されるような仕組みとなっている。MongoDB の利点として、スキー
マがないため、たとえアイテムの項目に何か追加があったとしても、カラム定義などは一切
無く、単にデータを投入すればよいだけであり、その点で変更の多いソーシャルアプリには
極めて向いた DB でもあったと言える。特に node.js のような Javascript や JSON を扱いや
すいシステムとは極めて相性がよいと仰っていて、フロントで起きた出来事をすぐ DB に反
映させてレスポンスを返すシステムとしては、MongoDB は一つの選択肢としてありえるよ
うに感じた。


考察:
 MongoDB の実例やコマンドのレファレンスなどはここ数ヶ月のあいだだけでも増えて
きたものの、実際の負荷やさばける量に対する考察が少なく、クライアントで INSERT を発
行しただけで成功を送ってしまい、サーバ側の結果を見ていない部分があるなど、実際に導
入するとなるとロストしてはいけないデータにどこまで使えるかは甚だ疑問である。また
エラーを検知できる関数があるようだが、その際にパフォーマンスが落ちるとのことで、そ
の点もどの程度が確認していかなければならない。


                             5
また、第 7 図を見ていただきたい。




                                      3)
 第 7 図:MongoDB におけるレプリケーションとレプリカセット


 この図はレプリケーション&レプリカセットという MongoDB が推奨する最低限のシス
テム構成である。ここから分かるように、マスター・スレーブ・コールドスタンバイによる
3 台構成で一つのレプリカセットが作られ、このレプリカセットが複数個作られることで、
スケールアウトが図られる。特に BSON 形式は常にキーや括弧を多く含むため、データ量の
増大はかなりあると言われており、大量のデータをスケールアウト環境で挿入しようとし
た場合に非常に多くの台数が必要になるのは目に見えている。したがって、 全てを
MongoDB にするのではなく、ログや分散が必要な部分と、提供する部分などに役割を分け
て運用しない限り、現実的なサービス提供は厳しいように思う。
 しかしながら、node.js との相性含め、内部運用ツールとして実験的に行うなど、営業側に
示す一つの方法としてはピコの例を見ていてもありえるように思えた。あとは出来る限り、
多くのデータを投入し、レプリカセット・レプリケーションをはって、検証していくことが
求められる。




 ※社外向けに一部改変しました。




                        6
参考資料:
1) Mongo Tokyo: MongoDB conference in Tokyo, Japan.
http://www.10gen.com/conferences/mongotokyo2011. (accessed 2011-03-02)
2) 「 NOSQL afternoon in Japan 」 開 催 の お 知 ら せ : NOSQL の 開 発 者 が 集 ま り ま す
   http://atnd.org/events/8460. (accessed 2011-03-02)
3) Bodamer,Roger. Mongo db japan.
http://www.slideshare.net/rogerbodamer/mongo-db-japan. (accessed 2011-03-02)
4) Takahiro, Inoue. Social Data and Log Analysis Using MongoDB.
http://www.slideshare.net/doryokujin/social-data-and-log-analysis-using-mongodb. (accessed
   2011-03-02)
5) Suguru, Namura. MongoDB + node.js で作るソーシャルゲーム.
http://www.slideshare.net/snamura/mongodb-nodejs. (accessed 2011-03-02)




                                             7

20110301 Mongo Tokyo

  • 1.
    2011/03/02 増田謙一 Mongo Tokyo のレポート 概要: Mongo Tokyo とは、NoSQL のなかでも昨今注目を浴びている MongoDB に関するカンフ 1) ァレンスである 。 カンファレンスでは、10gen の開発者である Roger Bodamer の講演や、 ㈱芸者東京エンターテインメントや㈱サイバーエージェント等で導入された事例が紹介さ れ、MongoDB の仕組みとケーススタディを伺うことができた。このレポートの目的は、その 情報を共有することにある。 MongoDB とは: 2) 昨今 NoSQL が注目を浴びており、昨年行われた NoSQL afternoon in Japan での事例か らも分かるように国内外含め多くの NoSQL が開発されてきている。そのなかでも、現在 MongoDB は月 12 万のダウンロードがなされ、非常に注目を浴びている NoSQL の一つで ある。上述した NoSQL afternoon のときには、 9 万ダウンロードと説明されていたため、 月 ここ 3 ヶ月でもダウンロード数を着実に伸ばしてきており、非常に注目されていることが分 2) かる 。導入事例も 1000 プロダクトを超え、国内でも導入例が増えており、これからも更な る伸びが期待される NoSQL と言えるだろう。 MongoDB の仕組み: MongoDB は極めて簡単なコマンドでデータの挿入、検索を行うことができる。ここでは NoSQL afternoon で発表された資料も交えて説明していく。 1 図はブログの記事を、 第 タグ をつけてそのまま挿入するコマンドである。 3) 第 1 図:MongoDB におけるデータの挿入 1
  • 2.
    MongoDB は BSONと呼ばれる JSON をバイナリ化した形式でデータを扱っているが、 表面的には JSON と変わらない形で操作することができ、上記の例でも JSON とほぼ同じ 形で「p」に代入されているのが分かる。次に検索を見てみよう。 3) 第 2 図:MongoDB における検索 第 2 図では、タグが存在する記事、著者名が k から始まる記事、著者名が roger の記事、を 検索する例が描かれている。MongoDB のみならず NoSQL の利点としてスキーマフリーと いう点が挙げられ、そのために正規表現や自由な記述によってデータを検索しやすくなっ ている。したがって、多くのデータをできるだけ取り込み、必要に応じて、必要なデータを検 索するのに極めて向いた仕組みとも言えるだろう。逆を言えば、そういった側面を強調して いるため、合計値を取るなど複数のデータを合わせて何かを行うということがしにくいと いう側面もある。 MongoDB の位置づけ: このようにスキーマフリーでデータを自由に扱える MongoDB であるが、Roger は KVS とも RDBMS とも異なった位置づけを行っている。(資料があがってないので、ここはあと で…) MongoDB ケーススタディ: 今回の MongoDB Conference では、㈱芸者東京エンターテインメント、㈱サイバーエージ ェント、 Preferred Infrastructure、 ㈱ 関心空間の事例が紹介された。そのなかでも、㈱芸者東 京エンターテインメント、㈱サイバーエージェントに注目して、紹介する。 2
  • 3.
    ㈱芸者東京エンターテインメントに関しては、@doryokujin さんが発表を行った。実例と しては、「おみせやさん」というソーシャルアプリでログ解析のバックエンドとし て MongoDBを使っているというものであった。 4) 第 3 図:おみせやさんのバックエンド側のアーキテクチャ 「中心的なデータサーバ(As a Central Data Server)」と書かれているように、あらゆる ログが MongoDB に流し込まれる。データ量は、圧縮した状態でアクセスログ一日 15GB、行 動ログ一日 5GB となっている。そして、MongoDB に入ったこのログを更に MongoDB 側で グループ集計を行い、フロントへと提供を行う。 4) 第 4 図:おみせやさんのフロント側の UI 3
  • 4.
    このようにおみせやさんでは、過去一日分のデータを MongoDB 上で様々な操作を行い、 整形した上でフロントに提供することを行っている。MongoDBは自身でも map や reduce ができ、hadoop 含め分散環境にも対応しているので、過去のログを集計する例として行っ たのがこのおみせやさんの例と言えるだろう。 次にみるのは、@snamura さんが発表されたアメーバピコでの MongoDB の導入事例で ある。MongoDB 自体は半年ほど前からピコで導入されているようだが、今回の発表ではピ コの環境下で行われるできごとをリアルタイムでフロント側に返す際のケーススタディに ついて紹介がなされた。ただ開発中かつ管理用のツールであるため、ユーザにも渡すような データの扱いはしていないことは留意すべきだろう。 5) 第 5 図:アメーバピコの解析システムのためのサーバ構成 この図から分かるようにサーバサイドに node.js を用い非同期通信で処理をさせ、そのデ ータを MongoDB に流しこむということを行っている。そして、現在開発されている管理側 のフロントが以下のようになっている。 4
  • 5.
    5) 第 6図:ピグ?のフロント側レポートシステム この図の中心部にあるリアルタイム販売データは現在ピコで販売されたデータが、即時 に反映されてすぐ更新されるような仕組みとなっている。MongoDB の利点として、スキー マがないため、たとえアイテムの項目に何か追加があったとしても、カラム定義などは一切 無く、単にデータを投入すればよいだけであり、その点で変更の多いソーシャルアプリには 極めて向いた DB でもあったと言える。特に node.js のような Javascript や JSON を扱いや すいシステムとは極めて相性がよいと仰っていて、フロントで起きた出来事をすぐ DB に反 映させてレスポンスを返すシステムとしては、MongoDB は一つの選択肢としてありえるよ うに感じた。 考察: MongoDB の実例やコマンドのレファレンスなどはここ数ヶ月のあいだだけでも増えて きたものの、実際の負荷やさばける量に対する考察が少なく、クライアントで INSERT を発 行しただけで成功を送ってしまい、サーバ側の結果を見ていない部分があるなど、実際に導 入するとなるとロストしてはいけないデータにどこまで使えるかは甚だ疑問である。また エラーを検知できる関数があるようだが、その際にパフォーマンスが落ちるとのことで、そ の点もどの程度が確認していかなければならない。 5
  • 6.
    また、第 7 図を見ていただきたい。 3) 第 7 図:MongoDB におけるレプリケーションとレプリカセット この図はレプリケーション&レプリカセットという MongoDB が推奨する最低限のシス テム構成である。ここから分かるように、マスター・スレーブ・コールドスタンバイによる 3 台構成で一つのレプリカセットが作られ、このレプリカセットが複数個作られることで、 スケールアウトが図られる。特に BSON 形式は常にキーや括弧を多く含むため、データ量の 増大はかなりあると言われており、大量のデータをスケールアウト環境で挿入しようとし た場合に非常に多くの台数が必要になるのは目に見えている。したがって、 全てを MongoDB にするのではなく、ログや分散が必要な部分と、提供する部分などに役割を分け て運用しない限り、現実的なサービス提供は厳しいように思う。 しかしながら、node.js との相性含め、内部運用ツールとして実験的に行うなど、営業側に 示す一つの方法としてはピコの例を見ていてもありえるように思えた。あとは出来る限り、 多くのデータを投入し、レプリカセット・レプリケーションをはって、検証していくことが 求められる。 ※社外向けに一部改変しました。 6
  • 7.
    参考資料: 1) Mongo Tokyo:MongoDB conference in Tokyo, Japan. http://www.10gen.com/conferences/mongotokyo2011. (accessed 2011-03-02) 2) 「 NOSQL afternoon in Japan 」 開 催 の お 知 ら せ : NOSQL の 開 発 者 が 集 ま り ま す http://atnd.org/events/8460. (accessed 2011-03-02) 3) Bodamer,Roger. Mongo db japan. http://www.slideshare.net/rogerbodamer/mongo-db-japan. (accessed 2011-03-02) 4) Takahiro, Inoue. Social Data and Log Analysis Using MongoDB. http://www.slideshare.net/doryokujin/social-data-and-log-analysis-using-mongodb. (accessed 2011-03-02) 5) Suguru, Namura. MongoDB + node.js で作るソーシャルゲーム. http://www.slideshare.net/snamura/mongodb-nodejs. (accessed 2011-03-02) 7