アーキテクチャパターン

3 層 Web アーキテクチャ

Web システムで最も広く使われる基本パターン「3 層アーキテクチャ」の構成と、クラウド上での実装例・スケーリング戦略を解説します。

3 層 Web アーキテクチャとは

3 層 Web アーキテクチャは、システムを「プレゼンテーション層・アプリケーション層・データ層」の 3 つの独立した層に分割するパターンです。1990 年代から使われ続ける成熟したパターンで、小規模な Web アプリから大規模エンタープライズシステムまで幅広く採用されています。

各層が独立しているため、層ごとに独立してスケールでき、保守性・変更容易性が高いのが特徴です。マイクロサービスへの移行前のステップとしても、まず 3 層で構築してから段階的に分割するアプローチが一般的です。

3 つの層の役割

1
プレゼンテーション層（Web 層）

ユーザーと直接対話する UI 層。HTML/CSS/JavaScript で構成された Web フロントエンドを CDN で配信します。

React / Next.js / Vue.jsTailwind CSSCloudFront / Azure CDNS3 静的ホスティングWAF（Bot 防御・DDoS 対策）
2
アプリケーション層（ロジック層）

ビジネスロジックを処理するサーバーサイド層。ロードバランサがトラフィックを複数のアプリサーバーへ分散します。

Node.js / Python / JavaECS Fargate / EC2 / App ServiceALB / Application GatewayAuto ScalingRedis（セッション・キャッシュ）
3
データ層

データの永続化・管理を担う層。プライマリ DB・キャッシュ・ストレージで構成されます。アプリケーション層からのみアクセス可能とし、直接の外部アクセスを禁止します。

Aurora / RDS（PostgreSQL / MySQL）ElastiCache（Redis）S3 / Azure Blob StorageDynamoDB（NoSQL）バックアップ・スナップショット

AWS 上の実装例

// インターネット → プレゼンテーション層
Internet → Route 53 → CloudFront (WAF) → S3 (静的アセット)
// API リクエスト → アプリケーション層
Internet → Route 53 → CloudFront → ALB (HTTPS) → ECS Fargate × N タスク
// アプリケーション層 → データ層
ECS Fargate → Aurora Serverless v2 (Primary AZ-a + Reader AZ-c)
ECS Fargate → ElastiCache Redis (Cluster Mode)
ECS Fargate → S3 (ファイルストレージ)
Route 53
DNS + ヘルスチェック
CloudFront + WAF
CDN・キャッシュ・Bot 防御
ALB
ロードバランサ・SSL 終端
ECS Fargate
コンテナ実行（サーバー管理不要）
Aurora Serverless v2
マルチ AZ・自動スケール DB
ElastiCache
セッション・API キャッシュ

スケーリング戦略

プレゼンテーション層のスケーリング

CloudFront が世界 400+ エッジロケーションでキャッシュ配信するため、オリジンサーバーへのリクエストを大幅削減。静的アセット（JS/CSS/画像）はキャッシュ期間を長く設定し、CDN のキャッシュヒット率を最大化する。

アプリケーション層のスケーリング

ECS Service Auto Scaling で CPU 使用率・リクエスト数に基づいてタスク数を自動増減（水平スケーリング）。ALB がリクエストを均等分散。スケールアウト時間を短縮するため、コンテナイメージを小さく保つことが重要。

データ層のスケーリング

Aurora Serverless v2 は ACU を自動スケール（最小 0.5 ACU〜最大 128 ACU）。読み取り負荷は Aurora Reader エンドポイントへ分散。ElastiCache でホットデータをキャッシュし DB へのクエリ数を削減（Read-Through / Write-Through パターン）。

このパターンの適用場面

  • •一般的な Web アプリケーション（EC サイト・業務システム・管理画面）
  • •SaaS プロダクトの初期リリース（まず 3 層で構築し、ボトルネックをマイクロサービス化）
  • •チーム規模が小〜中規模で、マイクロサービスの運用複雑性を避けたい場合
  • •既存オンプレシステムのリフト&シフト移行先（同一構造でクラウドへ移行しやすい）
  • •月数万〜数十万 UU 規模のサービス（Aurora Serverless + ECS Auto Scaling で十分対応可能）

ArchitectAI でクラウドアーキテクチャ設計を自動化しましょう

無料で始める（10クレジット）