サーバーを東京に移転 & OpenLiteSpeedに変更で超高速WordPress環境を得た話
みなさん、おはこんにちばんは。
FRONTL1NE運営チームのFL1NEです。
以前の記事でお伝えした通り、ここ最近FRONTL1NEのWebサイトを動かしているサーバーの構成を変更しました。
行なったことは以下の3つです。
- FRONTL1NEのWebサーバー所在地をサウスカロライナ州(アメリカ)から東京(日本)に移転しました。
(画像などの静的アセットを配信するサーバーはまだ移転されていません) - Webサーバーソフトウェア(HTTPサーバー)をnginxからOpenLiteSpeedに変更いたしました。
(更なる速度改善のため) - 以上2つに伴うサーバーの再構築
変更の目玉はやはり「アメリカから東京に移転」と「OpenLiteSpeed」です。
これらの判断をするに至った経緯と、まだ「OpenLiteSpeed」と呼ばれるWebサーバーソフトウェアの知名度が日本で低いと思われるので、なぜOpenLiteSpeedで高速化できたのかと、OpenLiteSpeedとWordPressの連携に関する話などをしたいと思います。
ぜひ最後まで読んでみてください。
(ちなみにこの記事は設定方法というより概念的な内容が中心です)
以前の記事はこちら
以前の構成と現在のサーバー構成
FRONTL1NEのWebサイトはGoogle Cloud Platform + Cloudflareにて動作しています。
以前のサーバー構成
ゾーン : アメリカ オレゴン州ダラス(us-west1-a)
マシンタイプ : e2-small (vCPU x 2、メモリ 2 GB)
起動イメージ : WordPress with NGINX and SSL Certified by Bitnami and Automattic
Webサーバー : nginx
CMSソフトウェア : WordPress
キャッシュ系 : WP Super Cache (FastCGIキャッシュは使ってなかった)
CDNサーバー : Cloudflare
静的アセットサーバー : Google Cloud Storage (us-west1-a)
現在のサーバー構成
ゾーン : 日本 東京 (asia-northeast1-a)
マシンタイプ : e2-small (vCPU x 2、メモリ 2 GB)
起動イメージ : openlitespeed-wordpress
Webサーバー : OpenLiteSpeed
CMSソフトウェア : WordPress
キャッシュ系 : LiteSpeedCache
CDNサーバー : Cloudflare
静的アセットサーバー : Google Cloud Storage (us-west1-a)
サーバー構成に関する補足
CloudflareはTTFB(サーバー応答時間)を低下させるのですが、現状HTTPSとファイヤウォール機能相当などをCloudflareに一任しているためCloudflareは必須です。
また、WP Statelessプラグインで画像などをGoogle Cloud Storageにオフロードしていました、これを外して静的アセットをCloudflareにキャッシュさせたいのですがWP Statelessが思ったより深いところまで侵食しているため一旦そのままにしてます。
サーバーを国外から国内に移動させた理由
「やっぱり俺たちに光の速度は遅すぎた」
はい、そもそもなんでアメリカにあったのかと言うと、オンプレだと地震による停電の影響だとかをもろに受けてしまうのでクラウドに移行することになりました。
その際にGoogle Cloud Platformであれば無料枠があり、条件がアメリカのリージョンに設置することだったのです。
しかしながら、徐々にFRONTL1NEのサイトへのアクセスが増加したことで、無料枠であるf1-microインスタンス(vCPU x 1、メモリ 0.6 GB)では性能が不足し、コストパフォーマンスがよかったe2-smallに構成を変更しました。
しかし、ここで気がつきました。
「もう無料枠じゃないし、そもそもアメリカじゃなくて国内にサーバーおいたほうがよくない?」
ちょうどその時、FRONTL1NEがTTFB(サーバー応答時間)が長すぎる問題を抱えていました。
冷静に考えれば、日本からアメリカにアクセスするだけでping数百msもあるので、結局日本むけWebサイトのサーバーは日本に置くべきだと思います。
検証でアメリカに立てたインスタンスと日本国内に立てたインスタンスを日本国内のPCからアクセスした際のTTFBを比較したところ、日本のほうが200~400ms早いという結果となり、高速化の実証できたので実際に移行することにしました。
なぜHTTPサーバーにOpenLiteSpeedをチョイスしたのか
リージョン変更となるとほとんどインスタンスを組み直しとなるので、ついでにさらなる高速化としてHTTPサーバーにメスを入れられないか模索していました。
当時利用していたnginx + php-fpm環境にFastCGI Cacheを組み込んだり、プラグインでWP Super Cacheなどを利用することで速度向上が狙えることが判明していましたが、複雑化しやすいのと、WordPressはnginxよりApache向けに作られている側面があるため、両者のいいとこ取りができるようなサーバーを探していたところ見つけたのが
「OpenLiteSpeed」
です。
画像はLiteSpeed公式のベンチマーク結果よりOpenLiteSpeedは、Apache, IIS, nginxに次いで「第4のWEBサーバー」とも呼ばれている、「LiteSpeed Web Server」のオープンソース版です。
オリジナルのLiteSpeedは有償のソフトウェアなのに対し、OpenLiteSpeedではほぼ同等の機能を無料で利用できます。
LiteSpeedは2003年より開発が開始され、長いことあまり有名ではありませんでしたが、2016年頃からシェアが急上昇し一気に知名度が上がりました。
今ではHTTPの最新規格であるHTTP/3に対応したサイトの45.8%ほどがLiteSpeedで動いていると言われています。
(出典 :Distribution of web servers among websites that use HTTP/3 | W3Techs.com)
OpenLiteSpeedには様々な特徴がありますが、中でも
- Apacheのリライトルールや.htaaccessが流用できる
- WordPressで利用する場合、専用キャッシュプラグインと連携させることで爆速化可能
- 専用のWebUIから簡単に設定が行える
- HTTP/3やQUICなどの最新規格にも対応している
などが魅力です。
LiteSpeed公式サイトより中でもやはり魅力となったのは、WordPressを動かす際の速さが他の環境に比べ際立っていることです。
LiteSpeed公式サイトよりWordPressの実行速度のキモとなりやすいPHPの実行環境ですが、LiteSpeedでは、PHP LSAPIというもので動作しています。
これはApacheのmod_PHPと比較して50%ほど早く、nginxのPHP-FPMと比較すると75%ほども早いそうです。 (出典)
LiteSpeed公式サイトよりWordPressそのものに関しても「LiteSpeed Cache」という単体でも優秀なプラグインを組み合わせることによって高速化できます。
(LiteSpeed CacheはApacheやnginxなどでも利用できます)
またLiteSpeed CacheとLiteSpeedのWebサーバーを組み合わせることで、より高度なキャッシュやユーザーがページにアクセスする前にクロールをしてキャッシュを生成しておくプリロード機能なども使えて最強です。
さらにもう一つ、OpenLiteSpeedのいいところとしてWebサーバーの設定をWebブラウザからGUIを通じて簡単にできることです。
こちらの管理画面から、新たなバーチャルホストを定義したり、リスナーのドメイン名を設定したり、SSL/TLSの設定など、必要なもの全てがコントロールできます。
また、リアルタイム統計ツール等も付属しており、サーバーの状態監視などにも役立ちます。
あ、日本語表示デフォルトで出来ます。
まとめ & 終わり
これらによって、FRONTL1NEは速度的に「速い」と言えるサイトになりました。
(正確には「速い」と言えるサイトに戻った)
さらにチューニングを行うことでより高速化が測れると考えています。(クローラーの設定など)
問題となっていたTTFBの長さなども解決できたのでひとまずこれでよしとします。
しかしながら、この移行過程でサーバーの503エラーやリンクエラーなどの障害が発生した結果、どうやらGoogleから検索順位低下などのペナルティを受けたようです。
アクセス数はだいぶ落ち込んでしまいましたが、これから徐々に戻していけるように新記事の投稿などに力を入れていきます。
今後もFRONTL1NEの更なる進化・高速化などを行なっていきます。
ぜひ定期的に見に来てみてください!
では、ここまで読んでいただいてありがとうございました。
Google Cloud Platform エンタープライズ設計ガイド
