先週のことになりますが、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が全額を負担)
・コンサルティングを行う
オープン化の結果：
・ユニークユーザー数の増加
・自社開発ゲームへのネガティブな影響はなし
・サイト導線を改善し、課金額・会員数も増加
４つのポイント：
・オープン＝参入しやすい
・サービス改善＝変更・改善を繰り返してゆく。トラフィックも変わってくる
・コンサルティング＝データの提供、データに基づいたアドバイス(パートナーとともに成長してゆく)
ゲームはそのまま公開してうまくいくケースは少ないので、ベータ期間を設けたりする
・プロモーション支援＝年末までに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)
１．データ消滅の心配がいらない
→頻繁に更新されるステータスに有効
２．不整合が起こりうる
→例外が発生してもユーザが得をするかたちで解消できるような処理の流れを作る
・スレーブ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
ゲームごとに作り方が違う
既存のソースを流用しているため、
特定のフレームワークに頼る必要は無い