小中規模向け低コストで可用性/拡張性の高いWordPress アーキテクチャ

シンプルかつ低コストで可用性・拡張性の高いWordpress 環境アーキテクチャを自動構成するCFn テンプレートおよび構築手順をGitHubに公開しました。ご自身のアカウントですぐに試すことができます。

https://github.com/tomofuminijo/aws-wordpress-midscale-arch

なお、AWS には、以下のようなWordPress を構築する際のベストプラクティスがありますが、この構成をすべて実現しようとすると比較的コストが高くなりがちですので、もう少し小規模でシンプルな構成かつ低コストである環境のほうが望ましい場合があります。

https://aws.amazon.com/jp/blogs/architecture/wordpress-best-practices-on-aws/


小さくシンプルに始めてコストかけたくない、ただ止めないように運用していきたいといった方向けのアーキテクチャになります。
本Blog サイトもこのアーキテクチャで現状運用しています。

アーキテクチャ紹介

アーキテクチャの特徴は以下の通りです。

  • 記事投稿やプラグインの追加/更新、WordPress 本体の更新などのメンテナンス目的で、WordPress Master インスタンスを一つ起動します。
  • 記事を参照するためのReader インスタンスはASG 構成にします。
  • 両方共同一のALB に関連付けます。ALB にはACM で管理されている証明書を構成して443 ポートのみでアクセスできるように構成します。
  • ALB のDNS 名に対してリクエストが来た場合は403 で返すようにListener Rule を設定し、正規のBlog 用ドメイン名のアクセスのみを通すようにします。
  • 画像データは、S3 バケットに保存します。その際にWordPress プラグインを構成します。
  • RDS はMulti-AZ 構成をオプションで選択できます。コストを取るか可用性を取るかを選択できます。
  • RDS の認証情報は、Secrets Manager で管理します。WordPress 構成時にはSecrets Manager からRDS の認証情報を取り出して自動的に構成します。これによりシステム構築中にDB の認証情報を運用者でも入手する必要がありません。
  • CloudFront にて、パスパターンによりALB / S3 にルーティングします。
  • ALB のルール設定で 管理用URL (wp-admin など) の場合は、Master インスタンスにルーティングします。
  • WordPress の更新はMaster インスタンスで実施し、AMI を作成後にASG に自動適用することができます。CFNの機能によりローリング更新が可能でブログサイトを止めずにAMI を入れ替えることができます。

是非試してみてください。