ポータブルなwebアプリケーションとそのインフラの未来の一考

naoya さんのポータブルな Web アプリケーションを受けて最近思ってることをば。140 文字で時々書いてるんだけど、まとまりがないので一回まとめておきます。

12-factor app

ステートフルなアプリケーションについては、Heroku の人が提唱してる 12-factor app というのが現在の状況をよく表してます。

Heroku や他の PaaS によってもたらされたこうした一種の”制約”によって、アプリケーションの新しいカタチが生まれてきています。引き算によって新しい価値が生まれてきているわけですね。

とはいえ、PaaS は PaaS でそれぞれに独自の仕様を持っているわけですが、Heroku の buildpack という仕組みを使って、Heroku とインタフェース仕様を揃えたdokkuやFlynnみたいなのも出てきました。まるで WSGI/Rack/PSGI が HTTP サーバに対してそうした様に、アプリケーションサーバもそれ自身が一定のインタフェース仕様によって共通化されていくことに対して、僕は興奮を抑えられません、PSGI を初めて知った時と同じ様に。

Docker

dokku は裏でDockerを使っています。PaaS の一つである dotcloud が彼らがサービスの中で使っている仕組みを OSS として公開したものですが、これが本当に爆発的に普及したのが 2013 年でした。あまりの普及により、dotcloud は社名が docker に変わってしまう程でした。

Docker の素晴らしいところは naoya さんも書かれている通り、イメージさえデプロイできれば、どんな環境(Linux には限りますが)の上でも動くというところです。コンテナ型の強みとして Xen や KVM と比べて大変軽量なので、上げたり下げたりが簡単なところが Immutable Infrastructure と呼ばれる使い捨ての仕組みと相性が良いわけです。

Docker コンテナをホスティングするようなサービスも当然出てきていて、そういうサービスを使えば、手元の Mac 上の VM の Linux で動いた Docker アプリが、全く同じファイル資源を使って本番環境でも動かせるわけです。もちろん CI も Docker 使って本番と全く同じものがテストができます。

Mesos+Docker

ここまでは naoya さんのエントリとかぶってるわけですが、僕が最近ずっと気になってるのは Mesos との組み合わせです。Docker によってアプリケーションがポータブルになってきても、それを動かす計算機資源はいずれにせよ必要になります。それを PaaS の様にお金と引き換えに全て誰かにお任せしてもいいですが、計算機資源を自分たちで持ってかつその上で Docker を効率よく動かすことができたら素敵です。Mesos ならできます。

Mesos は簡単に言えば、たくさんある計算機を束ねて、合計で cpu が何個メモリが何 GB ある一つの仮想計算機の様なもので、何かプロセスを実行したい時には Mesos から必要な計算機資源(cpu を 1 個、メモリを 1GB 等)配給してもらって、実行するということができるフレームワークです。

これを Docker と組み合わせると、ruby のアプリケーション A と python のアプリケーション B と node のアプリケーション C があって、A を 10 プロセス B を 5 プロセス C を 20 プロセス稼働させることが、1 つのクラスタで実現できます。なぜなら、ファイル資源は全て Docker のイメージが持っているのでパッケージの衝突とかを考える必要ないですし、クラスタのマシンが 1 つ死んだら、足りなくなったプロセスを残りの空いてるマシンで動かすというのも容易です(そういうのを管理するMarathonというフレームワークが既にあります)。

これによって、例えば以下の様なよくある悲しい状況も改善します。個人的には大規模本番サービスよりもむしろこういう用途の方が最初は Mesos のコストパフォーマンス高いかなと思います。

  • ちょっと試しに捗る系の web アプリを動かしてみたいけど、そのためのサーバをインフラからもらうには手間が掛かり過ぎるので、既存の別用途のサーバ使おう
  • 依存関係が複雑で、ググりながらいろんなパッケージとかを入れまくって、なんとか動かす
  • 意外といいツールだったのでみんな使いはじめる
  • 導入した人が辞める
  • そのサーバが老朽化したので別のサーバに移管しようとしたら、本来の用途と違うものが動いていて、しかも誰もセットアップ方法が分からない
  • いつまでもそのサーバを使い続ける or 職人技で新しいサーバをセットアップする

Docker によってアプリケーションはイメージで全て表現されているので、例え再現方法は不明であったとしても別のマシンで動かすだけであればアホでもできます。

Mesos では、ざっくり大きな目線でのキャパシティプランニングしかしないので、その範囲であればチームや部署で自由に資源を活用してもらうことができます。これは実際の業務と近くて、資産やコストを管理したい人は毎月の状況をざっくり捉えられていればいい一方で、現場の要求は毎日の様に変化するわけです。Mesos であれば、資産として常識的に必要十分な量さえ把握できていればコストの予測が容易ですし管理も簡単です。実際に利用する側は Mesos によってその枠を目一杯一つの計算機の様に扱うことができます。

もし予定よりもキャパシティが過不足になった場合も、Mesos の slave を必要に応じて足し引きするだけで資産の流動ができます。これはデータセンタであろうとクラウドであろうとかなり嬉しいと思います。特に、AWS を使ってハードウェアのキャパシティプランニングから解放されたとおもったら、結局インスタンスの細かいキャパシティプランニングすることになって悲しい思いをしてる人にとっては、Mesos 上でのざっくりしたプランニングだけして Reserved や Spot を組み合わせて運用しながら最適なインスタンスをどんどん組み替えていくことができるので、今までと全くちがうキャパプラができるようになって大変うれしいと思います。

ちなみに Mesos についてですが、UC Berkeley の研究から始まり、Twitter での本格導入、Airbnb での導入に続いていろんな企業が利用を始めているようで、最近 AWS/OSS 界隈では目立っている Netflix も導入を始めているようですので、これから盛り上がっていく可能性はかなり高いと思います。今のうちにキャッチアップしておくと、先行者メリットを享受できるかも知れないのでオススメです。

新しい計算機

よく言われてることですが、Mesos, Docker, Marathon, あとChronosという cron みたいなツールによって、今 OS によって実現されている、Kernel, Process, Process manager, Scheduler が同じアナロジーによって複数計算機上に実現されるわけです。もう、実際の計算機一つ一つに気を払う必要はほとんどの人にとってはなくなり、代わりに 1 つの大きい計算機資源を扱うスキルが要求される様になる世界がくるかもしれません。

そして、きっとそのうちそれを XaaS として提供するサービスが出てきて、さらに抽象化され、みたいな繰り返しが予想できますね。起こるかどうかは置いといて。

まとめ

  • 12-factor app 超重要
  • Docker は神
  • Mesos+Docker で次世代へ？

3500 文字くらいになった。何かのきっかけになってもらえれば幸いです。

おまけ

で、お前はやってんのかよと言うと諸々の理由により実は全然手は動かしてないです。。。もし本気で Mesos+Docker の導入を考えてるけど英語しか情報ないのがなーって人がいれば全力で協力させて頂きますのでお声がけ下さいませ。