Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（後編）
仮想化やクラウドを基盤とした新しいインフラの考え方である「Immutable Infrastructure」が注目されています。このImmutable Infrastructureをテーマに3月25日に渋谷にあるDeNAの大会議室で開催された勉強会「Immutable Infrastructure Conference #1」では、150人の定員に400人以上が申し込む人気ぶりでした。
（本記事は「Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（前編）」の続きです）
不自由さをアプリケーションが受け入れることでよい影響が
まずアプリケーションアーキテクチャへの影響についてですが、サーバがImmutableになるということは不自由になるということじゃないですか。サーバをセットアップすると、もうそのサーバは設定などをいじらないので、管理者は楽ですが。
その不自由さをアプリケーションが受け入れなくてはならないのですが、でもこうした制約というのは必ずしも悪いことではない。ということはぼくたちは経験的によく知っていて、例えばRESTとか。HTTPもRESTが前提になっていてステートレスなので仕様がシンプルに保たれているとか。
それと同じで、Immutable Infrastructureの制約を受け入れることで、アプリケーションの設計によい影響を与える面があります。
その1つ1つはここでは解説しませんが、この「The Twelve Factor App」によくまとまっています。
このサイトはImmutable Infrastructureの概念が出てきてから作られたのではなく、Herokuにアプリケーションをデプロイしていた人が、Herokuのアーキテクチャを前提にアプリケーションを作っていると、いままでよりきれいにアプリケーションがまとまるということに気づいて、そのことをより抽象度の高い概念として記述してまとめたものです。
Herokuというのはさっき説明したように、コンテナベースで、かつある意味Immutable Infrastructureなのですが、この制約を受け入れるには、例えば「プロセスはステートレスかつShared Nothingである」ことが求められます。
これはつまり状態を持たない、特定のサーバの中だけでしか持っていない情報がないようにする。
それから「設定をコードから厳密に分離することを要求する」というのは要するに、実行環境とアプリケーション環境を完全に切り離して動かせるように、ということ。
「すべて依存関係を、依存関係宣言マニフェストで完全かつ厳密に宣言する」というのは、要するにBundlerとかPerlでいうCPANファイルを指しています。
HerokuにRailsアプリをデプロイするときには、Bundlerに全部gemファイルを書いてRackアプリとして構成し、ステートレスな感じで、Herokuのコンテナが落ちたとしても、またgit pushすれば同じような状態になることを保証したアプリケーションを書く必要があるんですけど、そういうことを難しく説明するとこういうことだと。
こういうことをしたことで、例えば緑色の文字で書いたようなことがメリットとして出てきます。これも引用です。
「下層のOSへの依存関係を明確化し、実行環境間での移植性を最大化する」というのは、要するに制約を受け入れると、例えばHerokuで動かしていたアプリをCloud Foundryベースの別のPaaSで動かしたいときに、PaaS間でアプリケーションの移植性を保証してくれれば、ゼロコンフィグで移植できるとか、あるいはローカルで動いていたアプリをgit pushするだけでHerokuで動かせるということです。
それは当然、Immutableという制約を受け入れることによって、アプリケーションが廃棄されてもgit pushすれば同じように動くことを保証したからこそ可能になった、ということですね。
ということで、Immutableな制約を受け入れると、アプリケーションの再現性が向上するみたいな、一見不自由な制約がインフラだけでなくアプリケーションにもいい影響をもたらすのが、Immutable Infrastructureがもたらす未来だと思っています。
再現可能なアプリケーションになると
再現可能なアプリケーションという話をしましたが、どこでも再現できるポータビリティの高さは重要で、そうするとアプリケーションをいろんなナントカ as a Serviceに放り込めるようになる。
インフラがImmutableになることで、アプリケーション側が標準化され、いろんな環境にもっていけるようになると。
そうするといろんなサービスが使えるだけでなく、開発環境とプロダクション環境も同一視できるということ。プログラミングにおいては両者を同一視できるのは非常によいパターンです。
さらにShared Nothingなのでサーバをぼこぼこつっこむだけでスケールするようになる。
だんだん結論が見えてくるのですが、ステートレスかつShared Nothingだと、いかにもテストしやすそうじゃないですか。状態に依存していたりI/Oに依存しているアプリケーションはテストが書きづらいんだけど、アプリケーションが再現可能であれば、そのアプリを適当に動かしてテストして同じ結果が得られることが保証されるのでテストしやすい。
Dockerのいちばん典型的なユースケースはここで、JenkinsがDockerコンテナをぼこぼこ立ち上げてテストしてくれる。要するにCI as a Serviceみたいなものを自社で持ちたいケースでとてもうまく合っている。
そしてさっき説明した、上書きデプロイからコンテナベースのデプロイ、ということも見えてきます。
こんな感じで、Immutable Infrastructureというのはデプロイのやり方やアプリケーションの設計、テストがしやすければ開発ワークフローも変わっていくといった、よい影響を与えてくれるものなので、アプリケーション開発者も注目したらいいのではないかなと思います。
面白い例だなと思ったのはQuipperという会社の例で、Quipperでは、gitでブランチを切ってそれをGitHubにpushするたびに、Herokuでアプリケーションを立ち上げているそうです。
なぜそんなことをするかというと、開発じゃない人に「いまあの機能を開発しています」と言うときに、いままでなら開発用サーバにデプロイした後で見てもらったり、あるいはローカルにプロキシみたいなのを立てて、依頼があれば見せる、という感じだったと思うのですが、この方法だとgit pushするたびにHerokuでアプリが立ち上がってURLが付くので、プロジェクトマネージャみたいな人が機能を確認するときに、いつでもプルリクを見てURLからアプリを見て確認できる。コミュニケーションが非同期になるのが非常に良くて。
これはコンテナベースになっていて、アプリケーションが再現可能になっていて、仮想マシンでごりごりやらなくてもgit pushするだけでアプリが立ち上がる、というようなImmutable Infrastructure的な考え方が集約された結果、実現されているのではないかなと。
こういう事例が増えていったら面白いかなと思うし、自分たちでもやりたいと思っています。
まとめ
そろそろまとめです。
Immutable Infrastructureの現状は、まだまだDockerのようなものをプロダクションで使ってる例はほとんどなくて、開発者が試行錯誤している状況かなと。
ただ、Google Compute EngineはDockerをサポートしているし、Cloud FoundryベースのActive StateというPaaSベンダもコンテナをDockerにしたプラットフォームを作っているようです。大規模な事例は、まだこれからだと思っています。
Immutable Infrastructureによって、いままで固定的なものだと考えられていたコンポーネントが動的になっていくことで、結果的に、生き物のようにシステムが動く領域へまた一歩近づいてきたと。
そして昨今のサーバやインフラのパラダイムの集大成としてのImmutable Infrastructureは結果的に、アプリケーション設計や開発プロセスへも影響を与えていくだろうと思っています。
Immutable Infrastructure関連記事
あわせて読みたい
［速報］マウスとキーボード操作を強化した「Windows 8.1 Update」、Windows 8/8.1ユーザー向けに4月8日から無料配布開始。Build 2014
≪前の記事
Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（前編）
