Phpconf2010

大ヒット！ソーシャルアプリの裏側
2010/9/24 KLab株式会社
Kラボラトリー高田敦史
第2開発部新田祐介

Copyright 2010 KLab Inc. All right reserved.

■会社紹介

• 2000年8月設立、今年10周年を迎えます
• 大規模/高負荷モバイルサイトの構築/運用にて
負荷対策のノウハウを蓄積してきました
• ソーシャルアプリ向けホスティングサービス「DSAS
Hosting for Social」提供中！

http://www.klab.jp/dsas_host/index.html


■会社紹介

• 弊社にてソーシャルアプリを多数展開中！


■スピーカー紹介

■氏名
・新田祐介(twitter：@fushianako)
・KLab 株式会社第2開発部グループマネージャー
■略歴
・2006年にKLabに入社。
・以降、公式モバイルサイト/自社SNS開発をしてました。
・最近はソーシャルゲーム開発の駆け出しPMしてます。
・プロジェクトが佳境になるとうまい棒を持って登場します。
■趣味・特技
・毎週日曜の娘とのプリキュア観賞。
・native japanese(興味のある人はお問い合わせください)

■スピーカー紹介

• 自己紹介
– 高田敦史
– KLab株式会社: Kラボラト
リー、第二開発部PMO
• 略歴
– 2008年入社
– 研究開発 + ソーシャルアプリ
の開発 + アーキテクト
– 最近はくまをかかえています
• つくったものなど
– http://paintica.com/
– PHPは主にソーシャル
アプリの開発に使用。


■発表内容

■対象者
これからソーシャルアプリを開発する、もしくは
興味のあるエンジニア、開発リーダー、PM。
■発表内容
第1部：ソーシャルアプリの概要(新田)
第2部：激戦！ソーシャルアプリ格闘日記(新田)
第3部：ソーシャルアプリ負荷対策(高田)


■第1部

ソーシャルアプリの概要


■ソーシャルアプリの概要

■ソーシャルアプリとは？
・SNSの機能を使う事が出来るアプリケーション。
ex)自分が作ったアプリからSNSの友達情報を取得する。
・SNSの機能を使いたい場合は、各プラットフォームが提供する
JavaScriptAPIやWebAPIを利用する。

■実際、どのような事が出来るの？
・ギルドのような、SNS上の友達と協力して1つの目標を
達成するような協力プレイが出来る。
→SNS上の友達とプレイ出来る事で、気軽に始められる。
(友達がやってるから自分もやってみよう的な意味で。)
お陰で、トラフィックが激しくて負荷に悩まされます(＞＜)



