4月9日に「第2回 MongoDB JP 勉強会 in Tokyo」が開催されました。当日は天気の悪い中，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」の発表内容は以下の表とおりです。

勉強会最後にディスカッションの時間を用意していましたが，今回は時間の都合上，中止になりました。ただ，たくさんの参加者・Ustream視聴者の意見を拾うためにも，気軽なディスカッションの機会は今後取り入れて行きたいと考えています。ディスカッションだけでなく，ハッカソンなどの全員参加型のイベントも今後開催予定にしています。

なお，本勉強会の運営はフューチャーアーキテクト株式会社 さんの全面協力によって支えられました。 また，@understeerさん，@ixixiさんをはじめ，多くのスタッフにイベント運営を協力していただきました。ありがとうございました。

@doryokujin「Sharding詳解〜機能と仕組みの理解〜」

筆者 @doryokujin からはMongoDBの特徴的な機能であるShardingについて，機能と仕組みについてできるだけ詳しくお話してきました。本内容は動かし方の手順を示すようなチュートリアルとしての位置づけではなく，Shardingとは何か・どんな特徴があるのか・使用の際の注意点などにフォーカスして紹介しました。。

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の挙動について色々と検証されています。是非確認してみてください。

• MongoDBのShardingを試してみた。その１ - matsuou1の日記
• MongoDBのShardingを試してみた。その２ Migration中の挙動について - matsuou1の日記