Home
参照アーキテクチャをベースに課題に合わせた修正をする方針で構築しています。
-
後述の参照アーキテクチャを構成
-
コードで構成を管理できるようにTerraformによる記述
-
スケーラビリティや可用性を意識しFargateを利用するように変更
-
-
CloudFrontの利用で運用コスト削減
- アプリケーションサーバの負荷軽減
-
踏み台となるホストがなくても管理できるように変更
-
コンテナのサービスでオートスケール
-
SSHなどで接続されてしまうリスクの回避
-
https://docs.aws.amazon.com/whitepapers/latest/best-practices-wordpress/reference-architecture.html
https://futurice.com/blog/terraform-recipe-wordpress-fargate
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/AWS_Fargate.html
Terraformで site_domain, stage の変数を変更すれば dev, stg, prod(, dev2) のように
複数の環境をデプロイできるコードになっています。ただし tfstate の管理に注意が必要です。
開発環境を同じアカウントで作成すると環境が混在してわかりにくくなって説明のときに混乱しそうなのでデプロイしていません。
現段階ではデフォルトのstageはprodという扱いでGitHub Actionsでもprodのみにterraform applyしています。
参照アーキテクチャでは静的なファイルについてCloudFrontオリジンをS3バケットに設定していますがS3を静的なファイルの保存先に指定するにはアプリケーションで大きな変更が必要となってしまいます。
アプリケーションのアップグレードなどが困難にならないようにEFSの領域に保存するのみとしました。
静的ファイルの配信はCloudFrontからALBを経由したECSをオリジンとしてEFSの読み込み配信されることになります。
CloudFrontからの配信とすることでオリジンとなるECSへのアクセスは抑えることができますので問題ありません。
セキュリティのための制限としての要件ですが以下の理由から未実施です。
- 汎用的な状態のコードに留めておきたかったので本流のコードには入れていません
- IPv4 アドレスで制限するコードは
wafv2-with-ipv4ブランチに用意しました-
mainブランチには未適用
-
- IPv4 アドレスで制限するコードは
- CloudFrontでDDoSに対策できます
- WAFで不正なアクセスに対策できます
- ECSを利用しているので外部からのSSH接続はできません
-
aws ecs execute-commandにはAWSのクレデンシャルが必要
-
- IPv6 でもデュアルスタックでサービスできているのでそれを犠牲にしないようにしました
- IPv4 のアドレスで制限するためには IPv6 を無効にする必要があり、これはサービスの幅が狭まるためIPv4アドレスによる制限をやめました
単一のリージョンが不能になっても機能するように複数のリージョンでクラスタを組んでいます。
具体的には RDS Aurora MySQL が複数のサーバレスインスタンスでクラスタを組んでいるためコストが増えています
Fargate Spot キャパシティプロバイダーは、Fargate の Windows コンテナではサポートされません。
ARM64 アーキテクチャの Linux タスクでは、Fargate Spot キャパシティプロバイダーはサポートされません。Fargate Spot では、X86_64 アーキテクチャの Linux タスクのみサポートされます。
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/fargate-capacity-providers.html
今回は Graviton3 のインスタンスを活用するために ARM64 を採用したのでキャパシティプロバイダは FARGATE SPOT に設定されていますが、起動するタスクは FARGATE によるものです。