まず、第2版（Bexar）リリースに向けたDesign Summitが、2010年11月9～12日の4日間にわたって米テキサス州サンアントニオで開催された。この会議には12カ国・90以上の組織から250人以上の参加者が集まり、非常に盛況であった（写真）。また、日本企業や日本人開発者の参加が多かったことも特筆しておきたい。実際、筆者らが日本のシステム運用現場における重要性の観点からLive Migrationサポートの提案を行った他、IPv6サポート、ネットワークモデル拡張、管理コンソール、国際化（I18N）、集中インストールツールといった提案があり、ユーザーとしての立場だけでなく、開発への貢献という観点でも関心が高かったことが分かる。

写真　Design Summitの議論の様子。複数ハイパーバイザーサポートについて議論中（著者撮影）

　ところで、OSSの開発コミュニティーでは、プロジェクトが盛況であればあるほど、開発者が好きなことを言い過ぎて混乱に陥り、スケジュールや品質に問題が出ることも多い。実際、OpenStackプロジェクトの開発コミュニティーでも、2010年11月のDesign Summitの前後で、スケジュールが厳しいにもかかわらず追加機能項目が多過ぎるなど、多少の混乱が見られた。これは、開発者の間にUbuntu流の開発プロセスが浸透しきれていなかったこと、OpenStackへの関心が高く、機能追加への要望が高かったことが主な原因だったといえる。しかし、2010年12月以降、Release ManagerのThierry Carrez氏の強いリーダーシップの下、追加機能項目も整理され、開発者の間にも開発プロセスが徐々に浸透してきた状況である。また、Community ManagerのStephen Spector氏を中心とした情報発信も活発になされている。その熱気は日本にいても感じられる。

　日本のユーザーコミュニティーも立ち上がった。2010年10月21日（米国現地時間）のOpenStack 第1版（Austin）のリリースに合わせて「日本OpenStackユーザ会」の設立がアナウンスされ、2010年11月19日にはOpenStackコミュニティーのJim Curry氏他を招いて「日本OpenStackユーザ会　カンファレンス2010」が開催された。このイベントには、単体のソフトウェアに関するイベントであるにもかかわらず、120人以上の参加者があり、国内でも非常に関心が高いことをうかがわせた。

スケジュール

　プロジェクト発表以来の経緯を含めたスケジュール全体の流れを図1に示した。ここからリリースの実績と予定だけ抜き出して整理したものが下の表である。第4版（リリース D）以降、Ubuntuと同様に6カ月ごとのリリース間隔に変更される予定である。

図1　OpenStackの全体的なスケジュール《クリックで拡大》

　表の備考に記した通り、コミュニティーとしての目標は、第2版で商用品質の達成、第3版で（クラウド）サービスプロバイダー規模のスケーラビリティの達成である。ただし、「商用品質の達成」という目標は一般のOSSプロジェクトの感覚だと思うべきである。国内の商用環境で求められる品質に達するには、筆者は第3版（Cactus）のリリース後から3カ月位はかかると予測している。このために、筆者らも品質強化に取り組み、バグフィックスなどのフィードバックを積極的に行っていく所存である。

表　OpenStackのリリーススケジュール

　Design Summitについては、2010年7月19日のOpenStackプロジェクト発表時に初回が開催されているが、このときは発表前に水面下で参加者を募っており、最初のパブリックなDesign Summitはサンアントニオで開催されたものである。また、次回は1回スキップして2月の第2版（Bexar）の後ではなく第3版（Cactus）の後、2011年4月26～29日に米カリフォルニア州サンタクララで開催されることになっている。

　余談だが、表のように並べてみると分かる通り、リリースコードネームはテキサス州の地名からABC順に採って決めることになっている。これは、開発主体の米Rackspaceの本社がテキサス州にあることに由来する。コードネームの決定もDesign Summitで議論される話題の1つである。なお、第2版のBexarはスペイン語由来のテキサス州の郡（County）の名前で「ベア」と発音する。第4版のコードネームは未定だが、Dで始まるテキサス州の地名になることだけは間違いない。

OpenStackの構成

全体のコンポーネント構成

　OpenStackを構成する2大コンポーネントはNovaとSwiftである。NovaはAmazon EC2に相当し、仮想計算機（以下、VM）資源を管理する。SwiftはAmazon S3に相当し、オブジェクトストレージの機能を提供する。NovaとSwiftに加えてGlanceというコンポーネントがあり、VMの起動イメージの管理を担当する。これらは、第1版（Austin）時点ではまだ連携していなかったが、第2版（Bexar）以降、図2に示すようにNovaからGlanceを、GlanceからSwiftを利用する形で連携できるようになる。また、第3版（Cactus）以後に向けて、現状はNovaが行っているネットワークの管理も独立させ、各種のトンネリング技術やOpenFlowなどの新しいネットワーク技術によってIaaS環境のネットワークを柔軟に管理・構成できるようにする方向で議論が進んでいる（図2）。

図2　OpenStackの各コンポーネントの関係

OpenStack Compute：Nova

　Novaを用いてプライベートクラウド（IaaS）を構築するとは、どのような構成のシステムを構築することなのか？　イメージをつかんでもらうために、図3にNova（Austin）を用いて構築した比較的小規模なIaaS基盤の構成例を示した。なお、この構成はEucalyptusなどの類似のソフトウェアを用いても、ほぼ同様の構成となる。

