大ヒットソーシャルアプリの裏側

8,240 views

Published on

PHPカンファレンス2010での発表資料です

Published in: Technology

大ヒットソーシャルアプリの裏側

  1. 1. 2010/9/24   KLab 株式会社  K ラボラトリー 高田敦史  第 2 開発部 新田 祐介 大ヒット!ソーシャルアプリの裏側
  2. 2. ■ 会社紹介 <ul><li>2000 年 8 月設立、今年 10 周年を迎えます </li></ul><ul><li>大規模 / 高負荷モバイルサイトの構築 / 運用にて 負荷対策のノウハウを蓄積してきました </li></ul><ul><li>ソーシャルアプリ向けホスティングサービス「 DSAS Hosting for Social 」提供中! </li></ul>http://www.klab.jp/dsas_host/index.html
  3. 3. <ul><li>弊社にてソーシャルアプリを多数展開中! </li></ul>■ 会社紹介
  4. 4. <ul><li>・新田 祐介 (twitter : @fushianako) </li></ul><ul><li>・ KLab 株式会社 第 2 開発部 グループマネージャー </li></ul>■ スピーカー紹介 ・ 2006 年に KLab に入社。 ・以降、公式モバイルサイト / 自社 SNS 開発をしてました。 ・最近はソーシャルゲーム開発の駆け出し PM してます。 ・プロジェクトが佳境になると うまい棒 を持って登場します。 ■ 氏名 ■ 略歴 ■ 趣味・特技 ・毎週日曜の娘とのプリキュア観賞。 ・ native japanese ( 興味のある人はお問い合わせください )
  5. 5. <ul><li>自己紹介 </li></ul><ul><ul><li>高田敦史 </li></ul></ul><ul><ul><li>KLab 株式会社 : K ラボラトリー、第二開発部 PMO </li></ul></ul><ul><li>略歴 </li></ul><ul><ul><li>2008 年入社 </li></ul></ul><ul><ul><li>研究開発 + ソーシャルアプリの開発 + アーキテクト </li></ul></ul><ul><ul><li>最近はくまをかかえています </li></ul></ul><ul><li>つくったものなど </li></ul><ul><ul><li>http://paintica.com/ </li></ul></ul><ul><ul><li>PHP は主にソーシャルアプリの開発に使用。 </li></ul></ul>■ スピーカー紹介
  6. 6. <ul><li>■ 対象者 </li></ul><ul><li>これからソーシャルアプリを開発する、もしくは </li></ul><ul><li>興味のあるエンジニア、開発リーダー、 PM 。 </li></ul><ul><li>■ 発表内容 </li></ul><ul><li> 第 1 部: ソーシャルアプリの概要 ( 新田 ) </li></ul><ul><li> 第 2 部: 激戦!ソーシャルアプリ格闘日記 ( 新田 ) </li></ul><ul><li> 第 3 部: ソーシャルアプリ負荷対策 ( 高田 ) </li></ul>■ 発表内容
  7. 7. ソーシャルアプリの概要 ■ 第 1 部
  8. 8. <ul><li>■ ソーシャルアプリとは? </li></ul>■ ソーシャルアプリの概要 ・ SNS の機能を使う事が出来るアプリケーション。 ex) 自分が作ったアプリから SNS の友達情報を取得する。 ・ SNS の機能を使いたい場合は、各プラットフォームが提供する JavaScriptAPI や WebAPI を利用する。 ■ 実際、どのような事が出来るの? ・ギルドのような、 SNS 上の友達と協力して 1 つの目標を 達成するような協力プレイが出来る。 -> SNS 上の友達とプレイ出来る事で、気軽に始められる。   ( 友達がやってるから自分もやってみよう的な意味で。 )  お陰で、トラフィックが激しくて負荷に悩まされます ( >< )
  9. 9. ■ ソーシャルアプリの概要 ■ ソーシャルアプリの特徴 サービスを気軽に立ちあげられる 【ビジネス的観点】   ・ユーザの母体が SNS にあるが故の集客コストの削減。   ・流行っているからという理由で納得する人が多い ( w   ※ 半分冗談、半分本気です。 【技術的観点】   ・ OpenSocialAPI を使う事による、開発コストの削減。   ※ PC サービス立ち上げ時には認証系で助けられました。 気軽に立ちあげられる反面、同じようなテーマのアプリが 多いため、 他アプリとの差別化が重要 です!
  10. 10. ■ ソーシャルアプリの概要 ■ どうやって差別化していくか? ① アプリのテーマの選定   ・ 誰も考えていないようなテーマを選定していく事が重要。  ※ 最近だと 乙女系 が流行っているみたいですね。 ② 独自機能の提供   ・ ソーシャルアプリは数が多く、テーマがかぶる事が多いです。  ・ 既にかぶっている場合は、他のアプリを研究して   他アプリには無い機能を作り込むと効果的!   恋愛と同じように、 自分をアピールしなきゃダメ ! 劣化コピー では誰もあなたには振りむきませんよ!
  11. 11. ■ ソーシャルアプリの概要 ■ まとめ ・ ソーシャルアプリとは SNS の機能を使えるアプリケーション。 ・ SNS の機能による、友達の輪 ( ソーシャルグラフ ) を  使った協力プレイが特徴。 ・ 母体が SNS であるため、ヒットするとトラフィックが高く  負荷に悩まされる。  ※ 負荷に困ったら DSAS に相談 だ! ( w ・ 気軽に始められる半面、同じようなアプリが乱立するため  他社との差別化をしないと生き残れない。  
  12. 12. 激戦!ソーシャルアプリ開発日記 ■ 第 2 部
  13. 13. ■ 激戦!ソーシャルアプリ開発日記 ソーシャルアプリの特徴も含めた、私の苦労話を ノンフィクションでお送りいたします。
  14. 14. ■ 激戦!ソーシャルアプリ開発日記 その 1  集中砲 火
  15. 15. ■ 激戦!ソーシャルアプリ開発日記 ソーシャルアプリは他社との差別化が重要と言いましたが…
  16. 16. ■ 激戦!ソーシャルアプリ開発日記 恋してキャバ嬢 は見事に差別化に成功しました \ (^o^) /
  17. 17. ■ 激戦!ソーシャルアプリ開発日記 が、しかし、問題が・・・ 「弾幕薄いぞ!何やってんの!」 負荷に耐えきれなくなったのです \ (^o^) /
  18. 18. ■ 激戦!ソーシャルアプリ開発日記 サーバの状態を見ていたら・・・・ 最大秒間 PV(※) が・・・  初日  : 380PV/sec( な、なんだってー!! )   翌日  : 580PV/sec( ぇぇぇぇぇぇぇぇぇぇぇぇ )   最大 : 2000pv/sec 以上 ( \ (^o^) / ) ※ 最大秒間 PV : 1 秒間のページ閲覧数が一日で最も多いときのページ閲覧数 ※ 500pv/sec になると普通の Web アプリでは考えられない量です。 というわけで、地道に負荷対策をし始めました。 結果、最大秒間 PV はさばけるようになりました。 ( 詳細は高田から説明します。 )
  19. 19. ■ 激戦!ソーシャルアプリ開発日記 その2 ハイブリッド化
  20. 20. ■ 激戦!ソーシャルアプリ開発日記 同じテーマのアプリが出てくることはしばしばありますが…
  21. 21. ■ 激戦!ソーシャルアプリ開発日記 キャバをテーマにしたアプリも出てきました…
  22. 22. ■ 激戦!ソーシャルアプリ開発日記 ソーシャルアプリ業界ではよくあることです
  23. 23. ■ 激戦!ソーシャルアプリ開発日記 テーマがかぶった場合は… 新規機能を開発して差別化を行わないと死にます。 ここではその時のお話をしようと思います。
  24. 24. ■ 激戦!ソーシャルアプリ開発日記 ■ 新田が開発リーダーしていた頃のよくある光景 企画者  「他社アプリが伸びてきたから、うちも対策しないと」  「新田さん、こんな機能作れる?」 新田  「○○人日くらいあれば作れるので、作りますね。」 開発者  「新田さん、作り終わったので企画チェックしますね。」 企画者  「やっぱり、ここ、こう作りなおしてもらって良い?」 新田  「 謀反じゃーーー!!! 」
  25. 25. ■ 激戦!ソーシャルアプリ開発日記 仕様変更による、手戻りが発生し、リリースが遅れます。 他社からも遅れを取ってしまい、 機会損失 になります。
  26. 26. ■ 激戦!ソーシャルアプリ開発日記 ■ 新田が開発リーダーをしていたころに気をつけた事 企画者  「他社アプリが伸びてきたから、うちも対策しないと」  「新田さん、こんな機能作れる?」 新田  「作れるけど、こういう仕様にした方が面白くないっすか?」 企画者  「そうだね、こうした方が良さそうだね」 開発者  「新田さん、作り終わったので企画チェックしますね。」 企画者  「 OK !じゃリリースしましょう。」
  27. 27. ■ 激戦!ソーシャルアプリ開発日記 ソーシャルアプリは、スピードの流れが早いため 自分の担当にとらわれず、担当外の作業を積極的に 行なう事が、ヒットアプリを生み出す要因になります。 エンジニアのみなさん、少しでも良いので 企画のフィールドに首を突っ込むと楽になれますよ!
  28. 28. ■ 激戦!ソーシャルアプリ開発日記 ■ まとめ ・ソーシャルアプリはヒットすると、ありえない負荷がかかる。 -> 負荷対策をきちんとしないと機会損失になります。 ・ソーシャルアプリは常に追加開発をしないと他アプリに  追いぬかれ埋もれていく。 -> 結果として、機会損失に繋がる。 ・開発者が企画者マインドを少し注入しハイブリッドに  なることでヒットアプリへの道が広がる。
  29. 29. ソーシャルアプリ負荷対策 ■ 第 3 部
  30. 30. 1. ソーシャルアプリの負荷特性 2.KLab のシステム構成 3. リソース有効活用テクニック アジェンダ <ul><li>Web アプリ負荷対策の基本をおさえる </li></ul><ul><li>リソースの特性を意識する </li></ul><ul><li>参考 : </li></ul><ul><ul><li>LAMP で作るソーシャルアプリの負荷対策 http://tinyurl.com/orehamorimoto </li></ul></ul>
  31. 31. <ul><li>ユーザー固有のデータ </li></ul><ul><ul><li>大量 </li></ul></ul><ul><ul><ul><li>ゲーム内ステータス(体力、経験値など) </li></ul></ul></ul><ul><ul><ul><li>アイテム所持情報 </li></ul></ul></ul><ul><ul><ul><li>課金、購入ログ </li></ul></ul></ul><ul><ul><li>更新頻度: 高い </li></ul></ul><ul><ul><ul><li>ボタンを押すだけでステータス変化 </li></ul></ul></ul><ul><ul><ul><li>大量のログ </li></ul></ul></ul><ul><li>高頻度 + 大量のHTTPリクエスト(更新系) </li></ul>よくある高 ARPU なソーシャルゲームモデルを想定 ■ ソーシャルアプリの負荷特性
  32. 32. ミニゲーム結果 アイテム購入 他ユーザーを応援 アプリケーション ■ ソーシャルアプリの負荷特性 大量の更新リクエスト
  33. 33. マスターDB スレーブDB スレーブDB スレーブDB Webサーバー Webサーバー Webサーバー Webサーバー 1台に負荷が集中! 分散可能 ■ ソーシャルアプリの負荷特性 マスター DB への負荷集中
  34. 34. <ul><li>データベース ( 特にマスター ) </li></ul><ul><ul><li>最大コネクションは数百程度 </li></ul></ul><ul><ul><li>負荷分散も難しい </li></ul></ul>大量の更新系リクエストをさばくため、マスター DB のリソースが枯渇! ソーシャルアプリで重要なリソース ■ ソーシャルアプリの負荷特性
  35. 35. ■ ソーシャルアプリの負荷特性 モバイルサイトとの比較 ユーザーのアクション + ユーザー間アクション 情報閲覧 + DL 中心 リクエスト数 多 リクエスト数 少 参照 ( 多 ) = 更新 ( 多 ) 参照 ( 多 ) > 更新 ( 少 ) モバイル向けソーシャルアプリ モバイルサイト
  36. 36. <ul><li>ソーシャルアプリ = 大量の更新系リクエスト </li></ul><ul><li>マスターデーターベースに負荷が集中し、ボトルネックになりがち </li></ul>■ ソーシャルアプリの負荷特性 まとめ
  37. 37. <ul><li>D SAS </li></ul><ul><ul><li>高負荷・大規模サイト構築用インフラ統合技術 </li></ul></ul><ul><li>オープンソースベース </li></ul><ul><li>単一故障点が存在しない高信頼構成 </li></ul><ul><li>容易なメンテナンス・柔軟なスケーラビリティ </li></ul><ul><li>充実した監視機構とモニタリング </li></ul>http://www.klab.jp/dsas/ ■ KLab のシステム構成
  38. 38. マスターDB スレーブDB KV ストレージ (TokyoTyrant) Webサーバー Webサーバー Webサーバー Internet キャッシューサーバー (memcached) Webサーバー LVS(ロードバランサ) システム構成 ( インフラ ) ■ KLab のシステム構成
  39. 39. ■ KLab のシステム構成 Ganglia によるモニタリング 監視対象も追加できる
  40. 40. アプリ固有コード KLabSocialGamePlatform 高速画像合成ライブラリ (KGD) Flash合成ライブラリ Symfony APC ■ KLab のシステム構成 システム構成 ( アプリケーション )
  41. 41. <ul><li>Symfony を大幅に改造した独自フレームワークを使用 </li></ul><ul><ul><li>必要ない機能を省いて軽量化 </li></ul></ul><ul><ul><li>開発効率の向上 </li></ul></ul><ul><li>Opensocial 用の独自ライブラリ </li></ul><ul><li>画像合成、 Flash 合成は高速化改造済み PHP エクステンションを使用 </li></ul>■ KLab のシステム構成
  42. 42. 背景画像 ボディ画像 表情画像 ドレス画像 髪型画像 ■ KLab のシステム構成 画像合成について
  43. 43. <ul><li>キャッシュは非効率 + 必要ない </li></ul><ul><li>1 ユーザー (50KB) × 100 万 </li></ul><ul><ul><li>合成したアバター画像だけで、 50GB </li></ul></ul><ul><li>Memcached へのキャッシュ : 非現実的 </li></ul><ul><li>ローカルファイルへのキャッシュ </li></ul><ul><ul><li>メモリにキャッシュできないため I/O アクセス増加 </li></ul></ul><ul><ul><li>むしろ遅くなる </li></ul></ul>■ KLab のシステム構成
  44. 44. <ul><li>素材ファイル </li></ul><ul><ul><li>数百から数千程度 </li></ul></ul><ul><ul><li>キャッシュ可能! </li></ul></ul><ul><li>画像ライブラリの高速化 + キャッシュなし </li></ul><ul><ul><li>高速改造版 GD ライブラリ KGD は、 DSAS Hosting for Social でも提供中! </li></ul></ul><ul><ul><li>http://www.klab.jp/dsas_host/kgd.html </li></ul></ul>■ KLab のシステム構成
  45. 45. <ul><li>ハードウェアベース </li></ul><ul><ul><li>CPU </li></ul></ul><ul><ul><li>メモリ </li></ul></ul><ul><ul><li>HD </li></ul></ul><ul><li>役割ベース </li></ul><ul><ul><li>DBサーバー(マスター / スレーブ) </li></ul></ul><ul><ul><li>キャッシュサーバー + キーバリューストレージ </li></ul></ul><ul><ul><li>Webサーバー(Apache, PHP) </li></ul></ul>かぎりあるリソースを有効活用する ■ リソース有効活用テクニック
  46. 46. <ul><li>なるべくデータベースに接続しない </li></ul><ul><ul><li>コネクション数をへらす </li></ul></ul><ul><li>データベースへの接続時間を短かくする </li></ul><ul><ul><li>クエリを最適化 </li></ul></ul><ul><ul><li>接続を切る </li></ul></ul>コネクションをへらす ■ リソース有効活用テクニック マスター DB 有効活用 処理時間をへらす
  47. 47. <ul><li>SQL最適化、DBサーバーチューニングの話は、ソーシャルアプリにかぎらないので省略 </li></ul><ul><ul><li>ほんとはとても重要 </li></ul></ul><ul><ul><li>I/Oアクセスをへらせ!とだけ言っておく </li></ul></ul><ul><li>DBコネクションの節約方法について話します </li></ul><ul><ul><li>キャッシュサーバーの利用 </li></ul></ul><ul><ul><li>KVSの利用 </li></ul></ul><ul><ul><li>スレーブDBヘの分散 </li></ul></ul><ul><ul><li>ソーシャルAPIに関する注意点 </li></ul></ul>■ リソース有効活用テクニック
  48. 48. <ul><li>効率的なキャッシュの利用 </li></ul><ul><ul><li>Memcached の最大接続数は数万から数十万 </li></ul></ul><ul><ul><li>秒間数万リクエストを処理 </li></ul></ul>アプリ(PHP) MySQL Memcached 先にキャッシュを検索 なければDBに問い合わせ DB更新時にキャッシュも更新 ■ リソース有効活用テクニック キャッシュの利用
  49. 49. ■ リソース有効活用テクニック Webサーバー Webサーバー Webサーバー Webサーバー Memcached APC キャッシュ
  50. 50. <ul><li>KVS( キーバリューストレージ ) の利用 </li></ul><ul><ul><li>更新の一部を KVS に分散する </li></ul></ul><ul><ul><li>KVS: 連想配列のような、キー + 値の形式でデータを保持するストレージ </li></ul></ul><ul><li>TokyoTyrant </li></ul><ul><ul><li>平林幹雄さん (mixi) 作 </li></ul></ul><ul><ul><li>Memcache に近い高速な処理 </li></ul></ul><ul><ul><li>エビクション ( データ消滅 ) の心配がいらない </li></ul></ul><ul><ul><li>http://fallabs.com/tokyotyrant/ </li></ul></ul>■ リソース有効活用テクニック KVS の利用
  51. 51. MySQL TokyoTyrant Memcached 高速 データ信頼性 レプリケーション 高度なトランザクション/ ロック機構 HDへの書き込みが保証される 基本はオンメモリ トランザクション/ロック機構なし エビクションによるデータ消滅 a HDにも書き込む レプリケーション エビクションなし データ不整合の危険 TokyoTyrant の特性 ■ リソース有効活用テクニック
  52. 52. <ul><li>頻繁に更新されるユーザーステータス </li></ul><ul><ul><li>体力 </li></ul></ul><ul><ul><li>アイテム装備情報 </li></ul></ul><ul><ul><li>ログイン情報etc. </li></ul></ul><ul><li>RDBの機能(ロック、トランザクションなど)が必要ないデータ </li></ul>■ リソース有効活用テクニック TokyoTyrant の使い道
  53. 53. <ul><li>TokyoTyrant と MySQL の間の不整合が起こりうる。 </li></ul><ul><li>アトミックな更新処理は困難 </li></ul><ul><li>ユーザーが得する方向で処理を行なう </li></ul><ul><ul><li>順番が重要 </li></ul></ul><ul><ul><li>(1)(2)(3) 、どのタイミングで例外が起きてもよいようにする </li></ul></ul>(1)ユーザーの利益になる処理 on TT: 体力回復 (2)MySQLへの更新処理: アイテム消費など (3)ユーザーの損になる処理 on TT: 体力消費 注意点 ■ リソース有効活用テクニック
  54. 54. <ul><li>スレーブ DB: マスターからデータをコピーした DB( レプリケーション ) </li></ul><ul><li>DB への参照をスレーブ DB に逃がすことで、マスター DB の負荷を減少 </li></ul>マスターDB スレーブDB スレーブDB スレーブDB ■ リソース有効活用テクニック スレーブ DB への分散
  55. 55. <ul><li>注意点 : 最新のデータがあるとはかぎらない </li></ul><ul><li>レプリケーション遅延はいつでも起こりうる </li></ul><ul><li>スレーブ DB を利用できるデータ : </li></ul><ul><ul><li>ランキングなど、更新が少なく、遅延が致命的でないデータ </li></ul></ul>マスターDB スレーブDB スレーブDB スレーブDB ■ リソース有効活用テクニック
  56. 56. <ul><li>ソーシャルアプリ = SNS APIを使用 </li></ul><ul><ul><li>ユーザー情報(ユーザー名、SNSフレンドデータ) </li></ul></ul><ul><ul><li>ユーザー投稿テキストの保存 </li></ul></ul><ul><ul><li>アクティビティ送信 </li></ul></ul><ul><li>SNSが提供するAPIの使用は避けて通れない </li></ul>■ リソース有効活用テクニック ソーシャル API の注意点
  57. 57. <ul><li>ガジェットサーバー経由の認証情報を利用し、 API サーバーに問い合わせる </li></ul><ul><li>API との通信は HTTP </li></ul><ul><ul><li>最短でも数十 ms のコスト </li></ul></ul>ユーザー ガジェットサーバー APIサーバー SAP ■ リソース有効活用テクニック
  58. 58. <ul><li>レスポンスタイムアウトは日常的に起こりえる </li></ul><ul><li>API 通信がつねに成功する前提でアプリケーションを開発してはいけない </li></ul>- トランザクション開始 - => APIに問い合わせ - トランザクション終了 危険なコード タイムアウトの場合、DBコネクションを 数秒間無意味に保持 通信が成功しても、 数十 ms 程度のロス ■ リソース有効活用テクニック
  59. 59. <ul><li>水平分割 / 垂直分割を利用 </li></ul><ul><li>データベースを複数に分割 </li></ul><ul><ul><li>機能単位の分割(垂直分割) </li></ul></ul><ul><ul><li>ユーザー単位など、データ単位の分割(水平分割) </li></ul></ul><ul><li>注意点は、KVSの利用に似てくる </li></ul><ul><ul><li>データ整合性がネック </li></ul></ul>■ リソース有効活用テクニック それでも足りない場合
  60. 60. <ul><li>マスター DB への接続をへらそう </li></ul><ul><ul><li>キャッシュサーバーを利用 </li></ul></ul><ul><ul><li>一部の更新を KVS など NoSQL に分散 </li></ul></ul><ul><ul><li>参照系の処理をスレーブ DB に分散 </li></ul></ul><ul><ul><li>API 通信に気をつけよう </li></ul></ul><ul><ul><li>垂直分割 + 水平分割の利用 </li></ul></ul>■ リソース有効活用テクニック まとめ
  61. 61. ご静聴ありがとうございました。 不明点はお気軽にお問い合わせください。 ■ 最後に・・・

×