4月9日に「第2回 MongoDB JP 勉強会 in Tokyo 」が開催されました。当日は天気の悪い中、70名以上の参加があり多くの方が懇親会まで参加されました。本稿では、今回の勉強会のレポートをお届けします。
会場風景。70名以上の方が参加されました
これまでの MongoDB JPの活動について
まずはMongo DBの日本ユーザーグループの活動について簡単にお話しします。
2010年11月に「MongoDB JP 」が発足しました。現在メンバーも300名を超え、大変盛り上がりを見せてきています。ユーザーグループの活動として12月に「第1回 MongoDB JP & CouchDB JP 合同勉強会 in Tokyo 」を開催し、3月には開発元の10genのエンジニアをお招きしての国際カンファレンス、「 MongoDB Conference in Japan 」を開催してきました。
それに引き続き、今回の「第2回 MongoDB JP 勉強会 in Tokyo」が開催されました。
なお前回のカンファレンスより、MongoDB JPの活動に関するハッシュタグを #mongotokyo に統一することにしました。今後各地方での活動も盛んになり、#mongo*** （ 地域名）のハッシュタグが使われることを願っております。
今回の勉強会の内容
「第2回 MongoDB JP 勉強会 in Tokyo」の発表内容は以下の表とおりです。
順番
発表者
タイトル
1
@doryokujin Sharding詳解〜機能と仕組みの理解〜
2
@bibrost Type-safe MongoDB with Scala
3
@muddydixon アクセスログをできるだけいろいろ見る時のmapreduce + ニフティクラウドでの構築とパフォーマンスを初心者からわかりやすく
4
@yamaneko1212 地理空間インデックスを利用したWebアプリケーション(LT)
5
@joe_hrmn Tachy with MongoDB
6
@everyone
ディスカッション 〜MongoDBを活用し、震災対策に役立てないか？・MongoDBのここが知りたい〜
7
@everyone
懇親会
勉強会最後にディスカッションの時間を用意していましたが、今回は時間の都合上、中止になりました。ただ、たくさんの参加者・Ustream視聴者の意見を拾うためにも、気軽なディスカッションの機会は今後取り入れて行きたいと考えています。ディスカッションだけでなく、ハッカソンなどの全員参加型のイベントも今後開催予定にしています。
なお、本勉強会の運営はフューチャーアーキテクト株式会社 さんの全面協力によって支えられました。 また、@understeer さん、@ixixi さんをはじめ、多くのスタッフにイベント運営を協力していただきました。ありがとうございました。
@doryokujin「Sharding詳解〜機能と仕組みの理解〜」
筆者 @doryokujin からはMongoDBの特徴的な機能であるShardingについて、機能と仕組みについてできるだけ詳しくお話してきました。本内容は動かし方の手順を示すようなチュートリアルとしての位置づけではなく、Shardingとは何か・どんな特徴があるのか・使用の際の注意点などにフォーカスして紹介しました。。
資料 ビデオ 1 、2 、3 をご参照ください。
MongoDBが掲げるShardingのコンセプトは3つはあります。
1. Make the cluster “invisible”
クライアントが裏側でサーバーがSharding（分割）されているいることを意識することなく、シングルサーバーで運用しているときと同じ扱いで各種の操作ができます。
2. Make the cluster always available for reads and writes
フェイルオーバー・データの分割・Shard間でのバランシング、これらをすべて自動で行うことで、クラスタ全体を常に健全に保ち、常に読み書き可能な状態を保証しています。
3. Let the cluster grow easily
新しいサーバーの追加・撤退も自動かつ容易に行えるような仕組みになっています。
このようなコンセプトを掲げるMongoDBのShardingを深く理解するために、以下の4つのキーワードを提示し、それを詳細に説明するように心がけました。
1. Shard key
Shard KeyはShardingによってコレクションを分割する際のキーとなるものです。このShard Keyの選び方によって、Shard間に偏りが起こる確率が変わってきますので慎重に選択しなければなりません。また一度Shard Keyを決定してしまうと変更はほぼ不可能です。そんなShard Key選択における悪い例を3つ、良い例を1つを紹介しました。
2. Balancing, Migration
これらの機能はShard間のデータの均等な分散を維持する仕組みを提供してくれます。BalancingはShard間でデータの不均衡が生じた際に偏りの大きなShardからデータを移行することによって是正してくれる機能です。また、データの移行のことをMigrationと呼んでいます。MongoDBはこれらの機能を自動で行ってくれますが、「いつBalancing機能が発動するのか？」「Migrationが起こった時に生じる問題点」などを紹介しました。結論としてMigrationが起こってしまう（Balancing機能が発動する）と（4. Shardingクエリで詳しく紹介しますが）色々不都合が生じる可能性があるため、それ自身が起こらないように工夫する（Shard Keyの慎重な決定や継続的なモニタリング）ことが重要です。
3. mongos, config, mongo
これらはShardingを構成するサーバー群です。それぞれが異なる役割をもっており、特にmongosサーバーがクライアントとShardサーバー群を仲介する役割を持っており、コンセプト「Make the cluster “invisible”」を実現しています。それぞれのサーバーの役割について詳しく説明しました。
4. Sharding クエリ
Sharding環境における各種クエリは、シングルサーバーにおけるクエリと結果がどう違うのかについて説明しました。Shard環境におけるクエリはfindやupdateなどの多くのクエリに対しては効率的に処理を行ってくれますが、条件にShard Keyを指定しないと効率の良い処理が行われないこと、またMigration実行中のCountなどの集約処理においては正しい結果が得られない可能性があること、複数のShardに対してほぼ同時に書き込みがあった場合、ユニークキーの重複などDB自身に矛盾が起こってしまう可能性があることを紹介しました。
発表を終えて、今回資料を作成してみた感想と発表後の皆さんの反応をまとめると、MongoDBのShardingは非常に魅力的だけれども、特にクエリの実行結果やMigrationの安全性において、まだまだ未完成な部分もあるため、使用時には注意が必要であるということです。ただ、MongoDBの開発・コミュニティの盛り上がりを考えると、今後どんどん改善されていくことは間違いありません。その改善に少しでも貢献できるように努めて行きたいと思っています。
勉強会の後、@matsunoue1 さんがShardingの挙動について色々と検証されています。是非確認してみてください。
@bibrostさん「Type-safe MongoDB with Scala 〜静的型付け言語とMongoDBのつきあい方〜」
@bibrost さんからはScalaのような静的型付け言語とMongoDBのつきあい方について様々なわかりやすい具体例とともにお話していただきました。
静的型付けについて
まずは静的型付けについて、型推論も行ってくれる柔軟な言語Scalaを取り上げて丁寧に紹介されました。静的型付けの大きなメリットの1つは「変なことが起きない」 、コンパイル時に型が決まるのでデプロイされたコードで予期しないことが起きる可能性が少ない、バグがあっても追跡しやすいとのことでした。そのメリットを「トイレ」の実装を例にしてわかりやすく、おもしろく説明され、会場は大いに盛り上がりました。
静的型付け言語とMongoDBのつきあい方
次に静的型付け言語でMongoDBを扱うことについてメリットとデメリットをお話して頂きました。まずデメリットとしては、スキーマフリーをはじめとした、非常に柔軟かつ寛容な機能を持つMongoDBにおいては、型付けの制約は少なからず実装スピードに関しては足かせになってしまいます。ただし、それを補うだけのメリットをもたらす使い方もあるということです。その使い方とは、"Type-safe MongoDB" = Persistent for Model Class（モデルクラスの永続化）に用途を絞ることです。この用途の元ではアプリ側でほぼ定義が完結し、柔軟に扱えかつMongoDBの強力なクエリ機能を使用できます。
Scala + Rogueを使った実装
次に静的型付け言語であるScalaでの実装が紹介されました。同時に使用したScalaのWebフレームワークの1つであるLiftと、Lift向けにFoursquare社が開発したLift用のクエリ生成ライブラリ、Rogueに関するそのライブラリの構造とMongoDBのクエリの使い方について、コードベースで説明されました。
Katsumaweb.netのコレクション構造
最後に実際にScalaとMongoDBで実装されている Katsumaweb.net というサイトのモデル構造が紹介されました。
筆者の感想
本セッションでは、Web開発などにおいて、Scalaのような柔軟な静的型付け言語をMongoDBとともに用いることで、MongoDBの柔軟さにデータの「安全・安心感」をプラスできることが説明されました。あらゆるデータを寛容に受け入れてくれるMongoDBには良きしない変なデータが混入されていてもなかなか気づくことができません。しかし、それを事前に型チェックを行い、予期しないキーや値を排除してからMongoDBに格納されているデータにはそういった事態を減らすことができます。これは静的型付け言語のコンパイルの手間を大きく補うメリットではないでしょうか。特にScalaなら少ないコード量で記述できますし、非常に相性が良いのでは無いかと感じました。
今回はScalaとMongoDBという、非常におもしろい組み合わせでの使う例を聞くことができました。ただ、この組み合わせはFoursquareが採用しているなど、世界ではメジャーなものになってきつつあります。今後とも要注目の技術であるように感じています。
@muddydixonさん「アクセスログをできるだけいろいろ見る時のmapreduce + ニフティクラウドでのパフォーマンス」
@muddydixon さんからはMongoDBのMapReduceについて、非常に豊富な例とパフォーマンス検証が紹介されました。MongoDBのMapReduceに関しては簡単なサンプル以外で実践的なコードが記載された資料が少ないので、今回の発表と資料は非常に貴重なものとなっています。
不定形データの放置場所としてのMongoDB
非常に多数のサービスを抱え、ログという観点ではサービス間で全く独立していて互換性の無いような環境に身を置く@muddydixon さんにとってのMongoDBとは「不定形データの放置場所」 。まずはMongoDBに様々な不定形データを格納しておき、眺め、そこに有用な発見があった場合は本腰を入れてHadoopなどの他の技術を駆使して解析を行っていく、とのことです。MongoDBはその具体的なアクションにつなげるべき有用なデータを発見するためのツールとして使われています。
MongoDBのmapreduce
冒頭にも触れましたが、MongoDBのMapReduceは公開されている例がそれほど多くありません。そんなMongoDBのMapReduceについて、「 MapReduceとは何か？」から始まり、Mongo MapReduceの振る舞いとオプションが説明されました。ここでのポイントは、HadoopなどのMapReduceとは違ってShuffleフェーズがないこと、Reduceは複数回行われる可能性があるため、各キーごとにデータが完全に集約された状況で何らかの処理をしないといけない場合はFinalizeを使用するということです（注：本資料の発表内容はMongoDB v.1.8を想定したものになっています。現状の v.1.6.* 系ではオプションが異なりますので注意してください） 。
MongoDBでアクセスログを解析する
実際にアクセスログ解析を目的として、Mongo MapReduceを行う手順を具体的に紹介されました。mongoimportコマンドを利用してのデータインポートの方法から、時間単位・UU単位・セッション単位における集計方法をコードとともに解説して頂きました。特に「所感」と「小技・tips」では、普段なかなか知ることのできないコツや留意点が伝授されました。
nifty cloudでMongoDBの条件変えてパフォーマンスとってみる
ニフティクラウド上で以下のような計測条件の元、Twitterデータに対してクエリとMapReduceパフォーマンス比較を行っているとのことです。
Sharding 1. なし 3台 Striping 1. Striping なし 2. Striping あり(物理相当) VM mini Large 16
この計測結果（グラフ）と考察は非常に参考になりますので、資料を一読ください。
筆者の感想
MongoDBのMapReduceを利用した際のコードサンプルは非常に参考になると同時に、実際に使用・検証してみた上での考察やTipsもとても貴重な情報となっており、今後Mongo MapReduceを使う際の参考書的な存在になると思います。このような具体的な使用ケースの話を聞け、かつその本人にかれこれ質問ができるのも勉強会ならではの醍醐味だと感じました。
@yamaneko1212さん「地理空間インデックスを使ったWebアプリケーション」
@yamaneko1212 さんからはMongoDBの地理インデックスについて説明していただき、それを活用したWebアプリケーション、G＃（現在開発中）がデモとともに紹介されました。
Webアプリケーション紹介
G＃はTwitterのハッシュタグに位置情報を付与してそれをGoogleMap上に可視化することができるサービスです。これから色々おもしろい機能が実装されていくとのことで、今後が非常に楽しみです。
地理空間インデックス
G＃で使われる位置情報はMongoDBに格納され、MongoDBの提供する地理情報に対する各種の機能を利用して可視化や検索を可能にしています。そこでMongoDBにおける地理情報データの具体的な扱い方をサンプルコードとともに説明されました。次に、散り空間インデックスを利用する際の注意点、v.1.7からSphereクエリが利用可能なこと、Sharding環境では未対応（2011前半中に対応するらしいです）であることが紹介されました。
WebアプリケーションとMongoDB
WebアプリケーションでMongoDBを使用する際における以下の注意点を、PythonのWebフレームワークであるDjangoを例にして紹介されました。
設計レベルでの複雑性の低減のために、データを抽象化したオブジェクトを使うこと
カジュアルなドキュメント指向の危険性を指摘し、安易なスキーマ設計を行わないこと
おまけ（デマったーの紹介など）
さらにMongoDBを採用しているサービス、デマったーが限定で公開されました。非常におもしろい展開になりましたので、詳細はビデオをご覧ください。
筆者の感想
実際のWebアプリケーションへのMongoDBの活用例（かつ地理情報インデックスを利用した貴重な例）として貴重なお話が聞けました。何より@yamaneko1212 さんが話し上手で、常に笑いが絶えない発表となりました。今後もこのような具体的なサービスを見ながらバックで利用しているMongoDBを紹介する、といった形態が増えてくるといっそう理解が深まると良いですね。
@joe_hrmnさん「Tachy with MongoDB」
MongoDBを実サービスで大規模運用を行われているサイバーエージェントの @joe_hrmn さんが現在プレリリース中の実名SNS制サービス「Tachy」におけるMongoDBの利用事例が紹介していただきました。
システム構成
Tachyを構成する主な技術構成は「MongoDB＋ActiveMQ＋MySQL」となっています。MongoDB v.1.6.5（現在の最新Stable版）を、Replica Set + Sharding環境で利用されています。言語はJavaで、あわせてmorphiaライブラリを使用されているとのことです。
MongoDBの使いどころ
TachyのデータがMongoDBにどのように格納されているのか、実際のコレクションの紹介とともに使いどころが説明されました。特に、紹介されたコレクションは発言やコメントを取得する“ Entry” ・ユーザーのタイムラインを取得する“ Timeline” 、Room情報を取得する“ Room” 、それらの具体的なスキーマ構成やデータ挿入の方法が説明されました。
苦労した話・これから
1件ずつのインサートには非常に時間がかかるためBulk Insertを活用したこと、Masterのスイッチングがうまく行われないこと、Sharding環境ではSlaveへの書き込みを可能にする“ Slave OK” コマンドが効かない、といった問題点やTipsが紹介されました。また、今後はより複雑なクエリでの性能検証やコレクション構成の再検討、バックアップ・リストアの検証などを予定されているとのことです。
筆者の感想
まだ正式な発表のないサービスを具体例に話をしていただくという貴重な機会でした。ソーシャルサービスでのMongoDBの活用について、頻繁に書き込みのあるTimelineデータを格納する仕組みなど、大変参考なるお話が多かったと思います。これを期に、今後もソーシャルサービスでのMongoDB活用例が増えてくることを楽しみにしています。また、サービス開発とともに、MongoDBのパフォーマンスを今後もどんどん検証予定とのことですので、次回の発表を期待しています。
懇親会
懇親会もたくさんの方が参加され、大いに盛り上がりました。
今後のmongotokyoの活動について
毎月開催の「MongoDB勉強会」に加え、「MongoDBソースコードリーディング勉強会」・「スキーマデザイン討論会」も
mongotokyoは今後も勢力的に活動を続けて行きたいと思っています。毎月開催の「MongoDB勉強会」を中心に、今回の勉強会・懇親会で要望の多かった「MongoDBソースコードリーディング勉強会」 ・「 スキーマデザイン討論会」も開催を検討しています。まずは5月中旬に「第3回MongoDB勉強会」を開催予定です。この勉強会に向けての発表者・スタッフを募集を開始いたします。筆者のTwitterアカウント @doryokujin かメールアドレス mr.stoicman[at]gmail.com まで連絡をお待ちしております。
また、企業でMongoDBを導入されている方には本家サイトの Production Deployments をはじめとしたメディアに掲載して頂ける様に働きかけて行きますので筆者にお気軽にお声掛けください。現在すでに Preferred Infrastructure やVuzz が掲載されています。また近日、 CyberAgent と芸者東京エンターテインメント も掲載される予定です。
その他ドキュメントの整備など
MongoDBはv.1.8が登場し、多くの機能の改善がもたらされました（リリースノートはこちら ） 。それを日本語ドキュメントにも反映させていくなど、日本語ドキュメントの整備をよりいっそう進めて行きたいと思います。今後ともMongoDBをよろしくお願いします。
