ソーシャルアプリのプロトタイプ制作にMongoDBを活用

ソーシャルアプリのプロトタイプ制作にMongoDBを活用～PHP+Sleepy.Mongooseでお手軽永続化～Fungoing LLC / Satoshi MiyauchiTwitter : @bibrost

Profile 宮内聖 / Satoshi Miyauchi @bibrost 自宅警備員（週休2日）兼 Fungoing LLC 代表兼株式会社監査と分析システム開発担当兼株式会社ニジボックス傭兵 … etc Webデザイン、映像編集、Webサービスの開発など・・・いろいろ引きこもりフリーランス生活。と思ったら最近はたまに出勤。 Scala、MongoDB、Solrをメインにやってます ※お仕事、協業のご相談は随時受付中 Page : 1

Recent Works ( with MongoDB! )3月30日Open katsumaweb.net Scala+MongoDB+Rogueを使って開発前回のMongoDB勉強会で発表しました Webに資料もあります4月中旬～ソーシャルアプリ開発のお手伝いリクルート子会社のニジボックスという会社でアプリ開発のお手伝いをしています。 MongoDBを提案してプロジェクトで利用 → 今日はここの話をします！ Page : 2

Outline 1. プロジェクト概要 → 関わっている内容と、MongoDBの利用について 2. MongoDBでお手軽永続化 → コードを見ながら、利用方法を紹介 3. 実装の裏側 → どうやって実装してるか 4. Q&A → 実装した理由や狙いなどをQ&A方式で 5. MongoDB活用のセオリー → 今までの経験も含めた、MongoDB活用に関する所感 Page : 3

1. プロジェクト概要 Page : 4

2010年末にできたばかりで、ここへ来てスタッフも集まり気合入れてアプリを開発しようというプロジェクトへ参加。担当領域は社内フレームワークの改善、ログ分析プラットフォームの構築、開発プロセスの改善などがメイン。 Page : 5

まずやったこと機能ごとに開発するのではなく、小さいサイズからでも完成品を作りそれを毎週増築→レビュー→フィードバックしていく形の開発プロセスの提案。 Week1 Week2 Week3 Week4企画コンテンツコンテンツコンテンツコンテンツコンテンツ開発開発開発開発開発フィードレビューレビューレビューバック Page : 6

プロセスの意図 Week1 week2 week3 week4 ユーザが体験できるシナリオを少しずつ拡張していくことで、「ユーザが楽しませるために重要な要素」をレビュー、改善しやすくする。どんなに機能を増やしても、ユーザが入り込んできてくれなければまったく意味がない。この方法であれば、ユーザの導入に近い部分から完成していくので無駄な作業も減り本質的な改善に力を注げる。 [Week1] チュートリアル、最初のミッション、メインループ [Week2]アイテムの実装 [Week3]コミュニケーションの実装、、、という風に、徐々にできることを増やしていく。 Page : 7

と、いう狙いなのですが・・・リリースタイミングが多いので結構大変。更にレビューを受けての仕様変更は毎週あるというのが前提です。 Page : 8

この速度で開発しようとするといちいちRDBのスキーマ定義なんてしていられない・・・。メンバー間でのスキーマ同期にかかるコストも馬鹿にならないしどうしたものか Page : 9

ん、そういえば・・・ Page : 10

があるじゃないか Page : 11

そもそも、ログ分析部分はMongoDBでやるつもりだったのでSleepy.mongooseの環境は検証用にすでにあるログ分析プラットフォームアプリ Sleepy.Mongoose ログ送信クラス MongoDB ※MongoDBの接続ライブラリをセットアップするコストを減らすために Log Collection アプリ側はcurl＋jsonだけで利用可にする (Capped Collection) ログフロント Map/Reduce コンソール Analytics Source （JSで操作） Collection ログ閲覧画面 jQuery + Graph UI Sleepy.Mongoose Page : 12

Sleepy.Mongoose ＝Python+Pymongoで書かれた MongoDBのRESTinterface実装http://www.snailinaturtleneck.com/blog/2010/02/22/sleepy-mongoose-a-mongodb-rest-interface/ Page : 13

イメージ初期はMongoDBを粘土（CrayModel）のようにいじりまわして開発。内容が固まったらRDBで金型を作ってそこへ流しこむ・・・そんな感じ。 Week1 Week3 Week5 Week7 Week9 Week11 Week2 Week4 Week6 Week8 Week10 Week12 Week1~8あたりまではMongoDBで最終的にはどんどんシステムを練り続ける RDBに固める Page : 14

でプロトタイプを作っていこう！ Page : 15

