My Blog
https://images.microcms-assets.io/assets/83abe3ff71704bde831915fd55332987/2978b7192e494d0183e8132d857d11fb/OGP%20(1).png
最終更新日:2/28/2023
#nginx
FastCGIキャッシュを導入してWordpressサイトの高速化

最終構成図

先に最終構成と成果を共有します。


成果

  1. NginxのFastCGIキャッシュを導入して、パフォーマンスが75倍速くなった。
  2. 3 Pods体制とし、zone a/b/c に分散配置させ可用性を向上させた。
  3. 独立したクラスターを新規に作成して、他のサービスに影響を与えない構成とした。

プロジェクト背景

昨年、マーケティング施策をホームページに公開した際に、公開ページに対するスパイクアクセスが発生し、ホームページが閲覧できない状況が数回発生しました。スパイクアクセスが発生するタイミングでサーバのリソースを消費しきっており、確認はしていませんが、同じクラスタ上で稼働している他のサービスにも影響を与えていた可能性もあります。

会社としてはLINEをマーケティングで活用していく方針で、ホームページへのアクセスは今後も増加する見込みであるため、ホームページはスパイクアクセスに耐えながらも、常に高いパフォーマンスを維持し続けることが求められています。

改善の方針

  1. ホームページがダウンしないようにする。
  2. 他のサービスに影響を与えないようにする。
  3. パフォーマンスを維持、向上させる。

上記1と2の方針から、ホームページは既存GKEクラスタから切り出し、別クラスタで運用することとした。また、新クラスタではGKEの新しい運用モードであるAutopilotを選択しました。

AutopilotによりGKEノードの運用管理をGoogleに任せることでのノードの運用管理負荷の軽減、稼働したPod単位の課金となることで、利用状況に応じたコストの最適化が見込まれます。

パフォーマンスの改善に関しては、GKEのHPAにて対応することを想定しています。加えて、OPcache（バイトコードキャッシュ）、APCu（ユーザーキャッシュ）を使用するという指示も受けてました。

検証結果の共有

アクセスによる負荷は何に負荷を与えるか？

  • テスト環境でab試験を実施した結果から、Wordpressに負荷をかけた時、負荷が大きく増えるのはメモリではなくCPUでした。

メモリ消費はなぜ増えた？

  • pm.max_children の設定値を4と50の2つで負荷試験を実施した結果、50にするとメモリ使用量が増加しました。
  • メモリを増やすのは、ワーカープロセスの数です。
  • 今回のシステムにおいては、CPUの使用量とメモリの使用量は連動しないことがわかりました。

テスト環境にてab試験をpm.maxchildrenの値を変えて実施。pm.maxchildrenのほうがパフォーマンスが良い結果となりました。

Time taken for test:

  • pm.max_children=80 -> 1303秒
  • pm.max_children= 4 -> 1203秒

pm.max_childrenの値が大きかったため、PHPのワーカープロセスが増え、それに伴いメモリ消費が増えていたと考えられる。新しい環境においては、Podのスペックに合わせて調整しました。

Pod数によるパフォーマンスの変化

検証環境にて、ab試験をPod数を変えて実行しました。結果は以下のとおりです。

ab -n 1000 -c 100 "http://xxx.xxx.xxx.xxx/"

Pod数だけでなく、Podのスペックを変えることでも、アクセスのスパイク時に対応するための検証を行っています。例えば、CPU数を2倍にすれば、テスト時間が半分になるといったように、Pod数を増やすことと同じ効果を確認しています。

ただし、スペックを高くすることで、平常時にスペックを持て余し、Podあたりのコストが上がってしまうため、この時点では、小さいPodを稼働させ、アクセスが増えたときにPod数を増やすことで対応することにしました。

腑に落ちない

ここまで検証をしてきて、おそらく最初にあげた3つの改善の方針は達成できると思いました。

  1. ホームページがダウンしないようにする。
  2. 他のサービスに影響を与えないようにする。
  3. パフォーマンスを維持、向上させる。

しかしながら、パフォーマンスについてはもっと効率的になる方法があるのではないかと思っていて、追加で調べてみることにしました。

FastCGIキャッシュ

Nginx + PHP-FPM + Wordpress 高速化といったキーワードで更に調査を進めると、FastCGIキャッシュというNginxのキャッシュ機能が効果が高いということがわかってきました。

まずはab試験の結果を共有します。

125倍高速化しました。。。Pod数を増やしたり、スペックを調整したりして色々検証していたのが吹っ飛ぶくらいのインパクトです。

FastCGIキャッシュとは？

FastCGIレスポンスを直接キャッシュする機能です。アクセスによりPHP-FPMが生成するWebページはNginxによって一定期間キャッシュされ、同じページへのアクセスに対してはこのキャッシュが返されます。キャッシュはNginxのメモリに保存され、メモリの容量がいっぱいになった場合、最も古いキャッシュが自動的に削除されます。また、キャッシュ保持時間も設定することができます。これにより、メモリがいっぱいになってPodがクラッシュすることを防ぐことができます。

決めた

以下のポイントでこのFastCGIキャッシュを即採用すべきと考えました。

  • 圧倒的パフォーマンス。
  • 処理に対する負荷は非常に軽く、特別にスペックを盛る必要がない。
  • 負荷が軽いため、スケールを気にする必要がなくなり、コストダウンを見込めた。

導入方法

詳細な導入方法は、ネット上にたくさんありますのでまるっと省きます。

本番環境での比較

旧環境と新環境に対して、以下の試験を実施した結果を共有します。

ab -n 1000 -c 100 "http://xxx.xxx.xxx.xxx/"

旧環境の結果

新環境の結果

試験結果は旧環境では、Time taken for a test が 347.492秒、さらに1000回の試験に対して 143回の失敗という結果になりました。一方、新環境では、Time taken for a test が 4.621秒、1000回の試験に対して 0回の失敗という結果になりました。同じ試験に対して約75倍高速化し、失敗回数も0になり、信頼性も高まる結果となりました。

まとめ

今回、FastCGIキャッシュを有効化することでホームページの高速化という結果を得ることができましたが、これは全てのケースで有効というわけではありません。Wordpressで運用していた当社のホームページの環境でNginx + PHP-FPM の構成でサーバー環境を構築していたこと、FastCGIキャッシュが動的ページのキャッシングと相性が良かったことなどいくつかの条件が重なり、大きな成果に繋がりました。設定を誤ってしまうと、こちらの記事のような情報漏えいにつながる危険性もあります。とはいっても、環境によってはメリットが非常に大きいと思いますので、FastCGIキャッシュを利用していない場合は、導入を検討してみてはいかがでしょうか。