タグ別アーカイブ: ソーシャルアプリ

PHPカンファレンス2010へ行ってきました。

先週のことになりますが、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

ゲームごとに作り方が違う

既存のソースを流用しているため、
特定のフレームワークに頼る必要は無い