概要

最近話題の Immutable Infrastructure ですが、一体何者だろうと考えたところ「インフラをプロセスのように扱う」ことだという結論に至りました。

Immutable Infrastructure

Immutable Infrastructure とは昨今話題となっているサーバーインフラについての概念で、サーバーを Immutable、つまり状態をなくすことによって主に管理・運用面で様々な恩恵に与ろうというものです。

与れる恩恵については以下のスライドが分かりやすいです。

この Immutable Infrastructure について一家言持ってみようということで、その意味について考えてみました。

Infrastructure as Code とはインフラの構成等をプログラムコードの形で記述しておき、そのコードを実行することで目的のインフラを再現できるようにしておきましょうというものです (参考: Infrastructure as Code - naoyaのはてなダイアリー)。

このインフラの構成をプログラムコード化したものをここではレシピと呼ぶことにします。

Immutable Infrastructure のやり方ではこの Infrastructure as Code に倣ってインフラを構築するレシピを用意し、インフラを気軽に作ったり壊したりできるようにした上で、インフラの状態を更新する時はレシピを更新して再度新たなインスタンスを生成します。

Infrastructure as Code によってインフラがレシピ化されました。そのレシピを実行するとサーバーというインスタンスが生成されます。

これは丁度プログラムを実行するとプロセスというインスタンスが生成されることのアナロジーとして見ることができます。

Immutable Infrastructure ではインフラに状態を持たせません。つまりインスタンスを破棄すると保持していたデータは消え、何度インスタンスを生成しても同じ状態のものが得られます。

一方プロセスについても、終了するとメモリは解放され、何度同じプログラムを実行しても同じ状態のプロセスが生成されます (環境変数や引数は外部の状態と見なします)。

また、Immutable Infrastructure ではログ等のインフラに状態を持たせる要素を外部 DB に保存するという対策が取られますが、これはプロセスがデータをハードディスクに保存することと同じことだと考えられます。

図にするとこんな感じになります。

f:id:ntsujio:20140707141736p:plain

この図では「レシピ <---> サーバー」の関係と「プログラム <---> プロセス」の関係を相似と見ることができると思います。対応関係としては次のようになります。

このような考えに立つと、昨今の流行であるレシピのバージョン管理、レビューや Serverspec によるインフラのテスト等、元々プログラム開発で行われていた技法がインフラ開発に取り入れられたのも納得できます。

また、GitHub や Travis CI、Docker Hub のようなサービスを連携させて複雑なシステムを組み上げるのも、プロセスをパイプラインで繋いで複雑な処理を行うようなイメージで捉えることができるかと思います。