Lampで作るソーシャルアプリの負荷対策～アプリとインフラの調和のテクニック～

LAMPで作る
ソーシャルアプリの負荷対策
～アプリとインフラの調和のテクニック～

KLab株式会社
森本隼
2010/07/14

Copyright 2010 KLab Inc. All rights reserved. 1

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

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


■KLab株式会社会社紹介

• 子会社KLabGames(株)にて
ソーシャルアプリを多数展開中！


■スピーカー紹介

KLab株式会社
プロジェクトマネジメント部グループリーダー
森本隼 (twitter @morimotoj)

• 2006年 KLab株式会社入社
• 元々、自社メディア事業/SNS事業の開発リーダーをやっていました
• 2009年秋よりソーシャルアプリ開発のプロジェクトマネージャーをし
ています
• 海釣りを趣味としております
• 大勢の人前で話すのが初めてなので緊張してます＞＜


■本論に入る前に

• 本発表は主にモバイルのソーシャルアプリを元にしていま
す
• PHPフレームワークはCakePHP/symfonyを利用していま
す
• 両フレームワーク共に負荷対策のため、様々な拡張を加
えて使っています
• が、今回時間が取れなかったので、カスタマイズに興味の
ある方はセミナー後に個別にご相談ください（＾＾；
• また、モバイルソーシャルアプリ向けのFlash合成について
も色々経験してきました
• こちらについてもセミナー後に個別にご相談ください（＾＾；

■今日話したいこと

対象者
•これからソーシャルアプリの開発をしようとしている技術者の方
•ソーシャルアプリの仕様は理解したけど実際にどんなところに
気を使う必要があるのか興味がある方
•ソーシャルアプリにおけるボトルネックを知りたい方

内容
第１章：なぜ高負荷対策が必要なのか？
第２章：高負荷対応しやすいインフラとは？
第３章：アプリケーションの高負荷対策とは？


■第１章

なぜ高負荷対策が必要なのか？


■リリース直後のソーシャルアプリ（恋してキャバ嬢）
デイリーPV
デイリーPV …1日のページ閲覧数の合計
最大秒間PV
最大秒間PV …1秒間のページ閲覧数が一日で最も多いときのページ閲覧数

デイリーPV 最大秒間PV
初日 566万 380
2日目 1288万 580
3日目 1311万 580

アプリがヒットした場合
秒間3000PVを超えるアクセスも（経験談）


■リリース直後のソーシャルアプリ

各プラットフォームとも約2000万人ものユーザーを保有
リリース初日から新着アプリとして露出
それを見たユーザーがこぞってアプリをインストールする

リリース直後から
高負荷対策が必要

■アプリが負荷で長時間ダウンしてしまったら

無料のアプリが多数存在
アプリがダウンしていても他のアプリがある
一度離れたら戻ってこない

mixiにて先行してリリースしたA社のアプリ。高負荷
が原因で1週間ダウン後発の同種のアプリにユー
ザー数を抜かれてしまい、その後の独走を許してし
まった


■モバイルソーシャルアプリ特有の5秒ルール

• モバイルソーシャルアプリはHTTP通信が5秒を超えると強
制的にエラーページが表示されてしまう
• 5秒を超えるエラーが3分間に1000回を超えるとプラット
フォーム側にてアプリに対して一時的なペナルティが課せ
られてしまう
– プラットフォームにてアプリをメンテナンス状態に切り替えられてしまう
– メンテナンス状態が解除されるまで、ユーザーはアプリを利用できない

応答に5秒以上掛かる状態は
アプリが落ちているのと同じ


■高負荷対策が必要な理由まとめ

1. リリース直後から大量のユーザーアクセスがある
2. アプリがダウンすると他のアプリへ浮気されてしま
う
3. 5秒の遅延が続くとアプリが自動でメンテになっ
てしまう

ソーシャルアプリを成功させるため
高負荷対策は必須！！


■第２章

高負荷対応しやすいインフラとは？


■ソーシャルのインフラに求められる要件

1.サーバーの追加/削除がしやすい
・WEBサーバーはインスタンスを増やしやすいこと
・DBサーバーは参照先のDBを増やしやすいこと
（更新DBの追加は工夫が必要）

2. モニタリング機能が充実している
・問題の予兆を的確に捉える


■KLabの場合

KLabが長年ノウハウを蓄積してきた
高負荷・大規模サイト構築用インフラ統合技術

ＤＳＡＳ
(Dynamic Server Assign System)

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


■使用しているソフトウェア

全てオープンソースによる構成

OS - Linux
ロードバランサ - LVS
WEBサーバ - Apache 2.2.x
開発言語 - PHP 5.2.x
DBサーバ - MySQL 5.1.x
キャッシュサーバ - memcached

■サーバースペック
最近構築したソーシャルアプリ用インフラのスペック例

■通常スペックサーバ
（WEBサーバ,キャッシュサーバ等に利用）
CPU：Xeon L3360
メモリー：2GBx4
HDD SATA：500GBx2

