In Japanese: 「納涼もんご祭り」のミライト情報システム（ぼくの所属企業です）のブースで流してたスライドショウです。……ちゃんと上司の許可は取りましたのでご安心を？

1. 第一回 納涼もんご祭り
SIer だって
MongoDB できたよ！
株式会社ミライト情報システム
オープンソリューション技術本部

2. 第一回 納涼もんご祭り 2
ミライト情報システムについて
2012 年 7 月 1 日発足
「ミライト」は Mirai + IT の
造語
IT と技術で作る未来の
通信、未来の暮らし。
企業スローガン
「 OPEN THE NEXT! 」
私たちは、オープンシス
テムでお客様の「次」を
拓きます
ミライト・テクノロジーズ
株式会社ミライト情報システム
2012 年 7 月 1 日～
2012 年 10 月 1 日～
ミライト・
ホールディングス

3. 第一回 納涼もんご祭り 3
オープンソリューション技術本部
オープンスタンダード、オープンソースを活用して
素早く高品位なソリューションを提供する
https://www.miraitsystems.jp/

4. 第一回 納涼もんご祭り 4
MongoDB と MIS
ちょっとしたお付き合いで MongoDB の調査をはじめる
ちょうど MongoDB Casual Talks が行われたころ
http://www.zusaar.com/event/312159
すごい dis られよう……だけど、実際は？
10gen のセミナー受講したり
MongoDB Tokyo December 2012 出たり
ドキュメント指向とレプリカセットはクール！
けど、オートシャーディングは……うーん

5. 第一回 納涼もんご祭り 5
そもそも論として
我々は（曲がりなりにも） SIer なのです
お客様の要件を聞いて見積り出して仕事する
MongoDB のシステムは規模感をつかみにくい
総予算が見積もりにくい←コレ辛い！
スケールアップとかスケールアウトとか許されないことも
特にオートシャーディング
教科書的には：よいシャードキーを選ぶにはデータの性質をよく知る
でも商談成立前にデータくれるお客さんとか稀だしね
ぶっちゃけ売りにくいなあ～というのが感触

6. 第一回 納涼もんご祭り 6
だ・け・ど
NoSQL 全般にいえることだけど「万能選手じゃないけど尖ったところ
がある」 MongoDB は面白い！
我々は PostgreSQL については十分なノウハウがあるので、違うスト
レージエンジンを弾に持っておくのは損じゃない
とにかく案件を獲得して経験値を得よう！
そのためには「売りやすい要素」を見つけて一緒に挑戦してくれるお客
さんを探そう！
じゃあ、「売りやすい要素」ってなんかある！
レプリカセットだ！ 高可用性で攻めよう！レプリカセットだ！ 高可用性で攻めよう！

7. 第一回 納涼もんご祭り 7
チャンス到来！
とある案件の相談が
アクセスはそんなに多くない。
パフォーマンスはさほど重視しない
データボリュームもめちゃくちゃは大きくない
ただデータがロストするのは困る←ただデータがロストするのは困る←
仲がいいお客さんなので多少のチャレンジは OK 。

8. 第一回 納涼もんご祭り 8
さっそく提案！
「 MongoDB なら可用性はばっちり！」
「将来サービスが拡張する可能性があるなら AWS に載せちゃいま
しょう！」
「パフォーマンスを要求しないなら最初は低予算で行けるはずです！」
「 AWS+MongoDB なら無停止でバックアップも行けるはずです！」
……たぶん。

9. 第一回 納涼もんご祭り 9
さっそく提案！
「 MongoDB なら可用性はばっちり！」
「将来サービスが拡張する可能性があるなら AWS に載せちゃいま
しょう！」
「パフォーマンスを要求しないなら最初は低予算で行けるはずです！」
「 AWS+MongoDB なら無停止でバックアップも行けるはずです！」
……たぶん。
………… 提案通っちゃった！提案通っちゃった！

10. 第一回 納涼もんご祭り 10
鉛筆なめなめ構成立案 (1)
MongoDB 側は普通に三台構成
EIP を振ってシステムダウン時の対応を容易に
アプリが conf ファイルコンパイル時に抱き込んじゃうから IP 変わっちゃうと色々め
んどくさい
/var/lib/mongodb は別 EBS にしてスナップショットを取りやすく
監視は MMS と CloudWatch の併用
監視項目はまあお約束なところで……
Mongo っぽい部分は MMS にまかせてしまう
現在 CloudWatch Monitoring Script が動かなくて苦戦中（だれか教えて！）

11. 第一回 納涼もんご祭り 11
鉛筆なめなめ構成立案 (2)
アプリ側は ELB 利用で二重化
といっても永続データは全部 MongoDB に格納
なんかあったら問答無用で外部からリブート
今のところはオートスケールとかはやらない
こっち側は比較的シンプルな構成

12. で、こんな感じ

