Successfully reported this slideshow.

初心者向け負荷軽減のはなし

13,781 views

Published on

  • Be the first to comment

初心者向け負荷軽減のはなし

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

×