Recommended
More Related Content
What's hot
What's hot (20)
Similar to 初心者向け負荷軽減のはなし
Similar to 初心者向け負荷軽減のはなし (20)
初心者向け負荷軽減のはなし
- 2. 自己紹介 株式会社NDPマーケティング メディア事業部 本部長兼CTO 大西 貴聡 twitter @taka0024 Facebook taka0024 はてなID taka0024jp 主な仕事 Webサイトのプロデュース、 プランナー、ディレクション、マネージメント、S テスト、サイト運営、企画作成、コンサルティング、flash作成、画像作成、コーディン
- 3. 宣伝① NDPマーケティングの主な事業 • リスティング広告全般（PC、モバイル) • SEO キャッシング • 各種アフィリエイト リスティング • 各種メディア運営 リスティング • スマフォ向け広告媒体 ＳＥＯ キャッシングす るならどこが良 いだろう？ リスティング
- 4. 宣伝② ツイナビアプリにて絶賛公開中 デザインはテスト中のモノです。
- 5. はじめに • 今日話すのは初心者向けの内容となります。 – 負荷軽減を今から進めるに当たり、どんな部分に着 目すべきかを話します。 • 負荷軽減は色々なコスト削減に繋がります。 • 様々なアプローチでバランスが大事となりま す。 – プログラミングだけでは完結しません – DBだけ見るものでもありません – クラウドだけでは解決しません。 • サーバーサイドとクライアントまでの全てが対 象です。 – つまり、実行される環境を全て見る必要がありま す。
- 6. アンケート１（貴方の立場はどれに当てはまります か？） • プロデューサー • ディレクター、マネージャー • SE • プログラマー • その他
- 7. アンケート２（貴方はどれに当てはまります か？） • 受託開発 • 社内システム開発 • 自社サービス開発 • その他
- 9. アジェンダ • ある日突然負荷軽減して欲しいと言われた ら・・・。 – 見える化から始めよう – 費用対効果から見つめよう – SQLを見なおそう • 今から負荷軽減を意識してWebサイトを作ると したら – サーバー構成を考えよう – トラフィックを考えよう
- 10. おことわり • あまり今回はソースコードに関する説明はしま せん。（プログラムコードに期待していた方ス イマセン） • 概要などに留めている為、コアな話は少ないで す。 • LAMPの構成の話をしますが他の環境下でも互換 性がある様に話す様努めます。 （nginx+phpのカリカリの構成を期待してる方ゴ メンナサイm(__)m）
- 11. ある日突然負荷軽減して欲しいと言われた ら・・・。
- 12. 2009年4月某日 • 某携帯SNSゲームサイト運営会社よりサーバー負荷が酷 いので、助けて欲しいと依頼を受ける • 全てのプログラムを作り直せば負荷が減るのでは？ (運営会社社長の意見）
- 13. それからが地獄の日々でし た・・・。 ●|￣|＿
- 14. 当時の状況 • 日中はサクサク表示でき快適 • 夜8時を超えると負荷が激しくサイトが重くなる • 独自フレームワークがかなりの曲者 （当時でも対応する選択肢が数限られる制限の温床だった） • まだ当時はクラウドとの相性に関して判らない 時期 （クラウドに詳しい人をアサイン出来づらかった）
- 15. サーバー構成（うる覚え・・・。） Internet LVS Web Web Web Web DB1 DB2 DB3
- 16. Webプロデューサーの立場からの視点① 新規の企画で 狙えるはずの売上 当該的な負荷での売上ロス 現状の企画で 見込めるはずの売上 実際の売上
- 17. システムの負荷とは・・・。 • CPU • メモリ • ロードアベレージ • トラフィック • ディスクアクセス etc 起こっている問題点に対して、 対応する事が大きく異なる
- 18. まずは見える化から（全てのサーバーを監視せ よ！） 簡単に負荷を調べる方法→TOPコマンドを打つ ２４時間目視で監視は出来ない そこで カクタイ ムーニン などのMRTG系のツールを導入する
- 19. やっぱりボトルネックになっていたのはDBでし た。 • なぜかテーブル単位で垂直分割が行われていた （ただしテーブル数を平均化する形で各サーバーに分散しただけでした。） 一部のDBサーバーに集中して負荷が発生していた。 • セッション管理を全てDBで行なっていた。 • 若干古いMySQLを利用していた。
- 20. DBの垂直分散と水平分散とは・・・。 • 垂直分散とは 全てのテーブルを列単位で見て分割する事 αテーブル A～Eカラム F～Zカラム サーバー１ サーバー2 α －１ α －2 テーブル テーブル •JOINが苦手（どうしてもJOINしたいテーブル同士は同じサーバー内にしなければならな •元々使っているテーブル数が多い場合には有効な場合もある •負荷の状況に応じて、分散計画を立てやすいので、都度変更に応じられる （ただし、本来の仕様を必要に応じて変える事が出来ない場合は、それ以上望めない）
- 21. DBの垂直分散と水平分散とは・・・。 • 水平分散とは テーブルを行単位で見て分割する事 １～１０００行 サーバー１ β －１テーブル βテーブル サーバー2 β －2テーブル １００１行～ •元々取り扱うデータ量が多いテーブルで有効 •分散方法（パーティション）をレンジ、リスト、ハッシュなどから選べるが、 mysqlの場合上限は1024個まで •DB自体の機能として実装してないものもある。
- 22. 当時の対処方法（主にDBについて） • MySQLを最新の安定稼働するものに入れ替え • テーブル単位で垂直分割を見直し負荷を均等化 – 一部はJOINしているテーブルがあったので、 その関係性は維持できる様に考慮した。 • DBサーバーが不足していたので随時追加する 上記を繰り返し最終的にはDBサーバーが10台ぐらいになりました。 （Webサーバー１０台 memcached ３台 バッチ１台） • 実行SQLを全て見直し、負荷がかからないSQLに変更 • 実行するSQLから分析してINDEXを貼り直した。 • 部分的にmemcacheを導入して、SQL実行負荷を抑えた。
- 23. Webプロデューサーの立場からの視点② ユーザー数を増やす方法 •広告 •ソーシャル etc 集客する Webサイ 離脱してしまう ト サイトに訪れる その要因 •ターゲットとしてるユーザー層違 い •ユーザーの趣向違い •つまらない •サイトが重い etc
- 24. 費用対効果から見つめよう • ソースやロジックを直すと運営コストは下がる が、対応までに時間がかかる • サーバーを追加すれば、その運営コストが上が る 今ならクラウドを利用して、先にサーバーを追加して 後からソースやロジックを見直す方法論が効果的
- 25. 今ならこうするDB負荷分散１ • マスタースレーブ構成＋ memcached 当然、書き込み負荷が高い場合は有効的ではありません。 MySQLだったら・・・。 master masterはブラックホールエンジンを 使う slave slave masterのバイナリログ書き出し場所 をRAMディスクとする（MySQLの場 合） ランキングなどの再生成が可能で、 memca 参照が多くて揮発性の高いデータなどを 定期的にキャッシュ生成させる ched （マスタ系のデータはマスタ更新時にキャッシュ化させ るなど、タイミングが超重要！） 当然sessionはmemcachedを使いDBに格納なんてしません！
- 26. • 水平分散によるマルチマスタ構成 master slave ユーザー毎に使うマスターを変える 為、 1 1 中間的にハッシュ用途のDBを用意 (HASH) 参照先を動的に替えられる様にする DB サーバーを増やした場合は、 ハッシュの値を更に分散するだけで master slave 対応が早くできる 2 2 key-value ストアがオススメ •TokyoCabinet / TokyoTyrant •Kyoto Cabinet •MongoDB などなど・・・。
- 27. SQLを見なおそう • どんなSQLが遅くなる要因でしょうか？ – 無駄にINDEXが多いテーブルへのinsert、update、 delete – 大量にカラムがあるテーブルへの全行取得 – 大量に行があるテーブルへの大量行の取得 – JOIN句の多用 etc だけじゃない！
- 28. SQLを実行して判るもの • 例えば・・・。 SELECT hoge FROM foo ORDER BY RAND(); こんなの実装してあったら怖い・・・。 実装してやがった！
- 29. どうすればSQLを効率的に見直せるか１（MySQLの場 合） • long_query_timeを設定している状態でスロー ク エリ ログを取る（なるべく本番上が望ましい） →長時間やると負荷にもなります。 • mysqlsla http://www.hackmysql.com/mysqlsla • MyProfi http://myprofi.sourceforge.net/ • Query Analyzer https://www-jp.mysql.com/products/enterprise/query.html などの解析ツールを使って出現頻度などから、 遅くなるものを分析→改善候補①
- 30. どうすればSQLを効率的に見直せるか２（MySQLの場 合） • 通常のクエリ ログを取る （なるべく本番上が望ましい） →こちらも長時間やると負荷にもなります。 先ほどの解析ツールを使って出現頻度を調べる →改善候補②
- 31. 改善候補のSQLに対して • ①の場合 – SQL構文自体を見直し、改善点を探る。 （この時ORマッパーを使っているシステムだと最 悪！） – テーブル構造に誤りがないかを探る。 （当然JOIN句が多いものは必然的に出てくる） – 計画的にindexを再生成する • ②の場合 – memcacheに格納出来そうな場合は、それを利用する
- 33. サーバー構成 AWS内 Webサーバー DBサーバー （master） ロードバランサー DBサーバー （slave） Webサーバー DBサーバー （slave） ロードバランサーを除く全てのサーバーは64bit構成 点線表記はオートスケールで増えるサーバーとアクセス構成 VPS ×20台
- 34. サーバー構成を考えよう • 最近のサービスで求められる要求 – 大量のデータ（主にDB）を扱う – トラフィックをどの様にさばくか – 画像合成、flash生成などのコスト – APIを使う
- 35. 開発時に意識した点 • ゲーム内でキーワードが含まれるツイート数を ゲーム実行時から60分前までの有効数としてカ ウントする • AWSを使ってクラウド環境を確保したので、ト ラフィックによる従量課金のコスト （さくらのクラウドがあれば・・・。） • フューチャーフォン向けのサービスなので、携 帯までのパケットの流れ （いまさらフューチャーフォンですが・・・。）
- 36. APIを使うサイトの場合 • APIを利用する場合、利用者元のIPから実行回数 の制限が行われている その分サーバーを用意すべし。 (今回はVPSを20台用意しました。) ただし速度要求が無ければクラウドに
- 37. トラフィックをさばく方法 • HTMLを徹底的に圧縮 （一般的にはgzipを使うけど・・・。） – 空白スペースの除去 – 無駄な改行の除去 – HTMLコメントの除去 – カタカナは全て半角にする • VPSを再利用→画像サーバーとして使う VPS１ VPS２
- 38. 具体的なテクニック（ HTMLを徹底的に圧縮 ） • Smartyのプラグインを使った場合の例です。 <?php function smarty_outputfilter_cutpacket($output, &$smarty){ $output = preg_replace('/ss+/',' ',$output); $output = preg_replace('/[tnr]/','',$output); $output = preg_replace('/<!--.*-->/U','',$output); $output = mb_convert_kana($output, 'ka', 'SJIS-win'); return $output; } ?>
- 39. 具体的なテクニック（画像サーバーに振り分け る）1 <?php function smarty_function_imgserver($params, &$smarty) { return imgserver::get_imgserver(); } class imgserver { private static $list = array('http://01. hoge.jp', 'http://02.hoge.jp'); private static $server = null; public static function get_imgserver() { if ( !self::$server && is_array(self::$list) && count(self::$list) ) { self::$server = self::$list[mt_rand(0,count(self::$list)-1)]; } return self::$server; } } ?>
- 40. 具体的なテクニック（画像サーバーに振り分け る）2 <div><img src="{imgserver}spacer.gif" height="10" /></div> <div>ﾌﾞｯｸﾏｰｸはこのﾍﾟｰｼﾞにしてね</div> <div><img src="{imgserver}spacer.gif" height="10" /></div> 同じサーバーを参照する フューチャーフォンでは、１ページ100kb以内の制約があるので、 １ページに複数の画像が参照されるといっても、数種類とかの場合は、 同じ画像が参照されるケースでのDNSサーバーの名前解決を優先した方が得策
- 41. まとめ１ • 負荷軽減は結構地道な事をやって成果が出ま す。 検証 仮説 実施 既存のシステム改修で出来ないケースもあり得る ので、 新規開発毎に意識していく事で、プログラムスキ ル を磨いたり、アーキテクトを学ぶ経験になりま
- 42. まとめ２ • クリティカルな部分を見極め、そこから改善し ていく勇気！ プログラマー視点で見てしまうと、 感覚で気になる部分だけに目が行きがちですが、 ログを検証しながら進める事が大事です。
- 45. ご清聴ありがとうございました。