1. 要件

• AWS学習を目的としてAWS Lightsail環境の当サイトをAWS高可用性構成で再現する。
• あくまでも学習のため、削れるコストは可能な限り削る。
• Lightsail環境のデータベースやメディアを全て移行する。

可用性とコストのどちらを優先するかは都度判断。

2. 構成図の全体像と設計思想

この構成図は、WordPressをAWS上に構築するための、疎結合（Decoupled）なモダン・アーキテクチャを示しています。

この構成の肝となる3つのポイント

• 高可用性（High Availability）: CloudFront、ALB、FargateマルチAZ展開
• コスト最適化（Cost-Optimized）:Fargate Spot、Single AZ RDS
• ステートレスなコンピュート層：Fargateコンテナを使い、テーマ、プラグイン、メディアファイルを外部サービスへ外部化

3. 各コンポーネントの詳細解説：データの流れに沿って

データの流れ（フロントエンドからバックエンドへ）に沿って、各コンポーネントの役割と設計意図を解説します。

3-1. フロントエンド（VPC外サービス）：配信の効率化と可用性

ユーザーアクセスはまず、VPC（Virtual Private Cloud）の外にあるグローバルサービスで受けます。

• AWS Route 53 (DNS): DNSルーティングを行います。
• AWS CloudFront (CDN): データの配信の肝です。
• 静的コンテンツ origin: Amazon S3 から画像やCSS/JSをキャッシュして高速配信。
• 動的コンテンツ origin: ALBを経由してWordPress（Fargate）に接続。
• Amazon S3: WordPressのメディアファイル（アップロード画像など）を保存するストレージ。静的ファイルの配信はここを起点に行います。

設計のポイント：
静的ファイルをCloudFront/S3へ外部化することで、Fargateコンテナの負荷を大幅に軽減し、かつユーザーの体感速度を向上させています。

3-2. VPC内ネットワーク（Subnet設計）：疎結合と可用性の担保

VPC内は、高可用性を実現するために2つのアベイラビリティゾーン（AZ-a、AZ-b）にまたがって設計しています。

• Public Subnet: WordPressが動作するFargateコンテナを配置。
• Private Subnet: データベース（RDS）と、共有ストレージのマウントターゲット（EFS）を配置。外部からの直接アクセスを遮断し、セキュアに守ります。

コスト削減のポイント：
FargateコンテナはPrivate Subnet内に配置するとセキュリティを向上させることが可能ですが、NATゲートウェイ（月額2,000円ほど）が必要となります。
今回はコスト削減のためFargateコンテナはPublic Subnetに配置し、インバンドアクセスをALBに限定することでセキュリティを担保しています。

3-3. ロードバランサー（ALB）：マルチAZ可用性の鍵

• ALB (Application Load Balancer): Public Subnetにまたがって配置。CloudFrontからの動的リクエストを受け取り、背後のFargateタスクへ負荷分散します。

高可用性のポイント：
ALBは、AZ-aとAZ-bの両方のサブネットを監視し、正常なタスクにのみリクエストを振るため、どちらかのAZで障害が発生してもサイトは落ちません。

3-4. コンピュート層（Fargate）：ステートレス化とコスト最適化

WordPressが動作するコンピュート層は、EC2ではなくマネージドなコンテナサービスであるAWS Fargateを利用します。EC2のOSパッチ当てなどの運用負荷を軽減できます。

この構成の最大のポイントは、FargateのAutoScalingによる高可用性の実現です。

• On-Demand Base Task: 常時1台起動する、サイトの「生命線」となるベースタスク。安定性を確保。
• Spot Task: 負荷に応じて追加されるタスク。負荷低減により自動で停止。

コスト削減のポイント：
今回は学習目的のため、スケールアウトで追加される2台目以降のFargateはSpot Taskを採用しています。
Spot Taskはオンデマンドと比較して最大80-90%引きと安価に使用可能ですが、AWSのリソースが枯渇するとタスクが中断されるデメリットがあります。実際の案件ではオンデマンド：Spot は 50:50 の程度の比率が現実的です。

学習のポイント：
Fargateコンテナをステートレス化（ファイルはEFS、メディアはS3、DBはRDSへ外部化）しているため、Spot Task の突然の中断にも耐えられる設計になっています。

3-5. データベース層（RDS）：コスト優先のSingle AZ構成

• Amazon RDS for MySQL [Single AZ]: データベースはプライベートサブネットに配置。Fargateからの接続のみを許可。

