ぼくのかんがえた さいきょうの AWS 向け WordPress 環境を構築してみた

概要

StaticPress を用いて WordPress のサイトを静的サイトへ変換して S3 でホスティングする、という案件の AWS 環境を構築をしていて思ったんです。

(WordPress 管理者以外は、どうせアクセスしてこないんだし……)
(WordPress 使ってないときに Web サーバー用の EC2 インスタンス止めてよくない?)

ということで、やってみました。

要件

  • WordPress に StaticPress というプラグインをインストールし、静的サイトへ変換
    • サイト訪問者: S3 でホスティングする静的コンテンツのみアクセス可
    • WordPress 管理者: 管理画面アクセス時は Web サーバー上の WordPress 本体へアクセスを流す
  • WordPress 管理画面を一定の時間以上使用していない場合は、Web サーバーと DB サーバーを停止してランニングコストを最小限に抑える

つまり、どういうこと?

WordPress 管理画面を使用時 (記事投稿・更新時など)

  • Web サーバーと DB サーバーを起動し、起動状態に保つ
  • Web サーバーにアクセスを流す

WordPress 管理画面を一定の時間以上使用していない時

  • Web サーバー と DB サーバーを停止

サイト訪問者によるアクセス時

  • S3 でホスティングしている静的コンテンツを参照

構成要素

ECS (Fargate) + WordPress

こちらに記載したとおり、 Docker 公式の WordPress コンテナを Fargate 起動タイプの ECS で構成。

EC2 じゃなくて、Fargate 起動タイプの ECS とした理由は下記。

  • コンテナ (ECS) のほうが仮想マシン (EC2) より早く起動する (はずだと思った)
  • Fargate だと EC2 を常時走らせておく必要がなくコスト的に有利?

しかし、実際試したところ下記の事情からか、EC2 のほうが数十秒早く起動する (Apache が起動して 200 OK 返すようになる) ようだ。

  • Fargate のアーキテクチャ的な都合?
    • AWS 管理の計算資源や ENI をオンデマンドにアロケートしてるっぽい
  • WordPress イメージの docker-entrypoint.sh でコンテナ起動毎に WordPress のファイル群をコピーしている

今は反省している。

StaticPress + WP Offload S3 Lite + S3 による WordPress の静的サイト化

タスクストレージは一時的なものです。Fargate タスクが停止すると、ストレージは削除されます。
Amazon ECS の AWS Fargate – Amazon Elastic Container Service

ちなみに、WordPress の Docker イメージへのプラグイン組み込み方法はこちら。

RDS (Aurora Serverless)

不思議ちゃん風味だけど、かわいいヤツ。

  • 暇な時はすぐ眠ってしまう
  • やる気スイッチ入るのに時間がかかる

CloudFront + Lambda@Edge

やればなんでもデキるすごいヤツ。

今回は、/wp-admin 等の WP 管理画面系パスへのビューアーリクエストイベント時に、後段の Lambda を SNS 経由で呼び出すために使用。

SNS + Lambda

CloudFront へのビューアーリクエストイベントを購読して下記を実行。

  • ECS タスク起動状況を確認し、起動していなかったら ECS タスクを作成
  • WP 管理画面へのアクセス履歴を DynamoDB へ記録

CloudWatch Event + Lambda

下記をイベントドリブンで実行。

  • ECS Task State Change イベント: ECS タスク起動完了後に、パブリック IP を Route 53 のレコードセットへ設定するために監視
  • スケジュールイベント: 定期的に DynamoDB へ記録された WP 管理画面へのアクセス履歴を確認して、一定の時間以上無アクセス状態であったら ECS タスクを潰す

DynamoDB (TTL 有効)

TTL 機能を使いたかったのでなんとなく使用。WordPress と同じ DB を使えばいいじゃないか、という意見はごもっとも。今は反省している。

動作時の様子

といっても使用時の動作的には、ほぼ普通の WordPress なので Lambda の CloudWatch ログの様子をどうぞ。

/wp-admin アクセス時

ECS タスクが起動していないので、起動処理が始まるぞ。

ちなみに、起動処理以外はなにもしていないので、ECS タスク起動中は CloudFront のエラー画面となる。
Lambda@Edge で頑張れば起動中にローディング画面的なものを別途出すようにできるはず。

起動後の様子

ECS タスクが起動したので、Route 53 のレコードセットにパブリック IP を設定している様子。 ログの時刻に着目すると、起動に 1 分半程度かかっていることがわかる。

起動した後はただの WordPress です。

コード

だいたい Serverless Framework で構成してます。 IAM ロール周りはガバガバなので要注意。

hiraro/ecs-staticpress

まとめ

  • Lambda@Edge はやりたい放題できて良い
  • Aurora Serverless は使い所がありそうであんまり浮かばない
    • 起動時間がもう少し早くなれば……
  • コスト対策だけなら Lightsail 使えばよくない?
    • すごく安いし