<p>GKE Autopilotを使って、Wordpress環境を構築したときのTipを共有したいと思います。</p><h2 id="h4a5863d206">GKE Autopilotとは？</h2><p>GKE AutopilotはGKEの新しい運用モードで、Control PlaneとNodeをGoogleに運用管理してもらえます。</p><h2 id="h63b4b6c8bd">GKE AutopilotのHA (高可用性)</h2><p>GKE Autopilotで構築したクラスタは3つのAZで構成されるリージョンクラスタです。このため、3つのPodをデプロイすると各AZ上にPodが均等配置されると考えていました。しかし、実際はそうではありません。Autopilotはデフォルトで2つのAZを使います。このため、3つのPodをデプロイした時Podは3つのAZのうち2つのAZに配置されます。</p><h2 id="hfdf9f92b0b">3つのAZにデプロイしたい</h2><p>せっかく3つのAZがあるのに2つしか使えないことに納得できません。なにか方法があるはず。</p><h2 id="ha4c391e27d">Pod Topology Spread Constraints</h2><p>KubernetesのPod Topology Spread Constraintsを使うことで、Podの分散を制御できそうです。ただ、これを使うだけでは3つのAZへの均等配置は実現できそうにありません。あくまでPodの均等配置を制御してくれるだけで、Nodeを新しく作ってくれるわけではありません。Control Planeが認識しているNodeに均等配置するための機能です。</p><p>公式ドキュメント→<a href="https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/" target="_blank" rel="noopener noreferrer">Pod Topology Spread Constraints</a></p><h2 id="hb3e708b215">Pause Job</h2><p>3つのAZに均等配置するためには先に3つのAZにノードを作り、Podを少なくとも1つ稼働させ、Control Planeが3つNodeがあることを認識する必要があります。そこで、Deploymentを展開する前に、nodeSelector で各AZを指定したJobを起動します。これにより、3つのAZに最低一つのNodeが作られます。</p><p>William Dennissさんのブログを参考にしました。→<a href="https://wdenniss.com/ha-3-zone-autopilot-deployment" target="_blank" rel="noopener noreferrer">HA 3-zone Deployments with PodSpreadTopology on Autopilot</a></p><h2 id="h60524c465e">3ゾーンデプロイができました</h2><p><strong>Nodeのデプロイ状況を確認</strong></p><p><img src="https://images.microcms-assets.io/assets/83abe3ff71704bde831915fd55332987/3b3133978cf34eeb829aed0840c274e9/3zoneNodes.png?w=1972&amp;h=210" alt="" width="1972" height="210"></p><p><strong>Podのデプロイ状況を確認</strong></p><p><img src="https://images.microcms-assets.io/assets/83abe3ff71704bde831915fd55332987/d9b12807a65845748e1c723cfff7f86e/3zonePods.png?w=3944&amp;h=288" alt="" width="3944" height="288"></p><p>オレンジの枠内を確認すると、3つのPodが3つのAZに分散配置されていることがわかります。これで、AutopilotでもHAなデプロイが実現できました。</p>

PodSpreadTopologyで3つのAZにPodを均等配置しました。

<h2 id="he6c734c8e6">empty_gifとは？</h2><p>"empty_gif" は、NGINX Web サーバーで使用される画像ファイルのことです。この画像は、通常1ピクセルで透明なGIF画像であり、Webページに存在しているとWebブラウザによってロードされますが、実際には何も表示されません。</p><h2 id="h3d2590489a">使い所</h2><p>ECSやGKEなどでロードバランサーを利用するとき、ヘルスチェックが求められて、何かしらのファイルを用意する必要があります。そんなとき使えるのがempgy_gifです。ヘルスチェック用に何かしら特別なファイルを用意する必要もありませんし、nginx設定ファイルへの記述のみでお手軽に利用できます。</p><h2 id="h92c54cb2ef">書き方</h2><p>以下を、nginx.confのserverディレクティブ配下に記述しています。ヘルスチェックのアクセスログを残したくない場合、access_log off とするといいです。</p><pre><code>//default.conf
location = /healthcheck.html {
    empty_gif;
    access_log off;
    break;
}</code></pre>

Nginxのempty_gifが便利でした。

