2026.08.05 アーキテクチャ

イミュータブルインフラとは？サーバーを更新せず作り直す運用の実装と採用判断

イミュータブルインフラは、いったん動き始めたサーバーに手を入れず、変更したいときはイメージごと新しい個体を作って古い個体を捨てる運用モデルです。CNCFのCloud Native Glossaryは、これを「デプロイされたあとに変更できないコンピューターインフラ」と定義しています。定義自体は一行で済みますが、実際に回そうとすると、データをどこへ逃がすか、緊急パッチをどう当てるか、増え続けるイメージ世代を誰が保守するかという三つの壁にぶつかります。この記事では、ミュータブル運用との差、ゴールデンイメージとコンテナそれぞれの実装、KubernetesとAWSでの具体的な設定値、そして採用を見送ってよい条件までを実装目線でたどりました。版番号と仕様は2026年8月5日時点で各公式ドキュメントを確認した内容です。

まとめ：イミュータブルインフラは直すのをやめて捨てる判断への切り替え

先に結論を置きます。この考え方の価値は、サーバーを不変にすること自体にはありません。稼働中の個体に加えた変更を追跡する仕事を消し、「動いている環境はイメージから一意に再現できる」という前提を組織が信じられる状態を作る点にあります。信じられるから、障害時に原因調査を飛ばして作り直せます。

導入の順序を間違えないでください。最初に要るのはイメージ作成の自動化ではなく、状態の切り離しです。データやセッション、ログがサーバー本体に貼り付いたままだと、個体を捨てた瞬間にそれらも消えます。外部化が終わってから自動化へ進む、という順番になります。

見送ってよい条件も明確です。台数が1台か2台で、更新が年に数回、しかも状態を外へ出せない業務ソフトウェアが同居しているなら、イメージ運用の追加コストが上回ります。作り直しに寄せるのは、手で直した記憶が誰にも残らなくなる規模に達してからで構いません。

イミュータブルインフラの定義と「変更しない」が実務で指す境界

範囲が曖昧なまま議論すると、「パッチも当てないのか」という誤解で止まります。何を不変とみなすかを先に固定します。

稼働中の個体へ手を入れない前提とイメージ単位での置き換え手順

不変の対象は、サーバーの中身、つまりOSとミドルウェアとアプリケーションのバイナリおよび設定です。これを一つのイメージとして固め、デプロイ後は一切書き換えません。パッチを当てないという意味ではありません。パッチを当てた新しいイメージを作り、そこから起動した個体へ入れ替えるという手順に変わるだけです。

実務での判断はシンプルです。稼働中のサーバーへログインして設定ファイルを書き換えたら、その時点で不変性は失われました。緊急対応でそうせざるを得なかったなら、対応後に同じ変更をイメージ側へ反映し、作り直した個体へ置き換えます。この後追いを省いた瞬間、その1台は誰も再現できない個体に変わります。

Chad Fowlerが2013年に示した提唱の背景とペットと家畜の対比

この概念は、Chad Fowlerが2013年に公開した記事「Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components」で広まりました。Fowlerは関数型言語の不変データ構造を引き合いに出し、「自動化によって作られ、作成の瞬間から一度も変更されていないと確実に言えるなら、問題のほとんどは消える」と書いています。

同時期に広まった対比が、ペットと家畜です。ペットは名前を付けて世話をし、具合が悪くなれば治療する対象。家畜は番号で管理し、不調なら群れから外して入れ替える対象。サーバーを後者として扱えるかどうかが、この運用モデルを採れるかの実質的な分かれ目になります。名前で呼ばれているサーバーが社内にあるなら、それは治療対象として扱われている証拠です。

IaCと構成管理・デプロイ方式それぞれの役割の重なりと切り分け

混同されやすい三つの言葉との関係を整理します。IaC（Infrastructure as Code）はインフラの定義をコードで記述する手法であり、イミュータブルインフラを成立させる前提条件です。ただしIaCを入れても、適用先を毎回作り直すか既存サーバーへ差分を当てるかは、別の選択として残ります。

