がっつりMongoDB事例紹介

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

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

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

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 インストール数は考慮されていない

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

• 採用企業 600社以上

• 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もすごく期待されている！

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社(事例２)
従来の教科書通りの使い方
近年の新しい使い方

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

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

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

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

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

• システム構成図
16

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

おまけ）シャーディング性能
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

がっつりMongoDB事例紹介

More Related Content

What's hot (20)

Similar to がっつりMongoDB事例紹介 (20)

More from Tetsutaro Watanabe (18)

Recently uploaded (9)

がっつりMongoDB事例紹介