■ハイスペックサーバ（主にDBサーバに利用）
CPU：Xeon E5440 x2
メモリー：4GBx16
SAS HDD：146GB x8 Raid5

※ボトルネックになりやすいDBのIO周りには、高価な機材を投
ボトルネックになりやすいDBのIO周りには、高価な機材を
になりやすいDB
入しています

■サーバ構成
•WEBサーバは並列化可能で増設も簡易
•DBサーバはシングルマスタ/マルチスレーブ構成

DBサーバ
WEB Master
サーバ

DBサーバ
LVS WEB
Slave
（負荷分散）サーバ

WEB
INTERNET キャッシュ
サーバ
サーバ

■モニタリング機能について

トラフィック関係

各サーバーの
ロードアベレージ


■これで大丈夫？

スケールアウトさせやすいインフラであっ
ても、アプリケーションの作りがお粗末で
は負荷対策は不十分です


■第３章

アプリケーションの高負荷対策とは？


■負荷対応とは

高負荷対策とは、ズバリ！

HTTPの待ち行列を
取り除く
ことです


■負荷の正体
WEB/DBサーバ共に一度に接続できる
Connection数には上限がある

ロード WEB DB
バランササーバサーバ

○の部分でHTTPリクエストが
詰まると待ち行列が増えるこれが負荷の正体

コンポーネント間の接続時間をできるだけ短くし、
単位時間あたりのConnection数を増やす努力を
する！

■DBサーバの高負荷対策

まずはDBサーバの待ち行列を減らす

ロード WEB DB


■DBサーバの待ち行列を減らすには

WEBサーバはスケールアウトさせることで
負荷分散が可能だが、DBサーバは（更新
があるため）スケールアウトが難しい

１台のDBサーバで数多くの
リクエストを捌くためには？

アプリからDBにつないでいる時間
を極力短くすることが重要！

■DBサーバとの接続時間を短くするために

1. サーバパラメータをチューニングする
2. アプリからは高速なSQLだけ実行する
3. 遅いSQLを検出し、対策する
4. SELECTクエリをスレーブDBに逃がす
5. SELECT結果をアプリケーションでキャッシュする
6. アプリから明示的にDB接続を切断する


■1. サーバパラメータをチューニングする
DBサーバのメモリをMySQLに豊富に割り当てる
MySQLのデータがメモリに乗ることでディスクI/O
の頻度を減らすことが出来る

• 今回のサーバではテーブルやインデックスの
キャッシュ用に20GB割り当てています
• グローバルバッファとスレッドバッファに注意
- グローバルバッファ・・・インスタンスで1個だけ確保される
- スレッドバッファ・・・MySQLへの接続毎に確保される
参考：DSAS開発者の部屋：5分でできる、MySQLのメモリ関係のチューニング！
http://dsas.blog.klab.org/archives/50860867.html


■2. アプリからは高速なSQLだけ実行する

高速なSQLを実行するためのテーブル設計
1. レコード長を極力小さく
• 不要なカラムをもたない
• カラム長を極力小さく(intをやめてtinyintに等)
2. 不要になったデータは削除
• データ件数を減らして検索範囲を小さくする
3. 必要なインデックスのみ作成
• マルチカラムインデックスを活用


■2. アプリからは高速なSQLだけ実行する

高速なSQLを実行するために
1. インデックスの使用されないSQLを発行しない
2. 不要なJOINをしない
(O/Rマッパーを使っているときによく遭遇する)
3. 結果セットの大きくなるSELECTを発行しない


■3. 遅いSQLを検出し、対策する

slow_query_log
• 実行時間が閾値を超えるSQLを記録する機能
– 記録先はテーブルかファイルを指定可能
– インデックスが使われていないSQLも記録可能
– SELECT結果件数が閾値以上のSQLも記録可能

explain構文
• SELECT文の実行計画を表示する
– 遅いSQLをexplainで解析し、改修計画を考える


■4.SELECTクエリをスレーブDBに逃がす

マスタースレーブ
DB DB

Insert into hoge values(1,hoge); Insert into hoge values(1,hoge);

MySQLのレプリケーション機能
マスターDBの変更をスレーブDBに反映する仕組み
非同期処理のため、伝送遅延がおきる

前日のユーザーランキング等、遅延してもいい情
報をスレーブDBからSELECTすることでマスター
DBへの参照を軽減することが出来る

■5.SELECT結果をアプリケーションでキャッシュする

商品・アイテム等のマスタ情報は頻繁に値が
変わるわけではない

毎リクエストDBから取得する必要はない
一度取得したデータをキャッシュし、２度目以降はキャッ
シュから読み出すことでDBの処理を減らす


■6.アプリから明示的にDB接続を切断する

• PHPからのmysqlへの接続時間を短くする
• mysql_pconnect()を使用しない
• 時間のかかる処理の手前でDB接続を閉じる
• 外部API呼び出し前（OpenSocialAPI各種）
• 画像合成前
• 外部プロセス呼び出し前(exec(),proc_open()等)

