第1回：Eucalyptusに見るサーバー・インフラ技術

■IaaSクラウドはインフラ技術の集大成

　この記事を目にしているみなさんは、Eucalyptus（ユーカリプタス）の概要はすでにご存じだと思います。まだよく知らないという方は、「ユーカリプタス入門」連載に目を通してみてください。ここでは、「ユーカリプタス入門」第1回の冒頭部分を引用しておきます。

　「EucalyptusはAmazon EC2/S3 APIと互換性のあるクラウド基盤ソフトウェアで、カリフォルニア大学サンタバーバラ校のコンピュータサイエンス学科の研究プロジェクトとして開発されました。」

　さて、みなさんは「Amazon EC2/S3」と「Eucalyptus」のどちらにエンジニアとしての興味をそそられるでしょうか？　事前に用意されたサーバー環境でアプリケーションを開発したり、あるいはエンドユーザ向けのサービスを提供することに携わる方には、Amazon EC2/S3は便利なサービスであることは間違いありません。APIを利用して、サーバー運用の自動化を実現していくなども技術的な興味がわく所です。

　一方、アプリケーション開発やサービス提供のためのサーバー・インフラを自ら作り上げる立場のエンジニアの方には、技術的な意味では、Eucalyptusの方が興味をそそられるかもしれません。

　Amazon EC2/S3を実現する仕組みは、Amazonのエンジニアにしかわかりませんが、オープンソースとして提供されるEucalyptusは、誰でも自由にその仕組みを調べることができます。【図1-1】は、Eucalyptusで利用される主要なインフラ技術を書き出したものです。

　クラウドだからといって、魔法のような特別な技術が使われているわけではありません。サーバー・インフラに関わるエンジニアの方であれば、一度は目にした、もしくは実際に利用した経験のある技術が多数あると思います。（もちろん、Amazon EC2/S3で同じ技術が使われているかどうかはわかりません。しかしながら、Amazonの中には忍者はいるようですが、魔法使いがいるという話は聞いたことはありません……）。

【図1-1】Eucalyptus を実現するインフラ技術

　しかしながら、これら全てを根本から理解して、自信を持って使いこなせるという方はそれほど多くないのも事実ではないでしょうか。古い技術から新しい技術まで、さまざまなインフラ技術の集大成がEucalyptusです。Eucalyptus環境の構築はなかなか一筋縄ではいかないようですが、裏をかえすと、さまざまなインフラ技術を身につける格好の教材でもあります。

　この連載は1週間（5日間）の短期集中連載という形で、【図1-1】にあげたサーバー・インフラ技術を解説していきながら、Eucalyptusの中でどのように利用されているのかを紹介していきます。

　Eucalyptus環境の構築に成功した方も、まだまだこれからの方も、新たな目でEucalyptusを見直すことができるはずです。インフラ技術を身につけるには、まずは自分の手でいろいろ試すことが大切です。連載中の「ユーカリプタス入門」を参考にして、Eucalyptus環境の構築にチャレンジしながら、本連載をあわせて読み進めてください。

　Eucalyptusの実例を通して学ぶことで、すでに知っている技術についてもきっと新たな発見があると思います。本連載では、次のような技術について解説を進めていきます。

■Linuxカーネルの役割と起動プロセス

　今回はOSの基礎技術の1つとして、Linuxカーネルの役割と起動プロセスを学びます。EucalyptusでVMインスタンスを起動する際は、Walrusに保存されたマシン・イメージがノードコントローラにダウンロードされます。マシン・イメージの実体は、OS本体がインストールされたファイルシステムを含むディスクイメージ（ファイルシステム・イメージ）です。

　「ユーカリプタス入門」第2回に説明があるように、VMインスタンスを起動するには、この他にカーネル・イメージとラムディスク・イメージが必要です。これら3種類のイメージにはどのような役割があるのでしょうか？

　ここでは、【図1-2】に示したカーネル空間とユーザ空間の関係から、これらの役割をひもといてみます。

　一般にLinuxシステムは、（物理、もしくは仮想の）ハードウェアとその上で稼働するLinuxカーネル、そしてLinuxカーネルの力を借りて稼働するユーザ・プロセスの3つのレイヤーに分かれます。Linuxカーネルが動作するメモリ空間を「カーネル空間」、ユーザ・プロセスが動作するメモリ空間を「ユーザ空間」と呼びます。

　カーネル空間で稼働するLinuxカーネルは、デバイスドライバを使用してディスク装置などのハードウェアにアクセスしたり、あるいはユーザ・プロセスに対して、CPUやメモリなどのハードウェア・リソースを割り当てる役割を持ちます。一方、ユーザ空間で動作するユーザ・プロセスは、ハードウェアに直接アクセスすることができません。システムコールを利用して、Linuxカーネルにアクセスを依頼する形をとります。

