Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（前編）

仮想化やクラウドを基盤とした新しいインフラの考え方である「Immutable Infrastructure」が注目されています。3月25日、このImmutable Infrastructureをテーマに渋谷のDeNAオフィス大会議室で開催された勉強会「Immutable Infrastructure Conference #1」は、150人の定員に400人以上が申し込む人気ぶりでした。

これまでのImmutable Infrastructureに関する議論はおもにデプロイなど運用とインフラ周りの話題が中心でしたが、最初のセッションで登壇した伊藤直也氏は、Immutable Infrastructureが結果的にアプリケーションアーキテクチャにも大きな影響を与えるため、アプリケーション開発者もこの技術に注目すべきだと解説しています。

伊藤氏のセッションの内容をまとめました。

Immutable Infrastructureは実際には廃棄可能なコンポーネント

伊藤直也氏。DeNAで話すときが来たとは感慨深い（伊藤氏は元GREE）。

Immutable Infrastructureとは「不変のインフラ」ということなのですが、実際にはDisposable Components、廃棄可能なコンポーネントと言った方が現実を表しているかなと思います。

Immutableって言うと、サーバをセットアップしたら手を付けないという意味になりますけど、それよりも必要になったらサーバを作って、いらなくなったら捨ててしまうというのがImmutable Infrastructureの特徴です。

ただ「Disposable Components」っていうのはバズワード感が足りない（笑）。たぶん「Disposable Components勉強会」という名前だとこんなに人が集まったりしないと思うので（笑）、まあImmutable Infrastructureって言っといた方がかっこいい気がします。

そもそもなんでDisposableとかImmutableなのかっていうと、こういうこと、ありますよね。ある日、Railsサーバが納品されて、設定をいろいろ加えていって、そこに半年ぶりにRailsアプリをデプロイしようとするとき、果たしてちゃんとできるのか。ちょっとそのサーバ、動いてるんだから触るなよ、という状況になってるような。

つまり普通、サーバにはどんな設定が行われていて、いまどういう状態になっているのか、管理をしなければならない。

これまでは、例えば手順書を書いておいて、新しくサーバを導入して同じ状態にしたかったら手順書に従って手で実行するか、シェルスクリプト書いて実行するとか、工夫してきたところに、ChefやPuppetといったツールが出てきて、サーバの状態をコードで書けるようになった、というのが去年のホットなトピックでした。

でも、そもそも状態管理をするという前提ではなく、状態管理しなくてもいいじゃん、というコロンブスの卵みたいな発想が出てきて、それがImmutable Infrastructureの始まりだったと。

毎回サーバを新しくすればすっきりするよね

これは「情熱プログラマー」という本を書いた有名なプログラマのチャド・ファウラーさんがImmutable InfrastructureとDisposable Componentsについて書いたものですが、サーバを捨てろと（Trash Your Servers）、そこにコードを焼き付けろと（Burn Your Code）、そう書いてますね。

ただこれだと抽象的でまだよく分からないのですが、この文脈でよく語られるのがBlue-Green Deploymentというデプロイメントの手法で、これは2012年の「AWS re:Invent」というイベントでAmazonが1時間に1000回もデプロイしている方法を説明している図です。Publickeyの記事で詳しく書かれているので、ぜひ読んでみてもらいたいのですが。

これまでデプロイと言えば、いま動いているサーバのソフトウェアをアップデートして、リスタートするといったことをしていましたが、それだとよく事故るじゃないですか。

よくあるのはGem（Rubyのライブラリ）の依存関係がコンフリクトを起こして、リスタートしたら起動しなかったとか、あるいはサーバの適当な状態に依存していて、リスタートでその状態が失われてしまって動かなくなるとか。

そういうことがよくあるので、この図では何かをデプロイするときに、動いている既存のサーバとは別に、まったく新しいサーバ群を立ち上げて、新しいシステムが立ち上がったらロードバランサーを切り替える、そういう考え方がBlue-Green Deploymentです。

これを実施するには、クラウドというか仮想環境が前提になっていて、なぜかというとデプロイするために毎回何十台もサーバを調達するわけにもいかないですから、オンデマンドにサーバを立ち上げて環境を作れなければいけません。

そしてオンデマンドでサーバを立ち上げて環境を作るためには自動化とかが必須になって、そういう環境が整ってくると、こういうドラスティックなことができるよ、というのがImmutable Infrastructureなんです。

Immutable Infrastructureを難しく言うとそういうことですが、ざっくり言えばWindowsって調子が悪くなると再インストールしてすっきりさせるじゃないですか。OSにいろんなソフトウェアをインストールしたりカスタマイズしたりすると調子が悪くなりますが、再インストールすれば戻ります。

だったら、そもそも毎回作り直せばシステムはすっきりするよね、というのが簡単なImmutable Infrastructureの説明です。

Herokuはgit pushのたびに新しいコンテナを立ち上げる

これはそんなに新しい話じゃなくて、例えばHerokuは、git pushのタイミングでいま動いているアプリを上書きしているように見えるけれど、実際にはLinuxコンテナを使っていて、git pushされたコードは新しいコンテナで立ち上がって、古い環境は捨てられる、ということをしています。

これはまさに、Blue-Green Deploymentをやっているのに等しいです。

継続的インテグレーションのTravis CIなんかも、アプリのコードを送り込むとそのたびにLinuxコンテナを立ち上げて、テストをクリーンな環境で実行してくれるので、テストが変な状態に依存して落ちる、といったことがないようにできている例です。

そんな感じでImmutable Infrastructureでは、いままで固定的だったことが動的にできるので、例えばAmazonがやっているみたいに1時間に1000回デプロイすることも可能です。1000回はかなりすごいですけど。

もちろんAmazonはImmutable Infrastructureだけでこれを実現しているわけではなくて、SOAでコンポーネントの独立性を高めたりしていることもあるわけですが。

Immutableであることはアプリケーションアーキテクチャに影響を与える

次に、Immutable Infrastructureが、実際にアプリを作っている人や開発を回している人にどういう影響があるのか、というのを見ていきたいと思います。

先に結論を言ってしまうと、Immutable Infrastructureの影響はかなりあって、特にサーバがImmutableであるという制約はアプリケーションアーキテクチャに大きな影響を与えるだろうということ。

その結果、再現可能なアプリケーションとか、テストがしやすくなるとか、さっき説明したような上書きデプロイではなくコンテナデプロイが当たり前になっていくようなことが、これから起こるかもしれない。

Immutable Infrastructureと（インフラストラクチャと）言ってますけど、これによってアプリケーション開発者も無視できない設計や開発プロセスの変化が議論され始めているというのが昨今起きていることだと思います。

≫後編に続きます。後編では、Immutableの制約を受け入れることがアプリケーションに良い影響を与える、ということについて。

Immutable Infrastructure関連記事

• 「Immutable Infrastructure（イミュータブルインフラストラクチャ）と捨ててしまえるコンポーネント」 チャド・ファウラー氏
• 「Blue-Green Deployment」とは何か、マーチン・ファウラー氏の解説
• Amazonは1時間に最大1000回もデプロイする。クラウドネイティブなデプロイとはどういうものか？ AWS re:Invent基調講演（Day2 AM）