「Immutable Infrastructure（イミュータブルインフラストラクチャ）と捨ててしまえるコンポーネント」 チャド・ファウラー氏

「Immutable Infrastructure」（イミュータブルインフラストラクチャ）や「Blue-green Deployment」（ブルーグリーンデプロイメント）といった新しいデプロイの手法や考え方が登場して注目を集めています。

今週末に開催されるAmazonクラウドのコミュニティイベント「JAWS DAYS 2014」では、「Immutable Infrastructure」トラックが設けられ、朝から夕方まで丸1日かけてImmutable Infrastructureのセッションが行われますし、3月25日には有志によるイベント「Immutable Infrastructure Conference #1」が開催予定で、150人定員のところに450人以上もの希望者が集まっています。

こうした新しい手法は2012年12月に行われたAmazonクラウドのイベント「re:Invent 2012」でも紹介され、Publickeyでは記事として紹介しました。

• Amazonは1時間に最大1000回もデプロイする。クラウドネイティブなデプロイとはどういうものか？ AWS re:Invent基調講演（Day2 AM）

Immutable Infrastructureの話題が目に付くようになったのは昨年、2013年あたりからで、Kief Morris氏が2013年6月13日付けで「ImmutableServer」という記事をMartin Fowler氏のWebサイトにポスト、6月23日には「情熱プログラマー」の著者などとして知られるチャド・ファウラー氏が自身のブログに記事「Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components」をポストして、「Immutable Infrastructure」という言葉が広く使われる流れを作ったように思います。

本記事では、チャド・ファウラー氏から許可を得て、記事「Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components」の日本語訳を紹介します。また次の記事ではImmutable Infrastructureの考え方が登場するずっと前に、非常に近いデプロイメントの手法「Blue-Green Deployment」について解説したマーチン・ファウラー氏の記事「BlueGreenDeployment」の翻訳も紹介します（公開しました！）。

Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components - Chad Fowler

Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components

（2013年6月23日 Chad Fowler著）

開発者として、あるいはしばしばシステム管理をする者として、これまで経験したもっとも恐ろしいものの1つは、長年にわたり稼働し続けてなんどもシステムやアプリケーションのアップグレードを繰り返してきたサーバだ。

なぜか。その理由は、古いシステムはつぎはぎのような処置がされているに違いないからだ。障害が起きたときに一時しのぎのハックで対処され、コンフィグファイルをちょこっと直してやり過ごしてしまう。「あとでChefの方に反映しておくよ」とそのときは言うけれど、炎上したシステムの対処に疲れて一眠りしたあとでは、そんなことは忘れてしまうだろう。

予想もしないところでcronのジョブが走り始めて、よく分からないけれどなにか大事な処理をしていて、そのことを知っているのは関係者のうちの1人だけとか。通常のソースコード管理システムを使わずにコードが直接書き換えられているとか。システムがどんどん扱いにくくなっていき、手作業でしかデプロイできなくなるとか。初期化スクリプトがもはや、思いも付かないような例外的な操作をしなければ動かなくなっているとか。

もちろんOSは（きちんと管理されているならば）なんども適切にパッチが当て続けられているだろうが、そこには（訳注：やがて秩序が失われていくという）エントロピーの法則が忍び込んでくるものだし、適切に管理されていないとすればいちどもパッチは当てられず、もしこれからパッチを当てようものならなにが起きるか分からない。

システムはまるでトランプで作ったタワーのようになっていく。触れるのも怖いし、新たに別のものを作るのも怖い。なにがどう動いているのかさえさっぱり分からないのだ。

私たちはこの問題を解決するために何年ものあいだ、チームポリシーの策定から自動化までさまざまな方法を試してきた。そしていま試している新しい方法が「Immutable Deployments」（イミュータブル・デプロイメント）だ。

ソフトウェア業界にいる私たちの多くが、ソフトウェアアーキテクチャの不変性（immutability）の利点に気づき始めている。Erlang、Scala、Haskell、Clojureといったプログラミング言語の人気の上昇とともに関数型言語のプログラミングテクニックへの関心も高まっているが、その関数型言語は不変データ構造（immutable data structures）や単一代入変数（single assignment variables）を備えている。このことから（あくまで私たちの多くが経験を基に信じていることとして）、不変性はプログラムを、こんがらがりにくくするものだといえそうだ。

だとしたらこの手法を（可能なところから）インフラへ利用できないだろうか？ もしもシステムが自動的に生成され、その時点からいちども変更されていないと私たちが確実に知っているのなら、ここまで書いてきたような問題というのは起こりえない。システムのアップグレードが必要？ いいでしょう。アップグレード版システムを新規に作成し、古い方は捨ててしまえばいい。アプリのバージョンアップ？ それも同じこと。新バージョンでサーバを構築し、古いのは投げ捨ててしまうのだ。

私たち6Wunderkinderは、この方法に移行して4カ月が過ぎた。私たちはバックエンドインフラをより高速でスケーラブルで、顧客の信頼のおけるものにすべく、しかも私たちが開発するアプリケーションを前進させるために、より柔軟なものにするべく迅速な反復作業をしなければならないが、それを自信を持って行えるようになった。

さらに大事なことは、新しいプログラミングパラダイムと同様に、インフラをこのように考えることはシステムに対する私たちの見方を根本から変えてしまったのだ。新しいパターンとアンチパターンの登場だ。これはデプロイメントをどう考えるかにとどまらず、アプリケーションのコードへの考え方まで変えてしまっている（そしてチーム構成さえも）。

このアイデアは私にとってまだ進行形だ。これを最初に思いついたのは私たちではなく、まだ学ぶことは多い。そこには、いわゆる「クラウド」インフラも含むだろうし、モダンなソフトウェアアーキテクチャが一般にしていることだろうとも思う。

情熱プログラマー ソフトウェア開発者の幸せな生き方
本書は、等身大のプログラマの一人がキャリア開発の重要性を説き、そのための心構えなどを示したもの。「プログラマはビジネス視点を持って意識的なキャリア開発をすべき」という視点から、その実践方法を著者独特の生き生きとした共感できる語り口で伝える。