GREE株式会社で開催された「第14回オープンソーステクノロジー勉強会」に参加してきた。今回はなんと競合である「モバゲータウン」を運営する株式会社ディー・エヌ・エーのエンジニアを招聘する、という大胆な企画。先日オープンソースのwebアプリケーションフレームワークとして公開された「MobaSiF」についての話が聞けるというので、例によって仕事を放り出して参加してきた。

【リンク】
第14回 オープンソーステクノロジー勉強会 – GREE Labs
http://labs.gree.jp/Top/Study/20080708.html
　※当日使われたスライドを公開中

第14回オープンソーステクノロジー勉強会 －開催のご報告－ – GREE Labs
http://labs.gree.jp/Top/Study/20080708/Report.html

「モバゲー」を1人で開発した男 – DeNA 技師のメモ
http://d.hatena.ne.jp/tokiharu/20080225/1203932040
　※スピーカーのDeNA川崎さんについての記事リンクあり

2008年 2月の DeNA テクノロジーセミナースライド公開 – DeNA 技師のメモ
http://d.hatena.ne.jp/tokiharu/20080307/1204881160
　※質問があったことについての関連資料あり

2007.07.08 GreeLabs 第14回オープンソース勉強会
「モバイルフレームワーク MobaSiF」
スピーカー：川崎修平氏(株式会社ディー・エヌ・エー)

  • 携帯端末について

    • 昔と比べて携帯サービス開発は楽

      • 理由：
        • 勝手サイトでも端末認証できるようになった
        • 絵文字の扱いがだいぶ統一された
        • 画像フォーマットがgif / jpegでOKになった
        • タグの制約が減った
        • キャッシュサイズが大きく取れる
          …おおむね100KB取って大丈夫
        • 画面サイズ / 発色がリッチになった
      • それでもFlash / アプリ / 動画には機種別ノウハウが必要
      • モバイルサイトは敬遠する人もいるけど、やってみると楽しいよ
        • 制約が少なくなった
        • デザインパワーがいらないので独りで完結させられる

    • iモードID

      • リクエストラインに"guid=ON"クエリを乗せるとX_DCMGUIDヘッダが乗ってくる
      • フォームの場合は注意が必要
      <th>
  action
</th>

<th>
  hidden
</th>

      <td align="center">
  ×
</td>

<td align="center">
  ○
</td>

      <td align="center">
  ○
</td>

<td align="center">
  ×
