ぼくのかんがえたさいきょうの 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 の静的サイト化

StaticPress: WordPress を静的サイトへ変換するための WordPress プラグイン
- 静的変換時に S3 へファイル転送するためのプラグインも公開されている
- ぶっちゃけ最近はもうあまりメンテナンスされてない……？
WP Offload S3 Lite: WordPress へアップロードしたメディアファイルを S3 でホスティングするためのプラグイン
- Fargate の場合、コンテナ停止時に Docker ボリュームが消える仕様のため必須

タスクストレージは一時的なものです。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 使えばよくない？
- すごく安いし

概要

要件