デプロイ方式との関係も同じ構図です。ブルーグリーンデプロイメントは新旧2面を用意して切り替える方式で、イミュータブルな置き換えを実現する具体的な手段の一つにあたります。イミュータブルインフラは方式の名前ではなく、「置き換えでしか変更を反映しない」という運用上の約束事だと捉えてください。

ミュータブル運用が抱える構成ドリフトとスノーフレークサーバーの実害

パッチ適用の積み重ねが生む台数ごとの差異と再現不能になる状態

ミュータブル運用では、稼働中のサーバーへ順次パッチや設定変更を適用します。10台のうち3台で適用が失敗し、そのまま放置された。ある1台だけ障害対応時にライブラリを手動で入れ替えた。こうした差異が積み上がった状態を構成ドリフトと呼び、極端に固有化した個体をスノーフレークサーバーと呼びます。

Ansibleなどの構成管理ツールは、この差異を埋めるため冪等性を担保した収束処理を繰り返します。ただし収束が保証されるのは、ツールが管理下に置いた項目だけです。管理外で入った変更、たとえば手動で追加されたcron設定や、パッケージマネージャを経由せず配置されたバイナリは、何度収束させても残ります。作り直しに寄せると、この「管理外の変更」という概念自体が消えます。

障害復旧の所要時間が原因調査から作り直しへ切り替わる差の実像

実務でいちばん体感差が出るのは、障害時の初動です。ミュータブル運用では、まず「この個体だけなぜ落ちたのか」を調べます。ログを追い、他の個体との差分を探し、原因が特定できてから直す。調査時間は原因の性質に依存するため、事前に見積もれません。

置き換え前提なら、初動は個体の切り離しと再作成です。イメージが同一である以上、その個体固有の原因は再作成で消えるからです。原因調査は復旧のあとに、切り離した個体を残したまま行えます。復旧と調査を直列から並列に変えられる点が、この運用モデルの実利になります。

本番の変更禁止がセキュリティと監査で生む効果と残る限界の範囲

本番サーバーへのログインと書き換えを禁止できると、監査上の説明が短くなります。「本番の構成はどう変わったか」という問いに、イメージのバージョン履歴とデプロイ記録だけで答えられるからです。侵入者が永続的なバックドアを仕込んでも、次の置き換えで消えます。

限界も正直に書きます。週に一度しか入れ替えないなら、最悪7日間は仕込まれたままです。不変性が守るのはサーバー本体だけで、外部ストレージ側の改変は別の手段で守ります。

イミュータブル運用を成立させる三つの構成要素とイメージ置き換えの流れ

実装は「作る・置く・入れ替える」の三工程に分解できます。基盤ごとに道具は変わりますが、骨格は同じです。

ゴールデンイメージ作成をPacker 1.16系で自動化する工程

仮想マシン基盤では、必要なミドルウェアとアプリケーションを焼き込んだゴールデンイメージ（AWSならAMI）を作ります。この工程を自動化する定番がPackerで、2026年7月24日公開の1.16系ではprovenanceポストプロセッサとpacker verify-attestationコマンドが加わり、SLSA Build L1およびL2の来歴証明を出力できるようになりました。イメージが「どのソースから、どの手順で作られたか」を検証可能な形で残せます。

一方で、ビルド時間が新たな待ち時間として乗ります。OSの更新とパッケージ導入で10分から30分かかるのが一般的な範囲で、緊急パッチ時のリードタイムに直結する箇所です。ベースイメージを段階化し、頻繁に変わるアプリケーション層だけを最終段で焼くと、待ち時間を圧縮できます。

コンテナイメージのダイジェスト固定とタグ運用に潜む二つの落とし穴

コンテナは、レイヤが読み取り専用で積まれる構造そのものが不変性を前提にした設計です。ただしコンテナを使っているだけでは担保されません。落とし穴はタグにあります。

