第一回 納涼もんご祭り
SIer だってMongoDB できたよ!
株式会社ミライト情報システムオープンソリューション技術本部
第一回 納涼もんご祭り 2
ミライト情報システムについて
2012 年 7 月 1 日発足
「ミライト」は Mirai + IT の造語
IT と技術で作る未来の通信、未来の暮らし。
企業スローガン「 OPEN THE NEXT! 」
私たちは、オープンシステムでお客様の「次」を拓きます
ミライト・テクノロジーズ
株式会社ミライト情報システム
2012 年 7 月 1 日~
2012 年 10 月 1 日~
ミライト・ホールディングス
第一回 納涼もんご祭り 3
オープンソリューション技術本部
オープンスタンダード、オープンソースを活用して
素早く高品位なソリューションを提供する
https://www.miraitsystems.jp/
第一回 納涼もんご祭り 4
MongoDB と MIS
ちょっとしたお付き合いで MongoDB の調査をはじめる
ちょうど MongoDB Casual Talks が行われたころhttp://www.zusaar.com/event/312159
すごい dis られよう……だけど、実際は?
10gen のセミナー受講したり
MongoDB Tokyo December 2012 出たり
ドキュメント指向とレプリカセットはクール!
けど、オートシャーディングは……うーん
第一回 納涼もんご祭り 5
そもそも論として
我々は(曲がりなりにも) SIer なのです
お客様の要件を聞いて見積り出して仕事する
MongoDB のシステムは規模感をつかみにくい
総予算が見積もりにくい←コレ辛い!
スケールアップとかスケールアウトとか許されないことも
特にオートシャーディング
教科書的には:よいシャードキーを選ぶにはデータの性質をよく知る
でも商談成立前にデータくれるお客さんとか稀だしね
ぶっちゃけ売りにくいなあ~というのが感触
第一回 納涼もんご祭り 6
だ・け・ど
NoSQL 全般にいえることだけど「万能選手じゃないけど尖ったところがある」 MongoDB は面白い!
我々は PostgreSQL については十分なノウハウがあるので、違うストレージエンジンを弾に持っておくのは損じゃない
とにかく案件を獲得して経験値を得よう!
そのためには「売りやすい要素」を見つけて一緒に挑戦してくれるお客さんを探そう!
じゃあ、「売りやすい要素」ってなんかある!
レプリカセットだ! 高可用性で攻めよう!レプリカセットだ! 高可用性で攻めよう!
第一回 納涼もんご祭り 7
チャンス到来!
とある案件の相談が
アクセスはそんなに多くない。
パフォーマンスはさほど重視しない
データボリュームもめちゃくちゃは大きくない
ただデータがロストするのは困る←ただデータがロストするのは困る←
仲がいいお客さんなので多少のチャレンジは OK 。
第一回 納涼もんご祭り 8
さっそく提案!
「 MongoDB なら可用性はばっちり!」
「将来サービスが拡張する可能性があるなら AWS に載せちゃいましょう!」
「パフォーマンスを要求しないなら最初は低予算で行けるはずです!」
「 AWS+MongoDB なら無停止でバックアップも行けるはずです!」……たぶん。
第一回 納涼もんご祭り 9
さっそく提案!
「 MongoDB なら可用性はばっちり!」
「将来サービスが拡張する可能性があるなら AWS に載せちゃいましょう!」
「パフォーマンスを要求しないなら最初は低予算で行けるはずです!」
「 AWS+MongoDB なら無停止でバックアップも行けるはずです!」……たぶん。
………… 提案通っちゃった!提案通っちゃった!
第一回 納涼もんご祭り 10
鉛筆なめなめ構成立案 (1)MongoDB側は普通に三台構成
EIP を振ってシステムダウン時の対応を容易に
アプリが conf ファイルコンパイル時に抱き込んじゃうから IP変わっちゃうと色々めんどくさい
/var/lib/mongodb は別 EBS にしてスナップショットを取りやすく
監視は MMS と CloudWatch の併用
監視項目はまあお約束なところで……
Mongo っぽい部分は MMS にまかせてしまう
現在 CloudWatch Monitoring Script が動かなくて苦戦中(だれか教えて!)
第一回 納涼もんご祭り 11
鉛筆なめなめ構成立案 (2)アプリ側は ELB利用で二重化
といっても永続データは全部 MongoDB に格納
なんかあったら問答無用で外部からリブート
今のところはオートスケールとかはやらない
こっち側は比較的シンプルな構成
で、こんな感じ
第一回 納涼もんご祭り 13
アプリケーション側の話をちょっと
開発体制 我らがボスWebアプリの開発経験は豊富超忙しいのが難点
中途入社のおっさんWebとかよく知らないオープンソース界隈をうろうろとMongoDB推進担当w
Scalaでの製品開発 2 年Play! ……勉強中 だったはずが 社内案件でいきなり実戦投入wanomで SQLベタ書きがしんどいお年頃
入社2年目・配属後1年のピチピチ教えれば何でもこなす優等生Scala + Play!が人生初のWebアプリ
Developers
Manager
Architect / Researcher
第一回 納涼もんご祭り 14
す…… Scala だと……
Java VM上で動くオブジェクト指向関数型関数型言語
作った人: Martin Odersky関数型言語と型理論オタク
でもオブジェクト指向大好き
Java に Generics突っ込んだ共犯者
Java で関数型的なことができるかずっと頑張ってた
でも見切りつけて開発したのが Scala
ぶっちゃけいって、 SIer で使う言語じゃないですねw
第一回 納涼もんご祭り 15
でも Scala は結構 SIer にもいいのよ
Java のめんどくさい部分が結構サボれる
import文が楽だったり
強力な型推論で型宣言サボれたり
無精者向けの無精者向けの JavaJava っぽい感じで使える
さらに Scala っぽい機能を使うとよりエレガントに
書き換え不可な値 val と書き換え可な値 var
for comprehension によるリスト処理
case class とパターンマッチ
コンパニオンオブジェクト などなど……
第一回 納涼もんご祭り 16
Scala の難点(?)
言語機能がとてもいっぱいあるので、常に
違う……Scalaの本当の能力はこんなものじゃない!
感と戦う必要がある
「知ってる機能で書ければいいや」と割り切れば思ってるほど敷居は高くないですよ
どっちかというとコンパイルがゲロ遅なほうが……げふんげふん
ち か ら
第一回 納涼もんご祭り 17
なんで Scala にしたの?
開発人員の手がたまたま空いてたから
というのはまあ一面本当なんですが
Scala (/Java) のフレームワーク Play! が結構シンプルで使い勝手が良かった
我々は Rails の開発部隊もいるんですが、 Rails に比べると O/R マッパーありきの作りじゃないので、 MongoDB にしたからといってそんなに大変じゃない
MongoDB のドライバーは公式の Casbah を使った
第一回 納涼もんご祭り 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.newBuilderbuilder += "name" -> "Scala scalable programming"builder += "author" -> [ "Martin Odersky", "Lex Spoon", "Bill Venners" ]builder += "year" -> 2011val book = builder.result
第一回 納涼もんご祭り 19
実際の開発はこんな感じ
役割分担 渉外対応仕様切ったりなんだり進捗管理したり
AWS側の構造決定MongoDBスキーマデザインの基礎を 伝えたり、あとレビューとかScalaとか書けないのでぐぐりつつ Casbahのサンプルコードを書くなど
開発の主体Play+Scalaらしいコードをもりもり開発アーキテクトのしょぼいサンプルをかっこよく 直して取り込む
MongoDBスキーマデザイン担当 mongo shellでお試しして 狙ったクエリーができるかとか調べる比較的単純なロジックや JS周りの開発
Developers
Manager
Architect / Researcher
第一回 納涼もんご祭り 20
どんぐらい苦労した?
詳しい数字は秘密♡
でもン十人月とかそういうオーダーではないです
期間だけで言えば構想からリリースまで2ヶ月ぐらい?
おどろくほどカジュアルにできちゃってびっくり
Scala + Play! は割と身軽に使えて良い感じ
それに MongoDB + Casbah は割といい組み合わせ
スキーマレスなので作りながら考えることが許される
第一回 納涼もんご祭り 21
もんごっぽいこぼれ話
今回ビットマップデータのアップロード機能あり
でもアプリサーバーにはデータを置きたくない
GridFS使ったよ。けっこう楽ちん
コネクションをいつ張っていつ切る?
Play! はステートレス指向なので(多分)セッション毎にやる方法が見つからなかった(ぉ
ので今はクエリー(=Modelへのリクエスト)毎に張った切ったしてる
こうやるといいよ! って知ってる人教えてね(こらこら
でも基本的にはほとんど悩むことはなかった
第一回 納涼もんご祭り 22
まとめ
SIer でも MongoDB できたよ! という話
多分可用性が求められる小さな案件可用性が求められる小さな案件からスタートするのが良い感じではないかと
当然トランザクションがある処理は RDBMS の方がいい
選択肢を持ったということが重要
でもまだまだ経験値が足りないので徐々にスケールを増して行きたい
我々の部署には Rails エンジニアも多数いるので Mongoid とかも将来的には使ってみたい
部署外への輸出も……できるかな?
第一回 納涼もんご祭り 23
以上!
なんかあったらブース番に質問してね!
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.
Top Related