イミュータブルインフラストラクチャ

サーバーを変更せず、新しいイメージで丸ごと置き換えるインフラ運用手法

インフラ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 はイミュータブルインフラの究極形だ。サーバーの概念がなく、コードをデプロイするだけで新しい実行環境が自動的に作られる。

イミュータブルインフラストラクチャの背景や設計思想は関連書籍に詳しい。

関連用語