myapp:latestのような可変タグで参照していると、同じ定義から起動した個体でも、起動した時刻によって中身が変わります。参照はmyapp@sha256:...の形でダイジェストへ固定するか、少なくともビルドごとに一意な不変タグを発行してください。レジストリ側でタグの上書きを禁止する設定を有効にすれば、同じタグに別の中身が入る事故も止められます。

Terraformのcreate_before_destroyで決める入れ替えの順序

置き換え工程では、新旧どちらを先に処理するかで無停止性が変わります。Terraformで管理している場合、リソースのlifecycleブロックへcreate_before_destroy = trueを指定すると、新しいリソースを作ってから古いリソースを破棄する順序になります。既定は逆順のため、指定漏れがあると入れ替えのたびに空白時間が生じました。

注意すべきは名前が衝突するリソースです。セキュリティグループやIAMロールのように名前が一意でなければならないリソースは、新旧が一時的に併存できず失敗します。名前を固定せずname_prefix系の属性で生成させる構成に変えておくと、併存期間を作れます。

作り直しても壊れない状態の外出し設計と保持先を切り分ける基準

導入の失敗はほぼここに集中します。個体を捨てられる状態を先に作らないと、置き換えの自動化はただの障害要因になります。

永続データ・セッション・ログを本体から切り離す配置先の判断基準

基準は一つです。「その個体を今すぐ消しても、業務上失われて困るものが中に残っていないか」。残っているなら外へ出します。切り分けの典型は次の四つになります。

  • 永続データ：マネージドデータベースまたは外部ストレージへ寄せる
  • アップロードファイル：オブジェクトストレージへ寄せ、ローカルには置かない
  • セッション：外部のキーバリューストアへ保存し、粘着性に依存しない
  • ログとメトリクス：収集基盤へ即時転送し、本体には保持しない

着手順を付けるなら、まずログとセッションからです。切り出しの影響範囲がアプリケーション内に閉じることが多く、データベースの移設より短期間で終わります。逆にアップロードファイルの外出しは、既存コードのファイルパス依存を洗い出す作業が伴うため、見積もりが伸びやすい領域でした。

シークレットをイメージへ焼き込まずに起動時へ注入する実装手順

接続情報や鍵をイメージに含めると、イメージの流通範囲がそのまま漏洩面になります。レジストリやAMIの共有設定を一度誤るだけで露出するため、イメージには入れません。The Twelve-Factor Appが示すとおり、設定はコードから切り離し、実行環境から与えます。

手順は基盤ごとに決まっています。AWSならSecrets ManagerやSSM Parameter Storeから起動時に取得し、KubernetesならSecretリソースを環境変数やボリュームとして渡す形です。取得に使う権限はインスタンスプロファイルやサービスアカウントへ紐付け、長期の固定鍵をイメージにもコードにも置かない構成にしてください。鍵のローテーションのたびにイメージを作り直す事態を避けられます。

状態を外へ出せないミドルウェアが残る場合の妥協する範囲の決め方

すべてを外出しできるとは限りません。ライセンスがホスト名やMACアドレスに紐付く商用ソフトウェア、ローカルディスクへの書き込みを前提にした古い業務パッケージは実在します。無理をすると、作り直すたびに手作業の復旧が必要な個体が生まれます。

線引きは層で切ってください。Webとアプリケーション層はイミュータブルに寄せ、外出しできないミドルウェアが載る層だけ構成管理ツールで維持する。この二層構成は現実的な着地点で、全体を統一できないことを失敗と見なす必要はありません。ただし、どの層がどちらの運用かを文書化しておかないと、後任が本番へログインしてよいかを判断できなくなります。

KubernetesとAWSでイミュータブル性を担保する設定値の実際

readOnlyRootFilesystemとダイジェスト指定で書き換えを封じる

Kubernetesでは、コンテナのセキュリティコンテキストにreadOnlyRootFilesystem: trueを指定すると、ルートファイルシステムへの書き込みが拒否されます。書き込みが必要な一時領域はemptyDirボリュームとしてマウントし、書ける場所を明示的に限定してください。この一手で、稼働中コンテナへの後付け変更は事実上できなくなります。

