3層ウェブアプリケーション

このパターンは？

最も基本的で頻出の「3層アーキテクチャ」を Google Cloud で組む構成です。役割ごとに層を分け、各層を複数ゾーンに冗長化します。

• プレゼン層: 静的配信とロードバランシング
• アプリ層: ビジネスロジック（自動スケール）
• データ層: 永続データ（高可用DB）

構成

[ユーザー]
   │ HTTPS
   ▼
Cloud DNS (DNS) ──► 外部 Application Load Balancer ──► Cloud CDN ──► Cloud Storage (静的アセット/画像)
   │                         │
   │                         ▼
   │   アプリ層: Compute Engine (MIG) or Cloud Run / GKE
   │           （オートスケール・複数ゾーン・プライベートIP）
   │                         │
   ▼                         ▼
（同一の外部ALBが       データ層: Cloud SQL / AlloyDB
 上記バックエンドへ           （高可用 / リードレプリカ / 暗号化）
 振り分け）

外部 Application Load Balancer は単一の グローバル Anycast IP を持ち、世界中のユーザーを最寄りの Google エッジで受けてバックエンドへ振り分けます。同じロードバランサに Cloud Storage バケットバックエンド（静的）とアプリのバックエンドサービス（動的）をURL マップでパス分岐できます。

各層の役割

• Cloud DNS: ドメイン解決。SLA 100% の Anycast 権威 DNS。apex（ゼロネーム）も A/AAAA でロードバランサのグローバル IP に向けられます
• 外部 Application Load Balancer + Cloud CDN + Cloud Storage: 静的アセットをエッジ配信し、オリジン負荷を軽減。Cloud CDN は外部 ALB に紐づけて有効化します
• Cloud Load Balancing: リクエストを複数ゾーンのアプリへ分散。ヘルスチェックで異常なインスタンスを除外
• Compute Engine（MIG） / Cloud Run・GKE: アプリ本体。マネージドインスタンスグループ（MIG）のオートスケーラ、または Cloud Run の同時実行ベースの自動スケールで負荷追従
• Cloud SQL / AlloyDB: 高可用（HA）構成で別ゾーンのスタンバイに自動フェイルオーバー、読み取りはリードレプリカへオフロード

設計の勘所

• アプリ層・DB はプライベートIPのみで構成し、外部公開しない（VPC 内のプライベートサブネット相当）
• アプリ層から DB へは Cloud SQL の Private Service Connect / プライベートサービスアクセスで VPC 内部接続。アウトバウンドが必要なら Cloud NAT 経由に
• MIG はリージョン MIGにして、インスタンスを複数ゾーンに自動分散（ゾーン障害に耐える）
• ロードバランサ前段に Cloud Armor を置き、WAF / DDoS / IP 制御を追加できる

アプリ層の選択肢

データ層の選択肢

Well-Architected の観点

• 信頼性: リージョン MIG＋複数ゾーン分散、Cloud SQL/AlloyDB の HA で単一障害点を排除。ヘルスチェックで異常を自動隔離
• セキュリティ: 層の分離・最小公開・Cloud IAM のサービスアカウント・Cloud Armor・保存時/転送時の暗号化
• パフォーマンス効率: Cloud CDN＋グローバル ALB の水平スケール＋リードレプリカで読み取りを分散

よくある落とし穴

監視は Cloud Monitoring / Logging で各層のメトリクスとログを集約し、アラートポリシーから通知、MIG のオートスケーラへ負荷追従を任せましょう。SLO を定義して可用性を継続的に観測するのが理想です。