プログラマでありたい

おっさんになっても、プログラマでありつづけたい

Immutable InfrastructureとChefと冪等性の話

 最近話題になっているImmutable Infrastructure(イミュータブル・インフラストラクチャ/サーバ)。あんまりよく解っていないので、整理してみました。

Immutable Infrastructureとは?



 そもそもImmutable Infrastructureとは、何でしょう?極論すると、「稼働中のサーバの構成管理をやめて、サーバを使い捨てにしよう」という考え方です。これだけ言われても、さっぱり解らないと思います。
 まずは従来の考え方。Mutable Infrastructureというのか、既存のサーバに変更を加えていくことが前提になります。

 それに対して、Immutable Infrastructure。直訳すると変化しないインフラとなります。どういうことかと言うと、サーバ構成(ミドル・アプリ)を変更したい場合は新規にサーバを立ちあげ、そこに既存の機能と新規の機能を加えた形で構築します。そして、構築後に既存のサーバから新規のサーバに切り替えます。

Immutable Infrastructureと冪等性の話




 Immutable Infrastructureの考え方は理解できたかと思います。では、何故使い捨て(disposable)にする必要があるのでしょうか?その背景には、2つの理由があると思います。
 1つ目は既存の構成に手を加えるのは、著しい困難が伴うことがあるということです。例えば既存のミドルウェアをバージョンアップするとします。パッケージの依存関係を考えると、既存の環境を壊さないように気を使いながら、新規のパッケージを入れていくということが必要になります。言葉で書くとたいした問題ではないと思いますが、本番環境で動いているものに手を加えるのは想像以上にストレスが溜まります。
 2つ目は、冪等性を保証するのは難しいということです。そもそも冪等性とは、ある操作を1回行っても複数回行っても同じ結果であるという概念です。何故、ここで冪等性が出てくるかというとChefを始めとするインフラストラクチャ自動化フレームワークの特徴の1つとして、冪等性があります。例えば、単純にNginxをインストールするのをコードで管理したいのであれば、シェルスクリプトとsshだけあれば充分です。しかし、シェルスクリプトの場合、(よほど考えて作らない限りは)同じもう一度実行したらエラーになるでしょう。何故ならば、既にNginxがインストールされているから。その辺りの問題を解決するのがChefです。Chefならば基本的に冪等性が保証されているので、既存の環境に機能を追加するのも簡単です。と言いたいところですが、冪等性を保証するのはレシピを書いた人です。色々な状況を考え冪等性を担保するのは、中々大変です。
 上記の2つを解決策として、Immutable Infrastructureが注目されているというのが最近の文脈だと思います。使い捨てにするのであれば、既存環境との整合性を考える必要はありません。また都度構築するのであれば、冪等性も考える必要がありません。そして、AWSを始めとするクラウドのお陰で、仮想サーバを使い捨てに出来ます。と言うことで、Immutable Infrastructureという考え方が注目され始めています。

Chefは不要か?



 Immutable Infrastructureの流れの中で議論されるのが、ChefはToo Machなサービスではないかという点です。Chefの重要なコンセプトの1つに、冪等性があります。そこを保証する為に、過剰に力を入れているのではないかという批判です。サーバを使い捨てにするのであれば、冪等性を切り捨てられるからChefも要らないという話ですね。実際どうなのでしょう?私は、Immutable Infrastructureの流れが定着してもChefを使い人は増え続けるのではと考えています。理由としては、2つ考えられます。
 1つ目は、全てのサーバを使い捨てには出来ないという点です。現状、Immutableに出来るのは、アプリケーションサーバやプロキシサーバなど状態を持たないサーバ(Stateless Server)のみです。データベースやファイルサーバのように状態を持つサーバ(Stateful Server)には適用出来ません。じゃぁ、Stateful Serverの管理をどうするのとなるとChefのようなフレームワークを使う方が便利です。(そのうちRDSやS3のようなPaaS/SaaSに代替されて、そもそもサーバである必要は無くなるかもしれませんが。)
 2つ目の理由としては、使い捨てであろうが初回構築が必要ということです。使い捨てだから手作業で構築するのかというと、恐らくノーです。面倒くさいし、不正確です。一方でImmutable前提で、Chefの変わりにシェルスクリプト等でインストールするケースは増えると思います。しかし、独自のインストール・シェルがChefに較べて生産性が著しく高いかというと、そうでも無いのではと思います。やっぱりChefはProvisioningツールとして特化しているので、(最初に学習コストを払えば)色々な面で効率性が高いです。


まとめ



 考えがまとまってないので話長くなりましたが、Immutable Infrastructureの流れでChefが不要になるかどうかは、正直どうでもよい話だと思っています。ImmutableだからChefじゃなく別のツールでやるよというのと、Chef使ってImmutable Infrastructureを実現するよというのは矛盾なく成り立ちます。恐らくChef Serverからより軽量のChef Soloが出てきたように、Chef自身もImmutable Infrastructureの流れを受けて変化していくと思います。大事なのは、コードでサーバを管理するという考え方なのではないでしょうか?
 AWSを始めとするクラウドのお陰で今まで出来ていたことが簡単に出来るようになっています。それだけではなく、今まで出来ないことが出来るようにもなっています。そうなると当然、今までと考え方が変わってきます。その背景をしっかり見定めないとなぁと思います。


See Also:
何故、Chefなのか?
サーバ構築・デプロイの自動化の話。或いはChefとCapistranoの素敵な関係
運用視点でChef ServerかChef Solo + Knife Soloのどちらが良いか考えてみた
手動でサーバの設定をすることを禁ずる。入門Chef Solo
Statelessなサーバについて 〜クラウド時代のサーバの在り方


参照:
Immutable Infrastructureという考え方 - ✘╹◡╹✘
Immutable Infrastructure の有用性 - Togetter