第14回 オープンソーステクノロジー勉強会（at GREE）
「モバイルフレームワーク MobaSiF」
ディー・エヌ・エー 川崎修平さん（リンク）
- MobaSiFは先々月開発
- 博士課程のときにオークション大好きでいろいろやってたら南場さんに呼ばれてバイトからそのまま入社
- 昔と比べて携帯サービス開発は楽になった
- HTML返すだけだったら固有の問題なし
- ドコモは公式サイトでないと端末認証できなかった。一時的にセッションIDで引き回し
- 今はiモードid取れる
- 昔はロジックで絵文字変換。今は一括して外字で扱える
- gifやtableタグも使えるようになった
- キャッシュサイズ拡大。一律100KまでOK
- 昔は液晶の発色が悪く、機種ごとに色調変えていた。最近はPCサイトと同じような感じでOK
- 今でもFlashやアプリ、動画は機種依存
- iモードidは使い方にクセがある。formではpostとgetで書き方違う
- movaはxhtml使えない。背景色指定できない
- 901、701はtableタグが使えない
- CDMA 1X、ソフトバンクの古いのとか
- モバイルいやだってなかなか人が来てくれない。「JS動かないしめんどくさい」とか言われる。楽しいのに
- で、MobaSiF
- DeNAのモバイルサービスで使われているフレームワークから共通部分を整理したもの
- 基本思想
- 気軽にサービス作れる。運良く成功したら簡単にスケールできる
- モバオクは「オークション作ってみない？」「じゃ作ってきます」みたいな感じだった
- 複雑になりすぎない。軽め、浅めに作った
- 全体の動きを把握して作ってね、というもの。開発者が運用まで想定する。DBのパフォーマンス念頭に開発できる人が使う
- フレームワークもアプリの一部として変えていくのが前提
- 特徴
- 機能は端末認証、絵文字、キャリア判別など
- 軽い
- テンプレートの処理、地図の描画、アバターとかはCで書いたXSモジュールで
- プロセス起動時は最低限の読み込みで起動コスト抑えている
- シンプルな実装。そのほうが障害対応が楽。緊急の変な変更とかの融通が利く
- 依存モジュールが少ない。環境の変化に強い
- VMのバージョンで動かない、動くハードがないとかいうことが過去にあった
- 不可解な動きが少ない
- 動作環境はある程度縛る。linux、mysql、apache、fastcgi
- 対応端末は割り切り。FOMA900以降、WIN、3GC型
- これで漏れるのは会員の1％程度
- 新規サービスなら割り切っていい
- 基本機能
- ディスパッチャ
- メインループ。200行くらい。ユーザー情報から処理を実行
- 携帯電話情報取得
- UAと接続元IPから偽装かどうかを判別
- ドコモはヘッダ情報少ない。機種名からDBに格納した情報を呼び出す
- 絵文字変換
- テンプレート処理
- 事前コンパイル方式
- 軽くできるところは軽くしておこう
- テンプレートツールキットより20倍くらい速い
- 機能は最小限
- 静的なページも動的に生成している
- Webアプリ以外での使用も重視
- batch、daemon、監視スクリプトにも利用
- use MobaConf;で全機能にアクセスできる
- モバなんとかのサービスは非同期の処理多い
- 更新サーバーでまとめてDB書き込み
- daemon作りやすい
- モバゲーのフレームワークとほとんど一緒
- 違うところ
- メール送受信の部分を削除
- セキュリティ的に見せられないところを削除
- docomoの認証
- 絵文字取り回し向上
- 誤字訂正。「キャリア」の綴りを間違えてた
- 課題
- ビューの割合が多いページがDBアクセス多い。フレームワークを速くしても効果が薄い
- システム全体が巨大になって修正が危険に。いじりにくくなってきた。うまいぐあいに結合を分けたい
- 大人数の開発になるとコード品質のばらつきに弱い
- UTF8への移行
- DBだけで500台。それを全部変換するのも現実的じゃないしなー
- 質疑応答
- 非同期であとでDBに書き込むというやり方悩むのは、プロセスのキックを何にするか
- Webサーバーでローカルでキュー書き出し
- 専用のデーモンで更新サーバーに送り出し
- ファイルがあったら処理。バッチの場合もデーモンの場合も
- ファイル監視で取り漏れない？
- ないように書く。変な人が書くとあるかも
- デプロイ。DB変更ある場合の工夫ある？
- このへん直したいというのある？（ふじもとさん）
- 文字コード周り。mysql5ではいびつなことしなきゃなんなかったり
- 最近のはやりに追従するのは微妙。O/Rマッパーとか使わないし
- （ふじもとさんも）UTF8で作っときゃよかったと死ぬほど思ってる
- 愛用のCPANモジュールは？
- DBIくらい。ほとんど追加で入れてない。中の人間から「こんなのも入ってない」といやがられてる
- コードのばらつきは？
- ノリで作ったところからすごい大きくなったのでコーディングルールも決まってない
- 正しい書き方から遠いけど、この場合はこっちが正解、みたいな空気が読めれば
- だんだん空気感が伝わらなくなってきている。そういうコードが増えてくるとどれが本流の空気かもわからなくなる
- 地道にルール作っていかないと
- テストのやり方も人によって違う。事故が起こるとアレなのでなんとかしないと
- 非同期キューをファイルに書いてるのはなぜ？
- すごいこだわりはないが極力シンプルに
- 比較的軽めな情報に使っている。ファイルベースのほうが障害のリカバリがわかりやすい。現場ベースで柔軟にできる
- ヘッダ情報でわからない端末情報はDBから、のポリシーは？
- プロセスごとにキャッシュ
- 端末情報はエンジニアがSQLたたいて手で入れてるのでファイルベースでもいいんだけど
- XS使ってるけどPerlとCの使い分けは？
- ベンチとって割合が大きくてどの処理でも使う部分をXSに
- あんまり使われなくてもXSで書きたかったものもある（笑）
- DB500台の管理はインフラ側 or フレームワーク側？
- フレームワーク側というよりプログラム側でやってる
- 日記でもid別に分けるとか。半分くらいプログラム側で。コールする側変えてとか
- インフラ周りはほぼ標準
