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

Copyright 2010 KLab Inc. All right reserved.

2010/9/24 　 KLab 株式会社　

K ラボラトリー高田敦史　第 2 開発部　新田祐介

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


■ 会社紹介

• 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


• ユーザー固有のデータ– 大量

• ゲーム内ステータス ( 体力、経験値など )

• アイテム所持情報• 課金、購入ログ

–更新頻度 : 高い• ボタンを押すだけでステータス変化• 大量のログ

• 高頻度 + 大量の HTTP リクエスト (更新系 )

よくある高 ARPUなソーシャルゲームモデルを想定

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


ミニゲーム結果

アイテム購入

他ユーザーを応援

アプリケーション


大量の更新リクエスト


マスター DB

スレーブ DBスレーブ DBスレーブ DB

Web サーバーWeb サーバーWeb サーバーWeb サーバー

1台に負荷が集中！

分散可能


マスター DBへの負荷集中


• データベース ( 特にマスター )– 最大コネクションは数百程度– 負荷分散も難しい

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

ソーシャルアプリで重要なリソース



モバイルサイトモバイル向けソーシャルアプリ

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

リクエスト数少リクエスト数多

参照 ( 多 ) > 更新 (少 ) 参照 ( 多 ) = 更新 ( 多 )


モバイルサイトとの比較


• ソーシャルアプリ = 大量の更新系リクエスト

• マスターデーターベースに負荷が集中し、ボトルネックになりがち


まとめ


•ＤＳＡＳ– 高負荷・大規模サイト構築用インフラ統合技術• オープンソースベース• 単一故障点が存在しない高信頼構成• 容易なメンテナンス・柔軟なスケーラビリテ

ィ• 充実した監視機構とモニタリング

http://www.klab.jp/dsas/

■KLab のシステム構成


マスター DB スレーブ DB

KV ストレージ(TokyoTyrant)

Web サーバー

Web サーバー

Web サーバー

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

Web サーバー

LVS(ロードバランサ )

システム構成 ( インフラ )




Ganglia によるモニタリング

監視対象も追加できる


アプリ固有コード

KLabSocialGamePlatform

高速画像合成ライブラリ(KGD)

Flash 合成ライブラリ

Symfony

APC


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


• Symfony を大幅に改造した独自フレームワークを使用–必要ない機能を省いて軽量化– 開発効率の向上

• Opensocial 用の独自ライブラリ• 画像合成、 Flash 合成は高速化改造済み P

HPエクステンションを使用



背景画像ボディ画像

表情画像ドレス画像髪型画像


画像合成について


• キャッシュは非効率 + 必要ない• 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 の最大接続数は数万から数十万– 秒間数万リクエストを処理

アプリ (PHP)MySQL

Memcached

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

DB更新時にキャッシュも更新


キャッシュの利用



Web サーバー

Web サーバー

Web サーバー

Web サーバー

MemcachedAPC キャッシュ


• KVS( キーバリューストレージ ) の利用–更新の一部を KVS に分散する– KVS: 連想配列のような、キー +値の形式でデータを保持するストレージ

• TokyoTyrant–平林幹雄さん (mixi) 作– Memcache に近い高速な処理–エビクション (データ消滅 ) の心配がいらな

い– http://fallabs.com/tokyotyrant/


KVS の利用


MySQL TokyoTyrant Memcached

高速データ信頼性

レプリケーション

高度なトランザクション / ロック機構

HDへの書き込みが保証される

基本はオンメモリ

トランザクション /ロック機構なし

エビクションによるデータ消滅

aHD にも書き込む

レプリケーション

エビクションなし

データ不整合の危険

TokyoTyrant の特性



• 頻繁に更新されるユーザーステータス– 体力– アイテム装備情報–ログイン情報 etc.

• RDB の機能 (ロック、トランザクションなど ) が必要ないデータ


TokyoTyrant の使い道


• TokyoTyrant と MySQL の間の不整合が起こりうる。• アトミックな更新処理は困難• ユーザーが得する方向で処理を行なう

– 順番が重要– (1)(2)(3) 、どのタイミングで例外が起きてもよいようにする

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

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

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

注意点



• スレーブ DB: マスターからデータをコピーしたDB( レプリケーション )

• DBへの参照をスレーブ DB に逃がすことで、マスター DB の負荷を減少

マスター DBスレーブ DBスレーブ DBスレーブ DB


スレーブ DBへの分散


• 注意点 : 最新のデータがあるとはかぎらない• レプリケーション遅延はいつでも起こりうる• スレーブ DB を利用できるデータ :

– ランキングなど、更新が少なく、遅延が致命的でないデータ

マスター DBスレーブ DBスレーブ DBスレーブ DB



• ソーシャルアプリ = SNS API を使用–ユーザー情報 (ユーザー名、 SNS フレンドデ

ータ )–ユーザー投稿テキストの保存– アクティビティ送信

• SNS が提供する API の使用は避けて通れない


ソーシャル API の注意点


• ガジェットサーバー経由の認証情報を利用し、API サーバーに問い合わせる

• API との通信は HTTP– 最短でも数十ms のコスト

ユーザー

ガジェットサーバー

API サーバー

SAP



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

ョンを開発してはいけない

- トランザクション開始 - => API に問い合わせ - トランザクション終了

危険なコードタイムアウトの場合、 DB コネクシ

ョンを数秒間無意味に保持通信が成功しても、数十ms程度の

ロス



• 水平分割 / 垂直分割を利用• データベースを複数に分割

– 機能単位の分割 (垂直分割 )–ユーザー単位など、データ単位の分割 (水平

分割 )

• 注意点は、 KVS の利用に似てくる–データ整合性がネック


それでも足りない場合


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


まとめ


■ 最後に・・・

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

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

Technology