オープンソースのクラウド基盤「OpenStack」、その経緯と仕組みとは

2011年6月13日

クラウドを構築するために商用のソフトウェアやオープンソースのソフトウェアなどが多数登場してきています。その中の1つとして注目されているのがOpenStackです。

OpenStackとはどのようなソフトウェアなのか、その歴史的経緯と技術的な解説を行っているビデオ「openstack building a free massively scalable cloud computing platform」が公開されています。

これは2月にベルギーのブリュッセルで行われた「Free and Open Source Software Developers' European Meeting」(FOSDEM)で行われたセッションを記録したものです。

Building a free massively scalable cloud computing platform

OpenStackデベロッパのSoren Hansen氏。

fig

OpenStackには、NASAとRackspaceという2社が大きく関わっている。

fig

RackspaceとNASA

Rackspaceは2005年にクラウドサービスを開始した。

Rackspace Cloud Filesはオブジェクトストアで、ブロブデータを格納、取得できる。ただしこれはブロックデバイスではない。

特徴として、ほぼ無限のストレージで、使った分だけ支払うというモデルを実現できる。つまりAmazon S3のようなものだ。

fig

Rackspace Cloud Serversは、仮想マシンを実行するいわゆるクラウドコンピューティングで、VPSとAPIからなる。自動的にインスタンスのサイズやOSを選択できる。

おそらくこうしたサービスは最初にAmazonクラウドが提供したものだ。小さな一歩だが人類にとって大きな一歩、みたいなものだろう。

あらかじめたくさんハードウェアを調達しておかなくても、わずか数分で入手できるようにした。

コンピュータリソースの調達方法を根底から変える点が、クラウドコンピューティングの素晴らしいところだろう。

そして使った分だけ課金できる。これがRackspace Cloud Serviersだ。

fig

Cloud Filesは2009年に書き直され、2010年にはCloud Serversも書き直され、そしてオープンソース化した。

fig

NASAの経緯についても紹介しよう。

NASAは単に宇宙船を打ち上げるだけでなく、政府のための研究も行っている。そこでクラウドに注目し、構築を始める。

fig

Amazon EC2互換のEucalyptusを検討したが、スケーラビリティや信頼性の問題に直面し、NASAは自身でコンテナサーバをベースにしたNebulaを構築した。

fig

Openstackのミッション

興味深いことに、両者が同じ時期にクラウド開発に取り組んでおり、3月にRackspaceがオープンソース化したのに続いて、5月にはNASAがNebulaをオープンソース化した。

それでRackspaceの誰かがNASAに電話して、ちょうどオブジェクトストアを開発してオープンソースにしたところで、この2つを組み合わせてクラウドコンピューティングの開発を一緒に進めないか? といった話をした。

それが6月の半ばだったと思う。そこから話はとんとん拍子に進んで2010年7月にはデザインサミットをオースティンで開催。200人くらいが集まり、30社くらいの会社の賛同も得てOpenStackの発表を行った。

fig

OpenStackのミッションは、オープンソースのクラウドコンピューティング基盤として、シンプルな実装と大規模なスケーラブルを実現することだ。クラウドのApacheのように広まりたいと希望している。

fig

オブジェクトストアのSWIFT

続いてOpenStackの技術的な面を紹介しよう。

Openstack Storage / コードネームSWIFT。オブジェクトストレージのSWIFTは非常にシンプルだ。

これまでよく用いられていた方法や以前のCloud Filesなどでは、すべてのコンポーネントが状態を共有するために、マスターデータベースの内容を多くのスレーブで共有したり、Gossipのようなプロトコルを使って情報共有をしていた。

オブジェクトをストアするAPIをコールするとしよう。普通のやり方なら、例えばデータベースを参照して、すでにそのオブジェクトがあるかどうかを確認して、あれば上書きし、それをほかのサーバにレプリケートする、といったやり方になる。

fig

しかしSWIFTでは違う方法を採用している。例えばAPIでputを呼び出す。

PUT /APIバージョン/アカウント/コンテナ/オブジェクト

このときAPIのバージョンはあらかじめ決まっているので、アカウント名、コンテナ、オブジェクトの3つの値のMD5かなにかでチェックサムをとる。こんな値だとする。

089a3d9219f058807e4c15e51cd5d1ac

この最初の4バイトが、このオブジェクトを格納することになる3つのサーバをユニークに定義している(1つのオブジェクトは冗長性のために自動的に3つのサーバに格納される)。

いちいち何かを参照することはしないのだ。クラスタはリング構造を持ち、ノードには自動的にこれらの値が割り当てられる。状態を共有したりする必要がない。

これはPOST、GET、DELETEの操作でも同様に行われる。

オブジェクトのリストを出すときはどうするか? 例えば、あるアカウントのコンテナに格納されているオブジェクトの一覧をだすのはどうするか。

GET /APIバージョン/アカウント/コンテナ

このGETのアカウントとコンテナの2つの値から同じようにチェックサムを求める。この値も同じようにサーバをユニークに指定しており、そのサーバには、このアカウントのあるコンテナが格納しているオブジェクトの一覧を返すデータベースのように値を返してくれる。

状態を共有する場面ではこのような方法が使われている。こうした仕組みは非常にうまくスケールしてくれる。これがSWIFTの仕組みだ。

仮想マシンを管理するNOVA

Openstack Compute / NOVAは、少しSWIFTよりも複雑だ。

これは自分なりに説明した図だ。

fig

(図の右側に、コンピュータワーカー、ネットワークコントローラー、ボリュームワーカー、中央上にスケジューラ、左下がAPIサーバ)

APIサーバに対して仮想マシンを増やしたいとリクエストしよう。するとまずユーザーに関するバリデーションが行われ、仮想マシンののクオータがチェックされる。

同時にメッセージキューに命令が送られ、スケジューラがリクエストをピックアップし、コンピュータワーカーに送り、仮想マシンのイメージをフェッチする。

続いてネットワークコントローラーにIPアドレスをもらいに行き、ネットワークコントローラーはDHCPからIPを取得、ボリュームワーカーからはディスク領域を取得してブロックデバイスを割り当てられる。

そして仮想マシンが起動される。

仮想マシンごとにファイアウォールを関連させることもある。というのも、われわれのゴールは数百万もの仮想マシンを扱うことであり、1つの巨大なファイアウォールで全体をカバーすることはできない。できるだけ分散して処理する必要があるのだ。

関連記事

このエントリーをはてなブックマークに追加
follow us in feedly

タグ : オープンソース , クラウド , システム構築



≫次の記事
電子書籍で複雑なレイアウトを実現する「CSS Regions Module」仕様のドラフトが公開
≪前の記事
情シス部門の存在意義を問うクラウドサービス。米国では2割が導入の相談せず

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


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



Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus