突然WordPressで作った当サイトが重くなり暴走気味になりました。
解決に至る経緯からわかった3つのチェックポイントをメモ代わりに生地にしておきたいと思います。
暴走WEBサイトいったい何が？
日中は順調で、記事を重ねて追加し、順調におアクセスが伸びていました。
しかし、夕方以降、突如として過負荷状態となりました。
考えられる原因を列挙してみる
まずこのような際は考えられる原因を思いつく限り列挙してみます。
最終的にはこれらを一つずつつぶしていくことで解決に向かうはずです。
過剰なアクセスによる過負荷
ｎまずは一番考えられるのは過剰なアクセスです。
よくあるのがツイッターなどのSNSでいわゆるバズったときや、ヤフーニュースなどで取り上げられた時などに、一時的にアクセスが集中しサーバーがパンク状態になることがあります。
しかし、今回の場合、昨日より多少アクセスは増えたとはいえ自然増のレベルで、突如としてアクセス不能になるくらいのアクセスには見えません。
不正アクセスなどによる過負荷
SynFloodなどに代表されるいわゆる不正アクセスなどによって過負荷状態になる状態です。
これであれば、そのようなアタックを遮断した時点で正常に戻ります。
アクセスログなど、サーバーに書き出される様々なログに特徴的な記録が残ります。
また、一応、WAFやFail2banなどで、必要な不正アクセスに対する対処を行っていたことから可能性は高くはないと考えていました。
実際に、アタックを受けていた場合そのままにしておくのは危ないため、WEBサーバーおよびDBをストップさせたうえでサーバー内のログから調査した結果、不正アタックと思われるような記録が出てこなかったこと、また、パケットキャプチャを行い、過負荷状態の際の通信などを確認したところ、やはり現状で不正アクセスだと思われる通信は確認できませんでした。
WordPressの問題による過負荷
こちらについては不正アタックにもつながりますが、管理画面に対してのログインアタックや、コメント投稿によるアタックなど、WordPress固有による不正アタックで、見た目上は不正に見えないようなアタックなどが中心になりますが、WordPressの使用による過負荷というのが考えられます。
こちらについては、WordPressコアやプラグインなどのバージョンが古い場合によくありますが、その際の現状では基本的にすべてが最新で、つい最近のWordPressのコアアップデートによって、プラグインのアップデートも自動アップデートが可能になり、ONにしたばかりでした。
さらには、サーバーでWAF（WebApplicationFirewall）も稼働していて、最低限既知のアタックであれば検出できますが、それらしい検出はありませんでした。
サイトがトラブったらチェックしたい3つの項目
このような過負荷状態になった場合、確認したいことは3つです。
その3つを順番に確認し、解決へと向かうべきです。
サーバーの状況確認
mrtgなど、サーバーの状態を確認するツールを導入しているのであれば、即座にまずはサーバーの状態を確認しましょう。
サイトを見ようとしたら重いというだけではもしかしたら自分が利用しているインターネット接続プロバイダのトラブルで、通信事態が重いという可能性が否めません。そういう場合はYahooやGoogleへの接続も重いはずです。
一番わかりやすいのは当該サーバーの負荷状況を確認することです。
こちらの画像は実際の負荷状況です。
CPUの利用率を見ていただくとわかりますが、左端のほうにグラフが跳ね上がっている場所があると思いますがこれが、突如として起きた負荷です。この前までは、多少使用率は高いとはいえ即座に重くなるレベルではありませんでした。
その下のグラフが、CPUのロードアベレージです。
安全な状態というのはこのロードアベレージの数字がCPUコア以下である場合です。
その時点で当サーバーはAWSのLightsailの2番目のプランでCPUコアは1個でしたのでロードアベレージ1以下というのが快適な負荷状況となります。
突如として重くなってからは、平均しても5以上、多い時で20くらいになっており、これは【ロードアベレージ／コア数】倍通常時より重いということにつながりまs。
1コアですから、最大で20倍重い状態になったということです。
もともと低スペックなサーバーでしたからサイト自体が1~3秒程度で表示するレベルでしたので実にひどい場合は1分近く表示までに時間がかかっており、タイムアウトになるケースもあったものと思われます。
次に右側グラフですが、こちらはメモリです。
過負荷状態から解消されたあたりからグラフが一気に伸びた状態になっていますが、これはサーバーのグレードを上げたところです。
その手前を見ると、メモリが１GBに対して900MB程度使用していることになっていまs。
ようは、メモリは足りていないことがわかります。
よく見ていただくとわかるのですがグレードアップしてメモリを６GBに増設した状態にしたとたん、メモリの使用量が1GBを超えていまs。
ようは、メモリは慢性的に足りておらず、処理に時間をかけていたことがわかります。
アタック・過剰なアクセスを疑ってみる
大量の通信が発生すれば必然的に表示に重さが出てくるのは当然です。
これが、正当な通信であれば、それはサーバーのスペック不足ということですし、不正アタックなら不正アタックを遮断することで負荷が提言するはずです。
なので、負荷状況が確認出来たら次はその負荷の原因です。
アタックは確認できずアクセスが急増した感じでもない。。。
アタックについては、先述の通りログを確認しても不正と思しき記録がなかったこと、パケットキャプチャをしても、不正な通信に見える通信はなかったことでアタックの可能性は低くなりました。
次にあるのは突如アクセスが集中した可能性です。
負荷がかかっているという状況ではありますが、見ている限りでアクセスが急激に増えた感じではありませんでした。
WordPressの変更に気を付けて確認してみる
最後はこれです。
そういえばちょうどそのタイミングであのプラグインをインストールしたとか、設定を変更したとかが一番可能性が高いのです。
相性の悪いプラグイン同士を動かしてしまっているなどがあった場合、1アクセスでも重くなることはたまにあります。
現状で、順調に動いていた状態の際とアクセス量が違いがなくアタックも確認できなかったのを考えるとこの可能性が一番高いのです。
しかし、今回、新しくプラグインを導入したり、設定を変更したりはしていませんでした。
アップデートについてもコアアップデートをその日にやったわけでもなくプラグインについても同様です。
原因発見！原因はWordPress新機能にあり！
今回、突き詰めたところ、1回あたりのアクセスで、phpにかかる負荷が、サーバーの10%以上、同時プロセスを10個立ち上げている関係から、10アクセスあった時点でCPU使用率が100%を超え、超えた分は待機状態になるので、順番待ちとなり、結果重くなることはわかりました。
また、1人だけがアクセスしている分には重くなりませんが、3人くらいでいくつかのページを閲覧すると重くなることがわかりました。
このパターンは、WEBサイトの改ざんでよくみられることから、ヘッダやフッタなどに何か変なコードを入れられているのではないかと思い確認しましたが何もされておらず、通信内容をキャプチャしてみても変な通信は起きていませんでした。
しかし、なぜPHPが重くなるのかわかりませんでした。
WordPressの場合最も疑わしいのはMySQLなので、DBサーバーを当該サーバーから外部のサーバーに変更してみたところ、負荷がなくなりました。
これで感じたことは、DBサーバーを移転したら軽くなったのであれば、WEBサーバーとDBサーバーが同じサーバーであれば負荷が過剰になるということなので、明らかなサーバーのスペック不足であろうと思いました。（スペックは元々足りていませんでしたが、結果的にこれが直接の原因ではありませんでした。続きをお読みください。）
そこで、今回、当該サーバーをアップグレードしました。
メモリ１GBだったものを６GB、CPUは1コアだったものを2コアのプランにグレードアップしました。
その結果当該問題は一気に解消しました。
これで一安心したのですが、それでもサイトは多少もっさりしていて何か不満が残る感じでしたので、もう少し調べてみました。
原因はマシンリソースにあらず！答えは○○だった！
マシンスペックは20年前当時のサーバースペックレベルですから幾分か重いサイトであることは認識していました。
しかしながら、負荷というのはアクセスに比例して負荷状況がひっ迫してきて、要はグラフ的にはなだらかな上り坂になっていってどこかのタイミングで重くてサイトが見ていられないという状態に徐々になっていくものだと思っていました。
しかし、今回スペック不足が露呈するのが突然で、突然壁が高くなったイメージでした。
20年以上サーバー運用を経験していて今回こんな感じでスペック不足が露呈したのが初めてでしたので、何か納得のできない感じでした。
そこで、今一度WordPressに何かあったのではないかと思い、このトラブルが起きた日に、Wordpressで何をしたか再度詳細を思い出してみました。
少なくとも、プラグインやコアについては何もしていませんでした。
記事は50記事程度追加しましたが、この記事でバズったものがあるわけではありません。
2日前からアクセスが倍増して、マシンへの負荷が気にはなっていましたが、この倍増したものがさらに倍増したわけではないので2日前に動いていたのであれば今日も動くレベルでした。
それ以外では、新機能によるプラグインの自動アップデートをONにしたくらいです。
そうなのです。直接の原因はこれでした。
なぜわかったのかというと、ブログ記事を書くと自動的にツイッターに投稿してくれるプラグインがトラブル解消後から動かなくなったことからわかりました。
どういうことかというと、サーバーのスペックを上げたことで、問題は解消したように見えましたが実は解消していませんでした。
スペック内で許容できているだけで、根本的な問題は解決していなかったのです。
このツイッターへ投稿してくれるプラグインは、新しい記事が書きだされた際に、ツイッターへの投稿を行うのですが、この投稿については、投稿時に行うのではなく、新記事投稿後にサイトにアクセスがあった際に、wp-cronを利用して新記事があった場合に投稿してくれるのです。
ようは、記事を書いてもツイッターに投稿しないということは、wp-cronに問題が生じているということなのです。
そこで、wp-cronの状態を確認するプラグインを入れてみたところ、サイトへのアクセスが多く、毎回アクセスがあった際にwp-cronが稼働し、スケジュールを見ながら処理をするのですが、処理が終わる前に次のアクセス、次のアクセスと、アクセスが来るため処理が追い付かずwp-cronがエラーで止まるという状態でした。
これはいったいどういうことなのか？よく考えたら、プラグインの自動更新をONにしたことでこうなったようでした。
プラグインの自動更新をONにすると、サイトへアクセスがあるたびに、wp-cronを通じて、Wordpressのサーバーにつなぎ、プラグインの更新状況をチェックし、更新のあるプラグインがあったら自動的にアップデートをかける機能です。
どのプラグインかわかりませんが、もしかしたらチェックに時間のかかるプラグインがあるのかもしれません。
今回修正として、wp-cronはアクセスによって実行する仕様から、Linuxのcrontabで、サーバー側でcronだけを切り離して定期実行するように設定を変更しました。WEBサーバーからのアクセスはなくなります。
これによって、負荷がなくなり、さらには実際にWEBサイトへアクセスした際の表示までの測ぞも3倍増しました。
wp-cronが問題を起こす前からもwp-cronによって速度が遅かったのだろうなということまで推測されます。
もし、皆様のお使いのサーバーで定期実行が可能なのであれば、wp-cronは、アクセスから切り離されることを強くお勧めいたします。これによって、プラグインを入れたら重くなったというのがかなりなくなることが想定されます。