Deploymentのイメージ参照を更新すると、Kubernetesは既存Podへパッチを当てず、新しいReplicaSetを作ってPodを置き換えます。挙動そのものがイミュータブルな置き換えです。参照をダイジェストで固定しておけば、ノードごとにキャッシュ時期が違っても同一の中身が起動しました。

EC2 Auto Scalingのインスタンス更新で使う健全性の下限と上限

仮想マシン基盤では、EC2 Auto Scalingのインスタンス更新（Instance refresh）が置き換えの実行役になります。設定する値は主に二つです。MinHealthyPercentageは0から100の範囲で、置き換え中に維持する健全なインスタンスの下限割合を指定します。MaxHealthyPercentageは100から200の範囲で、一時的に許す上限割合を指定する項目です。

制約もあります。MaxHealthyPercentageを指定する場合はMinHealthyPercentageも必須で、両者の差は100を超えられません。差を広く取るほど同時に置き換えられる台数が増え、完了は速くなる代わりに一時的なキャパシティ変動が大きくなります。段階的に進めるならCheckpointPercentagesを昇順の配列で与え、末尾は100にします。CheckpointDelayを省略すると既定の3600秒（1時間）待つため、指定漏れで置き換えが止まって見える事故が起きがちです。

進め方そのものはローリングアップデートと同じ考え方で、違いは更新対象がアプリケーションのプロセスかインスタンス本体かという点にあります。

Bottlerocketが採る読み取り専用ルートと二面切り替えの仕組み

OS自体をイミュータブルに設計した例が、AWSのBottlerocketです。ルートファイルシステムはdm-verityで完全性を検証し、下位ブロックデバイスへの変更が検出されるとカーネルが再起動します。パッケージ単位の更新機構を持たず、更新はファイルシステムイメージ全体をダウンロードして再起動する方式です。

ルートデバイスにはアクティブとパッシブの2組のパーティションセットが置かれ、新しいイメージは非稼働側へ書き込まれてから起動先が切り替わります。イメージはTUFで署名され、起動に失敗した場合は自動でロールバックします。設定変更も型付きのAPI経由です。EKSやECSのワーカーノードとして採るなら、ノードへログインして調査する運用が前提から外れる点を、導入前にチームへ共有しておいてください。

イミュータブルインフラを採用すべき条件と見送ってよい場面の線引き

ここは言い切ります。この運用モデルは万能ではなく、規模と更新頻度によっては明確に過剰です。

採用して投資が回る条件は台数と更新頻度と環境差異の三つの実測値

採用して投資が回収できるのは、次の三条件のうち二つ以上に当てはまる場合です。第一に、同じ役割のサーバーが概ね5台以上あり、手作業では差異の追跡が現実的でないこと。第二に、更新が月に複数回発生し、置き換えの自動化が繰り返し使われること。第三に、開発・検証・本番の間で「本番だけ動かない」障害を過去に経験していること。

三つ目は軽視されがちですが、費用対効果の説明としてはいちばん通ります。環境差異による手戻りが四半期に一度でも起きているなら、その調査工数とイメージ運用の維持工数を並べて比較できるからです。

見送るべき場面はステートフルな単体サーバーと年数回だけの更新

逆に、次の条件が揃うなら採用しないでください。サーバーが1台か2台の構成で冗長化されておらず、置き換え中の停止時間を許容できない。状態がローカルディスクに強く依存し、外出しの改修に数か月かかる。更新は年に数回しかない。

この状況でイメージ運用を入れると、ビルド基盤・イメージ保管・世代管理という保守対象が三つ増えるのに対し、使う機会は年数回しかありません。構成管理ツールで手順をコード化し、変更履歴をリポジトリに残すところまでで止めるのが妥当な線です。

