先に要点
- 止められない・大量アクセスの段階では、CDN+WAF・マルチAZ冗長・オートスケール・読み取り分散(リードレプリカ)・キャッシュを組み合わせます。
- 具体的には、入口に CloudFront+WAF、アプリは ECS Fargate(オートスケール)、DBは RDS Multi-AZ / Aurora + リードレプリカ、ElastiCache(Redis)でキャッシュ。
- 土台は IaC(Terraform) + 監視(Datadog/CloudWatch+Sentry) + アラート。大規模ほど、再現性と「異常に早く気づく」ことが命です。
- 最大の注意は依然 過剰設計。マルチリージョンやシャーディングは、本当に必要になってから。
「止まると事業に大きく響く」「常時の大量アクセスをさばく」── ここまで来ると、構成はWebアプリ（中規模）から一段上がります。中規模の構成に、WAF・冗長化・オートスケール・読み取り分散・キャッシュを足して、高い可用性とスケールを取りにいきます。どこまで上げるべきかは可用性の段階が前提です。
対象と前提
- ダウンタイムが事業に直接響く（決済・基幹・大規模サービス）
- 常時の高負荷、または急激なスパイクをさばく必要がある
- 専任の運用・インフラ担当がいる（または用意できる）
- すでに中規模構成では可用性・性能が足りなくなっている
全体構成（リファレンスアーキテクチャ）
まず流れを絵で。入口でCDN+WAFが守り、ロードバランサーが複数のアプリへ分散、DBは主系+レプリカ。すべてマルチAZ(複数区画)で冗長化します。
各層を具体的なサービスに置くと、次のようになります。
| 層 | 役割 | AWSでの例 | GCPでの例 |
|---|---|---|---|
| 配信+防御 | CDN配信・WAF・DDoS緩和 | CloudFront + WAF + Shield | Cloud CDN + Cloud Armor |
| 入口(LB) | 複数台へ分散・TLS終端 | ALB | Cloud Load Balancing |
| アプリ実行 | コンテナをオートスケール | ECS Fargate(Auto Scaling) | Cloud Run / GKE |
| データベース | 冗長化 + 読み取り分散 | RDS Multi-AZ / Aurora + リードレプリカ | Cloud SQL(HA) / AlloyDB + レプリカ |
| キャッシュ | 読み取り高速化・セッション | ElastiCache(Redis) | Memorystore |
| 運用 | IaC・監視・アラート | Terraform / CloudWatch・Datadog + Sentry / PagerDuty・Slack通知 | |
アプリは状態を持たない（ステートレス）のでロードバランサー配下でオートスケール。DBは書き込みを主系、読み取りをリードレプリカへ逃がします（DBサーバーを分ける必要性の延長）。さらにRedisで重い読み取りやセッションをキャッシュします。
なぜこれを選ぶか
- 止まりにくい ── マルチAZで区画障害に耐え、各層を冗長化して単一障害点を減らす
- 負荷に追従 ── オートスケールでスパイクに対応し、平常時は縮小してコストを抑える
- 読み取りをさばける ── リードレプリカとキャッシュで、参照の多い負荷を主系から逃がす
セキュリティ（大規模では厚くする）
結論: 中規模の一式に加え、入口防御と監査を厚くします。 攻撃対象も影響も大きいので、ここは投資する価値があります。
具体的な参考: AWS WAF(CloudFront/ALB) / OWASP Top 10 / IAMのロール・ポリシー。
運用（IaC + 監視 + アラート）
大規模の肝は「豪華な構成」より「再現性と早期検知」です。
IaC（Terraform）
構成をTerraformでコード化。レビューでき、障害時に同じ環境を作り直せ、変更履歴も残る。手作業は事故と属人化のもと。
CloudWatchやDatadogでメトリクス、Sentryでエラー追跡。SLO(目標)を決め、閾値超えはPagerDutyやSlackへ即通知。異常に早く気づける状態を作る。
コスト感
冗長化・スケール・レプリカ・キャッシュのぶん、中規模より大きく上がります。マルチAZのDB、複数のアプリインスタンス、ロードバランサー、レプリカ、CDN転送量、Redisが主な項目です。規模に見合うかを常に確認し、コスト監視とアラートを必ず入れます。クラウド料金は構成で大きく変わるため、見積もりと実測を併用してください。
落とし穴
- 過剰設計 ── 必要のないマルチリージョンやマイクロサービス化まで進めると、運用とコストが跳ね上がる
- レプリケーション遅延 ── リードレプリカはレプリケーションの遅れで、書いた直後の読み取りに注意が要る
- 監視の不足 ── 大規模ほど「異常に早く気づく」ことが命。監視・アラート・ダッシュボードを最初に整える
- コスト暴走 ── オートスケールやレプリカが想定外に増えると費用が膨らむ。上限と監視を設ける
スケール時の移行余地
さらに上は、マルチリージョン（地理障害対応）、キャッシュの拡張、データが単一DBで限界ならシャーディングへ。ただしどれも複雑さが大きいので、本当に必要になってからにします（可用性の段階）。
よくある質問
Q. 中規模からいつ大規模構成へ上げるべきですか？
A. 「ダウンタイムが事業に大きく響く」「中規模構成では負荷をさばけない」が現実になったときです。先回りで作り込むと、運用とコストだけが増えます。可用性とスケールの不足が具体的な問題として表れてから、WAF・マルチAZ・オートスケール・レプリカと段階的に上げるのが無駄がありません。
Q. マルチAZとマルチリージョンはどちらまで必要ですか？
A. 多くの大規模サービスはマルチAZで十分です。マルチAZは同一地域内の複数区画に分散し、区画障害に耐えます。マルチリージョンは地理的災害まで想定する構成で、複雑さとコストが大きく上がります。地域全体の障害まで耐える要件が明確にある場合に限って検討します。
Q. リードレプリカを入れれば書き込みも速くなりますか？
A. なりません。リードレプリカは読み取りを分散する仕組みで、書き込みは主系に集中したままです。書き込みがボトルネックなら、主系のスペック向上や、最終的にはシャーディング（データ分割）を検討します。まず自分の負荷が読み取り中心か書き込み中心かを見極めることが先です。
Q. 大規模で一番優先すべきことは何ですか？
A. 監視と再現性です。大規模では障害の影響が大きいため、異常に早く気づく監視・アラートが命綱になります。あわせてIaCで構成をコード化しておくと、障害時に同じ環境を作り直せ、変更も安全に行えます。構成を豪華にする前に、この2つを固めることが効きます。
関連する考え方
- 可用性をどこまで上げるか: 可用性の段階
- 前の段階: Webアプリ（中規模）
- 読み取り分散の仕組み: DBサーバーを分ける必要性