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

このパターンは？

最も基本的で頻出の「3層アーキテクチャ」を Azure で実装した構成です。役割ごとに層を分け、各層を複数の可用性ゾーンに冗長化します。Azure 認定（AZ-104 / AZ-305）でも実務でも王道です。

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

構成

[ユーザー]
   │ HTTPS
   ▼
Azure DNS ──► Front Door (CDN + WAF) ──► Blob Storage (静的アセット/画像)
   │
   ▼
Application Gateway (L7 ロードバランサ・WAF・複数ゾーン)
   │
   ▼
アプリ層: VMSS or Container Apps  (自動スケール・複数ゾーン・プライベートサブネット)
   │
   ▼
データ層: Azure SQL Database  (ゾーン冗長・プライベートエンドポイント・TDE 暗号化)

VNet（仮想ネットワーク）の中で、パブリックに面するのは Front Door / Application Gateway だけにし、アプリ層とデータ層はプライベートサブネットへ閉じ込めるのが基本形です。

各層の役割

• Azure DNS: ドメイン解決。apex（ゾーン頂点）は Alias レコードで Front Door へ向ける。Traffic Manager と組み合わせれば DNS レベルの DR も可能
• Front Door + Blob Storage: 静的アセットを Microsoft のグローバルエッジ（POP）からキャッシュ配信し、オリジン負荷を軽減。WAF・SSL オフロードもここで担う
• Application Gateway: リージョン内で複数ゾーンのアプリへ L7 分散。ヘルスプローブで異常インスタンスを除外。L4 で十分なら Load Balancer も選択肢
• Virtual Machines / VMSS または Container Apps: アプリ本体。VMSS / Container Apps の自動スケールで負荷に追従
• Azure SQL Database: フルマネージドな SQL。ゾーン冗長構成で自動フェイルオーバー、読み取りは**読み取りレプリカ（読み取りスケールアウト）**へ逃がす

プレゼン層 ─ エッジとロードバランサの使い分け

「Front Door」と「Application Gateway」はどちらも L7 ですが、適用範囲が異なります。グローバル配信・キャッシュ・複数リージョンのフェイルオーバーは Front Door、単一リージョン内のゾーン分散は Application Gateway、と役割を分けて両方を重ねるのが定番です。

アプリ層 ─ ステートレスに保つ

アプリ層はステートレスに設計し、台数を自由に増減できるようにします。Azure では VM ベースなら VMSS（仮想マシンスケールセット）、コンテナなら Container Apps（サーバーレス）や AKS が選択肢です。

• サブネットを用途で分離（プレゼン / アプリ / データ）し、**NSG（ネットワークセキュリティグループ）**で層間通信を最小化
• アプリ層はプライベートサブネットに置き、直接インターネットへ公開しない
• 各層のサブネットを2つ以上の可用性ゾーンにまたがって配置（ゾーン冗長）

データ層 ─ 可用性と分離

• Azure SQL Database をゾーン冗長（Business Critical / Premium 等）で構成し、ゾーン障害時も自動フェイルオーバー
• DB はプライベートエンドポイント経由でのみアクセスし、パブリックネットワークアクセスは無効化
• 接続文字列やパスワードは Key Vault に保管し、アプリはマネージド IDで取得（資格情報をコードに埋め込まない）

設計の勘所

• ネットワークは VNet + サブネット分割。パブリック（エッジ/LB）/ プライベート（アプリ・DB）で明確に分離
• 認証・認可は Microsoft Entra ID に集約。アプリ→DB / アプリ→Key Vault はマネージド ID で接続
• インフラは Bicep / ARM / Terraform でコード化し、Immutable に入れ替えられるようにする
• 各層を最低2ゾーンへ。単一ゾーン配置は避ける

Well-Architected の観点

• 信頼性（Reliability）: 複数ゾーン・VMSS/Container Apps の自動スケール・ゾーン冗長 DB で単一障害点を排除
• セキュリティ（Security）: 層の分離・最小公開・Entra ID + RBAC・マネージド ID・TDE / Key Vault による暗号化
• パフォーマンス効率（Performance）: Front Door のエッジキャッシュ＋水平スケール＋読み取りレプリカ

よくある落とし穴

監視・運用

監視は Azure Monitor に集約します。メトリクスのアラートから自動スケールをトリガーし、各層のログ（アプリ / Application Gateway / SQL）を Log Analytics ワークスペースへ集約して横断分析しましょう。アプリのリクエストトレースは Application Insights で可視化すると、層をまたいだボトルネックの特定が容易になります。

AWS との対応

主要な構成要素を AWS の 3 層構成と対比すると、置き換えが把握しやすくなります。