<h2 id="ha503d3326c">最終構成図</h2><p>先に最終構成と成果を共有します。</p><h2 id="h6a434dc9d3"><img src="https://images.microcms-assets.io/assets/83abe3ff71704bde831915fd55332987/5d6195f0325642f4a763104babd4e78b/wordpress%E6%A7%8B%E6%88%90%E5%9B%B3.png?w=2666&amp;h=1500" alt="" width="2666" height="1500"><br>成果</h2><ol><li>NginxのFastCGIキャッシュを導入して、<span style="background-color:#fff491">パフォーマンスが</span><strong style="background-color:#fff491">75倍速く</strong><span style="background-color:#fff491">なった。</span></li><li>3 Pods体制とし、<span style="background-color:#fff491">zone a/b/c に分散配置させ可用性を向上させた。</span></li><li>独立したクラスターを新規に作成して、<span style="background-color:#fff491">他のサービスに影響を与えない</span>構成とした。</li></ol><h2 id="h04923d994a">プロジェクト背景</h2><p>昨年、マーケティング施策をホームページに公開した際に、公開ページに対するスパイクアクセスが発生し、ホームページが閲覧できない状況が数回発生しました。スパイクアクセスが発生するタイミングでサーバのリソースを消費しきっており、確認はしていませんが、同じクラスタ上で稼働している他のサービスにも影響を与えていた可能性もあります。</p><p>会社としてはLINEをマーケティングで活用していく方針で、ホームページへのアクセスは今後も増加する見込みであるため、ホームページはスパイクアクセスに耐えながらも、常に高いパフォーマンスを維持し続けることが求められています。</p><h2 id="h35abfadec1">改善の方針</h2><ol><li>ホームページがダウンしないようにする。</li><li>他のサービスに影響を与えないようにする。</li><li>パフォーマンスを維持、向上させる。</li></ol><p>上記1と2の方針から、ホームページは既存GKEクラスタから切り出し、別クラスタで運用することとした。また、新クラスタではGKEの新しい運用モードであるAutopilotを選択しました。</p><p>AutopilotによりGKEノードの運用管理をGoogleに任せることでのノードの運用管理負荷の軽減、稼働したPod単位の課金となることで、利用状況に応じたコストの最適化が見込まれます。</p><p>パフォーマンスの改善に関しては、GKEのHPAにて対応することを想定しています。加えて、OPcache（バイトコードキャッシュ）、APCu（ユーザーキャッシュ）を使用するという指示も受けてました。</p><h2 id="hf3a8835fb7">検証結果の共有</h2><h3 id="h68e14cfb68">アクセスによる負荷は何に負荷を与えるか？</h3><ul><li>テスト環境でab試験を実施した結果から、Wordpressに負荷をかけた時、負荷が大きく増えるのはメモリではなくCPUでした。</li></ul><p><img src="https://images.microcms-assets.io/assets/83abe3ff71704bde831915fd55332987/a6ba56dd444141dbb0963cad5d2c5929/%E8%B2%A0%E8%8D%B7%E8%A9%A6%E9%A8%93%E7%B5%90%E6%9E%9C.png" alt="" width="1600" height="701"></p><h3 id="h0d27ebd540">メモリ消費はなぜ増えた？</h3><ul><li>pm.max_children の設定値を4と50の2つで負荷試験を実施した結果、50にするとメモリ使用量が増加しました。</li><li>メモリを増やすのは、ワーカープロセスの数です。</li><li>今回のシステムにおいては、CPUの使用量とメモリの使用量は連動しないことがわかりました。</li></ul><p><img src="https://images.microcms-assets.io/assets/83abe3ff71704bde831915fd55332987/3dc40247227a4a2881361ef731db37e9/pasted%20image%200%20(1).png" alt="" width="1600" height="637"></p><p><span style="color:#000000">テスト環境にてab試験をpm.maxchildrenの値を変えて実施。pm.maxchildrenのほうがパフォーマンスが良い結果となりました。</span></p><p>Time taken for test: </p><ul><li><span style="color:#000000">pm.max_children=80 -&gt; </span>1303秒</li><li><span style="color:#000000">pm.max_children= 4 -&gt; </span>1203秒</li></ul><p><a href="https://images.microcms-assets.io/assets/83abe3ff71704bde831915fd55332987/544de1d2d95f467abfde8625860c3120/02a9ba49-35df-4ad8-bdcc-07bfe8417bda.png?w=600"><img src="https://images.microcms-assets.io/assets/83abe3ff71704bde831915fd55332987/544de1d2d95f467abfde8625860c3120/02a9ba49-35df-4ad8-bdcc-07bfe8417bda.png?w=2056&amp;h=1628" alt="" width="2056" height="1628"></a></p><p>pm.max_childrenの値が大きかったため、PHPのワーカープロセスが増え、それに伴いメモリ消費が増えていたと考えられる。新しい環境においては、Podのスペックに合わせて調整しました。</p><h3 id="h348d7f15d6">Pod数によるパフォーマンスの変化</h3><p>検証環境にて、ab試験をPod数を変えて実行しました。結果は以下のとおりです。</p><pre><code>ab -n 1000 -c 100 "http://xxx.xxx.xxx.xxx/"</code></pre><p><img src="https://images.microcms-assets.io/assets/83abe3ff71704bde831915fd55332987/048ab304ee4e4be79043b75b5faf85c2/image.png?w=2600&amp;h=1508" alt="" width="2600" height="1508"></p><p>Pod数だけでなく、Podのスペックを変えることでも、アクセスのスパイク時に対応するための検証を行っています。例えば、CPU数を2倍にすれば、テスト時間が半分になるといったように、Pod数を増やすことと同じ効果を確認しています。</p><p>ただし、スペックを高くすることで、平常時にスペックを持て余し、Podあたりのコストが上がってしまうため、この時点では、小さいPodを稼働させ、アクセスが増えたときにPod数を増やすことで対応することにしました。</p><h2 id="h8183aecba6">腑に落ちない</h2><p>ここまで検証をしてきて、おそらく最初にあげた3つの改善の方針は達成できると思いました。</p><ol><li>ホームページがダウンしないようにする。</li><li>他のサービスに影響を与えないようにする。</li><li>パフォーマンスを維持、向上させる。</li></ol><p>しかしながら、パフォーマンスについてはもっと効率的になる方法があるのではないかと思っていて、追加で調べてみることにしました。</p><h2 id="h12dbb69053">FastCGIキャッシュ</h2><p>Nginx + PHP-FPM + Wordpress 高速化といったキーワードで更に調査を進めると、FastCGIキャッシュというNginxのキャッシュ機能が効果が高いということがわかってきました。</p><p>まずはab試験の結果を共有します。</p><p><img src="https://images.microcms-assets.io/assets/83abe3ff71704bde831915fd55332987/e7683a349dc04c1491da33de3c83c269/image%20(6).png" alt="" width="2526" height="2198"></p><p><img src="https://images.microcms-assets.io/assets/83abe3ff71704bde831915fd55332987/dd9be5a9012b4e4295c69f0453ad0a0d/image.png?w=2400&amp;h=577" alt="" width="2400" height="577"></p><p>125倍高速化しました。。。Pod数を増やしたり、スペックを調整したりして色々検証していたのが吹っ飛ぶくらいのインパクトです。</p><h3 id="hc5c93d92a7">FastCGIキャッシュとは？</h3><p>FastCGIレスポンスを直接キャッシュする機能です。アクセスによりPHP-FPMが生成するWebページはNginxによって一定期間キャッシュされ、同じページへのアクセスに対してはこのキャッシュが返されます。キャッシュはNginxのメモリに保存され、メモリの容量がいっぱいになった場合、最も古いキャッシュが自動的に削除されます。また、キャッシュ保持時間も設定することができます。これにより、メモリがいっぱいになってPodがクラッシュすることを防ぐことができます。</p><p><img src="https://images.microcms-assets.io/assets/83abe3ff71704bde831915fd55332987/2fae8fbd443d4db6a6eeb10b665dd1aa/image.png" alt="" width="1588" height="1310"></p><h3 id="h94ae3e8d7b">決めた</h3><p>以下のポイントでこのFastCGIキャッシュを即採用すべきと考えました。</p><ul><li>圧倒的パフォーマンス。</li><li>処理に対する負荷は非常に軽く、特別にスペックを盛る必要がない。</li><li>負荷が軽いため、スケールを気にする必要がなくなり、コストダウンを見込めた。</li></ul><h3 id="h046afd68e1">導入方法</h3><p>詳細な導入方法は、ネット上にたくさんありますのでまるっと省きます。</p><h2 id="h569b5a92c7">本番環境での比較</h2><p>旧環境と新環境に対して、以下の試験を実施した結果を共有します。</p><pre><code>ab -n 1000 -c 100 "http://xxx.xxx.xxx.xxx/"</code></pre><h3 id="ha50dca80e9">旧環境の結果</h3><p><img src="https://images.microcms-assets.io/assets/83abe3ff71704bde831915fd55332987/ee91cc8832a44249b4901eaed27a0ecb/%E6%97%A7%E7%92%B0%E5%A2%83%E3%81%AE%E7%B5%90%E6%9E%9C.png" alt="" width="1762" height="2684"></p><h3 id="h84a8306b34">新環境の結果</h3><p><img src="https://images.microcms-assets.io/assets/83abe3ff71704bde831915fd55332987/512733accefb4c8fae3df53066af3b1f/%E6%96%B0%E7%92%B0%E5%A2%83%E3%81%AE%E7%B5%90%E6%9E%9C.png" alt="" width="1774" height="2618"></p><p>試験結果は旧環境では、Time taken for a test が 347.492秒、さらに1000回の試験に対して 143回の失敗という結果になりました。一方、新環境では、Time taken for a test が 4.621秒、1000回の試験に対して 0回の失敗という結果になりました。同じ試験に対して約75倍高速化し、失敗回数も0になり、信頼性も高まる結果となりました。</p><h2 id="ha214098e44">まとめ</h2><p>今回、FastCGIキャッシュを有効化することでホームページの高速化という結果を得ることができましたが、これは全てのケースで有効というわけではありません。Wordpressで運用していた当社のホームページの環境でNginx + PHP-FPM の構成でサーバー環境を構築していたこと、FastCGIキャッシュが動的ページのキャッシングと相性が良かったことなどいくつかの条件が重なり、大きな成果に繋がりました。設定を誤ってしまうと、<a href="https://www.itmedia.co.jp/news/articles/2105/24/news058.html" target="_blank" rel="noopener noreferrer">こちらの記事</a>のような情報漏えいにつながる危険性もあります。とはいっても、環境によってはメリットが非常に大きいと思いますので、FastCGIキャッシュを利用していない場合は、導入を検討してみてはいかがでしょうか。</p>

FastCGIキャッシュを導入してWordpressサイトの高速化

<p>こんにちは。2回目の投稿です。</p><p>ごほごほ。</p>

記事一覧