2014年3月時点で、日本MongoDBユーザ会に集められたMongoDBの事例紹介をします

1. MongoDB usecases
がっつり
MongoDB事例紹介
渡部徹太郎
2014/03/19
第16回
丸の内MongoDB勉強会

2. アジェンダ
• 自己紹介
• MongoDBは人気
• MongoDBの事例
1. Webアプリ・オンラインゲーム
2. アジャイル開発
3. 大量データ分析
4. ログ収集
5. データハブ
6. データ統合
7. 拠点間データ連携
• MongoDB,Incについて

3. 自己紹介
{"ID" ："fetaro",
"名前" ："渡部 徹太郎",
"所属" ："MongoDB JP - MongoDB 日本ユーザ会",
"経歴" ："学生時代は情報検索の研究(@日本データベース学会)",
"仕事" ：{"昔":"証券会社のオントレシステムのWeb基盤",
"今":"オープンソース全般"},
"特技"：["サーバ基盤","Linux","KVM","ruby","MongoDB"],
"エディタ"："emacs派",
"趣味"："自宅サーバ",
"MongoDB関連"：{
－"３年前に、友人の結婚式用のアプリを作った時に利用",
－"技評記事「MongoDBでゆるふわDB体験」",
－"日経SYSTEMS 8月号 「ドキュメント指向データベース」"},
"属性" : ["ギーク","スーツ"],
}
3

4. MongoDBは人気

5. MongoDBは人気(1/4)
• db-engines.comでは上位にランキング
図の引用元：
http://db-engines.com/en/ranking
•指標の元データ
o ウェブサイトでのシステム名称の登
場回数(Google, Bing)
o 一般的な人気度(Google Trends)
o 技術的なディスカッションの頻度
(Stack Overflow,DBA Stack
Exchange)
o 求人サイトにおける募集スキル
(Indeed, Simply Hired)
o プロフィール登場回数(LinkedIn)
o インストール数は考慮されていない

6. MongoDBは人気(2/4)
• LinkedInにおける
o NoSQLではMongoDBの技術者が圧倒的に多い
o NoSQL技術の標準になりつつある
図の引用元：
http://blogs.the451group.com/information_management/2013/12/
18/nosql-linkedin-skills-index-december-2013/

7. MongoDBは人気(3/4)
• 採用企業 600社以上

8. MongoDBは人気(4/4)
• MongoDB,Incは絶好調
o MongoDBはオープンソースなので誰でも開発できるが、
現時点では実質MongoDB,Incが開発している。
o 2013年10月に150,000,000$(約150億円)の投資を受けた。
▪ 米MongoDB、1億5000万ドルの資金調達「Oracleに
追いつく成熟度を目指す」
• 引用元：http://internet.watch.impress.co.jp/docs/news/20131007_618340.html
• 何が言いたいかというと...
「MongoDBは大人気！」
MongoDB,Incもすごく期待されている！

9. MongoDBの事例

10. MongoDBの事例 一覧
分類 利用している
MongoDBの特徴
本日紹介する事例
1 Webアプリ・オンラ
インゲーム
•水平分散
•リッチなデータ
[国内][SNS] CyberAgent
[海外][Web] orange
[国内][Web]大手ニュースサイトR社
[国内][Web] ZenClerk
2 アジャイル開発 •スキーマレス
•多機能
•使いやすい
[国内][Web] 株式会社キッチハイク
[国内][SIer] システムインテグレータM社
3 大量データ分析 •スキーマレス
•使いやすい
[海外][セキュリティ] McAfee
[製品] Jaspersoft(レポーティング・BI)、Pentaho(BI)、qlik view(
商用BI)、talend(ETL)、Splunk(商用M2M)
4 ログ収集 •スキーマレス
•使いやすい
[国内][SIer]野村総合研究所
[製品]Fluentd
5 データハブ •スキーマレス
•使いやすい
[海外][保険] MetLife
[海外][金融]グローバル信託銀行 X社(事例１)
6 データ統合 •スキーマレス
•使いやすい
[国内][Sier] ペタデータ株式会社(事例１)
[国内][Sier] ペタデータ株式会社(事例２)
7 拠点間データ連携 •レプリケーション
•使いやすい
[海外][金融]グローバル信託銀行 X社(事例２)
従来の教科書通りの使い方
近年の新しい使い方