mysql_connect() mysql_close() 時間のかかる処理

PHP PHP
実行開始実行終了

■DBサーバの待ち行列がなくなったら

ソーシャルアプリ全般においてDBサーバは
ボトルネックになりやすく、これが終われば
負荷対策の半分は終わったようなものです

WEBサーバは複数台並べることで負荷対策は
可能ですしかしサーバのランニングコストを圧
縮するためにも、より少ない台数で負荷を捌け
る方が望ましいです


■WEBサーバの高負荷対策

次にWEBサーバーの待ち行列を減らす

ロード WEB DB


■WEBサーバの待ち行列を減らすには

発想はDBサーバと同じ！

１台のWEBサーバで数多くのリクエスト
を捌くためには？

ユーザ（≒ガジェットサーバ）との
HTTP接続時間を極力短くする
ことが重要！

■WEBサーバとの接続時間を短くするために

1. APCを導入する
2. ユーザー情報をキャッシュする
3. プロファイルを取って現状を把握する
4. 画像合成を高速化する（案件個別のチューニング）


■1.APCを導入する

APC(Alternative PHP cache)
PHPのコンパイル結果をキャッシュを行う
拡張モジュール
• apc.shm_sizeにてキャッシュ用割り当てメモリを指定
• 環境によってはapc.statをoffにすることで
高速化する場合もあり

実はAPCにはもう一つの
便利な使い方が・・・

■1.APCを導入する

ユーザーキャッシュ機能
PHPの変数をキャッシュして別のリクエストで使いまわすことが出来る
→WEBサーバのメモリに保存するためSET,GETが非常に高速
→永続化されないため、一時的なキャッシュとしてつかうこと

$var = “hogehoge”;
//期限無しでキャッシュ
$result = apc_store(“key”,$var,0);
If($result ===true){
//キャッシュから値を取得
echo apc_fetch(“key”);
//キャッシュから削除
apc_delete(“key”);
}

■2.ユーザー情報をキャッシュする

モバイルソーシャルアプリの場合、
ユーザー情報をAPIで取得する必要がある

プラットフォーム

PeopleAPI etc… ユーザー
ソーシャル
情報
アプリ

友だち
情報



API呼出は時間のかかる処理なので取得結果を
一定期間キャッシュする仕組みを導入する。

キャッシュに適したデバイスの条件
・高速に読み書きできる
・WEBサーバ間で共有ができる

ＫＬａｂでは

memcachedを使用


memcached
メモリにデータをSET,GETするKVS

• 保存先はメモリのため高速
• RDBMSのような集計処理には使えない
• 永続化されないためmemcachedが停止するとデータ
も消える


■3.プロファイルを取って現状を把握する

それでも駄目ならプロファイリング！

• Xdebugを導入し、関数ごとの実行時間を取得する
• 取得結果をプロファイリングツールを使って解析する
(Windows・・・WinCacheGrind等）
• （呼び出し回数×実行時間）が大きい関数がボトルネッ
ク。
– ボトルネックを見つければ後は改善策を考えるだけ！

某アプリでは
画像合成処理がボトルネックになっていることが発覚

■4.画像合成を高速化する

恋してキャバ嬢のアバター画像合成処理

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

パーツごとの画像を読み込んで重ね合わせて合成
（利用ライブラリ:GD,ImageMagick）



• キャッシュを検討するもmemcachedの容量不足
• 1ユーザー(約50KB) × ユーザー数(200万（仮））
＝ 100GB

• 各WEBサーバのローカルにファイルキャッシュを試
したが、ディスクIOが上がって逆効果
• GD自体を改造して合成処理の高速化&キャッ
シュしない！



GDのネイティブ関数を改修
1. 画像の読み込み
• 画像読み込み関数のロジックを修正
2. 画像の重ね合わせ
• 画像コピー関数のロジックを修正
3. サムネイル画像の為の縮小
• 画像縮小関数のロジックを修正

ImageMagickを使い１～３まで500msecかかっていた案件でも
画像合成が100msec弱と、5倍以上高速化出来た。


■おわりに

本日のまとめ


■高負荷対策のまとめ

負荷対策とは
HTTPの待ち行列を取り除く行為
ロード WEB DB

• 初期開発時のみならず、機能追加や修正を行う毎に
待ち行列を作りやすい
• 負荷対策は、【待ち行列を発見→待ち行列の除去】を
繰り返す終りなき戦い
• アプリだけで頑張らずに時にはハードウェアへの積極的
な投資も検討する

■ご清聴ありがとうございました

質疑応答


Lampで作るソーシャルアプリの負荷対策～アプリとインフラの調和のテクニック～

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Lampで作るソーシャルアプリの負荷対策～アプリとインフラの調和のテクニック～

Semelhante a Lampで作るソーシャルアプリの負荷対策～アプリとインフラの調和のテクニック～ (20)

Mais de KLab株式会社

Mais de KLab株式会社 (10)

Lampで作るソーシャルアプリの負荷対策～アプリとインフラの調和のテクニック～