もう一つ見送るべきなのが「イメージを作れるが捨てられない」状態です。作り直しだけ自動化して古い個体の破棄を手動に残すと、消し忘れたインスタンスが課金され続け、しかも構成が古いまま稼働します。破棄まで自動で回らないなら、導入は先送りしてください。

導入コストの実像とイメージ運用が毎月新たに生む保守負債の内訳

見落とされやすいのが、運用開始後に発生し続けるコストです。イメージは世代ごとにストレージ費用が発生し、AMIならバックエンドのスナップショットも残ります。保持ポリシー（直近いくつまで残すか、ロールバック用に何日分残すか）を決めずに始めると、数か月で保管費用と一覧の見通しが悪化しました。

緊急パッチのリードタイムも設計事項です。イメージのビルド時間と置き換え時間の合計が、そのまま対応の下限時間になります。許容できないなら、例外的な手動適用の手順と、その後イメージへ反映するルールをセットで決めておきます。

ビルド基盤の維持、イメージ世代の棚卸し、ベースイメージの追随は、一度組んだら終わりではなく毎月発生する作業です。社内で回し切れるかを見極めたうえで、体制面から詰めたい場合は保守運用・内製化支援の相談段階で、どの工程を委託しどこから内製するかの分担を決めておくと、導入後に運用が止まる事態を避けられます。

イミュータブルインフラの仕組みと採用判断についてのよくある質問

実装時に判断が割れる論点をまとめました。

イミュータブルインフラとイミュータブルバックアップは同じ意味ですか？

別の概念です。イミュータブルバックアップは、取得済みのバックアップデータを一定期間だけ改変・削除できない状態にする保護機能で、ランサムウェア対策の文脈で使われます。対してイミュータブルインフラは、稼働環境そのものを変更せず置き換える運用モデルを指す言葉です。共通するのは「書き換えを禁じる」という発想だけで、バックアップ側はデータの保全、インフラ側は構成の再現性が主眼にあります。

コンテナを使えば自動的にイミュータブルインフラになりますか？

なりません。コンテナイメージの層構造は不変ですが、可変タグで参照していれば起動時期によって中身が変わりますし、稼働中のコンテナに入って設定ファイルを書き換えることも技術的には可能です。イメージ参照をダイジェストへ固定し、ルートファイルシステムを読み取り専用にし、稼働中コンテナへの侵入操作を権限と運用ルールで禁じて、初めて不変性が担保されます。

緊急のセキュリティパッチもイメージを作り直す必要がありますか？

原則は作り直しですが、猶予がない場合の例外手順を用意しておくのが現実的です。イメージのビルドと全台の置き換えに要する時間を平時に実測しておき、その時間内に収まるなら通常手順で通します。収まらない緊急度なら、稼働中の個体へ直接適用したうえで、同じ変更を必ずイメージへ反映してください。禁じ手は、直接適用したままイメージへ反映しないことです。放置すると次の置き換えでパッチが巻き戻ります。

オンプレミスの物理サーバーでもイミュータブル運用は実現できますか？

仮想化基盤があれば実現できます。物理サーバーの上にハイパーバイザを置き、仮想マシンのテンプレートを作り直して入れ替える構成なら、クラウドと同じ考え方が通ります。難しいのは、置き換え用の余剰リソースを常に確保する必要がある点です。クラウドなら一時的に台数を倍にできますが、オンプレミスでは物理容量の上限が先に来ます。余剰が取れないなら一台ずつ入れ替える方式に落とし、切り替え中の縮退を許容する設計にします。

ブルーグリーンデプロイメントとイミュータブルインフラの違いは何ですか？

抽象度が違います。ブルーグリーンデプロイメントは、新旧2面を用意して一気に切り替える具体的なデプロイ手順です。イミュータブルインフラは、変更を差分適用ではなく置き換えで反映するという運用上の原則で、その原則を満たす手順の一つがブルーグリーンにあたります。ローリングでの入れ替えも、個体を作り直しているならイミュータブルな運用です。まず原則を採るかを決め、そのあとに停止許容時間とコストから切り替え手順を選びます。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る