こんにちは。wevnalの大城です。

社内で運用しているメディアサイトが最近、表示が遅いとの連絡を受けサーバーを引っ越ししました。備忘録として残します。

目次

1.移行前の状態
2.移行先の環境構築
3.パフォーマンス調査
4.サーバーを引っ越しする

1.移行前の状態

移行前は、wpXクラウドを利用しておりました。
wpXクラウドは

wpXクラウドは、WordPressに最適化した圧倒的な高速環境を、より手軽かつ柔軟にご利用可能としたサービスです。初期費用無料、月額500円～(税抜)で始めることができ、ご利用の状況に合わせて全7段階の拡張が行えるため、フレキシブルなWordPress運用が可能です。

とのことで、メディアの立ち上げ時期などでコストを抑えたい時には向いているかと思います。

実際にwpXクラウドにて運用していた時は通常時5万/日PV程度で、ページ表示速度の遅さにより離脱も発生している状況でした。
また、弊社メディアは定期的にプッシュ通知も行なっております。プッシュ通知から引き上がってくるアクセスで15万/日PV程に達することもしばしばあり、CPU負荷が高まりページが表示されないこともありました。
wpXクラウドでは、転送量・容量毎にグレードが別れていますが、グレード間での物理的なサーバースペックに違いはないとのことでした。
そのため、今回のようなプッシュ通知からの引き上がりによる急なアクセスのような場合は、グレードアップでもCPUスペックやメモリが向上するわけではないため、ページ表示が遅くなる問題をなかなか解決できないという状況でした。

2.移行先の環境構築

前述の問題を解決するため、サーバーを柔軟に構成できるAWS（EC2+RDS）にて再構築することにします。
AWSにてWordPressを構築するにあたり、高速なWordPressサーバーを簡単に構築できると言われているKUSANAGIを利用します。

KUSANAGIサーバーとは

超高速WordPress仮想マシン「KUSANAGI」はあなたのWordPressサーバを通常の約10倍の速さにブーストさせます。ぜひこの速さをご体験ください。

KUSANAGIにはAWS用のイメージが無料で配布されています。すごい。
他にもGCPやらAzure、さくらクラウド向けのイメージもありますね。ほんとすごい。

KUSANAGIの公式ドキュメント通りに進めてサーバーも数分で立ち上げることができました。今後、WordPressサーバー作る時に重宝しそうです。

KUSANAGIの恩恵を最大限受けるために、キャッシュも合わせて設定します。
KUSANAGIにはキャッシュが2つあります。
fcache→nginxのキャッシュ
bcache→WordPressのプラグインによるキャッシュ
fcacheは、Webサーバーレベルのキャッシュのため、WordPressへのアクセスが発生しないため、より高速にページを表示させることが可能です。

kusanagi fcache on
kusanagi bcache on

KUSANAGIキャッシュについては以下の記事にて丁寧に説明されています。
https://blog.simmon.design/kusanagi-cache-tutorial/

3.パフォーマンス調査

パフォーマンス調査のために、先ほど作成した移行先環境にnewrelicを導入します。
newrelicはアプリケーションのパフォーマンスを調査できるサービスで、登録から１４日間のトライアル期間中は無料で「Pro」版と同様の機能が使用できます。

newrelicのトライアル版では関数の処理にかかった時間やDBアクセスにかかった時間などが可視化されるため、容易にパフォーマンスの調査が可能です。調査の結果、WordPressに導入している「WordPress Popular Posts」プラグインでの処理がボトルネックになっていることが判明しました。
「WordPress Popular Posts」プラグインは、サイト内のサイドバーに人気記事のリンクを簡単に表示させることができるプラグインです。人気記事をランキング形式で表示することができるのですが、ランキングを作成するためにアクセスをDBへ保存するため、アクセスが多いサイトの場合はDBアクセスがボトルネックとなります。

プラグインの設定で、データサンプリングという項目があります。
こちらの設定がデフォルトでは「無効」となっており、毎回DBへアクセス内容を保存しています。
サンプリングを有効にし、サンプル率を推奨値の100に設定することで、体感でかなりのスピード改善ができました!!

多分、というか、ほぼ確実にwpXクラウドでもページの表示が遅かったのは上記プラグインの設定によるものでした。
wpXさん、ホントすみませんでした。

参考：https://abikosan.com/wordpress_popular_postsga_tool

googleのスピードテストでも問題なさげ。

wpXクラウドでの表示スピードがそこそこ改善されたので、このままwpXで運用するでもよかったのですが、
さすがにプッシュ通知時のアクセス負荷は対応できないだろうということで、引き続き、引っ越しの準備を進めます。

4.サーバーを引っ越しする

wpXクラウドからAWS(KUSANAGIサーバー)へ引っ越します。
サーバーの引っ越しは、以下の手順で実施します。
1. ソース取得(wpXクラウド)
2. DBダンプデータ取得(wpXクラウド)
3. AWSのEC2へソースアップロード、RDSへDBダンプデータの流し込み（AWS）
4. DNS変更(お名前.com)

ここで注意すべきポイントが４のDNS変更です。

wpXクラウドにて独自ドメインを運用する場合は、ネームサーバーをwpXクラウド側に設定します。
そのため、一旦wpXクラウドからお名前.comのネームサーバーを使用するように設定変更する必要があります。
レンタルサーバー側だとNSレコードのTTLがどのくらい設定されているか確認できないため、デフォルトの86400秒(=1日)と仮定して、長くても2日間はwpXクラウド(旧サーバー)、AWS(新サーバー)の2つにアクセスが分散すると想定しました。そのため、この２日間はメンバーの作業はストップしてもらうような調整が必要でした。

作業後１〜2日経って、
・nslookupとかdigでNSレコードがお名前に変更されていること
・wpXクラウド側にアクセスがないこと
が確認できたら、AWSへのサーバー引っ越し完了です。

AWS for KUSANAGIでのスピードもみて見ました。

最適化部分での問題はあるものの、スピードには問題はなさそうです。

この後、プッシュ通知から引き上がってくるアクセスを捌くための構成を追加していきます。
プッシュ通知対策としての
・Route53設定
・CDN(cloudfront)導入
など、高負荷対策とSSL化のための
・AWS Certificate Manager(ACM)設定
・ELB設定(証明書を設定するためにEC2の前段に配置)
対応を行なっております。

こちらについては改めて記事を書きたいと思います。