実はいま、この原稿をサンフランシスコに向かう機中で確認しています。次回の10gen社突撃取材を敢行するために、飛行機に飛び乗ったまでは良かったのですが、ノープラン・・・。いろいろ考えなくてはいけないのに、なぜかこれまでの自分を振り返ったりしてみたら、営業アシスタントからスタートし、プロダクトマーケへ移籍、気が付いたら今回の執筆。
毎回とんでもないチャレンジ(試練)を与えられ、ついには直接メーカ取材。だけど、no challenge, no life。
何ごとも楽しむことにしなくては。
さてさて本題に！今回は実際に導入された事例を見てみます！友達が使っていたので自分も何気なく使っていたfoursquare。そこにもなんと！MongoDBが使用されていました！
今回、10gen社さんに許可をいただきましたので、その事例を、ここでご紹介しちゃいます。
foursquarefoursquareは、位置情報に基づいたソーシャル・ネットワーク・サービスを提供している会社です。利用者は、携帯電話から「ベニュー」(venue)と呼ばれる特定の場所で「チェックイン」(check-in)の情報を通知することにより、ポイント等を獲得することができます。2009年から急成長しており、foursquareでは限られた技術の中でアプリケーションの効率化が必要となっていました。そこでデータ量が膨大になるにつれて、ベニューとチェックインの情報をMongoDBへ移行することを決断しました。
既に、アメリカでは話題になっていたMongoDBは以前から気になっていたみたいです。敷居も高くない＆口コミでの評判も導入への後押しとなったそうです。聞いてみたところ、MongoDBのユーザはほとんどが口コミによるもの。口コミ効果って、やっぱりすごいんですね。
課題
foursquareのアプリケーションは、シングルRDBを使用していました。この構造のため、foursquareではアプリケーションへのアクセスに対応しうるだけのノードを簡単に追加することができませんでした。ここで、データを二つのノードに分けることにし、一つはチェックイン専用（もっとも大きなデータセット）そしてもう一つには、その他すべてを対応することにしました。ただ、チェックイン情報が一台のマシンで対応できる限界はすぐにくるだろうことは明確です。そこで、長期的に見て拡張性のあるソリューションを探す必要がありました。
確かに、世界で使用されているfoursquare。国内ですらいろんな人が同時に別の場所へチェックインすることなんて多々あること。それが世界中と考えると一台で処理できる限界なんて、あっという間なんでしょうね。
Why MongoDB?
foursquareではMongoDBを採用することで、スケーリングの問題解決のみでなくその他の課題に対しても解決できるこれらの機能を発見しました。
Auto-Sharding
foursquareではまず、既存のauto-sharding機能を持つMongoDBへデータを移行。auto-sharding機能では自動的にデータベースを分割してくれるため、書き込みを複数のノードへスケールすることが可能となりました。独自でshardingレイヤーを書くことなく、このauto-sharding機能に頼ることでfoursquareではアプリケーションが成長するにつれ、新しいノードを追加するのみで良くなりました。これによりfoursquareは裏側を気にすることなく、アプリケーション開発に集中することができるようになりました。
なんと簡単な！増えてきたと思ったら、ノードを追加するのみで大丈夫になるなんて！自動的に分割までしてくれるんですから、特に意識することなく使い続けれるってことですね。
Replica Sets
replica setsでは、各ノードに対して自動フェイルオーバー機能を提供しています。Amazon EC2上でfoursquareが稼働しており、ノードがいつ落ちてもおかしくないため自動フェイルオーバー機能はfoursquareの運用チームにとってはもっとも大切な機能の一つでした。この機能により製品の問題ともなりうるイベントでも通常運用タスクとして入れられることが可能となりました。
何か行動を起こしたときにすぐに結果が求められるソーシャル・ネットワーク・サービス。当たり前に返ってくると思っていても、処理している側に何が起こっているか意識せずにサービスを提供＆維持させるのって大変なんですね。ましてや、食事に行ったときにチェックインするのは入ってすぐのタイミング。それを逃したら、食事に集中してもう一度チェックインをしようとは思わないですもんね。それにも対応しうる環境作りって本当に、大切なんだとつくづく実感！
Harry Heymann氏
foursquareのHarry Heymann氏によると―
「アプリケーションに独自のshardingレイヤーやミドルウェアレイヤーを書くには、非常に時間と労力が必要となります。10gen社にアウトソースするのがbig winへとつながると考えました」
地理空間インデックス（Geospatial Indexing）
foursquareのもう一つの利点は、MongoDBがサポートしているgeospatial indexingです。これにより、位置データのクエリが容易にできるようになりました。
ドキュメント指向
RDBのスキーマ定義をする構造とは対照的に、JSON風なオブジェクトを持つMongoDBのドキュメント指向モデルは、オブジェクト指向のプログラミングと相性が良いです。foursquareのHarry Heymann氏によると「今のプログラマーはもうリレーショナルモデルでは考えなくなっている。なぜなら、今はほとんどのエンジニアがオブジェクト指向プログラマだから」とのこと。
MongoDBにより、データモデルを飛躍的に単純化させることができたfoursquare。例えば、タグ（'wifi あり'、'デートに最高'、'ホットスポット'等）を別のテーブルへ保管しテーブルのマッピングに頼らず、ベニューのドキュメントに直接MongoDBタグを埋め込むことができます。これにより実行時間が効率的になり、エンジニアの作業などの負担も軽減できました。
タグを別で保管すれば、もしもタグを追加したとしてもドキュメントのみを修正すれば良いってことですね。管理も楽だし、操作も簡単でとてもシンプル！
- foursquare社 Lead Server Engineer Harry Heymann氏（MongoNYC 2011より）
「MongoDBは、現場のエンジニアが抱えている問題を実質的に解決してくれるデータベースです。MongoDBは大規模ウェブアプリを知り尽くした人たちによって設計されており、実際にお客様が抱えている問題を解決できるように開発されたデータベースです。その作業は、オリジナルの1.0の設計から現在に至る。今も10genでは作業が続けられておりそれはすべてお客様の問題解決のお手伝いをするためです。例えば、次にこんな機能を追加してくれたらもっと作業が楽になるのに、と課題をもらえることに喜びを10genは感じているからです。きっと彼らはここ数年のうちに進化を続けることでしょう。またそれは、アプリケーション開発者にとって作業をもっと簡単にしてくれるでしょう」
なるほど…何も考えず＆気にかけることなく普通に使える裏側では、こんなにも苦労されていたんですね。何もしてないにもかかわらず、なんだか親近感＆愛着がふつふつとわいてきちゃいました！これを知ったからには、もっと活用していかないといけませんね。
さて！次は、いよいよ本陣の10gen社に突撃訪問です！
