Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏(後編)

2014年4月2日

仮想化やクラウドを基盤とした新しいインフラの考え方である「Immutable Infrastructure」が注目されています。このImmutable Infrastructureをテーマに3月25日に渋谷にあるDeNAの大会議室で開催された勉強会「Immutable Infrastructure Conference #1」では、150人の定員に400人以上が申し込む人気ぶりでした。

(本記事は「Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏(前編)」の続きです)

不自由さをアプリケーションが受け入れることでよい影響が

まずアプリケーションアーキテクチャへの影響についてですが、サーバがImmutableになるということは不自由になるということじゃないですか。サーバをセットアップすると、もうそのサーバは設定などをいじらないので、管理者は楽ですが。

fig

その不自由さをアプリケーションが受け入れなくてはならないのですが、でもこうした制約というのは必ずしも悪いことではない。ということはぼくたちは経験的によく知っていて、例えばRESTとか。HTTPもRESTが前提になっていてステートレスなので仕様がシンプルに保たれているとか。

それと同じで、Immutable Infrastructureの制約を受け入れることで、アプリケーションの設計によい影響を与える面があります。

その1つ1つはここでは解説しませんが、この「The Twelve Factor App」によくまとまっています。

fig

このサイトはImmutable Infrastructureの概念が出てきてから作られたのではなく、Herokuにアプリケーションをデプロイしていた人が、Herokuのアーキテクチャを前提にアプリケーションを作っていると、いままでよりきれいにアプリケーションがまとまるということに気づいて、そのことをより抽象度の高い概念として記述してまとめたものです。

fig

Herokuというのはさっき説明したように、コンテナベースで、かつある意味Immutable Infrastructureなのですが、この制約を受け入れるには、例えば「プロセスはステートレスかつShared Nothingである」ことが求められます。

これはつまり状態を持たない、特定のサーバの中だけでしか持っていない情報がないようにする。

それから「設定をコードから厳密に分離することを要求する」というのは要するに、実行環境とアプリケーション環境を完全に切り離して動かせるように、ということ。

「すべて依存関係を、依存関係宣言マニフェストで完全かつ厳密に宣言する」というのは、要するにBundlerとかPerlでいうCPANファイルを指しています。

HerokuにRailsアプリをデプロイするときには、Bundlerに全部gemファイルを書いてRackアプリとして構成し、ステートレスな感じで、Herokuのコンテナが落ちたとしても、またgit pushすれば同じような状態になることを保証したアプリケーションを書く必要があるんですけど、そういうことを難しく説明するとこういうことだと。

こういうことをしたことで、例えば緑色の文字で書いたようなことがメリットとして出てきます。これも引用です。

fig

「下層のOSへの依存関係を明確化し、実行環境間での移植性を最大化する」というのは、要するに制約を受け入れると、例えばHerokuで動かしていたアプリをCloud Foundryベースの別のPaaSで動かしたいときに、PaaS間でアプリケーションの移植性を保証してくれれば、ゼロコンフィグで移植できるとか、あるいはローカルで動いていたアプリをgit pushするだけでHerokuで動かせるということです。

それは当然、Immutableという制約を受け入れることによって、アプリケーションが廃棄されてもgit pushすれば同じように動くことを保証したからこそ可能になった、ということですね。

ということで、Immutableな制約を受け入れると、アプリケーションの再現性が向上するみたいな、一見不自由な制約がインフラだけでなくアプリケーションにもいい影響をもたらすのが、Immutable Infrastructureがもたらす未来だと思っています。

fig

再現可能なアプリケーションになると

再現可能なアプリケーションという話をしましたが、どこでも再現できるポータビリティの高さは重要で、そうするとアプリケーションをいろんなナントカ as a Serviceに放り込めるようになる。

インフラがImmutableになることで、アプリケーション側が標準化され、いろんな環境にもっていけるようになると。

そうするといろんなサービスが使えるだけでなく、開発環境とプロダクション環境も同一視できるということ。プログラミングにおいては両者を同一視できるのは非常によいパターンです。

fig

さらにShared Nothingなのでサーバをぼこぼこつっこむだけでスケールするようになる。

だんだん結論が見えてくるのですが、ステートレスかつShared Nothingだと、いかにもテストしやすそうじゃないですか。状態に依存していたりI/Oに依存しているアプリケーションはテストが書きづらいんだけど、アプリケーションが再現可能であれば、そのアプリを適当に動かしてテストして同じ結果が得られることが保証されるのでテストしやすい。

Dockerのいちばん典型的なユースケースはここで、JenkinsがDockerコンテナをぼこぼこ立ち上げてテストしてくれる。要するにCI as a Serviceみたいなものを自社で持ちたいケースでとてもうまく合っている。

fig

そしてさっき説明した、上書きデプロイからコンテナベースのデプロイ、ということも見えてきます。

fig

こんな感じで、Immutable Infrastructureというのはデプロイのやり方やアプリケーションの設計、テストがしやすければ開発ワークフローも変わっていくといった、よい影響を与えてくれるものなので、アプリケーション開発者も注目したらいいのではないかなと思います。

面白い例だなと思ったのはQuipperという会社の例で、Quipperでは、gitでブランチを切ってそれをGitHubにpushするたびに、Herokuでアプリケーションを立ち上げているそうです。

なぜそんなことをするかというと、開発じゃない人に「いまあの機能を開発しています」と言うときに、いままでなら開発用サーバにデプロイした後で見てもらったり、あるいはローカルにプロキシみたいなのを立てて、依頼があれば見せる、という感じだったと思うのですが、この方法だとgit pushするたびにHerokuでアプリが立ち上がってURLが付くので、プロジェクトマネージャみたいな人が機能を確認するときに、いつでもプルリクを見てURLからアプリを見て確認できる。コミュニケーションが非同期になるのが非常に良くて。

fig

これはコンテナベースになっていて、アプリケーションが再現可能になっていて、仮想マシンでごりごりやらなくてもgit pushするだけでアプリが立ち上がる、というようなImmutable Infrastructure的な考え方が集約された結果、実現されているのではないかなと。

こういう事例が増えていったら面白いかなと思うし、自分たちでもやりたいと思っています。

まとめ

そろそろまとめです。

Immutable Infrastructureの現状は、まだまだDockerのようなものをプロダクションで使ってる例はほとんどなくて、開発者が試行錯誤している状況かなと。

ただ、Google Compute EngineはDockerをサポートしているし、Cloud FoundryベースのActive StateというPaaSベンダもコンテナをDockerにしたプラットフォームを作っているようです。大規模な事例は、まだこれからだと思っています。

Immutable Infrastructureによって、いままで固定的なものだと考えられていたコンポーネントが動的になっていくことで、結果的に、生き物のようにシステムが動く領域へまた一歩近づいてきたと。

そして昨今のサーバやインフラのパラダイムの集大成としてのImmutable Infrastructureは結果的に、アプリケーション設計や開発プロセスへも影響を与えていくだろうと思っています。

fig

Immutable Infrastructure関連記事

あわせて読みたい

クラウド Immutable Infrastructure




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本