先週のことになりますが、PHPカンファレンス2010という催しで講演を聞いてきましたので、その時のメモ書きを公開させて頂きます。聞き違いの部分などもあるかと思いますがご容赦下さい。USTREAM等でも当日の様子が公開されているみたいです。
9/24 ビジネスデイ
———————————————————————————–
基調講演 「GREE Platformの現状と今後の取組について」
———————————————————————————–
お題:
・どのようにしていきたいのか
・オープン化してみて
2010年7月の会員数→2100万人以上(mixi、モバゲーも同じくらい)
Nintendo DSの販売数=3000万台
→GREEも同じスピードで成長
30代以上の会員も3~4割存在
GREE:オープン化でアプリの充実を目指す(会員数3000万を目指す)
ソーシャルゲーム市場は数億円規模に:
2011~2012年には本格的になる見通し
ソーシャルゲーム:
・開発費を抑えてスモールスタートが可能
・広告費も段階的に増やして行け、かつ高い利益を目指せる
運用/PDCAの重要度が高い
2010年6月末オープン化開始:
・改善を続けていかないとプラットフォームとして育たない
・画面/仕様を変更
・パートナーさんのアプリをCMで紹介(GREEが全額を負担)
・コンサルティングを行う
オープン化の結果:
・ユニークユーザー数の増加
・自社開発ゲームへのネガティブな影響はなし
・サイト導線を改善し、課金額・会員数も増加
4つのポイント:
・オープン=参入しやすい
・サービス改善=変更・改善を繰り返してゆく。トラフィックも変わってくる
・コンサルティング=データの提供、データに基づいたアドバイス(パートナーとともに成長してゆく)
ゲームはそのまま公開してうまくいくケースは少ないので、ベータ期間を設けたりする
・プロモーション支援=年末までに30タイトルのTVCM(GREEが全額負担)
今後の展開:
・スマートフォン対応(アンドロイドがくる)
・アジア・北米への展開
—————————————————–
モバイル ソーシャルアプリの開発と運用
—————————————————–
ウノウ(株):フォト蔵を運営
まちつく:300万インストール
オープンソーシャル:
・ユーザはプラットフォームを介してアクセスする
・友達・自分情報を取得できる
・APIを利用する
・OAuthで機種/個人を特定する
OAuth(opensocial_php_client)→グーグルコードのサンプルソースが参考になる
OAuthが使えるライブラリ:
・OAuth Consumer And Server Library for PHP
・Pear OAuth
・PECL OAuth
→Pear OAuthが一番良い
毎回データを取りに行くと遅くなる=キャッシュ、キューを使う処理が必要
APIがつながらないことが多いので、そのための処理が必要
オープンソーシャルのサポート側:
・問い合わせが多いのでシステム化が必要(1日最高でメール1000通)
・問い合わせを減らす工夫が必要
・重い負荷のかかった機能を一旦切り離して停止させる覚悟も必要
オープンソーシャルの運用:
・エンジニアに負担をかけないようにする
・ユーザアクセス数の少ない時間帯にメンテナンスを行う
オープンソーシャルの設計・企画:
・友達リストを取得するような処理は重いので避けた方がよい
・APIをできるだけ使わないようにする
・一日一回しかできない機能=午前4時などに更新するようにするとトラフィックが安定する
・やっている時にニヤッとしてしまうような機能がソーシャルには重要
オープンソーシャルの開発方法:
・Proxyサーバ、sandobox+firemobilesimulatorを利用
・もしくは通常のサイトとして開発
システム構成:基本はLAMP環境
・memchache→これがないと死ぬ
・Q4M
・Nginx→プロキシ
(下記二つは運用・設定ファイルの更新に利用)
・Puppet
・Capistrano
DB:
・可能な限りメモリを増やす
・ボトルネックはDISKアクセス
・できるだけデータをメモリにのせる
・レプリケーションはあまり効果がない
・マスター分割すると性能が2倍になる(ただし開発コストも増大)
フレームワーク:
・symfony(ORMに詳しくなくても実装できる)
swfEditor:swfのバイナリを書き換えられるツール
—————————————————–
~モバイルオープンソーシャルにも対応!
~ OpenPNE Ver3.6紹介
—————————————————–
手嶋屋:OpenPNE(2005年スタート)を開発、オープンソース化した会社
SNS:情報ネットワーク社会のさきがけ
週100~150サイトが新規開設されている
エンタメ系のSNSが多い(オンラインゲーム、ファンクラブ、ケータイゲームなど)
OpenPNE:日立、NEC、セイコーエプソン、バンダイ等で使われている
OpenPNE3.0:
・つぶやき機能を追加
・日記、ランキング、コミュニティもあり
・機能は着脱可能、モバイルでも利用可能
・モバイル対応
Symfonyを利用している:
・OpenPNEのプラグインはSymfonyのプラグイン機能を利用している
・OpenPNEソースはSymfony開発時に参考になる
Ver3.7以降、最新のモバイルオープンソーシャルに対応していく:
・twitter機能に対応
・iPhoneにも対応予定
OpenPNEを利用している150万ユーザークラスのサイトも存在している
資料はあとでブログに公開される(という話でした。)
—————————————————–
大ヒットソーシャルアプリの裏側
—————————————————–
ソーシャルアプリ:
・SNSの機能が使えるアプリ
・APIなどを利用する
・集客コストがかからない
・OpenSocialAPIを使うことによる開発コストの削減
誰も考えないようなテーマ、独自の機能を考えることが重要
他社との差別化をしないと生き残れない
恋したキャバ嬢:
・大ヒット
・負荷がすごい(最大2000PV/sec)
競合他社とテーマが重なった場合、新規機能を追加して差別化をしていかないとだめになる
手戻りが発生するとリリースが遅くなる(機会損失)
→自ら提案することで企画の意図が分かるようになり、手戻り減につながる
企画と一体になる=楽になる
負荷について:
ユーザ固有のデータ=アクセス、更新頻度高
→ソーシャルアプリでは特に負荷が高い、マスターDBへの負荷集中
Ganglia=オープンソースのモニタリングソフト
Symfonyがベース
画像合成処理:
・キャッシュは非効率
・ローカルファイルはI/Oアクセスが増える
・素材ファイルのみキャッシュ+GD高速化で対応
マスターDB対策:
・なるべくDBに接続しない
・クエリ最適化
・使わなければ接続を切る
DBコネクションの節約方法:
・memchacedの利用
DB更新時にキャッシュも更新
・APCキャッシュ→更新が少ないときに有効
・KVSの利用(TokyoTyrant)
1.データ消滅の心配がいらない
→頻繁に更新されるステータスに有効
2.不整合が起こりうる
→例外が発生してもユーザが得をするかたちで解消できるような処理の流れを作る
・スレーブDBを利用
レプリケーションの遅延は起こりうる
APIとの通信:
・レスポンスタイムアウトは普通に起こりうる
・APIへのリクエスト→DB更新とは分ける
—————————————————–
Scaling the Worlds Largest Social Gaming Network
世界最大ソーシャルネットワークゲームのスケーリング
—————————————————–
Zyngaのミッション:ゲームを通じて世界とつながる
ソーシャルゲーム:
・プレイが簡単で楽しい
・他人とつながる
月間ユーザ2億4000万
ゲームの体験者数:3億2000万
拠点は世界にある:
・世界のインターネット人口の10%がプレイしている
Facebookのトップゲーム:Zyngaが占めている
一週間に1000台のサーバを増設することもある
データ量1PB
システムの構成:
Webサーバ ー memchache - DB
サーバはすべて水平方向にスケール:
・キャッシュし、非同期
完全に自動化、API化されている
APIレスポンスキャッシュ内蔵
KVSを利用
DBはデータストアとしてのみ利用する
持続型memchached(membase)を利用
→分散型KVS
・速度、柔軟性がある
・クラスター内に存在している
利用しているもの:
membase
mcmux
(上記2つはオープンソース)
pecl-memchached
FontLabel
ゲームごとに作り方が違う
既存のソースを流用しているため、
特定のフレームワークに頼る必要は無い