「ふだんは 1 日 500 PV の平穏なブログ。それでも――突然のバズ砲で 5 万 PV が雪崩れ込む“あの瞬間”に耐えられるのか？」
WordBench 名古屋で聞いた AWS × WordPress 事例をきっかけに、“今ならどう組むか” を真面目に洗い直してみました。
ロードバランサと DNS ラウンドロビンを礼賛していた旧稿から 7 年。エッジキャッシュ、オートスケール、サーバレス DB……クラウドの武器庫は一変しています。
本記事では 「コストは最小、でもバズには落ちない」 を合言葉に、
- 負荷を測るモダン指標
- 2025 年流・三段ロケット構成（CloudFront → ALB → Aurora）
- 月 7,000 円スタートで 5 万 PV に耐えるスケールパス
を具体例と数字付きで共有。
“明日バズっても CloudWatch が静かに光るだけ”――そんな安心感ごとデプロイしたい人のための現場メモです。
ちなみに、このブログは Xserver の上で動いてるんだよ〜。エックスアクセラレータっていう
キャッシュで頑張ってるんだ〜。
そもそも“負荷”とは何を指すのか
| 観点 | 具体指標 | 目安 (バズ時) |
|---|---|---|
| トラフィック | Requests /sec, 同時接続数 | 300 RPS / 3,000 conns |
| レスポンス | p95 応答時間 | < 300 ms |
| リソース | CPU %, Mem %, DB 接続数, IOPS | 70 % を超えたら要拡張 |
| UX | LCP / TTFB | モバイルで < 2.5 s |
測定ツール例：AWS CloudWatch, WP Query Monitor, K6, Locust
古すぎる対策を卒業するチェックリスト
| もう卒業 | いま必須 |
|---|---|
| DNS ラウンドロビン | Route 53 + ヘルスチェック + フェイルオーバー |
| 物理ロードバランサ | ALB / NLB（マネージド・L7/L4） |
| 手動スケールアウト | Auto Scaling Group（CPU or RPS トリガ） |
| サーバー側キャッシュだけ | CloudFront + キャッシュポリシー |
| 単一 RDS | Amazon Aurora (writer + reader) |
現代 WordPress on AWS ― 三段ロケット構成
上図のマーメイドコードは下記
flowchart LR
CF[CloudFront<br/>+ WAF] --> ALB
ALB --> WP1(ECS / EC2<br/>PHP-FPM)
ALB --> WP2(ECS / EC2)
subgraph Cache Layer
REDIS[ElastiCache Redis<br/>オブジェクトキャッシュ]
end
WP1 <--> REDIS
WP2 <--> REDIS
subgraph Data
AURORA[(Aurora MySQL<br/>Writer / Reader)]
end
WP1 <--> AURORA
WP2 <--> AURORA
S3[(S3 + CloudFront<br/>Media offload)] <---> WP1図の要点
| 階層 | 役割 | 最低限の設定 |
|---|---|---|
| Edge | CloudFront | • cache-policy: CacheAllExceptCookieSession• Lambda@Edge で UA 分岐可 |
| WAF | OWASP + Geo ブロック | ルール 10 本以内なら無料枠 |
| ALB | SSL 終端 & Sticky 無し | ヘルスチェックを /wp-health.php に |
| App | EC2 or ECS | • PHP-FPM pm=ondemand• WP-Cron → EventBridge へ |
| Cache | Redis | wp-config.php で WP_REDIS_MAXTTL=600 |
| DB | Aurora MySQL | read/write split プラグインで自動振分 |
| Media | S3 + CloudFront | WP Offload Media Lite で自動同期 |
小さく初めて大炎上に耐えうる構成を考えるなら？
Stage 0 – EC2 t4g.small × 1
- Lightsail でも可。CloudFront だけは付ける。
Stage 1 – ALB + EC2 AutoScaling (min 1 / max 3)
- AMI に WordPress baked。Scale-out 5 min。
Stage 2 – Aurora Serverless v2 + ElastiCache
- DB とオブジェクトキャッシュを外だし。TTL を短く。
Stage 3 – ECS Fargate / EKS + Blue/Green
- Zero-downtime デプロイ、1 万 RPS まで検証済。
コスト感 (東京リージョン)
Stage 1 で平常 ≈ ¥7,000/月。
Stage 2 でも平常 ≈ ¥18,000/月。
“5 万 PV/日” バズ当日でも < ¥3,000 追加程度。
テストせずに語るな：負荷テスト最小セット
k6 run -e USERS=200 -e DURATION=60s wordpress_smoke.js- k6 スクリプトでホーム・記事詳細・検索を Weighted で回す
- p95 < 300 ms & エラー率 < 0.1 % を合格ライン
- Pipeline に組み込み、PR 時・本番前・月イチ定期で実行1 % を合格ライン
まとめ ― “用意するのは武器より撤退経路”
- ロードバランサ／ラウンドロビン単体では 2025 年の最低ラインに届かない
- キャッシュ ⇒ オートスケール ⇒ 分散 DB の三段ロケットが王道
- “PV 500 → 5 万” の瞬間費用は 数千円、機会損失で逃す広告収益より圧倒的に安い
これで明日バズっても安心だね〜。でも、お財布とは相談しようね〜。
FAQ
-
K6 って何？
-
OSS の負荷テストツール。JavaScript でシナリオを書き、CLI 一発で数万リクエストを同時発射できる。
-
Route 53 + ヘルスチェックを入れる理由は？
-
DNS ラウンドロビン単体では障害ノードに流れ続けるため。
-
ALB があるのに CloudFront を重ねる意味ある？
-
CloudFront は「キャッシュ＋グローバル PoP」。静的アセットをエッジで止め、ALB には PHP 処理だけを届ける構成にすることで、RPS/帯域とも 90 % 以上カットできることが多い。
-
Auto Scaling の閾値は何をトリガーにする？
-
シンプルに ALB RequestCount ≥ 100 /min か EC2 CPU ≥ 60 % を基準にして試算 → バースト時に 1 分以内で +1 台。
-
Aurora Serverless v2 と RDS MySQL、何が違う？
-
ピークが読めないブログ → Aurora Sls v2：30 秒で 0.5 ACU → 数百 ACU まで無段階拡張。
一定トラフィック＆レプリカ多数 → RDS MySQL：リーダー台数が決まっている方がコスト最
-
Redis（オブジェクトキャッシュ）は必須？
-
ぶっちゃけPV 500/日なら不要。5万/日なら要件等。
-
WordPress Cron を EventBridge に外出しするメリットは？
-
通常 WP-Cron はユーザーアクセス時に走る＝バースト時に同時多発して CPU を食う。
EventBridge へ移せば「1 分毎に 1 回だけ」実行でき、ピーク時も安定。
-
Lightsail と EC2、最初の 1 台はどちらが良い？
-
初学者／固定費を抑えたい → Lightsail：月額固定。
将来 Auto Scaling 前提 → EC2：AMI 化しやすく、後から ASG へスムーズに移行できる。
このBlogの構成は当然・・・
22万社以上が導入！法人向けレンタルサーバー『XServerビジネス』 👈️ 注: アフィリンクです。
あとこの記事はAWSの構成の話をしていたので、Xserverにしたら本記事の構成と全く異なりますのでご注意ください。
コメントを残す