今さら聞けない Immutable Infrastructure

devops

Immutable （不変な） Infrastructure は、サーバを一度セットアップしたら二度と変更を加えないという運用スタイルのことを指します。

クラウド環境では、必要に応じてすぐにサーバを用意し、不要になったら簡単に破棄することができます。Immutable Infrastructure は、このようなクラウドの特性を活かす運用スタイルとして、注目されつつあります。

背景

Immutable Infrastructure が提唱された背景にある技術として、 Auto Scaling や Blue-Green Deployment*1 などがあります。

Auto Scaling

Auto Scaling は、負荷に応じて自動的にサーバ台数を増減させる技術で、 AWS では標準で提供されています。常に必要な台数だけ起動していればいいので、コスト削減になるというものです。

Auto Scaling では、サーバが自動的に立ち上がったり、シャットダウンしたりするので、自然とサーバを使い捨てるスタイルで運用することになります。

Blue-Green Deployment

Blue-Green Deployment は、クラウドネイティブなデプロイ方法として近年注目されているデプロイパターンで、 Amazon.com や Netflix などで採用されていることが知られています。 たとえば、古典的なアプリケーションサーバのデプロイでは、アプリケーションコードをサーバに配置したのち、サーバソフトウェアを再起動することが求められます。しかし、 Blue-Green Deployment では、サーバ群をまるごと複製し、ロードバランサで切り替えることでデプロイとします。もしアプリケーションサーバが100台あれば、新しいバージョンのアプリケーションをインストールしたサーバをもう100台セットアップし、ウォームアップしたのち、そちらにトラフィックを切り替えるということです。 そうすることで、サーバソフトウェアの再起動時のパフォーマンス低下を気にする必要がなくなったり、ロールバックが簡単になったりという恩恵があります。

Auto Scaling と同様、 Blue-Green Deployment では、サーバは使い捨てになってしまうという制約があります。この制約を逆手に取り、「すべてのサーバは必ず使い捨てである」と割りきってしまえば、サーバの構築や管理がシンプルにできるのではないか、というのが Immutable Infrastructure の基本的な考え方です。

利点

Immutable Infrastructure がもたらす恩恵について考えてみます。

全てのサーバが同じ状態であることが保証される

あなたの手元のサーバ群で、 puppet/chef を使って長年のあいだ何度も更新を繰り返してきたサーバと、それらと同じ manifest/cookbook を使ってゼロからセットアップしたサーバが、完全に同じ状態になるという自信はありますか？

サーバをセットアップしたら二度と変更を加えないということは、全てのサーバが同じ状態であることが保証されます*2。これは大きな恩恵の一つです。

常にゼロからセットアップできることが保証される

いつでも確実にゼロからサーバをセットアップできることが保証されるということは、サービスの可用性を担保するうえで非常に重要です。

AWS などのクラウドでも、その中身はハードウェアなので、かならず物理故障は発生します。故障によって復旧不可能になったサーバをゼロからセットアップをしなければならなくなったとき、もたもたして時間がかかってしまうというのは多くのサーバ管理者が経験していると思います。

日頃から、いつでもサービスインできるクオリティのサーバがワンクリックでサービスインできる状態にしておけば、突然の故障にも慌てる必要がなくなります。

自動化が必須になる

Immutable Infrastructure では、「puppet/chef を適用したあと、 ssh でログインして手動で××をする」というようなセットアップ手順はもちろん許されません。 「二度と変更を加えない」ためには、まっさらな状態のサーバを起動するだけで、サービスイン可能な品質のサーバが完成する必要があります。この制約を守ると、「ワンクリックでサーバ起動からサービスインまで完了する」という環境を実現することができます。

セットアップの自動化は、属人性を廃したり、オペミスを減らしたりするだけではなく、サーバを抽象化して、ソフトウェアの1オブジェクトとして扱うという、クラウドネイティブな考え方においてとても重要な意味があります。

プロビジョニングがシンプルにできる

「二度と変更を加えない」ということは、「chef/puppet を最初の一度しか実行しない」ということを意味します。

chef や puppet には、「冪（べき）等性」という重要な機能があります。これは、同じサーバに何度も chef/puppet 実行を繰り返しても、同じ結果が得られることが保証されるという性質です。しかし Immutable Infrastructure では「chef/puppet を絶対に一度しか実行しない」ため、そもそもこの冪等性は不要であり、オーバースペックといえます。

極端に言えば、昔ながらのシェルスクリプトによるセットアップでも問題なく Immutable に運用することができます。冪等性が不要になるということは、プロビジョニングはとてもシンプルにすることができるのです。

テストとの親和性

たとえば serverspec によるサーバ状態の CI*3 を行っている場合、 CI 環境で作られるサーバと本番サーバの状態が乖離していたらテストの意味がなくなってしまいます。

Immutable Infrastructure では、すべてのサーバの状態が同じであることが保証されているので、 CI の結果の信ぴょう性が高まります。

サーバセットアップが簡単になる・サーバをいつでも使い捨てできるという Immutable Infrastructure の特徴も、テストのしやすさに貢献します。

サーバのポータビリティが高められる

たとえば AWS では、ユーザ同士でマシンイメージを共有することができるので、世界中の誰でも同じマシンスペックかつ同じ内容のサーバを構築することができます。

マシンイメージを構築するためのセットアップスクリプトを github などで共有し、ソーシャルコーディングで一つのサーバを改善していくという行為が、近いうちに当たり前になっていくかもしれません。

課題

Immutable Infrastructure はまだ未成熟な概念であり、解決すべき課題がいくつか残されています。

コスト

Blue-Green Deployment では、デプロイ時に現在稼働中のサーバ群と同じ台数のサーバが必要になるので、その分コストがかかります。

ログ

サーバを使い捨てにしてしまうと、当たり前ですが、サーバのファイルシステムに記録されていた各種ログファイルが消えてしまうため、何らかのログ集約の仕組みを用意する必要があります。

データベース、ストレージ

MySQL などの永続的 DB や、ストレージサーバを使い捨てにするのは、非常に技術的難易度が高いです。

逃げ道として、 Amazon RDS や MongoLab といった Database as a Service を利用することで、データベースサーバもまたひとつの抽象化されたオブジェクトとして扱うことができる、という手があります。

Immutable 前提なプロビジョニングツール

Immutable Infrastructure の文脈では Chef や Puppet の冪等性がオーバースペックである、と説明しましたが、 Immutable を前提にした軽量プロビジョニングツールという分野は、2013年11月時点ではまだデファクトスタンダードが登場していません。

まとめ

Immutable Infrastructure は、サーバを使い捨てにし、一度セットアップしたら二度と状態を変更しないという運用スタイルです。私は、 Immutable Infrastructure という概念は、単なる運用テクニックではなく、「サーバをソフトウェア部品として抽象化する」というクラウドネイティブな発想へシフトするものであると考えています。まだ若い概念であり、実践の定石が存在しない状態のため、今後の動きに注目しています。

参考資料

*1:Red-Black Deployment, A/B Deployment とも呼ばれている

*2:適切にデプロイ・切り替えが行われていれば、ですが

*3:Continuous Integration, 自動テスト

*4:サーバの追加・削除を検知したり、各サーバの情報を集約すること