本番環境で使いたいPHP

2,093 views
2,036 views

Published on

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,093
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

本番環境で使いたいPHP

  1. 1. 本番環境で使いたいPHP LOCAL  PHP部 勉強会   佐藤琢哉
  2. 2. 自己紹介•  佐藤琢哉  •  @nazo  •  最近スマホアプリ開発してます  
  3. 3. 今回の内容について•  本番環境でPHP使ってますか?  •  どうやって使ってますか?  •  金がないけど微妙に負荷がある環境とか 困るよね  •  そんな感じ  •  ソーシャルゲームみたいな超負荷の環境の 話はしません  •  EC2の話もしません
  4. 4. ケース別・本番運用の方法ケース1:レンタルサーバー
  5. 5. レンタルサーバーの定義•  借りているサーバー  •  root権限はもらえない  •  SSHできるかどうかは不問
  6. 6. レンタルサーバーでどうにかなるの?•  どうにかなるからレンタルサーバーを選ん でいる   –  お金だけが理由でレンタルサーバーを選ん じゃうのはちょっと…   –  実はサポートをする手間が省ける(サーバー 自分でいじれる人にはあまりない発想)  •  今時はVPSも安いので、「サーバーの面倒 見れるけど金がない」という人はVPSで
  7. 7. レンタルサーバーでできること•  .htaccessでの設定   –  できない場合もある   –  チューニングと呼べるほどの設定はない  •  フレームワーク等のキャッシュ設定   –  今回の話ではないけど…   –  ちゃんと設定すると大幅に速度UP   –  WordPress等でも
  8. 8. .htaccessで設定できる項目•  http://jp.php.net/manual/ja/ini.list.php  •  PHP_INI_SYSTEM”以外”の項目  •  もちろん.htaccess自体が使えないといけな い  •  正直ここでどうにかなることはほとんど ない
  9. 9. DBのインデックスの見直し•  必ずやろう(全然速度が違うよ!)  •  少ないデータでもそこそこ効果あり  •  検索クエリそのものを見直すのもあり  
  10. 10. その前にインデックスって何?•  索引  •  大量のデータから検索する処理を高速化 するための補助データ  •  本の目次
  11. 11. インデックスの考え方•  プライマリキー=インデックス   –  つまりプライマリキーで検索しているものは 既にインデックスが効いている  •  つまりプライマリキー以外で検索している ものを洗い出してインデックスを確認する  •  困った時はEXPLAIN
  12. 12. キャッシュによる高速化•  「何もしないプログラムは一番速い」  •  できるだけ「何もしない」に近づける  •  難しい処理を最初にしておいて、その結果 だけを読み込むのが「キャッシュ」  
  13. 13. キャッシュの方法•  フレームワークに付属の機能を使う  •  PEAR::CacheやZend_Cacheなどを使う  •  MemcachedやMongoDBなど  •  MySQLなど(DB)  •  自作
  14. 14. どういうところがキャッシュでき る?•  HTML部分のうち、毎回ほぼ同じものが出 てくるもの   –  例えば1日に1回しか変わらないランキング を、呼び出し毎に毎回計算していたら無駄  •  計算結果があまり変わらない部分  
  15. 15. どのキャッシュシステムを使う?•  再生成コストがどのくらいかかるか  •  どのくらい再生成するか  •  どのくらいの負荷がかかるか  •  どのくらいの永続性が必要か  
  16. 16. ケース別・本番運用の方法ケース2:VPS1インスタンス
  17. 17. そこそこ本格的•  基本的に1台の中であれば何でもできる  •  最近は安いのでホイホイ借りれる  •  メモリと予算のバランスが難しい   –  最低でも1Gはほしい   –  Virtuozzo系は避けよう  
  18. 18. Apacheのチューニング•  そんなにできることは多くない  •  メモリがきついケースが多いので、余計な モジュールは読み込まないようにしておこ う  •  mod_expire等で、静的コンテンツへのリ クエストをできるだけ減らす  
  19. 19. MySQLのチューニング•  ここも劇的に変わるようなことは少ない   –  台数が多くなると話が変わってくるよ  •  my-­‐****.confから適当に選ぼう
  20. 20. そもそもチューニングするために•  ボトルネックの調査 –  メモリが限界?スレッド数が限界?CPUが限 界?   –  ベンチマークすると怒られるよ   –  Munin  /  Cacti  等を入れる  
  21. 21. 低メモリVPS対策•  低メモリVPS=突然プロセスがこける   –  Apacheとか突然死して帰ってこないことがあ る   –  Virtuozzo系に顕著(スワップがないので)  •  Monitを入れておいて自動復帰させる
  22. 22. プログラム側の高速化•  cronが使えるので、重たい処理は別プロセ スで行うことができる  •  Webからのアクセス時に不要な処理はcron で外出しすると、ユーザー側の見栄えがい い  •  ただしトータルの処理量はそれほど変わら ない  
  23. 23. PHPアクセラレータ•  いろいろあるけど、現在の主流はAPC   –  APC以外を使う理由はほとんどない  •  apc.stat  は通常は  1  でいい   –  0にしたほうが多少高速になるけど管理が面倒   –  負荷が急なところだと初回アクセス時に死ぬ  •  よほどの理由がない限りは入れておこう   –  EC-­‐CUBEとか入れると動かなくなるよ  
  24. 24. ケース別・本番運用の方法ケース3:4台くらいのサーバー
  25. 25. 分散できる?できない?•  どう考える?  •  4台の役割
  26. 26. 今までどこがボトルネックだった のか•  いきなり4台構成にしていない場合は、今 までの監視結果からある程度把握できて いるはず  •  PHPが重いならPHPサーバーを多めに、 DBが重いならDBサーバーを多めにする
  27. 27. 全サーバーに同じものを入れる•  全てに均等に割り振りたいという発想  •  実際はDBが全部均一の役割にすることが できないため微妙  •  4台程度だと、静的コンテンツサーバーと PHPサーバーを別にするメリットはあまり ない
  28. 28. お金に余裕があるのでちゃんと バックアップしたい•  正解  •  4台程度だと、分散による効果はあまり 期待できない  •  それよりバックアップが大事  
  29. 29. サーバーにApache以外•  Nginx  +  php-­‐fpm   –  速度は出るけど…   –  何かあったときにちゃんと対応できる?  
  30. 30. ぼくのかんがえたさいきょうのわ りふり•  A:Web(PHP+静的コンテンツ)サーバー  •  B:DBマスターサーバー  •  C:DBスレーブサーバー+監視+ログ+ バックアップ  •  CにはAからのDBアクセスは行かない (バックアップに無理はさせない)  •  Dは?
  31. 31. 4台あると皆さんならどうします か?•  考えてみましょう
  32. 32. ケース別・本番運用の方法ケース4:16台くらい
  33. 33. 分散する前提•  何を何台割り当てるか  •  4台の時同様、全部に同じものを載せる 方法も無くはない  •  このあたりはもう専門的な知識が必要な ので、ちゃんと調べよう
  34. 34. ハードウェア構成を考える分岐点•  現代ではEC2などのクラウドサーバーを使 うことが多い   –  台数を増やすのが簡単だよ  •  物理サーバはかゆいところに手が届く   –  仮想サーバはIOはそこまで速くないよ  
  35. 35. PHP部分は4台の時と同じ考え•  どこが負荷があるのか  •  台数が多いので、cronで動かすサーバーだ けでも複数台設定することが可能  
  36. 36. まとめ
  37. 37. 構成を考える前に•  何故その構成にする必要があるのか   –  監視をする   –  計測をする  •  予算…
  38. 38. PHPプログラムをちゃんと   チューニングしよう•  サーバー台数を増やして解決=金  •  台数が少ないうちは地道に解決  •  台数が一定数を超えると、増やしただけ では解決しない  •  快適な環境は快適なプログラムから  
  39. 39. DBをチューニングしよう•  負荷の大半はDB  •  インデックスがちゃんと有効か  •  IO処理が入ってないか  •  どうしても処理しきれなくなったら分散  
  40. 40. 「金で解決」は   最後の手段!
  41. 41. おわり

×