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

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

はじめに

かつては「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 を触らないといけないと思ってはや半年くらい。全然ダメダメですね。そもそもクラウドもちゃんと使ってないわけですが。。。

リソース管理

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

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

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

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

終わりに

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