イミュータブルインフラストラクチャ
サーバーを変更せず、新しいイメージで丸ごと置き換えるインフラ運用手法
インフラDevOps
イミュータブルインフラストラクチャとは
イミュータブルインフラストラクチャは、デプロイ済みのサーバーに変更を加えず、新しいイメージ (AMI、コンテナイメージ) で丸ごと置き換えるインフラ運用手法である。「サーバーにSSHしてパッチを当てる」のではなく「新しいサーバーを作って古いサーバーを捨てる」。
ミュータブル vs イミュータブル
| 観点 | ミュータブル | イミュータブル |
|---|---|---|
| 更新方法 | SSH でパッチ適用 | 新イメージで置き換え |
| 状態 | サーバーごとに異なる | 全サーバーが同一 |
| 再現性 | 低い (手動変更の蓄積) | 高い (イメージから再現) |
| ロールバック | 困難 (変更を戻す) | 容易 (旧イメージに戻す) |
| 構成ドリフト | 発生する | 発生しない |
構成ドリフト
ミュータブルなサーバーでは、手動変更が蓄積して「本番サーバー A と B で設定が微妙に違う」状態 (構成ドリフト) が発生する。
ミュータブル:
サーバー A: OS パッチ適用済み、設定ファイル手動変更
サーバー B: OS パッチ未適用、設定ファイルは元のまま
→ 「A では動くが B では動かない」
イミュータブル:
サーバー A: イメージ v1.2.3 から起動
サーバー B: イメージ v1.2.3 から起動
→ 完全に同一
AWS での実装
| パターン | 方法 |
|---|---|
| Lambda | コードをデプロイ → 新しい実行環境が起動 (本質的にイミュータブル) |
| ECS / Fargate | 新しいコンテナイメージでタスクを置き換え |
| EC2 + ASG | 新しい AMI で Launch Template を更新 → ローリングアップデート |
| S3 + CloudFront | 新しい静的ファイルをアップロード |
コンテナとイミュータブルインフラ
コンテナは本質的にイミュータブルだ。Dockerfile でイメージをビルドし、実行中のコンテナには変更を加えない。
Dockerfile → docker build → イメージ (イミュータブル)
↓
コンテナ起動 → 問題があれば破棄して新しいコンテナを起動
前提条件
| 前提 | 理由 |
|---|---|
| IaC (SAM, CloudFormation) | インフラをコードで再現可能にする |
| CI/CD パイプライン | イメージのビルド・デプロイを自動化 |
| 外部ストレージ | データはサーバー外 (S3, DynamoDB) に保存 |
| ログの外部送信 | CloudWatch Logs にログを送信 |
サーバーレスとの関係
Lambda はイミュータブルインフラの究極形だ。サーバーの概念がなく、コードをデプロイするだけで新しい実行環境が自動的に作られる。
イミュータブルインフラストラクチャの背景や設計思想は関連書籍に詳しい。