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

1Copyright 2010 KLab Inc. All rights reserved.

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

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


■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合成についても色々経験してきました

• こちらについてもセミナー後に個別にご相談ください（＾＾；


■今日話したいこと

第１章：なぜ高負荷対策が必要なのか？

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

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

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

•ソーシャルアプリにおけるボトルネックを知りたい方

対象者

内容


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

■第１章


■リリース直後のソーシャルアプリ（恋してキャバ嬢）

デイリーデイリーデイリーデイリーPVPVPVPV …1日のページ閲覧数の合計

最大秒間最大秒間最大秒間最大秒間PVPVPVPV …1秒間のページ閲覧数が一日で最も多いときのページ閲覧数

最大秒間PVデイリーPV

5801311万3日目

5805805805801288万2日目

380380380380566万初日

アプリがヒットした場合

秒間3000PVを超えるアクセスも（経験談）


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

各プラットフォームとも約2000万人ものユーザーを保有

リリース初日から新着アプリとして露出

それを見たユーザーがこぞってアプリをインストールする

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


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

無料のアプリが多数存在

アプリがダウンしていても他のアプリがある

一度離れたら戻ってこない

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


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

• モバイルソーシャルアプリはHTTP通信が5秒を超えると強制的にエラーページが表示されてしまう

• 5秒を超えるエラーが3分間に1000回を超えるとプラットフォーム側にてアプリに対して一時的なペナルティが課せられてしまう– プラットフォームにてアプリをメンテナンス状態に切り替えられてしまう

– メンテナンス状態が解除されるまで、ユーザーはアプリを利用できない

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


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

1. リリース直後から大量のユーザーアクセスがある

2. アプリがダウンすると他のアプリへ浮気されてしまう

3. 5秒の遅延が続くとアプリが自動でメンテになってしまう

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


■第２章

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


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

1.サーバーの追加/削除がしやすい

・WEBサーバーはインスタンスを増やしやすいこと・DBサーバーは参照先のDBを増やしやすいこと

（更新DBの追加は工夫が必要）

2. モニタリング機能が充実している

・問題の予兆を的確に捉える


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

■KLabの場合

詳しくは http://www.klab.jp/dsas/

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

ＤＳＡＳ(Dynamic Server Assign System)


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

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

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


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

■サーバースペック

CPU：Xeon E5440 x2

メモリー：4GBx16

SAS HDD：146GB x8 Raid5

■通常スペックサーバ（WEBサーバ,キャッシュサーバ等に利用）

■ハイスペックサーバ（主にDBサーバに利用）

CPU：Xeon L3360

メモリー：2GBx4

HDD SATA：500GBx2

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


■サーバ構成

WEB

サーバ

LVS

（負荷分散）

INTERNETWEB

サーバ

WEB

サーバ

DBサーバ

Master

DBサーバ

Slave

キャッシュ

サーバ

•WEBサーバは並列化可能で増設も簡易

•DBサーバはシングルマスタ/マルチスレーブ構成


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

トラフィック関係

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


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

■これで大丈夫？


■第３章

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


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

HTTPの待ち行列を取り除く

ことです

■負荷対応とは


WEBサーバ

DBサーバ

ロードバランサ

■負荷の正体

WEB/DBサーバ共に一度に接続できるConnection数には上限がある

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

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


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

WEBサーバ

DBサーバ


■DBサーバの高負荷対策


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

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

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

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


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

1. サーバパラメータをチューニングする

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

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

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

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

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


■1. サーバパラメータをチューニングする

• 今回のサーバではテーブルやインデックスのキャッシュ用に20GB割り当てています

• グローバルバッファとスレッドバッファに注意- グローバルバッファ・・・インスタンスで1個だけ確保される

- スレッドバッファ・・・MySQLへの接続毎に確保される

参考：DSAS開発者の部屋：5分でできる、MySQLのメモリ関係のチューニング！http://dsas.blog.klab.org/archives/50860867.html

DBサーバのメモリをMySQLに豊富に割り当てるMySQLのデータがメモリに乗ることでディスクI/Oの頻度を減らすことが出来る


■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

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

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

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


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

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

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


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

• PHPからのmysqlへの接続時間を短くする

• mysql_pconnect()を使用しない

• 時間のかかる処理の手前でDB接続を閉じる

• 外部API呼び出し前（OpenSocialAPI各種）

• 画像合成前

• 外部プロセス呼び出し前(exec(),proc_open()等)

PHP

実行開始

PHP

実行終了

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


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

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

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


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

WEBサーバ

DBサーバ


■WEBサーバの高負荷対策


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

発想はDBサーバと同じ！

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

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


1. APCを導入する

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

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

4. 画像合成を高速化する（案件個別のチューニング）

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


■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自体を改造して合成処理の高速化&キャッシュしない！



1. 画像の読み込み

• 画像読み込み関数のロジックを修正

2. 画像の重ね合わせ

• 画像コピー関数のロジックを修正

3. サムネイル画像の為の縮小

• 画像縮小関数のロジックを修正

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

GDのネイティブ関数を改修


■おわりに

本日のまとめ


WEBサーバ

DBサーバ


■高負荷対策のまとめ

負荷対策とはHTTPの待ち行列を取り除く行為

• 初期開発時のみならず、機能追加や修正を行う毎に待ち行列を作りやすい

• 負荷対策は、【待ち行列を発見→待ち行列の除去】を繰り返す終りなき戦い

• アプリだけで頑張らずに時にはハードウェアへの積極的な投資も検討する


質疑応答

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

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

Technology