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