11. 1.Webアプリ・オンラインゲーム
• 利用される理由
o 複雑なデータモデルを扱う
o 利用ユーザの増加などによるトラフィックの増加が激しく、デ
ータの水平分散が求められることが多い
o 特にユーザログインがあるようなWebアプリケーション
水平分散 リッチなデー
タ
11

12. [国内][SNS] Cyber Agent
• アメーバピグにて利用
o 国内のMongoDB事例の先駆け
o slideshareの「MongoDBを半年間運用してみた」(2011/7)は有名
12
1.Webアプリ・オンラインゲーム
引用元：http://www.slideshare.net/matsukaz/mongo-db-8707809

13. 課題 選定理由・解決策 結果
•MySQLがスケーラビリテ
ィの上限に達して性能要件
を達成できなくなった
•RBMSでは非定型なメタデ
ータの管理が困難
•性能とスケーラビリティに
期待しMongoDBを導入
•60億におよぶ属性情報デー
タの代わりに、１コンテン
ツを１ドキュメントにする
構造を導入
•秒間11万件以上のクエリに
対応
•３年で200万ドル以上のコ
スト削減
•新規機能の導入のスピード
が著しく早くなった
•新規プロジェクトでは全て
MongoDBを利用する方針
となった
[海外][Web] orange
• 700万のウェブ・モバイルユーザに対する広範囲
コンテンツ・サービス提供
13
引用元：http://www.mongodb.com/customers/orange-digital
1.Webアプリ・オンラインゲーム

14. [国内][Web] 大手ニュースサイトR社
• 大手ニュースサイトにてポータルに利用
14
課題 選定理由・解決策 結果
•MySQLベースのストレー
ジシステムがEOSの為、シ
ステム再構築を行う必要が
あった
•ポータルサイトは書き込み
が少なく、読み出しが非常
に多い非対称なクエリバラ
ンスである事から
MongoDBを採用した。
•性能検証の結果、キャッシ
ュ層が必要無い程の性能が
確認できた。
• レプリケーションによるデ
ータ冗長性、安全性も優れ
ていた事からRDBMSから
完全に脱却した。
•システム全体としては、様
々な初期トラブル（CPU過
負荷など）に見舞われたが
ロジック過負荷になっても
MongoDBの超えることは
無かったため データ破壊な
ど致命的な状態には至らな
かった。
1.Webアプリ・オンラインゲーム

15. [国内][Web] ZenClerk
• MongoDBを活用した分析でサイト訪問者の購買意欲の高まりをい
ち早く察知し、 クーポンの"ベストタイミングオファー"を実現
15
課題 選定理由・解決策 結果
•格納データが、PCとスマ
ートフォンとブラウザごと
に取得できる情報が異なる
ため、
•一人一人のサイト訪問者に
対してマウスの動きやスマ
ートフォンのジェスチャー
といった詳細なデータを格
納しているため、それらを
合計すると膨大なデータ量
になってしまい、RDBMS
では安定した書き込みを行
うことができない。
•スキーマレスデータを扱え
る
•RDBMSと遜色がないほど
柔軟なクエリを組むことが
でき
•柔軟なイン デックスを用い
て高速な読み込みができた
。
•サーバーを増やす だけで容
易にスケールアウトするこ
とができた。
•サーバー1台だけで秒間
1,000アクセス以上の負荷
に耐えることができた。
•負荷に耐えられなくなった
時はサーバーの台数を増や
すだけで良いので、コス ト
が見積もり易い。
•副次的な効果として、
MongoDBをレプリケーシ
ョンすることで、1台はホ
ットス タンバイに、1台は
バッチ集計に、 残りの全台
をリアルタイム集計に用い
るといった柔軟な運用を行
うことがで き、高可用性を
維持することができた。
1.Webアプリ・オンラインゲーム

16. [国内][Web] ZenClerk
• システム構成図
16
1.Webアプリ・オンラインゲーム

