　15日（土）に Amazon AWS の日本ユーザー会(JAWS)によるフォーラム、JAWS DAYS 2014 に参加してきました。その中でも特に盛り上がっていたトラックのキーワード Immutable Infrastructure について、自分用に簡単にまとめたものを公開します。長文なので、お時間のあるときにでも見ていただけたら嬉しいです。

関連エントリ：JAWS DAYS 2014 レポート - よしだのブログ

Immutable Infrastructure とは

　Immutable Infrastructure とは、サーバーやネットワーク、ストレージなどのインフラを一度作ってリリースした後は、動いている本番環境には手を加えない、変更をしないという考え方です。以下、参考サイトです。

　現状はステートレスなアプリケーション・サーバーなど一部への適用が始まっているようです。

背景にある課題

　特に継続的な改修やデプロイが必要なウェブサービスやECの世界では、これまでのインフラを継続的に使う方法では、インフラの状態を追う必要がありました。パッチを当てる、カーネルのパラメータを調整する、ロードバランサの設定を変えるなどインフラへの変更は適宜行われます。平行して、アプリの開発や改修が平行して行われているケースでは、そのアプリが本当に正常に動くかをテストによって確かめる必要があります。きちんと全てのインフラの状態を追っていて、それを開発環境に反映しており、テストしている必要があります。

　一方で、大規模化するインフラでは、状態をきちんとトラックするのが難しいのが現実です（人的資源、予算、作業フローの整備など各種制約による）。さらに、日々アクセス状況に合わせて各パラメータを調整する必要があり、更に状態を追うことの難易度が高くなります。これが、現状の課題です。

Immutable Infrastructure を実現するためのツールや技術要素

　これらの課題を解決する一つの考え方・手法として提唱されたのが、 Immutable Infrastructure です。具体的にどのような方法かというと、今動いているサーバーやインフラは一切触らずに、次回のリリース用に環境ごと新たに作り直し、リリース時はロードバランサやDNSの切り替えによって一気に切り替える、というやり方です。この方法は Blue-Green Deployment と呼ばれています。リリースされるアプリはインフラ含め全てテストされた状態であることが完全に保証されます。

　従来であれば、実現が費用的にも困難であったわけですが、以下の技術的な発展やツールを背景に流行りつつあります。

IaaS によるオンデマンドでのハードウェアの調達が可能になった。
Heroku / Docker / Vagrant などによる仮想化、コンテナ技術の発展により、必要なインスタンスを素早くオンデマンドに作成・廃棄ができるようになった。
Puppet / Chef、AWS であれば Cloud Formation などの自動構築ツールの発展。インフラの設定や設計を記述でき、インフラの状態が容易にバージョン管理できるようになった。

　もちろん、完全な考え方ではなくいくつかの制約も存在します。例えば、データベースなどステートを保管、管理するサーバーについては今のところ実現が難しいとされています。