</td>
      formメソッド
      get
      post

      • [action]…

      • [hidden]…

      • この記事で追求しきれていなかったのに思い当たって汗顔

    • 機種対応

      • 全キャリア3G端末以上
        • DoCoMo : FOMA 900i～
        • au : WIN
        • SoftBank : 3GC
      • 旧機種(mova / CDMA 1X / SoftBank W,C,P)
        • 認証、キャッシュサイズ、タグなど制限が大きい
        • モバオクでは会員数ベースで1%程度、PVならもっと下がる
        • 思い切って非対応にしてしまうのもあり
  • MobaSiFについて
    • MobaSiFとは / 基本思想
      • モバオク、ポケットアフィリエイト、モバゲータウン、モバコレ
        …DeNAのモバイルサービスの共通部分を抜き出して整理したもの
      • 気軽にサービス開始、成功したら簡単にスケールできる
      • 細かいところはこだわらない
      • 開発者はFW全体を把握して開発すべし
        複雑になり過ぎない。引継ぎしやすい。
      • 運用まで想定して開発しよう
        DBのパフォーマンスなども考慮して開発できるべき
      • サービスとともにFWも変化していく
    • 特徴
      • 軽い
        • パフォーマンスが必要なところはXSモジュール(アバタとか)
        • 起動コスト小 – apache / マシンのリスタート時に負荷をかけないように
      • 素朴な実装
        • 全体を理解しやすい
        • 融通が利く
      • 依存モジュールが少ない(ほとんど標準モジュール)
        • 環境の変化に強い
        • モジュールのバージョン固有不具合なんかにハマりにくい
      • 動作環境はある程度しばる
        …linux,mysql,apache,fastcgi
    • 基本機能
      • ディスパッチャ
      • 端末情報取得
      • ユーザ認証
      • 絵文字変換
      • テンプレート処理
      • 基本遷移
        …非会員は会員登録ルートとか
    • ディスパッチャ
      • モバイル用環境変数の設定
      • リクエストパラメータ取得
      • ユーザデータ取得
        …サービスによっていろいろ（ペナルティ、登録情報など）
      • ステータスチェック
      • モジュールロード
      • 処理実行
    • 端末情報取得
      • IPからキャリア
      • UAからキャリア / 端末タイプ / モデル名
      • 端末識別情報からユーザ情報
      • 画面サイズ
      • ※UAから取得できない端末固有の情報は機種名をキーにDBから引いてくる(Flash対応とか)
    • 絵文字変換
      • 内部はSJIS
        au / DoCoMoはそのまま、SoftBankは独自3byteコード
      • 絵文字はプログラマが意識しないで扱える
        • リクエスト取得時に内部コードに変換
        • ページ出力時端末に合わせて変換
    • テンプレートエンジン
      • 独自開発
      • 事前コンパイル
        共通テンプレートをコンパイルすると３キャリア分のバイナリを生成
      • 共有メモリ(mmap)で読み込むから高速
      • 必要最低限の機能
        …変数埋め込み、条件分岐、ループぐらい
      • 静的ページも動的生成
        …ユーザ情報を含めてテンプレートに渡るようにしてる
    • webアプリ以外での利用
      • batch / daemon / 監視スクリプトなど
      • use MobaConf ; でMobaSiFすべての機能が利用可能に
      • daemonについて
        • 更新情報など非同期処理
          …アプリがファイルキューに書く → daemonが更新サーバに送信、など
        • daemonを作りやすい仕組みが整備済み
    • モバゲー運用中のものとの違い
      • メール送受信
      • セキュリティ的に見せられないコード
      • iモードIDによる認証
      • 絵文字の取り回し
      • 誤字の訂正
        …“CAREER"とか / 運用中のじゃ直せないし
    • モバゲーでの課題
      • DBアクセスで律速なのでFW高速化にあまり意味がない
      • システム全体の巨大化によりFW修正が危険になってきた
        ＞疎結合にしていきたい
      • 少人数開発を前提にしてるので品質のばらつきに弱い
        ＞10人くらいまでは意思統一できるが…
      • そろそろutf8に統一したい…
  • 質疑応答

    • Q:非同期処理のキックタイミングは？

    • A:webサーバのファイルキューに書き出し、専用daemonが処理サーバに転送

    • Q:本番リリース時(たとえばDBの変更があるなどの場合)にFWで考慮してることは？

    • A:FWでなんとかできるものでもないので手順書ベース。
      普段はrsyncを地味にまわす。
      マスタDBの切り替えは準備しておいて朝方５分ほど行進を止めて、とか。
      ＞その辺の話はここで公開されているスライドにもう少し詳しく記述されている

    • Q:手直ししたいところは？

    • A:文字コード。MySQLとSJISの相性の悪さ。UTF8にしたいのだが…。
      流行りもの(ORMとか)に乗っかるかどうかは微妙。

    • Q:必ず入れてるCPANモジュールなどはある？

    • A:DBIぐらい。特定のモジュールに依存しないようにしてるので。

    • Q:コード品質のばらつきにはどう対応している？

    • A:サービス / 会社が伸びる勢いに流されて開発者を増やしたので、人もコーディングルールもちゃんとしてない面がある。「こう書くべき」という『空気』がコーディングルールのような役割を果たすが、『空気』の種類が増えてくると本線が見えなくなる。
      地道にルールを作るとか、テストの手法が属人的でルールとして確立していないので作らないと。

    • Q:なぜ非同期処理にファイルキューを採用したのか？

    • A:こだわりはないがシンプルであること、障害からのリカバリが簡単であることが理由
      決済などクリティカルな部分は別の手段で行っている。

    • Q:端末固有の情報をDBから引いているそうだが、DBと設定ファイルの使い分けに基準は？

    • A:機種情報はDBに格納 -> プロセスごとにキャッシュしている。機種情報は運用側が管理画面から更新したりするよね…という発想なので自然にDBになったが、現在はエンジニアが手でSQLを叩いていたりする。

    • Q:XSモジュールとperlの使い分けに基準はある？

    • A:初期のオークションサービスでベンチマークを取り、ボトルネックになっている箇所 / 共通して多く使われる処理からXSにしていった。
      「なんとなく書きたかった」という一面もある。

    • Q:DBの負荷分散についてFW側での対応はしている？また、特殊なインフラを採用している？

    • A:FWの機能というよりはアプリケーション側で対応している。
      インフラは標準的なもの

  • 感想
    • まずこのような「勉強会」を開くことができる社風に感嘆。
    • そして競合他社のエンジニアを呼んでしまう大胆さに感動。
    • ノウハウをかなりのところまで惜しげもなく公開していた。情報は共有してこそ価値が膨らむんだよね。
    • 懇親会にも参加したのだが、同業者との交流まで踏み込むことができなかった（シャイなので / 空腹だったので）。次回は勇気を出してみよう。
    • なんとなく気後れしてしまい会社名を伏せて参加したのだが、別に伏せる必要もなかったよな、と反省。
    • 私も呼ばれたり話をさせてもらえるぐらいの何かをとっとと作りたいものだ。