17. 2.アジャイル開発
• 利用される理由
o スキーマの変更頻度が非常に高い
o 直観的にデータを表現できる
o ORマッパーを使う必要はなく、ライトウェイトなスクリプト言語
(javascript,ruby)との相性がよい。
o アプリ開発をサポートする機能が沢山ある
• その他
o ハッカソンなどでは常連のDB
スキーマレス 多機能 使いやすい
17

18. [国内][SIer] システムインテグレータM社
• Webシステム作成案件で可用性を求めてMongoDBを利用
18
課題 選定理由・解決策 結果
•新規に構築するWebサービ
スにおいてダウンタイムレ
スでレプリケーションによ
る 高可用性を実現したい。
•RDBMSではレプリケーシ
ョンを行うにはそれなりの
手間が必要
•新規案件であるためスピー
ド感のある開発が求められ
た
•MongoDBを採用し、レプ
リカセットの構成を実現
•スキーマレスの利点を生か
し作りながら考えることに
より、短期間で開発を完了
できた。
•レプリカセットによりシン
プルな構成でダウンタイム
レスの高可用性を実現でき
た。
2.アジャイル開発

19. 課題 選定理由・解決策 結果
•機能追加・仕様変更が多い
•新規Webサービスではデー
タサイズの見積りが難しい
。
•位置情報（経度・緯度）の
扱いに適したデータベース
を探していた。
•Ruby on Railsで利用できる
DBを利用したい
•スキーマを決めずに開発を
開始できる
•データ容量の拡張が簡単
•位置情報の扱いが得意
•日常的に起こる機能追加・
仕様変更に素早く対応でき
た。
•ユーザー数増加に伴うデー
タサイズの増加にも対応で
きるので、安心してサービ
ス成長に取り組める。
•地理空間インデックス機能
を使って、位置情報を使用
するクエリを簡単に実装で
きた。
[国内][Web] 株式会社キッチハイク
• スタートアップ企業にてRuby on Railsのバックグラウンドで採用
19
2.アジャイル開発

20. 3.大量のデータ分析
• 利用される理由
o 大量のデータを扱う
▪ 安価なハードウェアで大量データを扱える
o 柔軟にクエリー組み立てる必要あり
▪ 様々なキーに対して、複雑なインデックスを張ることができる
▪ 集計等のリッチなクエリーが既存機能だけで実現できる
o 動的にクエリが書けるため、新規分析軸の導入が用意
水平分散 柔軟なクエリ
20

