最近のサーバの抽象化について

学者でもなんでもない現場のいちエンジニアの感想です。しかも、どれもちゃんと使ったことないので、聞きかじりをまとめたメモ書きなので嘘が入ってますが、興味ある方がいればどうぞ。

はじめに

かつては「OS=物理サーバ」であって、その物理サーバの資源(CPU,RAM,DISK,etc.)をどのように使うかはOSがプロセスに割り振る形で決定されていました。しかし、それでは例えば以下の様な問題があります。

  • ファイルシステム資源をプロセスが自由にコントロールできない
    • ProcAとProcBで使いたいlibfooのバージョンが異なる場合面倒
  • CPU, RAM資源もコントロールしにくい
    • 同居してるプロセスがメモリ食い尽くして、みんな死亡、みたいな
  • そもそも異なるOSを同居して使うことができない
    • CentOSばかり使ってるのに、使いたいライブラリがDebianでしか動かないとか

解決する方法はいくらでもあるわけですが、ちょっと前から流行っているのがいわゆる仮想サーバで、XenとかKVMとかVirtualBoxとかそういうやつですね。物理サーバをコントロールするOSはホストOSと呼ばれ、実際ユーザが使いたいプロセスはホストOSの上にゲストOSという形で仮想的な計算機にインストールすることで、ホストOSとは切り離した自由な環境を手に入れることができます。CPUやRAMの分配も起動時に自由に設定することができます。

これらは昨今サーバの主流であると思われるAWSを始めとするいわゆるクラウドという環境に繋がっていきます。ユーザは自分でホストOSを管理する必要がなくなり、雲の中にならんだ物理サーバ群に対して、自分が必要とするサーバリソースを要求すれば自由にサーバを手に入れることができるようになりました。なんてライフチェンジングなんでしょう。もう物理サーバを細かく事業ごとに見積もる必要はなくなって、要求に応じてサーバを起動するだけで必要な規模のサーバ群が手に入るなんて!

ただ、クラウドは少々お高いですし、人によっては物理サーバはそこそこ持ってるのでそれをAWSの様に柔軟に使いたいという人もいます。そういう人はプライベートクラウドとか呼ばれる、AWSクローンみたいな仕組みを使ってます。OpenStackとかがありますね。これらの実際は、KVM等の仮想マシンと付随するサービス(例えばS3やEBSやENIなど)と、それらを管理するAPI群という感じです。これでデータセンタの資産管理も柔軟性が上がってウハウハですね。

まぁしかし、そうは問屋が卸さない。今紹介した仮想マシンベースのクラウドと呼ばれるものは、どうしても物理サーバの資源を限界まで使いきれません。仮想マシンということで物理マシンの挙動に限りなく近い状況を再現している代わりに、そのオーバヘッドも馬鹿になりません。また、そもそも起動終了がOSの起動終了なのでそんなに高速でもないです。

最近の話題

といったところが、大抵の人が2,3年前くらいにたどり着いてたところかなと。で、最近の話。

コンテナ型

ひとつはLXCという形の仮想環境が徐々に流行りつつあるかなと思ってます。大きな契機だったのはdockerというLXCをクラウドっぽく管理するツールがdotcloudからOSSで公開されたところじゃないかなと個人的には思ってます。dotcloudはPaaSと呼ばれるサービスを展開していてHerokuなんかと同業です。これらは、アプリケーション単位でサーバを割り当てて、必要なライブラリとかをよしなにインストールしてくれて、かつフロントにアクセスするためのドメインとかまで準備してくれるというもので、AWSで頑張って全部手で設定してたのと比べると圧倒的にDev寄りで僕はとても好きです。

で、PaaSを実現する方法としてdotcloudはLXCを使ってるみたいです。LXCというのは(僕は使ったことないんですが)Linuxの軽量仮想環境で、完全な仮想マシンを作る代わりに、OSはひとつのままで、プロセスをあたかもLinuxの”コンテナ”の様にしてしまう、という方法を取っています。プロセスなので軽量ですが、Linuxであればホストとゲストでディストリビューションが違っても動きますし、もちろんファイル資源も自由に扱えます。仮想マシンのようなオーバヘッドもありません。

