II（イミュータブル・インフラストラクチャー）
IT業界の最近の略語（新語）にII(Imutable Infrasutracture ：イミュータブル・インフラストラクチャー）というのがある。
日経コンピュータ誌の9月4日号に「ITインフラは使い捨てへ」というタイトルの特集記事が出ている。
実はこの記事よりも以前に、Web+DB Press誌（Vol.81)に「使い捨てサーバによる運用の変革」という特集記事が出ている。
タイトルが似ており、記事の内容も似ているが、Web+DB Pressの方が各種関連ツールやシステム構成の説明など、より実践的な内容になっている。以下、記事からの引用部分は「」で記す。
Web+DB Presの記事によれば、II（イミュータブル・インフラストラクチャー）は、2013年6月、Chad Fowler氏が提唱した概念であり、「インフラのサーバなどの各コンポーネントを常に再構成できるようにしておき、いつでも捨てられる（Disposable)ようにしよう」というのが基本コンセプトのようである。
これを実現するために、「各サーバーを一度セットアップしたら、その後はその状態を変化させず、不変（Immutable)にする」という原則をインフラの各コンポーネントに導入する。
上記のDisposableという言葉から、両誌の記事のタイトルに「使い捨て」という言葉が使われているようだが、捨てることが目的ではなく、ITインフラを自動で素早くいつでも構築できることがポイントだと思われる。（いつでもすぐに構築できるから、古い設定のITインフラは捨てることができる）
もう一つのポイントは不変（Immutable)である。
一般にシステムの運用を開始すると、OSやミドルウェアへのパッチ適用やバージョンアップ、環境設定の変更などが発生する。アプリケーション・サーバのように複数台で運用を続けていると、長い年月の間に、サーバ間で環境設定に差異が生じるケースがある。
また、本番環境と開発環境とで、環境設定に差異が生じる場合もある。その結果、機能追加などでアプリケーションをバージョンアップした時、開発環境では問題なく動作していたのに、本番環境にリリースしたら動かなかった、という事態も起こり得る。
このような事態を避けるために、環境設定を変更する場合は、古い設定のITインフラを捨てて、新しい設定のITインフラを再構築する。
そして再構築したらそれ以降設定は一切変更せず、不変（Immutable)を保つという考えである。
このように、IIの目的は、記事のタイトルにもある通り、「運用の変革」にあるといえよう。
システム運用を簡潔にして自動化を図り、人的ミスが混入するリスクを最小化することが狙いだといえる。
このように書くと良いことずくめのようだが、IIはまだ発展途上の技術である。また、デメリットもある。さらにその要件「状態を変化させずに不変にする」から、IIに向いたシステムと不向きなシステムとがある。
「DBやファイルサーバなどの本質的に状態を持つ必要があるステートフルサーバは、IIの対象とはできない」
IIは、アプリケーションサーバのように、状態を持たず、複数台で運用するシステムに適しているようだ。
IIでは設定を変更するたびにITインフラを構築しなおす必要があるから、インフラ構築を自動化できることが前提条件になってくる。自動化を可能にした背景には、サーバの仮想技術とサーバ構成管理技術（プロビジョニングツール）の進化がある。
「IIはもともと、AWS(AmazonWebService)上でデプロイをより進化させるために生まれたアイデアです。それもあり、AWSによるIIは本流と言える」
記事では、AWS以外でIIを実現する構成として、DockerとHAProxyを使用した構成が紹介されている。
システム運用・保守の改革、ないしは改善を検討している方には参考になるのではないかと思う（但し、いくつかの企業で導入、評価が進んでいるようだが、先に記したようにまだ発展途上の技術である）。