コストと可用性のトレードオフ：
高可用性を目指すならRDSもマルチAZ（Multi-AZ）にすべきですが、今回は「学習目的」であり「削れるコストは削る」という方針のため、あえてSingle AZ構成にしています。これにより、RDSのコストを大幅に削減しています。
コスト度外視で高可用性・耐久性・性能を求める場合はAWS Auroraも使用可能です。

3-6. ストレージ層（EFS）：Fargateステートレス化の肝

• Amazon EFS (Elastic File System): Fargateコンテナは起動・終了を繰り返すため、コンテナ内にテーマ、プラグイン、設定ファイルを保存できません。これらを複数のFargateコンテナ間で共有・保存するための共有ストレージです。
• EFS Mount Target: 各AZのプライベートサブネットにマウントターゲットを配置し、Fargateからマウントします。

疎結合設計のポイント：
Lightsailでは1つのVPS内にあったすべてのファイルを、Fargate、RDS、EFS、S3へと外部化した疎結合設計にすることで、スケーラビリティと可用性を実現しています。

4. 既存Lightsail環境からの移行手順

Lightsailの環境（WordPress Certified by Bitnami）からの移行は、以下のようなステップになります。

1. 各コンポーネントの作成
2. 中心となるFargateとRDS,EFS,ALBを接続
3. LightsailのMySQLからデータをエクスポート（mysqldump）
4. RDSへデータをインポート（Fargate経由）
5. テーマファイルをFargate WordPressの管理画面からアップロード（マウント済みのEFSに自動アップロード）
6. プラグインをFargate WordPressの管理画面からインストール&有効化
7. LightsailのWordPressからwp-content/uploadsディレクトリをS3へコピー
8. Fargate WordPressメディアアップロードから画像がS3にアップされるように接続
9. CloudFrontとALB,S3を接続し、動的ページをALB、静的ファイルをS3から取得するようビヘイビア設定
10. 動作検証（WordPress動作やスケールアウトなど）
11. WordPressサイトURLやDB内URLを本番ドメインに切り替え
12. Route 53でDNSを切り替え
13. DNS浸透待ちで数日経過後にLightsail停止

このプロセスを通じて、Lightsailという「オールインワン」のシンプルさから、AWSの基本サービスの「疎結合設計」への変化を深く理解できます。

5. この構成を作るにあたって学んだこと

以下のAWS技術と設計思想を理解し、実際に作成できることの証明ができます。

• 疎結合設計（Decoupled Architecture）: Web、DB、Storage、Global Servicesの分離。
• 高可用性（High Availability）: CloudFront、ALB、マルチAZネットワーク設計の理解。
• コスト最適化（Cost-Optimized）: Fargate Spot、Single AZ RDSの使い分け。
• AWSの基本サービスの理解: Route 53, CloudFront, ACM, ALB, VPC (Subnet/SG), Fargate, RDS, EFS, S3
• コンテナ技術: Fargateの利用とコンテナのステートレス化。
• トレードオフの理解: 学習目的として可用性とコストのバランスを意識した設計（例：RDS Single AZ）。

5-1. 苦労したポイント

• CloudFrontがWordPressログインユーザーのアクセスをキャッシュしてしまう：
  CloudFrontのキャッシュポリシーを変更し、WordPressログインを判別するCookieを持ったアクセスはキャッシュさせない
• Fargateコンテナの操作：
  EFSマウントしたファイル以外は保持されず、デフォルトだと機能が最小限でzip解凍すらできなかった
• RDSが直接操作不可：
  RDSがPrivate Subnet内に存在するため直接接続ができずFargate経由で接続する必要があった
• エラー原因の特定：
  複数のコンポーネントに跨るため、どこにエラーがあったか特定が難しい
• 料金が高い：
  可能な限りコストを削減するための構成かつ安価なプランを使用したが、それでも月8,000円ほどかかる見込み
  RDS無料枠はAWSアカウントを作成して1年間のみなのが痛い

6. まとめと今後の展望

この構成は、学習用としてはかなり実戦的なWordPress環境が作成できたのではと思います。Lightsailからのステップアップとして、Fargateや疎結合設計を学ぶのに最適でした。

ただし、小規模なブログを運用するには過剰なスペックかつ高価です。おとなしく国内レンタルサーバー + Cloudflare を使用した安価な環境が現実的でしょう。
僕はしばらく学習に使用する際にのみ起動し、Lightsailでの運用を継続しようと思います。

今後の展望としては、以下を想定しています。

• CloudFrontのより詳細なキャッシュ設定
• IaC を使用したstg環境の作成
• GitHub からの CI/CD
• Lambda@Edgeを使用したS3画像ファイルのWebP,AVIF生成自動化

ご相談・ご依頼お待ちしております。

お問い合わせはこちら