21. 課題 選定理由・解決策 結果
•他技術ではスケーラビリテ
ィと機能がともに十分なも
のが無い
•Hbase/Hadoopでは複雑な
クエリに対応できない
•Luceneではスケーラビリテ
ィに問題があり
•MongoDBの自動シャーデ
ィングでスケーラビリティ
を実現
•動的に柔軟なクエリが書け
るため、新しい分析結果を
追加する場合の開発が簡単
•地理空間インデックスの利
用により、地理的な観点で
のデータ分析が容易に
•レイテンシーを1/3に削減
•動的スキーマの変更が可能
になり、開発者の生産性が
大幅に向上
•市場に対する新しいサービ
スの投入が迅速化
[海外][セキュリティ] McAfee
• セキュリティサービスのビッグデータ解析にMongoDBを
利用
21
(事例の出典 MongoDB,Inc http://www.mongodb.com/customers/mcafee)
3.大量データ分析

22. 4.ログ情報の蓄積
• 利用される理由
o 様々なログの形式を蓄積可能
o キャップ付きコレクションで、古いログを自動的に消せる
o とりあえずレプリケーションしておけば、データは冗長化できる
o MongoDBにとりあえずログをためておき、そのほかの集計ミドルウェ
アで集計するという使い方がよい
▪ 他の集計ミドルがよい理由は、
たとえば、時系列データを日付をキーにして水平分散させると、検
索頻度の高いレンジ（例えば今週、今月）のデータが格納されてい
るシャードに負荷が偏ってしまう
スキーマレス 多機能 レプリケーショ
ン
22

23. [国内][SIer] 大手SIer N社
• サーバのログ収集にfluentd + MongoDBを利用
23
4.ログ情報の蓄積
課題 選定理由・解決策 結果
•サーバが多く、障害時にロ
グ情報を収集する手間がか
かっていた
•fluentdであれば各サーバの
ログを自動的に収集できる
。flluentdはMongoDBがデ
フォルトであるため
MongoDBを利用
•障害対応の効率UP
•MongoDBは運用が簡単で
あるためログ運用負荷も高
くない

24. 5.データ統合
• 利用される理由
o 多数の分散された既存データソースのデータをMongoDBに集約
して、アプリケーションに対してビューとして提供する
o 既存のデータソースに手を加える必要はない
o アプリケーションに対しては高速なビューを提供可能
スキーマレス 使いやすい
24
MongoDB
データを集約
ユーザ
既存のデータソース
アプリケーショ
ン

25. 課題 選定理由・解決策 結果
•顧客データを個別に管理す
る70以上の既存RDBMSが
存在し、そのデータを統合
をしたいが、RDBMSでは
工数がかかりすぎた
•モバイルで利用したいとい
う要件があるが、端末の増
加に合わせてスケールアッ
プすることがRDBMSでは
難しかった
•既存のRDBMSの情報を統
合してアプリケーションを
開発。
•MongoDBの開発容易性か
ら、２週間でプロトタイプ
が作成でき、90日でリリー
スできた。
•１０年間できなかった顧客
データの統合が実現。それ
も既存の顧客データには手
を入れずに実現できた
•巨額な投資が必要な
RDBMS統合を、安価(約
$3M)に、迅速に、達成でき
た(過去同プロジェクトで
は約$25M)
•企業内外でNOSQLの標準
としてMongoDBを採用
[海外][保険] MetLife
• 70以上の既存RDBMSに拡散した顧客情報をMongoDBで
統合
25
(出典 MongoDB Inc http://www.mongodb.com/press/metlife-leapfrogs-insurance-industry-mongodb-powered-big-data-application)
5.データ統合

26. [海外][保険] MetLife
• システム構成
MongoDB
データを集約
ユーザ
既存の顧客データ(約70台)
アプリケーシ
ョン
5.データ統合

27. [国内][SIer] ペタデータ株式会社（事例１）
• 音楽専門放送業 大手「株式会社スペースシャワーネットワーク」
70以上の配信サイトの配信実績情報の統合サービス （Allegro IoT）
にMongoDBを活用
o 公式HP：http://petadata.jp/ja/OurWorks001.html
課題 選定理由・解決策 結果
•配信実績情報は事業者毎に
異なるフォーマットであり
、それを統一する必要があ
った。
•一部の事業者の配信実績情
報を手作業で整形していた
。
•フォーマットが変更される
こともあり、事前にスキー
マが決定できないため、
従来のRDBMSに格納が難
しかった。
•スキーマを決定する前に、
システムに取込む必要があ
ったため。
•容易にレプリケーションが
可能なため。
•手作業によるミスがなくな
り、事務作業が格段に減っ
た。利用企業より好評を得
ている
5.データ統合

28. [国内][SIer] ペタデータ株式会社（事例２）
• 製薬会社 中堅S社 異なる温度センサーのリアルタイム温度情報の統
合サービス （Allegro IoT）にMongoDBを活用
o 公式HP：http://petadata.jp/ja/OurWorks002.html
課題 選定理由・解決策 結果
•リアルタイム温度管理が必
要だった。
•温度センサーからの温度情
報のフォーマットが変更さ
れることがあり、その都 度
システムの修正が必要だっ
た。
•温度情報のフォーマットが
変更された場合、設定の変
更だけで対応する手段が な
かった。
•温度情報はXMLだったが、
XMLのツリー情報をそのま
ま取り込む必要があった。
•パフォーマンスを保ちつつ
、スキーマレスで温度情報
を取り込む必要があった た
め。
•ツリー情報をそのまま取り
込むことができるため。（
JSONを取り込めるため）
•容易にレプリケーションが
可能なため。
•温度情報のフォーマットの
変更があっても取得が可能
になった。 （取得後にフォ
ーマット変更があったか判
断すればよくなった。）
•リリース以来（2014年3月
で2年2か月）一度も停止す
ることなく運用しているた
め、システム運用の手間が
減った。
5.データ統合

29. 6.データハブ
• 利用される理由
o スキーマレスであるため、様々な形式のデータソース
のデータを格納できる
o ドライバが豊富であり、アプリも作りやすい
スキーマレス 使いやすい
アプリ１
アプリ２
アプリ３
データソース１
データソース２
データソース３
Mongo
DB
バッチコピー API
・・・
・・・

30. [海外][金融]グローバル信託銀行 X社（事例１）
• 企業内でのデータアクセスを統合するために、データハ
ブとして利用
課題 選定理由・解決策 結果
•データの複製がシステム間
で無数に存在する
•一つのシステムでの変更が
複数のグループに影響
•EDWのシステムレスポン
スタイムが遅い
•頻繁にアクセスするデータ
は集中的に管理したい，と
いうニーズ
•動的なスキーマ: 必要な時
だけデータを正規化する
•性能: 一つの論理DBで全て
のデータを管理・運用
•シャーディング: スケール
アウトによりデータを容易
に追加
•一カ所からバッチ，もしく
はRESTでデータアクセス
可能
•顧客向けポータルサイトの
レスポンスタイムが90%改
善
•開発期間の短縮データソー
スのエンハンスが容易
6.データハブ

31. [海外][金融]グローバル信託銀行 X社（事例１）
• 新旧のシステム構成比較
アプリX
アプリ１
アプリ２
アプリ３
データソース１
データソース２
データソース３
データソースN
バッチコピー
アプリX
アプリ１
アプリ２
アプリ３
データソース１
データソース２
データソース３
データソースN
Mongo
DB
バッチコピー API
・・・
・・・
・・・
・・・
6.データハブ

32. 7.拠点間連携
• 利用される理由
o 各拠をまたがりレプリカセットを組むことにより、
タ拠点で同じデータが見れる
o レプリケーションの耐久性が高く、多少遅延のある
通信経路でも構築可能
o レプリケーションの機能により、物理的に近い拠点
からデータを複製することが可能
o レプリケーションの構成が柔軟
▪ 書き込み一貫性が柔軟(w値,j値)
▪ 多様なセカンダリreadonly,hidden,delayed
レプリケーショ
ン
使いやすい

33. [海外][金融]グローバル信託銀行 X社（事例２）
• 各拠点で迅速にローカルアクセス出来る様に、参照デー
タをリアルタイムで分散／配布
課題 選定理由・解決策 結果
•バッチ処理によるデータ配
布の遅れが最大36時間に及
ぶ
•同じデータのグローバル配
信に複数課金されるSLA未
達成による規制違反（罰金
）
•同じを保有する20カ所の分
散システムを管理する必要
性
•自動レプリケーション: デ
ータ配信がリアルタイム、
ローカルにデータを読む事
が可能
•キャッシュとデータベース
の同期: キャッシュが常に
アップデート
•単純なデータモデリングと
分析: 変更が簡単、理解し
やすい
•違反金$40,000,000を5年間
の間に節約
•データ配信に対する課金は
一回のみ
•グローバルにデータ同期と
各拠点でのローカルRead
が保証
•統一したグローバルデータ
サービスに移行
7.拠点間連携

34. [海外][金融]グローバル信託銀行 X社（事例２）
• 新旧のシステム構成比較
バッチ連携
ゴールデン
コピー
レプリケーション
プライマリ
レプリカセット
7.拠点間連携
近い拠点から
データを読み取る

35. さいごに
• MongDBの普及のために、MongoDBの活用
事例を集めています！
• 公開しててもよいという人がいましたら、
ぜひお声掛けください

36. おまけ）シャーディング性能
Top5マーケティング企業 米国政府省庁 Top5 投資銀行
データ キー/バリュー 10以上
キー/バリュー、配列、ハ
ッシュを含む
20以上
キー/バリュー、配列、ハ
ッシュを含む
クエリ キーベース
1１クエリで1～100ドキ
ュメント
80%:20% = read/write
compundクエリ、レンジ
クエリ、mapreduce
2:8=read:write
compundクエリ、レンジ
クエリ
5:5=read:write
サーバ台数 ～250 ～50 ～5しゃ
トラフィック 1,200,000 ops/sec 500,000 ops/sec 30,000 ops/sec