Home
https://docs.aws.amazon.com/whitepapers/latest/best-practices-wordpress/reference-architecture.html
https://futurice.com/blog/terraform-recipe-wordpress-fargate
- エンドユーザーがコンテンツを閲覧する際、移行前後で違いを感じない画面表示であること
- 今回はデータ移行作業は不要で移行先の環境構築を目標としています
- 開発環境と本番環境をそれぞれ異なる環境で管理できること
- 異なる環境を構築可能ですが、以下の理由で開発環境を構築していません
- 本番環境のレビューや運用の前に開発環境を構築してもあまり意味がないと感じました
- 開発環境を同じアカウントで作成すると環境が混在してわかりにくくなります
- 開発環境を構築する場合は以下のような投入で構築可能
terraform plan -var 'site_domain=dev.example.com' -var 'public_alb_domain=dev.example.com' -var 'stage=dev'- 開発環境を構築する場合は CI/CD で更新する環境もそちらに修正した方がよいです
- 制限事項に追記します
- 異なる環境を構築可能ですが、以下の理由で開発環境を構築していません
- 記事の更新は顧客が行い、AWS環境の保守は貴方が行うこと
- 簡単な固定ページや投稿ができることを確認し顧客の要件は満足としました
- AWS 環境の保守については Terraform のコードや GitHub Actions で行います
- 環境の調査やデバッグには
aws ecs execute-commandでコンテナに入れます
- クラウドへの移行に伴い発生する内部構造の修正はある程度なら顧客が対応できる
- S3 をメディアのバケットにする場合は注意が必要そうですが今回は S3 からの配信をしていません
- EFS を用いたので既存の環境とほぼ同じ内部構造で動作しています
- CloudFront からの配信としたのでオリジンに負荷はあまりかかりません
- 制限事項に追記します
- 参照アーキテクチャではメディアの配信元として S3 を用いています
意された開発用AWSアカウントで下記が実施できること
- Wordpressの一般画面が表示されている
-
/wp-adminほか、投稿したページやコメントで確認しました
-
- 管理画面でログインができ、記事を更新できる
- 投稿や編集のほか、テーマやプラグインの導入までチェック済みです
- ElastiCache for Memcached を利用するときにほぼ必須となるものは
Dockerfileでインストール済みです- W3 Total Cache プラグインの導入
- ElastiCache ClusterClient の導入
- 各種キャッシュを ElastiCache に載せれることや ECS でのサービスを正常にできることを確認済みです
- 開発用AWSアカウントであるため、以下のIPでのみアクセスできること
- 制限事項に追記します
- データベースはRDSまたはAuroraを使用すること
- ロードバランサーとしてApplication Load Balancer(ALB)を使用すること
- Wordpressを動かすリソースのAvailability Zoneで障害が起こったとしても画面表示が行えること
- ドメインの設定はRoute53の
training.example.io.ゾーンを利用すること
- IaC等で冪等性を担保した構成管理ができていること
- IlaCはHashiCorp社のTerraformを利用すること
- 継続的に発生するコストの削減を意識した構成になっていること
- セキュリティを意識した構成になっていること
- 制限事項に追記します
- 不定期にスパイクが発生しても自動的に対応できること
- アプリケーションはステートレスな構成になっていること
- モダナイズ(Docker, Kubernetes, Serverless etc...)をしても構わない
- ただし、EC2と比較して何が優れていて何に気をつけなければならないか明示する必要がある
- 構築内容を論理的にメリットとデメリットを踏まえて顧客へ説明できること
- 本格的な Terraform の利用ははじめてでしたが、おおよそは説明できます
- パブリックなサイトの情報を参考に構築しても構わない
- GitHub に存在するレポジトリの中から参照アーキテクチャのデプロイをしているレポジトリを元に修正をしました
- ただし、自身の言葉で構築内容の詳細を説明できること
- Terraform + EKS の組み合わせや CDK + ECS の試行もしましたので構成については説明できます
- 少し回り道にはなったものの切り分けて考えることができたので、周辺の技術をよく理解できました
- デプロイと撤去の繰り返しで Billing が高くなってしまったのは反省点です
- 最終的な維持コストは低くなっています
- つまり「このサイトにこう書いてあって作ったのでよくわかりません」という説明しかできない場合は参考にすべきではない
- 多くの冗長化の仕組みや構成の理由について把握していますが、詳細な情報が省かれているリソースの詳細については作法のみを把握した箇所もあります
- 作法のみを把握したようなケースについてもどのような運用を意図されているのかについてはドキュメントを読みました
- CI/CDやコンテナサービスの活用が可能であれば、より望ましい
- GitHub Actions から
terraform deployが走るようにしました - 実運用では開発環境やステージング環境へのデプロイを CI/CD にするべきですが今回は本番環境にデプロイしています
- ただし、運用上の問題や予測されうる障害への対応を説明に含めること
- 参照アーキテクチャを中心に使うことで多くの典型的な問題や障害については AWS が推奨する方法で解決しています
- 個別のリソースについてどのような対応が求められるかも把握はしています
- GitHub Actions から
- 属人的な運用作業はなるべく少ない状態で顧客へ提供できるほうが望ましい
- Terraform のソースコードでデプロイできるようになっています
- 負荷監視や自動復旧などが含まれていれば望ましい
- 参照アーキテクチャでカバーされている範囲について満足しています
- Datadog などでの監視もくわえることを検討しましたが、少し時間に余裕がありませんでした
- また、予測されうる障害に対してどのように対処するかを説明できればより望ましい
- ECS は自動でスケールアウト、スケールダウンするように記述されています
- RDS はマルチAZのクラスターです
- ElastiCache についてはキャッシュにアクセスできなくてもアプリケーションが動作するようにしてあります
- とくに強力な冗長性の確保はしていません
- S3 や EFS についてはプラットフォームが十分な冗長性の確保をしていると判断しています
- 選定候補にあるリソースが選定されなかった場合、なぜそれを選定しなかったかを論理的に説明できれば望ましい
- 参照アーキテクチャを採用することでなるべく「AWS に似つかわしくない構成」を取り込まないように留意しました
- EKS(EC2) を利用するつもりでしたが、技術に触れていくうちに Fargate(ECS) が優れていると感じてそれを採用しています
- インスタンスがどこに配置されていてリージョンに障害が発生したときにどうするのか、などを考慮しなくてもよいからです
- Wordpressのプラグインは使用する前提でも構わないが評価対象には含まれない
- ElastiCache for Memcached をキャッシュにつかうため、いくつかのプラグインや拡張を入れています
- 構成図はPowerPointやdraw.ioなどで作成し、それをもとに説明できればより望ましい
- 参照アーキテクチャを元にした構成なのでそれを使って説明することができます
- 独自に構成図などを用意することが時間的に難しいと判断したこともあり、参照アーキテクチャに基づく構成にしました
- 自身のGithubリポジトリなどで構成管理等のコードが閲覧できればより望ましい
- Terraform でデプロイするコードを GitHub に配置済みです
- https://github.com/takano32/wordpress-on-aws
久々にAWSをAWSらしく扱う貴重な機会になりました。
普段は「めちゃくちゃに難しい箇所の修正」「よくわからないバグを調査して修正」のような仕事をしているので息抜きになりました。