13. 第一回 納涼もんご祭り 13
アプリケーション側の話をちょっと
開発体制 我らがボス
Web アプリの開発経験は豊富
超忙しいのが難点
中途入社のおっさん
Web とかよく知らない
オープンソース界隈をうろうろと
MongoDB 推進担当ｗ
Scala での製品開発 2 年
Play! ……勉強中 だったはずが
社内案件でいきなり実戦投入ｗ
anom で SQL ベタ書きがしんどいお年頃
入社２年目・配属後１年のピチピチ
教えれば何でもこなす優等生
Scala + Play! が人生初の Web アプリ
Developers
Manager
Architect / Researcher

14. 第一回 納涼もんご祭り 14
す…… Scala だと……
Java VM 上で動くオブジェクト指向関数型関数型言語
作った人： Martin Odersky
関数型言語と型理論オタク
でもオブジェクト指向大好き
Java に Generics 突っ込んだ共犯者
Java で関数型的なことができるかずっと頑張ってた
でも見切りつけて開発したのが Scala
ぶっちゃけいって、 SIer で使う言語じゃないですねｗ

15. 第一回 納涼もんご祭り 15
でも Scala は結構 SIer にもいいのよ
Java のめんどくさい部分が結構サボれる
import 文が楽だったり
強力な型推論で型宣言サボれたり
無精者向けの無精者向けの JavaJava っぽい感じで使える
さらに Scala っぽい機能を使うとよりエレガントに
書き換え不可な値 val と書き換え可な値 var
for comprehension によるリスト処理
case class とパターンマッチ
コンパニオンオブジェクト などなど……

16. 第一回 納涼もんご祭り 16
Scala の難点（？）
言語機能がとてもいっぱいあるので、常に
違う……
Scala の本当の能力は
こんなものじゃない！
感と戦う必要がある
「知ってる機能で書ければいいや」と割り切れば思ってるほど敷居は
高くないですよ
どっちかというとコンパイルがゲロ遅なほうが……げふんげふん
ち か ら

17. 第一回 納涼もんご祭り 17
なんで Scala にしたの？
開発人員の手がたまたま空いてたから
というのはまあ一面本当なんですが
Scala (/Java) のフレームワーク Play! が結構シンプルで使い勝手が
良かった
我々は Rails の開発部隊もいるんですが、 Rails に比べると O/R マッ
パーありきの作りじゃないので、 MongoDB にしたからといってそんなに
大変じゃない
MongoDB のドライバーは公式の Casbah を使った

18. 第一回 納涼もんご祭り 18
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.newBuilder
builder += "name" -> "Scala scalable programming"
builder += "author" -> [ "Martin Odersky",
"Lex Spoon",
"Bill Venners" ]
builder += "year" -> 2011
val book = builder.result

19. 第一回 納涼もんご祭り 19
実際の開発はこんな感じ
役割分担 渉外対応
仕様切ったりなんだり
進捗管理したり
AWS 側の構造決定
MongoDB スキーマデザインの基礎を
伝えたり、あとレビューとか
Scala とか書けないのでぐぐりつつ
Casbah のサンプルコードを書くなど
開発の主体
Play+Scala らしいコードをもりもり開発
アーキテクトのしょぼいサンプルをかっこよく
直して取り込む
MongoDB スキーマデザイン担当
mongo shell でお試しして
狙ったクエリーができるかとか調べる
比較的単純なロジックや JS 周りの開発
Developers
Manager
Architect / Researcher

20. 第一回 納涼もんご祭り 20
どんぐらい苦労した？
詳しい数字は秘密♡
でもン十人月とかそういうオーダーではないです
期間だけで言えば構想からリリースまで２ヶ月ぐらい？
おどろくほどカジュアルにできちゃってびっくり
Scala + Play! は割と身軽に使えて良い感じ
それに MongoDB + Casbah は割といい組み合わせ
スキーマレスなので作りながら考えることが許される

21. 第一回 納涼もんご祭り 21
もんごっぽいこぼれ話
今回ビットマップデータのアップロード機能あり
でもアプリサーバーにはデータを置きたくない
GridFS 使ったよ。けっこう楽ちん
コネクションをいつ張っていつ切る？
Play! はステートレス指向なので（多分）セッション毎にやる方法が見つ
からなかった（ぉ
ので今はクエリー（＝ Model へのリクエスト）毎に張った切ったしてる
こうやるといいよ！ って知ってる人教えてね（こらこら
でも基本的にはほとんど悩むことはなかった

22. 第一回 納涼もんご祭り 22
まとめ
SIer でも MongoDB できたよ！ という話
多分可用性が求められる小さな案件可用性が求められる小さな案件からスタートするのが良い感
じではないかと
当然トランザクションがある処理は RDBMS の方がいい
選択肢を持ったということが重要
でもまだまだ経験値が足りないので徐々にスケールを増して行きた
い
我々の部署には Rails エンジニアも多数いるので Mongoid とかも将来
的には使ってみたい
部署外への輸出も……できるかな？

23. 第一回 納涼もんご祭り 23
以上！
なんかあったらブース番に質問してね！
4.0 で作成いたしました。
marks to export the 100px bitmap