本番環境で使いたいPHP

LOCAL  PHP部 勉強会  佐藤琢哉

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

今回の内容について •  本番環境でPHP使ってますか？  •  どうやって使ってますか？  •  金がないけど微妙に負荷がある環境とか困るよね  

•  そんな感じ  •  ソーシャルゲームみたいな超負荷の環境の話はしません  

•  EC2の話もしません

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

レンタルサーバーの定義 •  借りているサーバー  •  root権限はもらえない  •  SSHできるかどうかは不問

レンタルサーバーでどうにかなるの？

•  どうにかなるからレンタルサーバーを選んでいる  – お金だけが理由でレンタルサーバーを選んじゃうのはちょっと…  

– 実はサポートをする手間が省ける（サーバー自分でいじれる人にはあまりない発想）  

•  今時はVPSも安いので、「サーバーの面倒見れるけど金がない」という人はVPSで

レンタルサーバーでできること •  .htaccessでの設定  – できない場合もある  – チューニングと呼べるほどの設定はない  

•  フレームワーク等のキャッシュ設定  – 今回の話ではないけど…  – ちゃんと設定すると大幅に速度UP  – WordPress等でも

.htaccessで設定できる項目 •  http://jp.php.net/manual/ja/ini.list.php  •  PHP_INI_SYSTEM”以外”の項目  •  もちろん.htaccess自体が使えないといけない  

•  正直ここでどうにかなることはほとんどない

DBのインデックスの見直し •  必ずやろう（全然速度が違うよ！）  •  少ないデータでもそこそこ効果あり  •  検索クエリそのものを見直すのもあり  

その前にインデックスって何？ •  索引  •  大量のデータから検索する処理を高速化するための補助データ  

•  本の目次

インデックスの考え方 •  プライマリキー＝インデックス  – つまりプライマリキーで検索しているものは既にインデックスが効いている  

•  つまりプライマリキー以外で検索しているものを洗い出してインデックスを確認する  

•  困った時はEXPLAIN

キャッシュによる高速化 •  「何もしないプログラムは一番速い」  •  できるだけ「何もしない」に近づける  •  難しい処理を最初にしておいて、その結果だけを読み込むのが「キャッシュ」  

キャッシュの方法 •  フレームワークに付属の機能を使う  •  PEAR::CacheやZend_Cacheなどを使う  •  MemcachedやMongoDBなど  •  MySQLなど（DB）  •  自作

どういうところがキャッシュできる？

•  HTML部分のうち、毎回ほぼ同じものが出てくるもの  – 例えば１日に１回しか変わらないランキングを、呼び出し毎に毎回計算していたら無駄  

•  計算結果があまり変わらない部分  

どのキャッシュシステムを使う？

•  再生成コストがどのくらいかかるか  •  どのくらい再生成するか  •  どのくらいの負荷がかかるか  •  どのくらいの永続性が必要か  

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

そこそこ本格的 •  基本的に１台の中であれば何でもできる  •  最近は安いのでホイホイ借りれる  •  メモリと予算のバランスが難しい  – 最低でも１Gはほしい  – Virtuozzo系は避けよう  

Apacheのチューニング •  そんなにできることは多くない  •  メモリがきついケースが多いので、余計なモジュールは読み込まないようにしておこう  

•  mod_expire等で、静的コンテンツへのリクエストをできるだけ減らす  

MySQLのチューニング •  ここも劇的に変わるようなことは少ない  – 台数が多くなると話が変わってくるよ  

•  my-­‐****.confから適当に選ぼう

そもそもチューニングするために

•  ボトルネックの調査 – メモリが限界？スレッド数が限界？CPUが限界？  

– ベンチマークすると怒られるよ  – Munin  /  Cacti  等を入れる  

低メモリVPS対策 •  低メモリVPS＝突然プロセスがこける  – Apacheとか突然死して帰ってこないことがある  

– Virtuozzo系に顕著（スワップがないので）  

•  Monitを入れておいて自動復帰させる

プログラム側の高速化 •  cronが使えるので、重たい処理は別プロセスで行うことができる  

•  Webからのアクセス時に不要な処理はcronで外出しすると、ユーザー側の見栄えがいい  

•  ただしトータルの処理量はそれほど変わらない  

PHPアクセラレータ •  いろいろあるけど、現在の主流はAPC  – APC以外を使う理由はほとんどない  

•  apc.stat  は通常は  1  でいい  – 0にしたほうが多少高速になるけど管理が面倒  – 負荷が急なところだと初回アクセス時に死ぬ  

•  よほどの理由がない限りは入れておこう  – EC-­‐CUBEとか入れると動かなくなるよ  

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

分散できる？できない？ •  どう考える？  •  ４台の役割

今までどこがボトルネックだったのか

•  いきなり４台構成にしていない場合は、今までの監視結果からある程度把握できているはず  

•  PHPが重いならPHPサーバーを多めに、DBが重いならDBサーバーを多めにする

全サーバーに同じものを入れる •  全てに均等に割り振りたいという発想  •  実際はDBが全部均一の役割にすることができないため微妙  

•  ４台程度だと、静的コンテンツサーバーとPHPサーバーを別にするメリットはあまりない

お金に余裕があるのでちゃんとバックアップしたい

•  正解  •  ４台程度だと、分散による効果はあまり期待できない  

•  それよりバックアップが大事  

サーバーにApache以外 •  Nginx  +  php-­‐fpm  – 速度は出るけど…  – 何かあったときにちゃんと対応できる？  

ぼくのかんがえたさいきょうのわりふり

•  A:Web（PHP＋静的コンテンツ）サーバー  •  B:DBマスターサーバー  •  C:DBスレーブサーバー＋監視＋ログ＋バックアップ  

•  CにはAからのDBアクセスは行かない（バックアップに無理はさせない）  

•  Dは？

４台あると皆さんならどうしますか？

•  考えてみましょう

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

分散する前提 •  何を何台割り当てるか  •  ４台の時同様、全部に同じものを載せる方法も無くはない  

•  このあたりはもう専門的な知識が必要なので、ちゃんと調べよう

ハードウェア構成を考える分岐点

•  現代ではEC2などのクラウドサーバーを使うことが多い  – 台数を増やすのが簡単だよ  

•  物理サーバはかゆいところに手が届く  – 仮想サーバはIOはそこまで速くないよ  

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

まとめ

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

•  予算…

PHPプログラムをちゃんと  チューニングしよう

•  サーバー台数を増やして解決＝金  •  台数が少ないうちは地道に解決  •  台数が一定数を超えると、増やしただけでは解決しない  

•  快適な環境は快適なプログラムから  

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

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

おわり