case study to use mongodb in middle-class sier / (中規模) sierだってmongodbできたよ！

第一回納涼もんご祭り

SIer だってMongoDB できたよ！

株式会社ミライト情報システムオープンソリューション技術本部

第一回納涼もんご祭り 2

ミライト情報システムについて

2012 年 7 月 1 日発足

「ミライト」は Mirai + IT の造語

IT と技術で作る未来の通信、未来の暮らし。

企業スローガン「 OPEN THE NEXT! 」

私たちは、オープンシステムでお客様の「次」を拓きます

ミライト・テクノロジーズ

株式会社ミライト情報システム

2012 年 7 月 1 日～

2012 年 10 月 1 日～

ミライト・ホールディングス


オープンソリューション技術本部

オープンスタンダード、オープンソースを活用して

素早く高品位なソリューションを提供する

https://www.miraitsystems.jp/

https://www.miraitsystems.jp/


MongoDB と MIS

ちょっとしたお付き合いで MongoDB の調査をはじめる

ちょうど MongoDB Casual Talks が行われたころhttp://www.zusaar.com/event/312159

すごい dis られよう……だけど、実際は？

10gen のセミナー受講したり

MongoDB Tokyo December 2012 出たり

ドキュメント指向とレプリカセットはクール！

けど、オートシャーディングは……うーん

http://www.zusaar.com/event/312159


そもそも論として

我々は（曲がりなりにも） SIer なのです

お客様の要件を聞いて見積り出して仕事する

MongoDB のシステムは規模感をつかみにくい

総予算が見積もりにくい←コレ辛い！

スケールアップとかスケールアウトとか許されないことも

特にオートシャーディング

教科書的には：よいシャードキーを選ぶにはデータの性質をよく知る

でも商談成立前にデータくれるお客さんとか稀だしね

ぶっちゃけ売りにくいなあ～というのが感触


だ・け・ど

NoSQL 全般にいえることだけど「万能選手じゃないけど尖ったところがある」 MongoDB は面白い！

我々は PostgreSQL については十分なノウハウがあるので、違うストレージエンジンを弾に持っておくのは損じゃない

とにかく案件を獲得して経験値を得よう！

そのためには「売りやすい要素」を見つけて一緒に挑戦してくれるお客さんを探そう！

じゃあ、「売りやすい要素」ってなんかある！

レプリカセットだ！高可用性で攻めよう！レプリカセットだ！高可用性で攻めよう！


チャンス到来！

とある案件の相談が

アクセスはそんなに多くない。

パフォーマンスはさほど重視しない

データボリュームもめちゃくちゃは大きくない

ただデータがロストするのは困る←ただデータがロストするのは困る←

仲がいいお客さんなので多少のチャレンジは OK 。


さっそく提案！

「 MongoDB なら可用性はばっちり！」

「将来サービスが拡張する可能性があるなら AWS に載せちゃいましょう！」

「パフォーマンスを要求しないなら最初は低予算で行けるはずです！」

「 AWS+MongoDB なら無停止でバックアップも行けるはずです！」……たぶん。


さっそく提案！

「 MongoDB なら可用性はばっちり！」

「将来サービスが拡張する可能性があるなら AWS に載せちゃいましょう！」

「パフォーマンスを要求しないなら最初は低予算で行けるはずです！」

「 AWS+MongoDB なら無停止でバックアップも行けるはずです！」……たぶん。

………… 提案通っちゃった！提案通っちゃった！


鉛筆なめなめ構成立案 (1)MongoDB側は普通に三台構成

EIP を振ってシステムダウン時の対応を容易に

アプリが conf ファイルコンパイル時に抱き込んじゃうから IP変わっちゃうと色々めんどくさい

/var/lib/mongodb は別 EBS にしてスナップショットを取りやすく

監視は MMS と CloudWatch の併用

監視項目はまあお約束なところで……

Mongo っぽい部分は MMS にまかせてしまう

現在 CloudWatch Monitoring Script が動かなくて苦戦中（だれか教えて！）


鉛筆なめなめ構成立案 (2)アプリ側は ELB利用で二重化

といっても永続データは全部 MongoDB に格納

なんかあったら問答無用で外部からリブート

今のところはオートスケールとかはやらない

こっち側は比較的シンプルな構成

で、こんな感じ


アプリケーション側の話をちょっと

開発体制我らがボスWebアプリの開発経験は豊富超忙しいのが難点

中途入社のおっさんWebとかよく知らないオープンソース界隈をうろうろとMongoDB推進担当ｗ

Scalaでの製品開発 2 年Play! ……勉強中だったはずが　　　社内案件でいきなり実戦投入ｗanomで SQLベタ書きがしんどいお年頃

入社２年目・配属後１年のピチピチ教えれば何でもこなす優等生Scala + Play!が人生初のWebアプリ

Developers

Manager

Architect / Researcher


