Prochain SlideShare
がっつり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
Identifiez-vous pour voir les commentaires