インフラの層構造

インフラリソースを「依存関係の方向」に基づいていくつかの層に分けて捉えるアーキテクチャパターン。複雑なインフラを理解・構築する際の認知負荷を下げる。

動機

クラウドインフラには多数のリソースが存在し、それらの依存関係は複雑になりがちだ。層として捉えることで：

• 構築順序（依存関係）が自然に決まる
• 「この問題はどの層の問題か」が明確になる
• 新しいリソースを追加する際に適切な層が分かる

ECS Fargateの例

ECS Fargateでは3層構造で整理できる：

┌─────────────────────────────────────────┐
│  トラフィック層（L3）                     │
│  Route53 → ALB → TargetGroup            │
├─────────────────────────────────────────┤
│  コンテナ層（L2）                        │
│  Cluster → Service → Task               │
├─────────────────────────────────────────┤
│  基盤層（L1）                            │
│  VPC, Subnet, SG, IAM, ECR, Logs        │
└─────────────────────────────────────────┘

上位の層は下位の層に依存する。構築は下から、削除は上から行う。

一般的な層の分類

Webシステムにおける典型的な層：

他のアーキテクチャとの関連

• Clean Architectureのレイヤードアーキテクチャも同様の発想（依存の方向を制御）
• コンテナオーケストレーションでも「インフラ」「オーケストレーター」「アプリ」の層がある
• Infrastructure as Codeでモジュール化する際の単位として活用できる

設計への示唆

層を意識すると以下のメリットがある：

• テスト可能性: 上位層をモックして下位層を単体テストできる
• 交換可能性: ある層の実装を変えても他層への影響を最小化できる
• 責任の所在: 問題が発生した際に「どの層の問題か」を特定しやすい

関連

• Clean Architecture
• ECS Fargate
• コンテナオーケストレーション
• Infrastructure as Code
• アーキテクチャ