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

このパターンは？

最も基本的で頻出の「3層アーキテクチャ」を OCI で組む構成です。役割ごとに層を分け、各層を**複数の可用性ドメイン（AD）／フォルトドメイン（FD）**に冗長化します。

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

構成

[ユーザー]
   │ HTTPS
   ▼
OCI DNS (権威 DNS / Traffic Management) ──► WAF エッジポリシー (CDN) ──► Object Storage (静的アセット/画像)
   │
   ▼
Load Balancer (L7・複数AD/FD・パブリックサブネット)
   │
   ▼
アプリ層: Compute(インスタンスプール) or OKE  (オートスケール・複数AD/FD・プライベートサブネット)
   │
   ▼
データ層: MySQL HeatWave / Base Database  (HA・プライベートサブネット・暗号化)

各層の役割

• OCI DNS: ドメイン解決。**Traffic Management（ステアリングポリシー）**でヘルスチェック連動のフェイルオーバーや、リージョン誘導も
• WAF エッジポリシー + Object Storage: 静的アセットをエッジでキャッシュ配信し、オリジン負荷と egress を削減。**Pre-Authenticated Request（PAR）**で限定公開も可能
• Load Balancer: リクエストを複数 AD/FD のアプリへ分散。ヘルスチェックで異常バックエンドを除外し、TLS 終端と WAF を前段に寄せる
• Compute（インスタンスプール）/ OKE: アプリ本体。オートスケール（メトリクス／スケジュール）で負荷追従
• MySQL HeatWave / Base Database: HA（複数 AD/FD への自動フェイルオーバー）、読み取りはリードレプリカや HeatWave クラスタでスケール

ネットワーク設計（VCN）

VCN でサブネットを層ごとに分離するのが基本です。

• リージョナルサブネットを使えば、1 サブネットが複数 AD にまたがれて冗長化が楽
• プライベートサブネットからの外向き更新は NAT ゲートウェイ、Object Storage 等への到達はサービスゲートウェイでインターネットを経由させない
• ファイアウォールはセキュリティリストより**NSG（ネットワークセキュリティグループ）**を層ごとに付けると管理しやすい

設計の勘所

• サブネットは**パブリック（LB）/ プライベート（アプリ・DB）**で明確に分離する
• DB はプライベートサブネットに置き、パブリック IP を付けない
• 各層を**2つ以上の AD（AD が1つなら 2つ以上の FD）**に分散して配置する
• アプリは**カスタムイメージ＋インフラ自動化（Terraform / OCI Resource Manager）**で標準化し、Immutable に入れ替える

Well-Architected の観点

• 信頼性（Reliability）: 複数 AD/FD・オートスケール・HA データベースで単一障害点を排除。DNS の Traffic Management でリージョン／エンドポイントのフェイルオーバー
• セキュリティ（Security）: 層の分離・最小公開・IAM のインスタンスプリンシパルでキーレス化・Vault による鍵管理と保存時暗号化
• パフォーマンス効率（Performance）: エッジキャッシュ＋水平スケール＋リードレプリカ／HeatWave で読み取りを高速化

よくある落とし穴

監視は OCI Monitoring で各層のメトリクスを MQL で集計し、アラーム発火→Notifications（ONS） で通知、あるいはオートスケール連携につなげます。LB のヘルスチェックとアプリ／DB のメトリクスを併せて見るのが要点です。