すまんがとは言ったが、あんまり申し訳ない気持ちは無い。高負荷によるアクセス制限が行われたというログは例の12/1のバースト時にしか残ってなかったから。503エラーが日常的に数千回も発生しているような慢性的なリソース不足の状態で制限が掛かってないというのも良くわからないんですが。対応策そもそもWordpressみたいにLLで作られたCMSはCPUリソース的にしんどいものがあります。根本的にはフロントエンドサーバを用意してキャッシュするしかないでしょう。Wordpressだとプラグインでキャッシュ機構を実現するようなものもありますが、Apacheの.htaccessやWordpress本体のソースを書き換えたりと危険な処理をするものが多いようなので、あまりそれらの方法は取りたくありません1。レンタルサーバではフロントエンドをどうこうするのは出来ないです。.htaccessで設定できるところまでが限界。HTTPを実はあんまりよく知らない(私はNginx原理主義者)ので.htaccessを頑張って設定すればphpの実行結果もキャッシュできるのかもしれませんが、頑張るモチベーションが生まれるほどにApacheが好きじゃない。それに、月間何十万PVもあってちゃんと収益化までできているブログを月500円かそこらのレンタルサーバに押し込んで皆に迷惑かけているという状況がそもそもアカンと思うので、VPSをどこかで借りてサーバ移行することとした。今年の2月にドメイン取っておいてよかった(運営開始から3年経ってようやく取った)。現状測定まずは現状を測定しましょう。サイト表示にかかる時間のベンチマークを取ります。Benchmark)コマンドが楽です(先ほどApacheをdisっておきながら)。apache2-utilsで入ります。Windowsとかは適当にどこかからバイナリを持ってきてください。対象URLという感じでテストできます。基本、ローカルで実施するためのツールと思いますが、リモートサイトを測定するときは-Bオプションで自分のIPアドレスを指定してあげないとダメみたいです。ちなみに、私のブログを対象にやらないでね。やったら容赦なく開示請求かける。これを使って、まずは共用サーバで動いている私のブログを測定してみました。いっても、あまり負荷掛けられないのでリクエスト送信数は数十回と少なめに。0.48RPS...。秒間1アクセスに満たない...。なんとなく想像してたけどこれは厳しい。Webサイトのレスポンスとしてはゴミの領域です。これアカンだろ...。早く気付けなかった...。ちなみに、ローカルマシンに構築したインストール直後のWordpressで33msec/30RPSといった感じでした。これはもちろん要求したURLに対する応答だけなので、実際のブラウザアクセスでは多数のAjaxリクエストが発生することを考えると体感速度はもっとひどいでしょう。VPS選定こんな遅いサーバではやってられません(遅くなった原因の一翼は自分にあるのですが)。VPSにさっさと引っ越します。EC2)かなぁといったところ。AWSの見積もりツールで色々やってみたが、EC2はリージョンが日本だとt2.microで$14くらいと結構安いのだけど、データ転送量が高い。1日10GBとして1か月300GBとすると、データ転送量だけで$41もかかるようだ。ぼええ?マジかあ?これみんな払ってんの?と思ってググってみると、これが原因で他サーバに乗り換えたという報告もちらほら。自分みたいな規模のサイトで運営するにはAWSでは全然スケールメリットがでないようだ。AWS便利ぃー!おっしゃれー!セクシー!みたいに絶叫しているエンジニアもずいぶん前から見かけたが、それなりの規模のソシャゲーとか運営しないとセクシーじゃないんだね。いう訳で庶民の味方(?)さくらVPS。1台VPSは契約しているので、もう一台契約する。高速化方法を色々検討したり、ググったりして調べた。結果、以下が有効と判断。参考にしたのが、下記の@ITの記事。FastCGIだけかな、と私は判断。ブログはほとんどが静的なコンテンツである。Wordpressではアクセスのたびにデータベースアクセスを経て同じHTMLをphpで生成している。アクセスのたびにIOの発生にphpの実行。ここの処理をバイパスできるのは非常に大きい。今回はそれに加えてphp7.0にしたが、これは単にphp5.xシリーズのサポートが終わっており、Ubuntu16.04でphpパッケージをインストールすると標準が7.0系になっていることによる。5.xから7.xでパフォーマンスの改善もかなりあるらしいが、キャッシュを導入すればあまり恩恵は無い(最悪値は改善される)。ちなみに、上記記事では1100%の高速化、22830%の高速化などと勇ましいことが列挙されているが、データやプラグインがふんだんに入り、かつインターネット越しにアクセスするような実環境ではここまでの効果は望めないと思われる。13300RPSというすさまじい値になった。これだけやれば実サイトでは十分だろう。その他にもWordpress向けに特別チューニングした仮想マシンイメージとかクラウドサービスなどがあるようだが、私にとっては知識があってかつ汎用的な環境(Ubuntu)で運用することに意味があるので、こういうものは最初から選ばなかった。特殊化を進めるとトラブルがあったときに困るので。【超簡単!】Ubuntuで作る手間いらずのほっこりnginx+wordpress環境!というふざけた名前の記事で解説していたのだが、この内容はすでに古いので以下に書きなおした。Ubuntuで作る高速WordPress運用環境のまとめサイト移行WordPressの移行作業はそんなに苦労しない。やり方は色々あるのだけど、ようはDBを復元したうえでwordpressのディレクトリ一式をコピーすれば良いです。クリーンインストールしたい場合は、wp-content以下を復元すれば良いはずです。移行時にちょっと面倒なのがDNSの設定です。サーバ移行時にはドメインに紐づくサーバのIPアドレスを変更します。移行先のwordpressサイトが完全に復元できてからドメインに紐づくIPアドレスを変更したい...と思いますよね?しかし、Wordpressの設定を復元した段階でこれは不可能になります。Wordpressは内部に設定されたドメイン名をしつこく使用してこようとします。そのため、DNSのIPアドレスを更新する前に管理画面に入ろうとしても、現状のサイトに飛ばされてしまいます(伝わるかな?)。一時的に移行先のサーバのIPアドレスを直接指定しておきましょう。wp-config.phpにdefine(&#039;WP_HOME&#039;,&#039;http://123.456.789.012/&#039;);define(&#039;WP_SITEURL&#039;,&#039;http://123.456.789.012/&#039;);という設定をしておけば、移行先のサイトの管理画面にIPアドレス指定でログインすることができます。移行作業が終わったらこの設定を削除すれば元に戻ります。私はバックアップにUpdraftPlusプラグインを使っているので、このプラグインをつかって復元します。上記の仮設定をしたうえで、wp-content/updraft/以下のバックアップファイルをコピーします。その後、UpdraftPlusの管理画面から復元ボタンを押せば復元できます。DNSレコード更新DNSのAレコードとAAAAレコード(IPv6)を新サーバに移行します。浸透するまで数分~数十分かかるのでちょっと待ちましょう。OSでDNSキャッシュしている場合はクリアしてください。このブログは新しいサーバで動いていますが、Windowsは(そして最近のUbuntuディストロも)ローカルにDNSキャッシュを持つので、しばらくたたないと新サイトにはつながりません。強制的にDNSキャッシュクリアするにはなんかコマンドがあったはずですが忘れました。適当にぐぐってみてください(Windows嫌いなので適当)。request)'''秒間221アクセスです。ちなみにこれは、Wifi接続されたノートパソコンからリモートサーバーに対してアクセスして測定した結果です。こんな感じでだいたい500倍くらいになりました。うーん、正直もうちょっと早くなっても良いかな?と思いましたが、ローカルで(VPS内部で)テストしたら秒間1万アクセスくらいは平気で出るので、もう回線のボトルネックでしょう。大きなサイトでもない限り、秒間250アクセスという値は十分に高性能と言えるんじゃないでしょうか。まとめ今回はサイトの負荷増を確認してからサイト移行まで実質作業時間3時間程度というなかなかすばやい動きだったように思います。子供が寝てる横でVPSの設定とかしてたぜ。これが30代子持ちエンジニアだっ!分かったか!分かったらさっさと寝ろ!ちなみに、Wordpressの話題を扱うブログでよく「良くわからずにキャッシュを使うのは危険」などという話が書いてありますが、正確にはキャッシュが危険なのではなくてWordpressのキャッシュプラグインが危険なのだと思います。投稿ナビゲーションUbuntuで作る高速WordPress運用環境のまとめ【質問#87】anoparaブログのレイアウトや運用環境についてanopara作者:withpop昼はサラリーマン。頑張れば何でも出来る。