dockerのいいところはEC2の上でも走らせられるので、例えばDCの物理サーバとEC2のインスタンスの間で、全くおなじLXCのイメージを使うことができたりします。最初はEC2でスモールスタートしておいて、規模が大きくなったらDCの物理サーバに移す、または逆、とかいう時に環境間の差異を考えなくてよいというのは凄まじく良いことですね。

何が言いたいかというと、仮想マシン最高、クラウド最高、で思考停止してたら置いてかれますよ、と。クラウドなんて全然完璧じゃないし、AWSに完全依存して本当にいいんですか?プライベートクラウド構築したらそれで完璧?というわけで僕もいい加減LXCを触らないといけないと思ってはや半年くらい。全然ダメダメですね。そもそもクラウドもちゃんと使ってないわけですが。。。

リソース管理

それから、もう一つの方向として、MesosYARNといったリソース管理機構にも注目しておくべきだと思います。クラウドにせよLXCにせよ、物理サーバのリソースを柔軟に分割できるのはいいんですが、それをどうやって割り振るかは人手に寄っていることが多いです。あれ、せっかくクラウドになって物理サーバの見積もりからおさらばできたと思ったのに、結局どのインスタンスを使うか見積もりしないといけないんですか、みたいな。まぁあとでサイズを変えるのがスナップショット使って簡単にできるのは良いことですが。あと、AWSだと負荷に応じてWEBサーバを追加・削減する機能があったりしますが、その度にインスタンスを起動終了するのは如何にも遅そうですし、お金もかかります。

MesosやYARN(は名前しか知らないんですが)は、自分達が持っている資源群を1つのプールとしてみなして、ジョブがやってくると必要なリソースを今空いてるところから貸し出し、終わったら返してもらう、というイメージだと思ってます。例えば、普通アプリケーションサーバとHadoopの様なバッチ用サーバは、サーバとして分離させると思いますが、Hadoopのサーバが頑張って一所懸命に計算してる横で、アプリケーションサーバはピーク時間じゃないから結構暇、とかが起こります。Mesosはこういう状況をもっとうまく処理するために、Frameworkという単位でアプリケーションを規定して必要なリソースをmasterに問い合わせると、空いているスレーブのリソースを貸し出してそこでFrameworkを動かす、とかができるようになっています。

何が面白いかというと、うまくリソースの粒度を設計すれば、サーバ(もしくはインスタンス)の負荷はどれもいつもそこそこ同じくらいになって、リソース管理が簡単になります。全体としてリソースが足りないな、ということになれば同じ設定のslaveをただ追加するだけで終わりです。こうした作業をアプリケーション毎にする必要はなく、Mesosのクラスタとしてリソース管理さえしていれば良い、というのは新しいカタチの抽象化だと思います。もちろん、EC2の上で動かすこともできるわけで、リザーブドインスタンスでクラスタをどーんと確保しておいて、あとはMesosでリソースを利用するとかもできるわけです。ポータビリティも上がるので、物理サーバが足りないときにクラウドのインスタンスを足して凌ぐとかももしかしたらできるかもしれないですね。

もちろん問題はあって、バックエンドのジョブ(MRとか)には最適なんですが、即時応答の要求されるフロントやデータベースとかは簡単にはいかなさそうですね。まさかリクエスト毎にリソースを確保するわけにはいかない。でも、例えばアプリケーションサーバは一定時間リソースを確保し続けて、時間が来たらLBから切り離した後にリソースを返却する、とかすればいけるかも。データベースはRiakとかMongoDBみたいなクラスタリングのあるものを利用すれば、アプリケーションサーバと同じ要領でいけるかも。などなど、夢は広がります。また、管理アプリとかバックエンドの計算資源みたいな肩身の狭い用途にも最適ですね。ちっちゃいアプリや大したことない計算のためにイチイチサーバを準備してもらったりするのは誰にとっても良いことではないので。MesosでLXCを割り当てたりしたら、、、妄想は楽しいですね。

終わりに

というわけで、自分自身はどれも全然使ってない旧世紀の人間ですが、聞きかじった程度の知識をまとめておきました。たかが計算機の使い方だって、どんどん進化しています。あなたもこれからの新しい使い方を考えて実践してみましょう!