WordPressで運用している複数のサイトを静的サイト化（Serverless JAMStack化）した

wordpress-desktop
2021.02.08

WordPressを静的サイト化した理由

  • WordPressを5.5系から5.6にアップグレード後に、AMPが出力されなくなった
  • WordPerssのメモリ制約が厳しくなった
  • 運用コストの削減

WordPress5.6 へアップグレード後にAMPが出力されなくなった

  • AMP出力はWordPress公式プラグインを利用していたが、5.5系で正常に動作していた標準のAMPテーマが動かなくなった（※環境依存の事象だがバグの疑いが強い）

    不具合を確認後、管理画面からAMPを再出力しようとしたが、原因不明のエラーで出力できず。原因はnginxの書式と、WordPressのAMPテーマの相性だったのだが、WPのバグにしか思えない事象だったので全サイトの静的サイト化を決めた。

WordPerssのメモリの稼働条件が厳しくなった

メモリ512MBでは足りない？

  • MySQL5.6以降のキャッシュメモリ消費が大きい（バグ説あり）
  • GutenbergやElementorのようなGUIのエディタのメモリ消費が大きい
  • WordPressのプラグインによるメモリ消費
  • テーマやAMPがGUIで編集する前提になったので、その管理画面でのメモリ消費が大きい

  • メモリ不足の対策で、メモリ上限を制限したりSWAPで補強するとシステムの調整に手間がかかる

    課題への具体的対策（候補）

  • インスタンス単位のメモリ容量を増やす
    • 最も簡単な対策だが、月額コストが台数分増加して、管理コストが現状のまま負担になる
  • メモリは現状のまま増やさず、記事を公開するだけのサーバとして運用する
    • 機能が制限されて、メモリ管理の運用コストが大きい
  • 静的サイト化してJAMStackで管理を一元化する
    • 後述するが、今のところ大量の記事を静的サイト化する手段がない
  • WordPressのクラウドサービスやWordPress以外のサービスへ移行する
    • コスト的には大きな差はないが、自前サービスとの連携や運用ノウハウの蓄積が難しくなる

運用コストの削減

静的サイト化を実現するための懸念点

  • 既存のプラグインやサービスでは、大量のページの静的サイト化が難しい
    OSSのプラグイン「WP2static」が便利だったので過去にブログでネタにしていたのだが、MySQLのメモリ消費が激しい上CPU負荷も大きい、細かな設定ができない、記事数が多いと出力に失敗する等の制限がある
落ちないWebサイトの構築 【WordPressを静的サイト化する】
落ちないWebサイトの構築 先日、このサイトとは別に運用しているWordPressの１つが不安定になってしまい、不具合の原因を調べたところMySQLのアップグレードが原因でutf8mb4の文字コード指定に異常が発生していた。 復旧のために対
blog.hidenori.biz

  • WordPressで記事を1つ追加すると「インデックス」と「AMP」と「タグ＋カテゴリ」の更新が必要になる
    例えば、記事数が100件のWordPressを静的サイトに出力すると3～4倍のファイル数の出力が必要になる
    ※ 記事100件あたり（タグやカテゴリ数は記事によって増減する）

    • 記事本体 x 100件
    • 一覧ページ x 10件
    • AMPページ x 100件
    • タグ（タグ一覧） x 10件
    • カテゴリ（カテゴリ一覧） x 10件
    • 記事の画像 x 100件
      ※ 例えば、100件のWordPress記事を静的ページへ出力すると、500前後のファイル出力が必要になる

  • PHPを利用して静的サイトを出力すると、前述のメモリ不足の制約が大きい

  • WordPressの記事数が100件を超えたあたりから静的サイトの出力が厳しくなる

  • WP2staticを利用する例だと、3000件の記事の出力（＝15000個前後のファイル出力）に2～3時間掛かった(1CPUメモリ1GBのVPS=Lightsail,PHP7,MySQL5.7を利用)

  • MySQLのキャッシュが開放されないので、2回目以降の記事出力では更にメモリ制約が厳しくなる

  • AWSの小規模インスタンスを利用すると、CPUクレジットの消費が大きいので更に時間がかかる

    プラグインだと遅い＆制約が多いので、独自ツールの開発を決定

    前置き・ツール制作前に環境整備

  • MySQL5系は5.6以降に修正されていないバグが多いのでMySQL8を使う

  • セキュリティ対策を優先してWordPressのAPIは使わない（wp-api.php, xmlrpc.php, wp-json等は無効化）

  • 問い合わせフォーム等はJAMStackで提供

  • WordPressのプラグインとして動作させると遅くなるので独立したツールを、Python or C# or Java を候補に構築する（C#を採用）

    ツール構築の成果

  • WP2staticでは2～3時間掛かっていた3600件以上の投稿(15556件のhtml出力)が、約20分で生成できるようになった

  • WP2staticでは過負荷でMySQLが落ちることがあったが、独自ツールではMySQLの停止が発生しなくなった

  • 3台のVPS(メモリ512MBx1台+メモリ1GBx2台)で運用していたWordPressをVPS1台(CPUx2メモリ2GB)に統合、月額費用は50%削減

  • 統合したVPSサーバーはステージング環境として運用し、本番環境はS3+CloudFrontへデプロイする構成に変更。セキュリティリスクを最小に、可用性と信頼性が最大になった

  • Javascriptのスクレイピングにも対応したが、今のところWordPressでは必要がないので将来の機能として保留

  • WordPressと独立したツールなので、HTMLの置換や整形等の独自処理も実装可能

  • ステージング用のサーバー1台に集約できたので、メンテナンスの手間が大幅に減った

    今後の課題

  • 問い合わせフォームは設置済みだが、コメント機能や記事検索をJAMStackで提供する方法を検討する

  • JAMSackは静的ページ内に組み込めるが、サーバーサイドレンダリング(SSR)が必要になった場合は別途設計を検討する必要がある

  • パーマリンクやカテゴリの親子構造にも対応したが、条件が無限に発生してしまうので、id表記とslug表記だけをサポート範囲として考えている

  • WebUI等で管理画面の対応も可能だが、WordPressを静的出力するためのシンプルなCLIツールとして目的を最優先に運用している

kichijoji.cloud サービス紹介

落ちないWordPressサイト構築・移転・セキュリティ検査・マーケティング支援


blog.nekovideo.net