■ソーシャルアプリの特徴
サービスを気軽に立ちあげられる
【ビジネス的観点】
・ユーザの母体がSNSにあるが故の集客コストの削減。
・流行っているからという理由で納得する人が多い(ｗ
※ 半分冗談、半分本気です。
【技術的観点】
・OpenSocialAPIを使う事による、開発コストの削減。
※ PCサービス立ち上げ時には認証系で助けられました。

気軽に立ちあげられる反面、同じようなテーマのアプリが
多いため、他アプリとの差別化が重要です！



■どうやって差別化していくか？
① アプリのテーマの選定
・誰も考えていないようなテーマを選定していく事が重要。
※ 最近だと乙女系が流行っているみたいですね。
② 独自機能の提供
・ソーシャルアプリは数が多く、テーマがかぶる事が多いです。
・既にかぶっている場合は、他のアプリを研究して
他アプリには無い機能を作り込むと効果的！

恋愛と同じように、自分をアピールしなきゃダメ！
劣化コピーでは誰もあなたには振りむきませんよ！



■まとめ
・ソーシャルアプリとはSNSの機能を使えるアプリケーション。
・ SNSの機能による、友達の輪(ソーシャルグラフ)を
使った協力プレイが特徴。
・母体がSNSであるため、ヒットするとトラフィックが高く
負荷に悩まされる。
※ 負荷に困ったら DSASに相談だ！(ｗ
・気軽に始められる半面、同じようなアプリが乱立するため
他社との差別化をしないと生き残れない。


■第2部

激戦！ソーシャルアプリ開発日記


■激戦！ソーシャルアプリ開発日記

ソーシャルアプリの特徴も含めた、私の苦労話を
ノンフィクションでお送りいたします。



その1 集中砲火



ソーシャルアプリは他社との差別化が重要と言いましたが…



恋してキャバ嬢は見事に差別化に成功しました＼(^o^)／



が、しかし、問題が・・・

「弾幕薄いぞ！何やってんの！」

負荷に耐えきれなくなったのです＼(^o^)／



サーバの状態を見ていたら・・・・
最大秒間PV(※)が・・・
初日：380PV/sec(な、なんだってー！！)
翌日：580PV/sec(ぇぇぇぇぇぇぇぇぇぇぇぇ)
最大：2000pv/sec以上(＼(^o^)／ )
※最大秒間PV：1秒間のページ閲覧数が一日で最も多いときのページ閲覧数
※500pv/secになると普通のWebアプリでは考えられない量です。

というわけで、地道に負荷対策をし始めました。
結果、最大秒間PVはさばけるようになりました。
(詳細は高田から説明します。)



その２ハイブリッド化



同じテーマのアプリが出てくることはしばしばありますが…



キャバをテーマにしたアプリも出てきました…



ソーシャルアプリ業界ではよくあることです



テーマがかぶった場合は…
新規機能を開発して差別化を行わないと死にます。

ここではその時のお話をしようと思います。



■新田が開発リーダーしていた頃のよくある光景
企画者
「他社アプリが伸びてきたから、うちも対策しないと」
「新田さん、こんな機能作れる？」
新田
「○○人日くらいあれば作れるので、作りますね。」
開発者
「新田さん、作り終わったので企画チェックしますね。」
企画者
「やっぱり、ここ、こう作りなおしてもらって良い？」
新田
「謀反じゃーーー！！！」



仕様変更による、手戻りが発生し、リリースが遅れます。
他社からも遅れを取ってしまい、機会損失になります。



■新田が開発リーダーをしていたころに気をつけた事
企画者
「他社アプリが伸びてきたから、うちも対策しないと」
「新田さん、こんな機能作れる？」
新田
「作れるけど、こういう仕様にした方が面白くないっすか？」
企画者
「そうだね、こうした方が良さそうだね」
開発者
「新田さん、作り終わったので企画チェックしますね。」
企画者
「OK！じゃリリースしましょう。」



ソーシャルアプリは、スピードの流れが早いため
自分の担当にとらわれず、担当外の作業を積極的に
行なう事が、ヒットアプリを生み出す要因になります。

エンジニアのみなさん、少しでも良いので
企画のフィールドに首を突っ込むと楽になれますよ！



■まとめ
・ソーシャルアプリはヒットすると、ありえない負荷がかかる。
→ 負荷対策をきちんとしないと機会損失になります。
・ソーシャルアプリは常に追加開発をしないと他アプリに
追いぬかれ埋もれていく。
→ 結果として、機会損失に繋がる。
・開発者が企画者マインドを少し注入しハイブリッドに
なることでヒットアプリへの道が広がる。


■第3部

ソーシャルアプリ負荷対策


アジェンダ
1.ソーシャルアプリの負荷特性
2.KLabのシステム構成
3.リソース有効活用テクニック

•Webアプリ負荷対策の基本をおさえる
•リソースの特性を意識する
•参考:
•LAMPで作るソーシャルアプリの負荷対策
http://tinyurl.com/orehamorimoto


■ソーシャルアプリの負荷特性

• ユーザー固有のデータ
– 大量
• ゲーム内ステータス(体力、経験値など)
• アイテム所持情報よくある高ARPUな
• 課金、購入ログソーシャルゲーム
– 更新頻度: 高いモデルを想定
• ボタンを押すだけでステータス変化
• 大量のログ
• 高頻度 + 大量のHTTPリクエスト(更新系)



大量の更新リクエスト
ミニゲームアプリケーション
結果

アイテム
購入

他ユーザー
を応援



マスターDBへの負荷集中
1台に負荷が
集中！スレーブDB
スレーブDB
スレーブDB

マスターDB

分散可能

Webサーバーebサーバーebサーバー
W W Webサーバー



ソーシャルアプリで重要なリソース
• データベース(特にマスター)
– 最大コネクションは数百程度
– 負荷分散も難しい

大量の更新系リクエストをさばくため、マスターDBの
リソースが枯渇！



モバイルサイトとの比較
モバイルサイトモバイル向けソーシャルア
プリ

情報閲覧 + DL中心ユーザーのアクション+
ユーザー間アクション

リクエスト数少リクエスト数多
参照(多) > 更新(少) 参照(多) = 更新(多)



まとめ
• ソーシャルアプリ = 大量の更新系リクエスト
• マスターデーターベースに負荷が集中し、ボ
トルネックになりがち


■KLabのシステム構成

• ＤＳＡＳ
– 高負荷・大規模サイト構築用インフラ統合技術

• オープンソースベース
• 単一故障点が存在しない高信頼構成
• 容易なメンテナンス・柔軟なスケーラビリティ
• 充実した監視機構とモニタリング
http://www.klab.jp/dsas/



システム構成(インフラ)
Webサーバー

マスターDB スレーブDB
Webサーバー

LVS(ロードバランサ)
Webサーバー KVストレージ
(TokyoTyrant)

Webサーバー
Internet キャッシューサーバー
(memcached)



Gangliaによるモニタリング

監視対象も追加
できる



システム構成(アプリケーション)

高速画像合成ライブラリ
アプリ固有コード (KGD)

Flash合成ライブラリ
KLabSocialGamePlatform

Symfony

APC



• Symfonyを大幅に改造した独自フレームワー
クを使用
– 必要ない機能を省いて軽量化
– 開発効率の向上
• Opensocial用の独自ライブラリ
• 画像合成、Flash合成は高速化改造済み
PHPエクステンションを使用



画像合成について

背景画像
ボディ画像
表情画像
ドレス画像
髪型画像



• キャッシュは非効率 + 必要ない
• 1ユーザー(50KB) × 100万
– 合成したアバター画像だけで、50GB
• Memcachedへのキャッシュ: 非現実的
• ローカルファイルへのキャッシュ
– メモリにキャッシュできないためI/Oアクセス増加
– むしろ遅くなる



• 素材ファイル
– 数百から数千程度
– キャッシュ可能！
• 画像ライブラリの高速化 + キャッシュなし
– 高速改造版GDライブラリKGDは、DSAS
Hosting for Socialでも提供中！
– http://www.klab.jp/dsas_host/kgd.html


■リソース有効活用テクニック

• ハードウェアベース
– CPU かぎりあるリソースを有効
– メモリ活用する

– HD
• 役割ベース
– DBサーバー(マスター / スレーブ)
– キャッシュサーバー + キーバリューストレージ
– Webサーバー(Apache, PHP)



マスターDB有効活用
処理時間
をへらす
コネクション
をへらす

• なるべくデータベースに接続しない
– コネクション数をへらす
• データベースへの接続時間を短かくする
– クエリを最適化
– 接続を切る


• SQL最適化、DBサーバーチューニングの話
は、ソーシャルアプリにかぎらないので省略
– ほんとはとても重要
– I/Oアクセスをへらせ！とだけ言っておく
• DBコネクションの節約方法について話します
– キャッシュサーバーの利用
– KVSの利用
– スレーブDBヘの分散
– ソーシャルAPIに関する注意点



キャッシュの利用
• 効率的なキャッシュの利用
– Memcachedの最大接続数は数万から数十万
– 秒間数万リクエストを処理

先にキャッシュを検索 DB更新時に
なければDBに問い合わせキャッシュも更新

Memcached

アプリ(PHP)
MySQL



Webサーバー

Webサーバー
APCキャッシュ Memcached

Webサーバー

Webサーバー



KVSの利用
• KVS(キーバリューストレージ)の利用
– 更新の一部をKVSに分散する
– KVS: 連想配列のような、キー+値の形式でデー
タを保持するストレージ
• TokyoTyrant
– 平林幹雄さん(mixi)作
– Memcacheに近い高速な処理
– エビクション(データ消滅)の心配がいらない
– http://fallabs.com/tokyotyrant/


TokyoTyrantの特性
データ信頼性高速

MySQL TokyoTyrant Memcached

レプリケーション HDにも書き込む基本はオンメモリ
a
高度なトランザクション/ レプリケーショントランザクション/ロック
ロック機構機構なし
エビクションなし
HDへの書き込みが保エビクションによる
証されるデータ不整合の危険
データ消滅



TokyoTyrantの使い道
• 頻繁に更新されるユーザーステータス
– 体力
– アイテム装備情報
– ログイン情報etc.
• RDBの機能(ロック、トランザクションなど)が
必要ないデータ



注意点
• TokyoTyrantとMySQLの間の不整合が起こりうる。
• アトミックな更新処理は困難
• ユーザーが得する方向で処理を行なう
– 順番が重要
– (1)(2)(3)、どのタイミングで例外が起きてもよいようにする

(1)ユーザーの利益になる処理 on TT: 体力回復

(2)MySQLへの更新処理: アイテム消費など

(3)ユーザーの損になる処理 on TT: 体力消費



スレーブDBへの分散

スレーブDB
スレーブDB

• スレーブDB: マスターからデータをコピーしたDB(レ
プリケーション)
• DBへの参照をスレーブDBに逃がすことで、マス
ターDBの負荷を減少



スレーブDB
スレーブDB

• 注意点: 最新のデータがあるとはかぎらない
• レプリケーション遅延はいつでも起こりうる
• スレーブDBを利用できるデータ:
– ランキングなど、更新が少なく、遅延が致命的でないデー
タ



ソーシャルAPIの注意点
• ソーシャルアプリ = SNS APIを使用
– ユーザー情報(ユーザー名、SNSフレンドデータ)
– ユーザー投稿テキストの保存
– アクティビティ送信
• SNSが提供するAPIの使用は避けて通れな
い



ガジェットサーバー

ユーザー
SAP

APIサーバー

• ガジェットサーバー経由の認証情報を利用し、API
サーバーに問い合わせる
• APIとの通信はHTTP
– 最短でも数十msのコスト



• レスポンスタイムアウトは日常的に起こりえる
• API通信がつねに成功する前提でアプリケーション
を開発してはいけない

タイムアウトの場合、DBコネクションを
危険なコード数秒間無意味に
数秒間無意味に保持
通信が成功しても、数十程度のロス
数十ms程度
数十程度の
- トランザクション開始
- => APIに問い合わせ
- トランザクション終了



それでも足りない場合
• 水平分割 / 垂直分割を利用
• データベースを複数に分割
– 機能単位の分割(垂直分割)
– ユーザー単位など、データ単位の分割(水平分
割)
• 注意点は、KVSの利用に似てくる
– データ整合性がネック



まとめ
• マスターDBへの接続をへらそう
– キャッシュサーバーを利用
– 一部の更新をKVSなどNoSQLに分散
– 参照系の処理をスレーブDBに分散
– API通信に気をつけよう
– 垂直分割+水平分割の利用


■最後に・・・

ご静聴ありがとうございました。
不明点はお気軽にお問い合わせください。


Phpconf2010

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (15)

Similar a Phpconf2010

Similar a Phpconf2010 (20)

Más de KLab株式会社

Más de KLab株式会社 (12)

Phpconf2010