そして導入後・・・喜びのお言葉 MongoDBに病みつきです!! 準備(CREATE)なしでいきなり挿入(INSERT)なんて!? もうmySQLには戻れません!! チームメンバーFさん Page : 16

２. MongoDBでお手軽永続化 Page : 17

こんなコードが書けるようにフレームワークを拡張しました Page : 18

とりあえず永続化！ // データを作って、、、 $data = array( ‚name‛ => ‚Sword‛, ‚category‛ => ‚Weapon‛ ‚price‛=> 1200 ); // insert _persistence()->insert( ‚item‛, $data ); Page : 19

データとってくる // とりあえず10件とってくる $docs = _persistence()->from( ‚item‛ )->fetch(10); // 11~20件目をとってくる $docs = _persistence() ->from( ‚item‛ ) ->skip(10) ->fetch(10); // 件数をとってくる $count = _persistence() ->from( ‚item‛ ) ->count(); Page : 20

検索してみる // 名前が一致したものをとってくる $docs = _persistence() ->from( ‚item‛ ) ->cBy(‚name‛,‛Sword‛) ->fetch(10); // 範囲を含めてとってくる $docs = _persistence() ->from( ‚item‛ ) ->cOr( array(‚category‛ => ‚weapon‛, ‚category‛ => ‚armor‛) ) ->cBetween(‚price‛,1000,2000) ->skip(0) ->fetch(10); Page : 21

並び替える // priceの昇順でとってくる $docs = _persistence() ->from( ‚item‛ ) ->cOr( array(‚category‛ => ‚weapon‛, ‚category‛ => ‚armor‛) ) ->cBetween(‚price‛,1000,2000) ->sortAsc(‚price‛) // ->sortDesc(‚price‛) ->skip(0) ->fetch(10); Page : 22

更新してみる // とりあえず取得 $docs = _persistence()->from( ‚item‛ )->fetch(10); $docs[0][‘price’] = 1500; // 新しいオブジェクトで更新 $docs = _persistence() ->updateById( ‚item‛, $docs[0][‘_id’][‘$oid’], $docs[0] ); Page : 23

削除する // とりあえず取得 $docs = _persistence()->from( ‚item‛ )->fetch(10); // 1件目にあったデータを削除 $docs = _persistence()->removeById( ‚item‛, $docs[0][‘_id’][‘$oid’] ); Page : 24

といった風に、アプリ側のコードだけで手軽に永続化できるよ！ MongoDBのクエリは書くのが結構面倒なのでよく使いそうなのを簡単に使えるようにしておいた Page : 25

プロトタイプとはいえ、紙芝居ではプレイ感をレビューしきれない。そこでこの機能でとりあえず実装。 Page : 26

設定自社フレームワークに組み込んであるので、二行ほど変更するだけ // ENV.php define(‚MONGOOSE_HOST‛,‛http://xxx.xxx.xxx.xxx:27080‛); define(‚MONGOOSE_DB‛,‛fw‛); ※Sleepy.MongooseのサーバはAWSに設置 Page : 27

３. 実装の裏側 Page : 28

クライアント環境 PHP 5.2 ~ (json_encode/decode) + php_curl 以上 Page : 29

サーバ環境 MongoDB 1.8 + Pyhton 2.7 + Pymongo 1.10.1 + Sleepy.Mongoose Page : 30

永続化の仕組み Persistence->from(“col”) QueryBuilderを返す QueryBuilder->cBy() QueryBuilder->cBetween() QueryBuilder->skip() Criteria QueryBuilder->sortAsc() Application QueryBuilderクラスは Criteriaクラスに QueryBuilder->fetch() 条件を保存 Persistence->insert() Persistence->find() Persistence->updateByID() Persistence->removeByID() Sleepy.MongoosePersistenceクラス群を使ってアプリから永続化。 Persistence->request()最終的にはrequestメソッドが MongoDBSleepy.Mongooseにアクセス Page : 31

内部処理private function request( $table, $command, $query, $post = NULL ){ $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $this->api."{$table}/_{$command}{$query}"); curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 5); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); if( isset($post) ){ curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $post ); } $result = curl_exec($ch); $result = json_decode($result,true); return $result;} どうってこともない、cURLを使ってSleepy.Mongooseにリクエストするだけの簡単なおしごと Page : 32

Fromメソッドの処理 // _persistence()はプロセス内で一回だけPersistence // インスタンスを生成して返すヘルパ（いわゆるgetInstence） $p = _persistence(); // fromメソッドはnew QueryBuilder(‚collection‛)を返す $builder = $p->from(‚collection‛); // cBy,skipなどのメソッドは設定が加わった$thisを返す $builder = $builder->cBy(‚‛,‛‛); $builder = $builder-> ->skip(10); // fetch,countは自身に設定されたcriteriaを使い // cURL経由でSleepy.Mongooseにアクセス $builder->fetch(10); 以上はすべて繋げて書けるので前述のコードになる Page : 33

