LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog

Blog


「第6回 MongoDB 勉強会 in Tokyo」で話しました

どうもこんにちは。検索サービス開発室にて非イケメン枠を担当している大平です。
twitterでは「@just_do_neet」と名乗っていますが、実際はさだまさしと自転車が好きな、ごく普通のサラリーマンエンジニアです。

さて、先日開催されました「第6回 MongoDB 勉強会 in Tokyo」にて、機会をいただき僭越ながら発表をさせていただきました。

7月末にリリースした「NAVER Photo Album」という写真共有アプリにてMongoDBを用いたという事もあり、テクニカルな方面に深掘りした内容よりも実践的なTipsの方が良いかなと思い、事例紹介という文脈で発表をさせていただきました。

発表させていただいた資料は以下になります。

事例:とある写真共有アプリでのMongoDB

View more presentations from NAVER Japan

構成としては3章立てです。仔細については資料を見ていただくとして、ざっくりご紹介すると以下のテーマについて話しました。

  1. MongoDBを用いたデータの設計・モデリングに関わる話
  2. 実際の運用時に気をつけなければいけない話
  3. scalabilityを売りにした他ミドルウェア(HBase)との性能・特徴比較の話

ひとつづつ感想戦的に補足をします。

MongoDBのデータ設計

スキーマレスなデータ構造を持つのがMongoDBの特徴なので、様々な具象性をもつデータを一括りにして扱いたい場合や、とりあえずデータを放りこんでおいてどう使うか(データのスキーマをどう考えるか)は後回しにしたい場合など、非常にMongoDBのようなデータベースは便利に使えると思います。

今回の事例としては、複雑で多様なユーザーの行動を「アクティビティフィード」という形でデータ的にも一括りに扱いたい、というアプリケーション側の需要に合致したため、MongoDBは非常にマッチした案件だったと思っています。

ただ、

  • トランザクション機能が無い
  • ドキュメントの同一性の判定機能が弱い(_id が重複しなければ、それ以外が同じなデータのN重登録を抑制する方法が無い) 
  • データが肥大化する

といった点を気をつけて採用を行なう必要があると思います。特に上2つについては、厳密なアプリケーションでは致命的な欠陥につながります。同時書き込みが多く発生し、かつデータの厳格性・一意性が非常に強く求められるようなプロジェクトでは、MongoDBの使用は茨の道になりそうな感触を個人的には持っています。

今回のPhotoAlbumでは

  • 書き込みは非同期(ユーザー行動発生時にQueueingサーバーに登録。MongoDBへの登録を行なうのはDequeue処理を行なうbatchのみ) 
  • 定期的にデータのrepair処理を行なうbatchを用意し、データのズレが発生したら補正する。
  • たとえデータが全部飛んでも大丈夫・・(他のトランザクショナルなDB ※MySQL※ から復元できる)

 という感じで、データ書き込み処理の並列性は高くなく、データの厳格性についてもそれほど必要無いような状況で運用しており、先に挙げたような懸念点をあまり気にしなくて良いような環境にしています。

運用Tips

実際に運用時に気をつけた事を記載しましたが、内容的には「後で資料を見ておいてね」でもよかったかもしれません。(この時間帯はオーディエンスの方々も眠そうな人が多かったです..笑)

資料中に項としては最後に書いていますが見落としがちでインパクトが大きそうなのがセキュリティです。
セキュリティ周りは勉強会主催者の井上様も触れられていましたがMongoDBは現状非常に弱いです。こちらの検証を行わず導入を進めてしまうと、直前で社内のセキュリティポリシーに合致しないため採用却下というようなケースも起こり得そうなので注意が必要ですね。

HBaseとの比較

正直なところ ユースケースが違うのでHBaseとMongoDBの性能を純粋に比較するのはあまり意味が無いとは思います。こちらについては参考程度に見ておいてください。

MongoDBは小規模でも大規模でも運用可能なパワフルな機能を持ったドキュメント指向DBだが、Consistencyは非常に弱い(CAPで言うAPを重視)

HBaseは基本的には大規模での運用を考慮して作られた列指向DBで、Strong Consistencyを持つがSPoFがある(CAPで言うCPを重視)

そういった特徴を無視してまで特定のシチュエーションでのBenchmarkの性能結果を元にミドルウェアの採用を行なう必要は個人的には無いと思っています。
それぞれ、ミドルウェアの特徴にあわせて、適正な場所で使用する事を心がけるのが一番良いのではないかと思います。

なお、本資料に記載しているHBaseのチューニングの内容をもっと深掘りして本記事に記載しようと思ったのですが、ちょっと長文になってしまったのでそちらはまたの機会にご紹介できればと思います。

まとめに代えて

自腹で購入したMongoDB マグカップ

発表資料末尾にも書きましたが、MongoDBの、特に日本のコミュニティは非常に強力で、我々開発者にとっては心強い存在です。少しでも今回の発表内容がMongoDBのコミュニティ、そしてこれからMongoDBを用いて開発をしようと考えておられる技術者の方々のお役に立てれば幸いです。

来年には日本で二回目となるMongoDBのカンファレンスが開催されるとの話も聞いておりますので、そちらにも是非参加させていただき、何かレポート記事でもこのブログで書くことができればいいな、などと思っております。