「PHPカンファレンス2010」に行ってきました。
ここで腹ごしらえをした後、会場に。
最初から最後まで居たけど、以下、気になった講演の要点のみ。
Gree青柳氏
会員について
- ソーシャルプラットフォームを持つ各社の会員数
- Gree→2,125万人
- mixi→2,102万人
- DeNA→2,048万人
- NintendoDS→3,086万人
- Greeの特徴
- DSの販売本数と同じように会員数が伸びている
- 年齢層が高い(30代が34％→TVCM効果？？)
GreePlatformのオープン化について
- 携帯型ゲーム機に比べて、まだコンテンツが弱い→オープン化でタイトルを充実させたい
- 2011〜2012年に本格的なソーシャル時代を迎えると思われる
ソーシャルアプリについて
スマートフォン対応
- 詳細については2010年中に順次公表
グローバル展開
- 海外拠点を開設する予定
- 外国籍の社員採用積極化
- ローカルプレイヤーとの業務・資本提携を検討中
ウノウ個々一番氏
「まちつく！」→300万インストール
- なぜモバイル？→ガラケーすごい
ウノウの近況
運用開発設計
- OpenSocial
- 通常モバイルとの違い
- IPで縛るのは無理→OAuthで正しいアクセスかどうかを判断
- UIDの機種情報は取れない代わりに、owner_idとかをもらえる
- パソコン阪との違い
- RESTfulAPIしか使えない
- JavaScriptは避けたい
- OAuth
- Web APIは速くない
- インターネット越しの通信なんだから速いわけがない
- 毎回の情報を取りに行くとスゴい遅くなる
- 基本キャッシュ
- キュー処理にしたり
- 取得できなかった時の処理を正しくハンドリングすることが鍵
- 特に問題ないなら処理をログはいてスキップする
- 問題がある場合は、適切なメッセージとユーザーが気になることが書いてあるページへ移動
- サポート
- 問い合わせが多いので、システム化しないとスグに破綻する
- 「火の七日間」で一日1000通のお問い合わせ
- 各社ツール出している(使いやすいかどうかはともかく)
- 問い合わせを減らす工夫
- 「友だち一覧が更新されない」
- 24時間が規約だと24時間にしたくなるが、30分とかに減らす
- そもそも友達一覧を実装しない
- FAQに書く
- 動かない、重い機能を一旦停止する
- 「友だち一覧が更新されない」
- 問い合わせが多いので、システム化しないとスグに破綻する
- 障害対応
- メンテナンス
- エンジニアの数も体力も有限
- 負のループ(深夜対応→昼ごろ出社→また深夜まで対応→また昼ごろ出社→また…)
- 実は、昼間のメンテナンスのほうが、結果的にユーザへの還元になるのではないか
設計、企画
開発
- スピードスピードスピード
- どれだけ速く企画を成立させるか
- ユーザー数
開発の仕方
- サーバ
- (それっぽい独自ProxyサーバOR各社Sandbox)＆FiremobileSimulator
- Proxy自体使わず普通のサーバ
- サーバサイド技術
- PHP5,2.x 5.3.x
- MySQL
- Memcache
- Q4M
- Nginx(Proxyサーバとして)
- Puppet
- Capistrano
- ミドルウェア
- Disk遅い、メモリ速い
- 最近、メモリ安い
- 可能な限り、メモリに乗せる
- しかし、データはメモリに乗せないといけないものがほとんど。
- DiskのWriteで頑張る(データベースの考え方)
- レプリケーションはあまり意味が無い
- マスタ分割→性能が2倍→でも、動かなくなった…
- 開発コストの増大
- ORMを最初から使うことで対応(ORMは窮屈だから良い)
Flash
- ming
- SwfEditor→絶賛☆
障害事例
- DBがロールバックされなかった
- Capistranoでデプロイし続けたらアパッチのメモリがあふれた
その他
- 10年前からLAMP変わってない、LAMP構成を運用できる人なら問題ない
- 求人再開しました。
KLab高田氏＆新田氏
ソーシャルアプリの特徴
- 気軽に起ち上げられる反面、差別化をしないと生き残れない(恋愛と同じ？！)
「恋してキャバ嬢」
- 差別化には成功したが、問題も発生
- 問題二件
- 負荷に耐えられなくなる
- 最大秒間PV…初日380、翌日580、最大2000
- 仕様変更に伴う手戻り発生→機会損失
- 負荷に耐えられなくなる
- 問題に対する解決策
- 負荷対策→後述
- 仕様変更対策→企画が持ち込まれた際に「提案」をする
- ソーシャルアプリはスピードの流れが速いため、自分の担当にとらわれずに担当外の作業を積極的に行うことが重要。
負荷対策
- モバイルサイトとの比較(一番の違い)
| モバイルサイト | ソーシャルアプリ |
| 参照(多)＞更新(少) | 参照(多)＝更新(多) |
- DSAS(http://www.klab.jp/dsas/)
- システム構成(アプリ側)
- KLabSocialGamePratform
- Symfonyベース→必要ない機能を省いて軽量化
- 高速画像合成ライブラリ(KGD)
- Flash合成ライブラリ
- APC(アクセラレータ)
- 画像合成
- キャバ嬢の画像
- 背景、ボディ、表情、ドレス、髪型
- キャッシュは非効率＋必要ない
- 1ユーザー50KB×100万＝合成したアバター画像だけで50GB
- Memcachedへのキャッシュ→非現実的
- ローカルファイルへのキャッシュ→I/O増加、遅くなる
- 素材ファイル…数百〜数千→キャッシュ可能
- 画像ライブラリの高速化＋キャッシュなし(参考URL)
- キャバ嬢の画像
- データベース(マスターDBへの接続を減らそう)
- やりとりを減らす(DBへのアクセス回数を減らす)
- クエリの書き方の工夫
- キャッシュの利用
- Memcachedの最大接続数は数万から数十万
- 秒間数万リクエストを処理
- APCキャッシュ
- KVSの利用
- TokyoTyrant
- エビクションの心配がない
- MySQLとMemcachedの「中間」
- データ信頼性… MySQL＞TokyoTyrant＞Memcached
- 速度… Memcached＞TokyoTyrant＞MySQL
- 扱うのに適したデータ→頻繁に更新されるユーザーステータス
- 体力
- アイテム装備情報
- ログイン情報…etc.
- 注意点
- MySQLとのデータ不整合の棄権
- アトミックな更新処理は困難
- ユーザーが得する方向で処理を行う
- 「体力回復アイテムを使った→アイテムは減らなかったけど体力は回復した」等
- TokyoTyrant
- スレーブDBへの分散
- 最新の情報が入っているとは限らない
- レプリケーション遅延がいつでも起こりうる
- ランキングなど遅延することが致命的ではないデータを格納する
- ソーシャルAPI SNSAPIを使用
