1. 本番環境で使いたいPHP
LOCAL
PHP部 勉強会
佐藤琢哉

2. 自己紹介
• 佐藤琢哉
• @nazo
• 最近スマホアプリ開発してます

3. 今回の内容について
• 本番環境でPHP使ってますか？
• どうやって使ってますか？
• 金がないけど微妙に負荷がある環境とか
困るよね
• そんな感じ
• ソーシャルゲームみたいな超負荷の環境の
話はしません
• EC2の話もしません

4. ケース別・本番運用の方法
ケース１：レンタルサーバー

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. どのキャッシュシステムを使う？
• 再生成コストがどのくらいかかるか
• どのくらい再生成するか
• どのくらいの負荷がかかるか
• どのくらいの永続性が必要か

16. ケース別・本番運用の方法
ケース２：VPS１インスタンス

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とか入れると動かなくなるよ

24. ケース別・本番運用の方法
ケース３：４台くらいのサーバー

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. ４台あると皆さんならどうします
か？
• 考えてみましょう

32. ケース別・本番運用の方法
ケース４：１６台くらい

33. 分散する前提
• 何を何台割り当てるか
• ４台の時同様、全部に同じものを載せる
方法も無くはない
• このあたりはもう専門的な知識が必要な
ので、ちゃんと調べよう

34. ハードウェア構成を考える分岐点
• 現代ではEC2などのクラウドサーバーを使
うことが多い
– 台数を増やすのが簡単だよ
• 物理サーバはかゆいところに手が届く
– 仮想サーバはIOはそこまで速くないよ

35. PHP部分は4台の時と同じ考え
• どこが負荷があるのか
• 台数が多いので、cronで動かすサーバーだ
けでも複数台設定することが可能

36. まとめ

37. 構成を考える前に
• 何故その構成にする必要があるのか
– 監視をする
– 計測をする
• 予算…

38. PHPプログラムをちゃんと
チューニングしよう
• サーバー台数を増やして解決＝金
• 台数が少ないうちは地道に解決
• 台数が一定数を超えると、増やしただけ
では解決しない
• 快適な環境は快適なプログラムから

39. DBをチューニングしよう
• 負荷の大半はDB
• インデックスがちゃんと有効か
• IO処理が入ってないか
• どうしても処理しきれなくなったら分散

40. 「金で解決」は
最後の手段！

41. おわり