各機能は育成フェーズを経て正式機能へ

　OpenStackのアーキテクチャの特徴を一言で表すと疎結合である。サーバ、ストレージ、ネットワーク、認証などの各機能が、メッセージキューやAPIを通じ、連係して動く。そして、各機能の開発プロジェクトは独立して動いている。

　では現在、どのようなプロジェクト、機能があるのだろうか。以下、表1がその一覧である。

　Integratedフェーズにある機能がいわば正式機能だ。Integratedフェーズに入ったプロジェクトは「常に動く」ことを求められ、途中脱退は許されない。そして、その一歩手前が、Incubatedと呼ばれる育成段階である。Integrated入りを目指すプロジェクトは、まずIncubated入りを申請し、承認される必要がある。そしてIntegratedと同様のテスト、リリース管理を要求されるようになる。この育成期間を経て、OpenStack Technical Committeeの判断をもって晴れて卒業、Integrated入りとなる。

　なお、いきなりIncubated入りを要求しても、承認される見込みは薄い。申請前からOpenStackコミュニティーでの認知度を高め、実績を作ってから申請する流れが一般的である。よって、多くのExternal、育成段階前のプロジェクトは、OpenStackの開発プロセスを経験するため、また、認知度を高めるため、コミュニティーが提供する「StackForge」サイトでソースコードを管理している。ぜひ金の卵を探してみてほしい。

注目のプロジェクト

　さて、全ての機能について解説したいところではあるが、誌面の都合上、注目プロジェクトに絞りたい。筆者の独断と偏見で、議論と開発が活発な3つを選んだ。

Neutron

　「Neutron」はネットワーク管理機能である。従来、ネットワーク管理機能は、サーバ管理機能である「Nova」の一機能であったが、要求の高度化に伴い、バージョンFolsomでNovaから分離した。

　Neutronのミッションは大きく2つある。1つは複数ユーザーのネットワークを分離する、いわゆるマルチテナントネットワークを実現すること、もう1つは、その実装を隠蔽することである。

　例えば、ユーザーにサブネット設定を開放した場合、“192.168.0.0/24”というサブネットは、複数のテナントが利用する可能性が高い。そのような場合でも破綻しないように制御することがNeutronのミッションである。また、Neutronは利用するネットワーク技術を環境や要件に応じて選択できるよう、プラグイン構造で実装されている。よってユーザーは足回りのネットワーク技術やベンダー仕様を習熟する必要はなく、Neutronの標準インタフェースを理解していれば操作できる。これが後者の、実装の隠蔽のメリットである（図）。

図　Neutronが実現するマルチテナントネットワーク実装の隠蔽

　では、どのようなネットワーク技術が使われているのだろうか。OpenStack Foundationが行った最新のユーザー調査では、Open vSwitchやLinux Bridgeといったオープンソースネットワーク技術の採用実績が多い。ソフトウェア的にVXLANやGRE、VLAN、OpenFlowなどを駆使し、マルチテナントネットワークを実現している。最近では分散ルータなど、従来は商用製品の「売り」であった機能もオープンソースで実現できるようになってきた。よって、規模や要件によってはオープンソースで十分、というケースが今後も増えるだろう。一方で商用SDN製品は、価格に見合うだけの価値をアピールする必要に迫られている（参考：OpenStack User Survey Insights: November 2014）。

　Neutronは同時期にバズワードとなったSDN（Software Defined Networking）の影響もあり、議論の多いプロジェクトである。雑音も多い。だがプロジェクトは次バージョンKiloに向け、これまでの技術的負債を軽くするリファクタリングを開発の重要テーマにするなど、健全な方向に向かっていると筆者は考えている。

Ironic

　サーバ管理機能であるNovaは、KVMやXenなどのハイパーバイザーで仮想化されたサーバをその管理対象としてきた。しかし、ハイパーバイザーのオーバーヘッドがない物理サーバ、いわゆるベアメタルサーバを、仮想マシンと同じようにOpenStackの管理下で使いたいという要望が増えてきている。特に仮想化のオーバーヘッドが出やすいI/O性能が重視されるデータベースサーバ、数％でも性能を上げたい科学技術計算、シミュレーション用途で期待が大きい。また、パブリッククラウドの雄である「Amazon Web Services」（AWS）がベアメタルサーバのサービスを提供していないため、競合するサービスプロバイダーが差別化要素になり得るとして注目している。