図3　Novaで構築したオンプレミスのIaaS基盤の例（第1版（Austin）時点）

　図3を見て分かる通り、“API Node”“Scheduler Node”“Network Node”“Compute Node”“Volume Node”および“ObjectStore”の6つのコンポーネントが登場する。

　これらのうち、API Nodeがクラウドを代表して利用者からの要求を受け付ける役割を担う。Scheduler Nodeがクラウド全体の資源を管理し、起動すべき適切な物理サーバを選択して、要求されたスペックのVMを割り当てる役割を担う。VMの起動イメージは、第1版（Austin）時点ではObjectStoreがテンプレートを格納しており、Compute NodeはObjectStoreからVMの起動イメージをダウンロードした上でハイパーバイザーに指示を出し、VMの起動・停止を行う。Network Nodeは、NATやVLANの設定など、VMとエンドユーザーの間に立って通信を中継する。Volume Nodeの役割は、不揮発性のブロックストレージの提供である。第1版（Austin）では、AoE（ATA over Ethernet）のみサポートされているが、第2版（Bexar）でiSCSIや、SheepDogなどの分散ブロックストレージのサポートも追加される見込みである。

　なお、これらのコンポーネントは、ObjectStore以外、RPC通信によって協調動作する。また、図3では比較的小規模なインストール例としてAPI NodeとScheduler Nodeを同じ物理サーバで動作させるパターンで図示したが、Novaのコンポーネントは全て別々のサーバで動作させることが可能なモジュラーな構造となっている。

　利用者インタフェースとしては、Amazon EC2互換なAPIと、RackSpaceのCloudServers APIをベースとしたOpenStack APIをサポートしている。第1版（Austin）時点では、開発者によってよく試験されているのはAmazon EC2 APIのクライアント実装であるEuca2oolsを使う方法である。原理的にはHybridFoxなどのAmazon EC2 APIをサポートしたGUIツールも利用可能である。管理者用のインタフェースとしては、第1版（Austin）ではコマンドを用いる以外にないが、今後Djangoベースで開発されたWeb管理コンソールが公開される見込みである。

OpenStack Object Storage：Swift

　前述の通りSwiftは、AWSで言えばAmazon S3に相当するオブジェクトストレージサービスである。オブジェクトストレージとは、端的に言えばデータの倉庫であって、一般のファイルサーバとは違い、大容量ファイルをファイル単位で取り出す（GET）、または格納する（PUT）という操作に最適化されたストレージサービスのことである。つまり、写真データであれば画像処理ソフトで直接開くなどの操作はできないが、高速に大量・大容量な入出力を行えることが特徴である。例えばログデータ・バックアップデータの格納や、CDN（Contents Delivery Network）などのファイル配布用途に適している。

　Swiftも、Novaと同様に“Auth”“Proxy”“Account”“Container”“Object”の5つのコンポーネントで構成されており、別々の物理サーバに配置できるモジュラーな構造となっている。特にObjectはデータの実体を格納する役割を担い、運用中に動的に追加（削除）してSwift全体の容量を増加させることもできる。また、データは自動的に冗長化されるためObjectサーバが1台故障してもデータを失うことはない。

　利用者のためのインタフェースは、RackSpace CloudFilesのRESTプロトコルを実装している。JavaやPython、Rubyといった各種言語のSDKが提供されている他、アプリケーションとしてはCyberDuckでの利用実績が報告されている。

今後のOpenStack

　本稿執筆時点（2011年1月13日）で、第2版に入る機能のソースコードレベルの提案が締め切られ、レビューとマージ作業が行われているところである。

　提案によっては間に合わなかったものもあるが、OpenStackコミュニティーのブログにRelease ManagerのThierry Carrez氏が書いた第2版での新機能の概要をまとめた記事が出ている。この記事から第2版（Bexar）の目玉をピックアップしてみた。

Nova

• Live Migrationのサポート
• VM起動イメージの保管場所としてGlanceのサポート
• ログメッセージの国際化
• IPv6サポート
• iSCSIサポートなど

Swift

• クライアント側でのオブジェクト分割機能のサポート（現行の5Gバイトの上限の撤廃）
• Amazon S3インタフェースサポートの追加など

Glance

• バックエンドストレージとして Amazon S3の追加など

　これら以外にも、細かな機能追加が数多くあるので、興味のある方はぜひ一度目を通してみてほしい。また、第3版以降に向けた改善提案の議論も少しずつ始まっている。

まとめ

　OpenStackは、始まって間もないまだ若いプロジェクトである。しかし、オープンな開発体制で運営され、新しい提案を持った参加者が次々に現れている。また、Ubuntuプロジェクトにならったシステマチックな手法で運営されており、新規機能の追加もよくコントロールされている。オンプレミスでのクラウド（IaaS）環境の構築を検討しているユーザーにとっては、注目に値するプロジェクトであるといえる。

　今後も日本OpenStackユーザ会などを通して情報を発信していくので、第2版以降の発展に期待されたい。

伊藤雅典

株式会社NTTデータ 技術開発本部

シニアITスペシャリスト。専門分野はオペレーティングシステム一般。専門以外には進化論などに興味を持つ。現在はインタークラウド連携の研究開発に従事するほか、GICTFやVIOPSなど、各種団体・コミュニティーで活動中。趣味は子育て。