【図1-2】Linuxのカーネル空間とユーザ空間

　3種類のイメージに話を戻しましょう。まず、カーネル・イメージは、カーネル空間に読み込まれるLinuxカーネルのプログラムコードそのものです。Eucalyptusの環境では、Walrusからダウンロードされたカーネル・イメージが、KVM/Xenなどの仮想化ハイパーバイザーによって作り出された仮想マシンの仮想メモリに読み込まれた後に、実行を開始します。物理サーバーの場合は、/bootファイルシステムの中にあるカーネルファイル（ファイルネームがvmlinuzで始まるファイル）がこれに相当します。GRUBなどのブートローダが/bootファイルシステムからメモリに読み込んで、実行を開始します。

　では、ユーザ・プロセスを実行するためのアプリケーション・プログラムはどこにあるのでしょうか？　物理サーバーの場合、その大元は物理ディスク内のバイナリファイルです。これがLinuxカーネルによってユーザ空間に読み込まれて、アプリケーションの実行を開始します。もう少し正確にいうと、このバイナリファイルは、物理ディスク上に作成されたファイルシステムの中に格納されています。ファイルシステムについては、ここでは詳しくは解説しませんが、ツリー構造のディレクトリを作成してファイルを格納するための大きな入れ物だと考えて下さい（下に掲げる【図1-3】の左側）。

　一方、Eucalyptus、あるいは一般的なサーバー仮想化環境では、仮想マシンから物理ディスクを直接認識することはできません。仮想マシンからは、エミュレーションによって作成される仮想ディスクが認識されます。この時、物理ディスク上のイメージファイルの内容が仮想ディスクの中身になります。

　少し複雑ですが、【図1-3】の右側のような関係です。イメージファイルの中には、物理ディスクと同様にファイルシステムが作成されているので、ファイルシステム・イメージとも呼ばれます。Eycalyptusの環境では、Walrusからダウンロードされたマシン・イメージ（ファイルシステム・イメージ）は、ノードコントローラの物理ディスクに配置された後に、VMインスタンスの仮想ディスクの内容として見えるようになります。

【図1-3】ファイルシステム・イメージの構造

　次回に詳しく説明しますが、ノードコントローラに配置されたファイルシステム・イメージは、Linuxのループバック・デバイス機能を利用すると、ノードコントローラのLinuxからもその内容を見ることができます。ノードコンローラでは、これを利用して、VMインスタンスを起動する前にファイルシステム・イメージの内容をカスタマイズしています。

　最後はラムディスク・イメージです。これは、Linuxカーネルがディスク装置にアクセスするためのデバイス・ドライバと、Linuxカーネルが最初に実行する「initスクリプト」を含むアーカイブファイルです。

　Linuxカーネルがメモリに読み込まれて実行を開始すると、まずはじめに、サーバーのメモリを利用したラムディスク領域をマウントして、その中にラムディスク・イメージの内容を展開します。そして、そこに含まれるinitスクリプトを実行します。この後の処理は、initスクリプトに従って行われます。

　initスクリプトは、一般的には、ラムディスク・イメージに含まれるデバイス・ドライバを読み込んで、ルートファイルシステムを含むディスク装置にアクセスできるようにした後に、ルートファイルシステムをマウントして、その中に含まれる/sbin/initを起動します。起動中のLinuxのプロセスをpsコマンドで確認すると、必ず /sbin/init がプロセスIDが1の最初のプロセスになっているはずです。

　ところで、なぜこのような回りくどいことをするのでしょうか。Eucalyptusのような仮想サーバー環境では少しわかりにくいかもしれませんが、物理サーバーの場合は、ルートファイルシステムを含むディスク装置の種類が環境によってさまざまあることが1つの理由です。

　ディスク装置の種類によって、それを利用するためのデバイス・ドライバが異なります。そこで、ルートファイルシステムを含むディスク装置の種類に合わせて、必要なデバイス・ドライバを含むラムディスク・イメージを事前に用意することで、さまざまなディスク装置からLinuxが起動できるようにしているのです。

　この方法を利用すると、NFSサーバー上に用意したルートファイルシステムをネットワーク経由でNFSマウントしてサーバーを起動する「ネットワーク・ブート」も簡単に実現できます。initスクリプトを修正して、物理ディスク上のファイルシステムをマウントする部分をNFSマウントに書き換えておけばよいのです。