　「Ironic」はIncubatedプロジェクトとなってから、卒業までに時間がかかっている。ネットワークやストレージをソフトウェア的にコントロールできる、また、既に抽象化されている仮想化環境と違い、ベアメタルサーバは考慮点が多く、ベンダーによる実装の違いも吸収する必要がある。また、他機能との連携もNovaの実装をそのままは流用できない。これが卒業までに時間がかかっている理由である。

　だが、2014年秋、ついにIronicはIntegratedプロジェクト入りを承認された。次リリースのKiloを期待したい。

TripleO

　OpenStackは多様な機能の集合体であるため、インストールが簡単ではない。また、導入後の増設やアップデート作業も、順序やタイミングを厳密に管理する必要がある。よって、どうしても人依存の運用になりがちである。これはOpenStackの普及を阻んできた大きな原因の1つだ。

　そこで、OpenStack自身が持つオーケストレーション機能（Heat）、イメージ管理機能（Glance）、ベアメタルサーバプロビジョニング機能（Ironic）などを用い、インストールやアップデートを自動化してしまおうという取り組みが「TripleO」である。OpenStack On OpenStack、Oが3つでTripleOというわけだ。

　このTripleOは運用管理ツールであり、OpenStackの外部プロジェクト扱いである。だが、米Red Hatや米Hewlett-Packard（HP）などから開発者が参加し、OpenStackの導入、運用の負担を減らそうと活発に開発が行われている。

開発手法とリリースサイクル

　さて、世界中から多くの開発者を集め、また、さまざまなプロジェクトを抱えるOpenStackコミュニティーであるが、その開発はどのように行われているのだろうか。

OpenStackの開発環境「Gozer」

　OpenStackの開発は、GitHub（ソースコード管理）、Gerrit（レビュー）、Launchpad（仕様、バグ管理）、Zuul（ジョブ管理）、Jenkins（継続的インテグレーション）といった、ポピュラーなオープンソースとWebのサービスによって支えられている。ツールの連係と自動化が徹底されており、ソースのコミットからレビュー、テストがスムーズに流れるように作られている。いわゆる「継続的デリバリー」を実現するパイプラインだ。日々の変更を低いリスクで取り込むには、このような開発インフラが必須である。このパイプラインは「Gozer」と呼ばれている。

　ちなみにこのGozerは、OpenStackをベースとした米RackspaceとHPの2つのクラウドサービスで動いている。直近のバージョンJunoの開発サイクルでは、6カ月の間に170万ものジョブを実行し、18Tバイトものログを生成した。世界でも最大規模のソフトウェア開発プロジェクトといえるのではないだろうか。

リリースサイクル

　現在、OpenStackは6カ月ごとに新バージョンをリリースするサイクルで開発が行われている。また、セキュリティパッチなど不具合の修正は、直近2バージョンが対象である。進化の激しいクラウド技術の取り込みを優先している結果ではあるが、従来のソフトウェアと比較し、短い印象は否めない。ユーザーにとって、アップデート戦略は必須の検討事項である。

　なお、3年間同じバージョンを使い続けたいなど、長期にわたるバージョン固定サポートのニーズはある。ただし、それは進化から取り残されるということも意味する。今後OpenStackに対応したアプリケーションは増え続けると予想されるが、古いバージョンのOpenStackでのサポートは期待できないだろう。3年前のAndroidスマートフォンで、新しいアプリケーションが動かないことと同様である。

　結果、古いままの基盤はアプリケーション開発者に使ってもらえない、売れないため、その存在意義が問われることになるだろう。やはりバージョンアップに追随する方式、運用は検討すべきである。OpenStackのイノベーションを、取り込むためにもだ。

　第3回は、OpenStackが提供する機能、特に注目されている機能について解説した。また、開発手法とリリースサイクルも理解することで、よりOpenStackプロジェクトがイメージしやすくなったのではないだろうか。なお、次回からはさらに技術的に深掘りし、設計・実装のポイントを紹介する予定である。活用のイメージを膨らませていただきたい。

真壁 徹（まかべ とおる）

米Hewlett-Packard Company クラウドチーフテクノロジスト

　HPのクラウドの方向性、最先端の開発状況を日本のお客さまにお伝えし、かつ日本のお客さまの声を米国HP本社にフィードバックする役割を担う。アーキテクトとして設計支援も担当。

　公共分野のソフトウェアエンジニア、通信業界担当のプリセールスエンジニアを経て現職。趣味はビール。