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

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

イミュータブルインフラストラクチャは、デプロイ済みのサーバーに変更を加えず、新しいイメージ (AMI、コンテナイメージ) で丸ごと置き換えるインフラ運用手法である。「サーバーに SSH してパッチを当てる」のではなく「新しいサーバーを作って古いサーバーを捨てる」。

ミュータブル vs イミュータブル

ミュータブルとイミュータブルの違いを以下にまとめる。

観点	ミュータブル	イミュータブル
更新方法	SSH でパッチ適用	新イメージで置き換え
状態	サーバーごとに異なる	全サーバーが同一
再現性	低い (手動変更の蓄積)	高い (イメージから再現)
ロールバック	困難 (変更を戻す)	容易 (旧イメージに戻す)
構成ドリフト	発生する	発生しない

構成ドリフト

ミュータブルなサーバーでは、手動変更が蓄積して「本番サーバー A と B で設定が微妙に違う」状態 (構成ドリフト) が発生する。

ミュータブル:
  サーバー A: OS パッチ適用済み、設定ファイル手動変更
  サーバー B: OS パッチ未適用、設定ファイルは元のまま
  → 「A では動くが B では動かない」

イミュータブル:
  サーバー A: イメージ v1.2.3 から起動
  サーバー B: イメージ v1.2.3 から起動
  → 完全に同一

AWS での実装

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

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