　Eucalyptusの環境では、ラムディスク・イメージはWalrusからダウンロードしますが、物理サーバーや一般のサーバー仮想化環境では、/bootファイルシステムにあるファイルネームがinitrd（もしくはinitramfs）で始まるファイルがラムディスク・イメージ（初期ラムディスク）になります。GRUBなどのブートローダは、Linuxカーネルと同時に初期ラムディスクをメモリに読み込んだ後に、Linuxカーネルの実行を開始します【図1-4】。

【図1-4】Linuxカーネルの起動プロセス

■仮想化ハイパーバイザーとマシン・イメージ

　これまでの説明で、カーネル・イメージ、ラムディスク・イメージ、そしてマシン・イメージ（ファイルシステム・イメージ）の役割の違いが理解できたと思います。

　VMインスタンスが起動してしまえば、そこで実行されるさまざまなアプリケーションはマシン・イメージの中に含まれていますので、VMインスタンスの利用者から見れば、マシン・イメージの内容が最も重要です。「ユーカリプタス入門」第3回では、起動したVMインスタンスに新しいアプリケーションを導入した後に、マシン・イメージを再作成する方法が説明されています。この時、カーネル・イメージとラムディスク・イメージは、基本的には、既存のイメージを再利用します。これらを新しく作成するのは、既存とは異なるカーネルでVMインスタンスを起動する場合です。

　仮想化環境でカーネルを変更する際は、仮想化環境に固有の考慮点がありますので、一般ユーザが安易にカーネルを変更するのは危険です。したがって、Eucalyptusでは、新しいカーネル・イメージとラムディスク・イメージの登録はシステム管理者のみができるようになっています。

　一方、複数の仮想化ハイパーバイザーを使用する際は、仮想化ハイパーバイザーに応じてカーネル・イメージ、ラムディスク・イメージを選択する必要があります。例えば、KVMは完全仮想化を提供するので、物理サーバーで使用する通常のLinuxカーネルがそのまま利用できます。Xenの準仮想化モードを利用する場合は、準仮想化環境専用のLinuxカーネルを使用します。また、仮想ディスクを使用するためのデバイス・ドライバも異なります。KVMでは、virtioと呼ばれる準仮想化ドライバが標準です。一方、Xen環境では、独自の準仮想化ドライバが必要になります。

　ここで、仮想ディスクにアクセスするためのデバイス・ドライバはラムディスク・イメージに含まれることを思い出しておいて下さい。VMインスタンスを起動するノードコントローラの仮想化ハイパーバイザーの種類に応じて、適切なカーネル・イメージとラムディスク・イメージを使用しないとVMインスタンスの起動に失敗します。

　ところで、最近はLXC（Linuxコンテナ）と呼ばれるコンテナ型の仮想化にも注目が集まっています。仮想マシンごとに異なるLinuxカーネルを起動するのではなく、ホストマシンのLinuxカーネル上で、独立した複数のユーザ空間を並列実行するため、オーバヘッドが少ないという特徴があります【図1-5】。

　一般の利用者からは、1つのユーザ空間が1つのVMインスタンスのように見えます。このため、旧式の性能の低いサーバーをクラウドで利用したり、あるいは、Amazon EC2など既存のクラウドのVMインスタンスをコンテナでさらに分割して利用するなどの活用方法が考えられます。

　コンテナ自体はそれほど新しい技術ではありませんが、現在、いくつかのオープンソースのクラウド・ソフトウェアでLXC対応が進められています。EucalyptusのLXC対応はまだこれからのようですが、単体サーバーでLXCを利用するのはそれほど難しくありません。筆者のBlogの記事「RHEL6.0 で LXC (Linux コンテナ）」などを参考にしてください。

【図1-5】コンテナ型仮想化の構造

　ちなみに、将来、EucalyptusでLXCが利用できるようになったとすると、VMインスタンスを起動するにはどのようなイメージが必要でしょうか？　【図1-5】からわかるように、VMインスタンス個別のLinuxカーネルはありませんので、カーネル・イメージとラムディスク・イメージは不要です。マシン・イメージだけで、VMインスタンスが起動します。逆に言うと、ホストマシンと同じLinuxカーネルが必ず使用されるわけですので、利用者が自由にLinuxカーネルを選択することはできなくなります。

■さいごに

　初期ラムディスクを利用したLinuxの起動プロセスは、20年前にLinuxカーネルの開発が始まった当初からある古い技術です。しかしながら、さまざまなサーバー仮想化技術を組み合わせて利用するクラウド環境を適切に管理する上で、必須の技術であることがお分かりいただけたと思います。

　単純なものを組み合わせて複雑なものを創り上げていく、これこそがサーバー・インフラ技術、あるいはクラウドの本質なのかも知れません。次回以降もIaaSクラウド環境の完全理解に向けて、基本技術を1つずつ理解していきましょう。