す…… Scala だと……

Java VM上で動くオブジェクト指向関数型関数型言語

作った人： Martin Odersky関数型言語と型理論オタク

でもオブジェクト指向大好き

Java に Generics突っ込んだ共犯者

Java で関数型的なことができるかずっと頑張ってた

でも見切りつけて開発したのが Scala

ぶっちゃけいって、 SIer で使う言語じゃないですねｗ


でも Scala は結構 SIer にもいいのよ

Java のめんどくさい部分が結構サボれる

import文が楽だったり

強力な型推論で型宣言サボれたり

無精者向けの無精者向けの JavaJava っぽい感じで使える

さらに Scala っぽい機能を使うとよりエレガントに

書き換え不可な値 val と書き換え可な値 var

for comprehension によるリスト処理

case class とパターンマッチ

コンパニオンオブジェクトなどなど……


Scala の難点（？）

言語機能がとてもいっぱいあるので、常に

違う……Scalaの本当の能力はこんなものじゃない！

感と戦う必要がある

「知ってる機能で書ければいいや」と割り切れば思ってるほど敷居は高くないですよ

どっちかというとコンパイルがゲロ遅なほうが……げふんげふん

ち　か　ら


なんで Scala にしたの？

開発人員の手がたまたま空いてたから

というのはまあ一面本当なんですが

Scala (/Java) のフレームワーク Play! が結構シンプルで使い勝手が良かった

我々は Rails の開発部隊もいるんですが、 Rails に比べると O/R マッパーありきの作りじゃないので、 MongoDB にしたからといってそんなに大変じゃない

MongoDB のドライバーは公式の Casbah を使った


Casbah どうよ？

んー、 Java のフレームワークよかはずっとマシだけど……

Scala は Hash の K → V の V の型が一致してないといけないので、 JSON っぽくサラっと書けない

MongoDBObject オブジェクトを組み立てないといけないので少し面倒

Builder と '+=' 演算子とか使って少しは楽できるけどJSON

var book = { name: "Scala scalable programming", author: [ "Martin Odersky", "Lex Spoon", "Bill Venners" ], year: 2011}

Scala + Casbah

val builder = MongoDBObject.newBuilderbuilder += "name" -> "Scala scalable programming"builder += "author" -> [ "Martin Odersky", "Lex Spoon", "Bill Venners" ]builder += "year" -> 2011val book = builder.result


実際の開発はこんな感じ

役割分担渉外対応仕様切ったりなんだり進捗管理したり

AWS側の構造決定MongoDBスキーマデザインの基礎を　伝えたり、あとレビューとかScalaとか書けないのでぐぐりつつ Casbahのサンプルコードを書くなど

開発の主体Play+Scalaらしいコードをもりもり開発アーキテクトのしょぼいサンプルをかっこよく　直して取り込む

MongoDBスキーマデザイン担当　mongo shellでお試しして　狙ったクエリーができるかとか調べる比較的単純なロジックや JS周りの開発

Developers

Manager

Architect / Researcher


どんぐらい苦労した？

詳しい数字は秘密♡

でもン十人月とかそういうオーダーではないです

期間だけで言えば構想からリリースまで２ヶ月ぐらい？

おどろくほどカジュアルにできちゃってびっくり

Scala + Play! は割と身軽に使えて良い感じ

それに MongoDB + Casbah は割といい組み合わせ

スキーマレスなので作りながら考えることが許される


もんごっぽいこぼれ話

今回ビットマップデータのアップロード機能あり

でもアプリサーバーにはデータを置きたくない

GridFS使ったよ。けっこう楽ちん

コネクションをいつ張っていつ切る？

Play! はステートレス指向なので（多分）セッション毎にやる方法が見つからなかった（ぉ

ので今はクエリー（＝Modelへのリクエスト）毎に張った切ったしてる

こうやるといいよ！って知ってる人教えてね（こらこら

でも基本的にはほとんど悩むことはなかった


まとめ

SIer でも MongoDB できたよ！　という話

多分可用性が求められる小さな案件可用性が求められる小さな案件からスタートするのが良い感じではないかと

当然トランザクションがある処理は RDBMS の方がいい

選択肢を持ったということが重要

でもまだまだ経験値が足りないので徐々にスケールを増して行きたい

我々の部署には Rails エンジニアも多数いるので Mongoid とかも将来的には使ってみたい

部署外への輸出も……できるかな？


以上！

なんかあったらブース番に質問してね！

4.0 で作成いたしました。

marks to export the 100px bitmap

For larger sizes export the page and scale it appropriately.

The background consists of a white rectangle with opacity=0. If you want to select it, switch to layer "Background" and use [TAB] until you get the object you want to select.

The trademark symbol is part of a dedicated layer. Turn it visible/invisible depending on your needs.

case study to use mongodb in middle-class sier / (中規模) sierだってmongodbできたよ！

Documents