不変インフラ（Immutable Infrastructure）

可変インフラとは何が違う？

従来の 可変（Mutable）インフラ は、稼働中のサーバに SSH で入って直接更新 します。

• apt upgrade でパッケージを上げる、設定ファイルを書き換える、パッチを当てる…
• サーバは 作った後もずっと変化し続ける

一見ふつうですが、この「あとから手を入れる」が積み重なると 問題の温床 になります。不変インフラはここを断ち、更新＝入れ替え に置き換えます。

なぜ作り直すのか：ドリフトとスノーフレーク

手作業の更新を続けると、実際の構成が「あるべき姿」から少しずつズレて いきます。これが 構成ドリフト（Configuration Drift） です。

そして、緊急対応や試行錯誤の手当てが積み重なった結果、誰も全体を再現できない“一点もの”のサーバ ができあがります。これが スノーフレークサーバ（Snowflake Server）。雪の結晶のように 二つと同じものがない、という皮肉な呼び名です。

• 「本番だけ動く」「あのサーバだけ落とせない」状態になりがち
• 同じ手順で作っても 同じ環境が再現できない
• 障害時、何がどう変わっているのか分からない

不変インフラでは、変更を直接当てずイメージを作り直す ため、ドリフトが生まれる隙がありません。稼働環境は常に 「ビルドした時のまま」 に保たれます。

どう実現する：イメージ / コンテナ / IaC

不変インフラは概念であり、特定ツールの名前ではありません。実際には次の組み合わせで成り立ちます。

• イメージ化：OS・ランタイム・アプリ・設定を 1つのイメージに固める。マシンイメージ（AMI 等）や コンテナイメージ（Docker）。
• 構成のコード化：環境の作り方を コードで宣言 する。サーバ構成は IaC で、サーバの中身は Dockerfile などで。
• 入れ替えデプロイ：新イメージで新インスタンスを起動し、ロードバランサの向き先を切り替えてから旧を破棄。

コンテナはこの考え方をそのまま体現しています。Dockerfile から作ったイメージは 読み取り専用 で、起動するたびに同じ状態。詳しくは コンテナとは（VMとの違い） も参照。

# イメージ＝不変な“設計図”。更新はこのファイルを変えて作り直す
FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]

ビルドしたイメージにバージョンの タグ を付けておくと、入れ替えも巻き戻しも タグを指すだけ になります。

# v2 をビルドして稼働、問題が出たら v1 に戻すだけ
docker build -t myapp:2.0.0 .
# 障害時のロールバック（前のイメージへ入れ替え）
kubectl set image deployment/myapp app=myapp:1.9.3

うれしさ：ロールバックと再現性

入れ替え前提だからこそ、運用が安定します。

• ロールバックが容易：問題が出たら 前のイメージに差し替えるだけ。逆操作の手順書はいらない。
• 環境差が消える：開発・ステージング・本番で 同じイメージ を使えば「自分の環境では動く」が起きにくい。
• 水平スケールが楽：同一イメージから 何台でも同じ環境 を量産できる。
• デプロイ手法と好相性：イメージごと入れ替えるので、デプロイ戦略（ブルーグリーン / カナリア）と自然に噛み合う。

つまずきポイント：状態(State)の置き場所

「サーバを捨てる」前提と相性が悪いのが データ（状態） です。インスタンスを消すと一緒に消えるもの を中に置いてはいけません。

• DB・アップロードファイル・ログは 外部（マネージドDB・オブジェクトストレージ・ログ基盤） に逃がす
• サーバ自身は ステートレス に保つ（捨てても困らない状態にする）
• 設定値や秘密情報も イメージに焼き込まず、環境変数やシークレット管理で外から注入

まとめ：いつ効くか

• 手作業による“環境のズレ”に悩んでいる → 不変インフラでドリフトを断つ
• ロールバックや再現性を重視したい → イメージ単位の入れ替えで安全に巻き戻す
• コンテナや IaC を既に使っている → その延長で自然に取り入れられる

「直さない・作り直す・状態は外へ」。この3点が不変インフラの背骨です。