一点だけ注意元のSleepy.Mongooseはcountに対応していないっぽいです探し方が悪いだけかもしれない Page : 34

仕方ないのでforkして自分でcountインターフェイスを追加githubに上げているのでよろしければどうぞhttps://github.com/bibrost/sleepy.mongoose※本体が更新されてたのでマージしないと、、、 Page : 35

4. Q&A Page : 36

Q. PHPのMongoDBドライバは使わないの？・使う可能性がある開発チームの数が多く、環境の設定をできるだけ減らしたかった・アプリ側のインフラをいじりたくない・ポリシー上DBサーバに直接アクセスできないなどの理由からSleepy.Mongoose経由にしています。 Page : 37

Q. もう本番でもMongoDBでいいのでは？・Complex Transactionが使えない →有料アイテム購入などで必要・MongoDBをメンテできるエンジニアがいないので本番はMySQL。 Page : 38

Q. プロジェクトへの効果は？・開発者間でDBスキーマを同期させる必要がなく、 Subversion上のソースだけで完結するので作業のオーバーヘッドが減ったと感じる ※コレクション名、DB名の変更＝初期化・まだ未知数だが、そもそも複雑なクエリは書けないのでRDBに移したときもパフォーマンスを出しやすいのではと期待 Page : 39

５. MongoDB活用のセオリー Page : 40

ここ数ヶ月MongoDBを使ってきた経験をもとに、僕なりの活用セオリーをまとめてみました。これから試してみようかな？という方の参考になればと思います。 Page : 41

僕が思うMongoDBのサイコーなところスキーマレス！ × なのにクエリが強力！＝ストレスフリーなアプリ開発！しかも盛りだくさんなおまけつき！（Sharding, Replica Set, Geo Index and more…） Page : 42

僕が思うMongoDBのサイテーなところ信頼性なさすぎ Page : 43

ようするに信頼性を犠牲にしても、開発効率や柔軟性が重視されるケースに活用するとGood プロトタイプ制作だと信頼性なんて二の次どころか不要。バックエンド系も許容範囲が広げやすい。フロントなユーザ投稿コンテンツなどクリティカル度低いものに Page : 44

一応擁護しておく信頼性が全くないわけじゃないです。が、そこを強化するとパフォーマンス落ちたり他のソリューションとの差別化ができなくなってきたりで深い闇のMongoDBワールドが待っています Page : 45

Use case... 用途適正理由高速なCappedCollection、柔軟なスキーマログ解析系 ○ 事例も多く使いやすい悪くはないが、RedisやMySQL(memcache)などキャッシュ △ 他の選択肢を検討してもよいかとプロトタイプ制作 ○ スキーマレスかつクエリも使えるのでとても便利信頼性が低いのであまりやらないほうがいいかな。認証系 △ ただし、OpenSocialのように外部に本体があるなら使ってもいいかも？ゲーム・エンタメ △ 厳密な処理が必要じゃないシステムであればOK 多少のデータロストを許容できるなら強力。コミュニティ・CGM ○ このあたりはデータのプロパティ追加も起きやすくスキーマフリーの力を発揮できる決済系 ××× 考えないほうがいいとおもいます。業務システム ×× 向いてないと思います Page : 46

まずはプロトタイプ制作にMongoDBを使うのはオススメ。影響範囲も少なくストレスフリーに開発ができますよ！ Page : 47

でストレスのないアプリ開発を楽しみましょう！ Page : 48

ありがとうございました。Satoshi Miyauchi @bibrost Page : 49

http://cloudrop.jp	6297
http://www.nogutetu.com	1090
http://d.hatena.ne.jp	1076
http://webcache.googleusercontent.com	260
http://gihyo.jp	140
http://fungoing.jp	49
url_unknown	40
http://infra.rrdtool.net	39
http://www.slideshare.net	17
http://shadianpardaz.com	6
http://paper.li	5
http://us-w1.rockmelt.com	4
http://localhost	3
http://twitter.com	3
http://cache.baidu.com	2
http://freeandroidgames.appspot.com	1
http://ventil.se	1
http://timprx.appspot.com	1
http://gaeforyou.appspot.com	1

ソーシャルアプリのプロトタイプ制作にMongoDBを活用

by fungoing on May 13, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

19 Embeds 9,035

Statistics

ソーシャルアプリのプロトタイプ制作にMongoDBを活用 — Presentation Transcript