2016年秋、OpenStackは何をカバーすべきかという古くて新しい問題特集:成熟するOpenStack、企業における利用の現場(4)

Mark Shuttleworth氏がメディアのインタビューに、「Big Tent」と呼ばれるOpenStackのプロジェクト群は崩壊すると答えて、一部で話題となった。「OpenStackはどのような機能をカバーすべきか」は古くて新しいテーマだ。

» 2016年11月29日 05時00分 公開
[三木 泉@IT]

 2016年10月下旬に開催されたOpenStack Summit Barcelona 2016で、Ubuntuの創立者であるMark Shuttleworth(マーク・シャトルワース)氏がメディアのインタビューに、あらためて「Big Tent」と呼ばれるOpenStackのプロジェクト群は崩壊すると答え、一部のOpenStack関係者の間であらためて話題になった。これはOpenStackの現在および将来を考える上で、重要な材料の1つだといえる。

 「Big Tent」とは、OpenStackの中核であるコンピュート、ストレージ、ネットワーク以外の機能を開発する比較的新たなプロジェクトの総称。OpenStack Foundationは、「DefCore」という活動を通じ、中核コンポーネントを定義した一方で、それ以外の新規プロジェクトを「Big Tent(大きなテント)」と呼び、プロジェクト成立要件を緩和した。その後、プロジェクトの数は急増した。

 Shuttleworth氏はもともと、OpenStackが基本コンポーネントの機能の安定的な提供に徹するべきだ主張してきた。OpenStack Summit in Barcelona 2016におけるInformation Ageのインタビューでも、「〜 as a service」を目指すプロジェクトについて批判している。

 「OpenStackでうまくいっていないものはたくさんある。Trove(データベースソフトウェアと連携するサービス)は大失敗だ。Sahara(Hadoop/Spark on OpenStack)も大失敗だ。Ironic(仮想マシンでなく物理マシンを展開する機能)、TripleO(OpenStackをOpenStack上で運用する機能)も大失敗だ。他にもある。OpenStackプロジェクトのリストを見れば、その大部分が大失敗だ。世界を変えるものではなく、興味深いものでもない。必要なものでもない」

 多くのBig Tentプロジェクトは実質的に単一のベンダーが推進しているもので、自社の利益追求のために開発が進められており、OpenStackというプロジェクトに対するユーザー組織の信頼を傷つけるものだというのがShuttleworth氏の主張だ。

 PC WEEKの取材に対しては、「(例えば)オンデマンドでビッグデータをやるために、OpenStackだけの独自カスタムAPIが欲しいと思っている人は誰もいない」と話し、企業のCIOが求めているのは安定的でコスト効率の高いコンピュート、ストレージ、ネットワーク環境だという考えを示している。

OpenStackは何を提供すべきか、これは今に始まった議論ではない

 Shutterworth氏の主張は正当なものだが、これまでの文脈を知らない人には誤解されやすい部分もある。

 もともとDefCoreという取り組みが始まったのは、OpenStack開発プロジェクトにおいて、中核機能の開発が落ち着いてきた一方で、周辺機能の整備を目指すプロジェクトの提案が増えたことが背景にある。

 そこで、「これらの新たなプロジェクトが提供する機能を全て含まないとOpenStackとは呼べないのか」、あるいは「どの機能を含めばOpenStackと呼べるのか」を定義しようとしたのがDefCoreだ。

 筆者は2013年11月、OpenStack FoundationのCOOであるMark Collier(マーク・コリアー)氏と、同財団のエグゼクティブ・ディレクターであるJonathan Bryce(ジョナサン・ブライス)氏、そしてPiston Cloud Computingの共同創立者で当時CTOを務めていたJoshua McKenty(ジョシュア・マッケンティ)氏に、OpenStackの上位レイヤへの機能拡張について聞いた

 この取材と同時期にDefCore Committeeが発足し、同委員会はその後OpenStackに不可欠なコアサービスとしてNova、Neutron、Swift、Cinder、Keystone、Glanceを規定。その他をオプションサービスとした。オプションサービスには、記事執筆時点でHorizon、Ceilometer、Heat、Trove、Sahara、Ironic、Zakar、Manila、Designate、Barbican、Magnum、Murano、Congressがある。その他に多数のプロジェクトが生まれているが、上記を除けはインキュベーション段階だ。

 McKenty氏はDefCore Committeeの議論を積極的にリードした。その後同氏がOpenStackの世界を去ってPivotalに移った後、DevCoreについて尋ねた際、同氏はこの活動が成功だったと話した。

運用担当者のサービス提供を支援する機能必要

 つまり、「OpenStackがどのような機能をカバーすべきか」は今に始まった議論ではない。だが、OpenStackが存在し続ける限り、必ずついて回るテーマだともいえる。

 だが、まず議論の前提として、インキュベーション段階にあるプロジェクトとそうでないプロジェクトを混同すべきではない。インキュベーションプロジェクトは、無理やりに一般企業で例えるなら社内実験プロジェクト的な意味合いを持っている。

 実質的に単一のベンダーが始めたプロジェクトであっても、複数の企業が参加し、ある程度の支持を勝ち得なければインキュベーションを卒業できない。言い換えればインキュベーション段階のプロジェクトは、開発に参加するメンバーを広げる時期にあるともいえる。

 Shuttleworth氏が名指ししたプロジェクトのうち、Trove、Sahara、Ironicについてはインキュベーション段階を卒業している。だが、DefCore Committeeによる活動を経て、あくまでもオプションという位置付けになった。OpenStackを導入するユーザーが、必ずこれらを利用しなければならないというものではない。

 Shuttleworth氏の言う通り、「企業のCIOが求めているのは安定的でコスト効率の高いコンピュート、ストレージ、ネットワーク環境」だとしても、この人たちはコアサービスだけを利用すればいい。

 2013年11月のインタビューで、OpenStack FoundationのCOOであるCollier氏と、エグゼクティブ・ディレクターであるBryce氏が述べていることは、そのまま同ファウンデーションの現在の立場だと考えられる。

 本特集で紹介したNTTドコモ、フォルクスワーゲンをはじめとする多くの企業において、プライベートクラウドインフラとしてOpenStackを展開する人々の多くは、これを社内のユーザーに対するサービスとして提供している。社内ユーザーには、必ずパブリッククラウドと比較されることになる。このため、CIOはともかく、実際に社内ユーザーに対してOpenStackを推進している人たちが、メガパブリッククラウドのように豊富な機能を提供できなくても、コンテナベースの開発環境やビッグデータのインフラ環境といった、ユーザーの需要が見込まれる機能について、円滑かつ効率的に提供したいと考えるのは当然のことだ。

 端的に言えば、複数の意味でOpenStackプライベートクラウド担当者はメガクラウドサービスと競っている。データ量の多いアプリケーションなどにおけるコスト効率や、安心して使えるセキュリティなどは、CIOには受けるかもしれないが、社内の実ユーザーは必要とする機能を迅速に、面倒なく使える環境を求めている。狭義のインフラを提供するだけでなく、ユーザーの求める利便性を提供することが、プライベートクラウドの成功の1つのカギとなっている。

 Shuttleworkth氏が批判するBig Tentプロジェクトの一部は、OpenStack上でデータベースやコンテナ、Hadoopなどをオンデマンドでほぼ自動的に提供できるようにするためのAPI群を提供するものだ。データベースソフトウェアやコンテナ運用ソフトウェア自体をOpenStackで提供しようとするものではない。プライベートクラウドサービス担当者の労力を節約しながら、社内ユーザーの求めるより上位レイヤのサービスを迅速に提供する後押しをすることを目的としている。「使い物になるのなら使いたい」と思う担当者は多いだろう。

 例外として、Magnumはコンテナスケジューリングを含むコンテナ環境配備機能の開発プロジェクトとしてスタートした。だが、その後コンテナスケジューリング機能の開発は停止し、現在はKubenetes、Mesosなどの運用を支援するプロジェクトという位置付けになっている。

 関連して、Shuttleworth氏の「(例えば)オンデマンドでビッグデータをやるために、OpenStackだけの独自カスタムAPIが欲しいと思っている人は誰もいない」というコメントについても、補足する必要がある。

 最近、オープンソースプロジェクト間での競合や勢力争いが、さまざまなところで頻繁に見られるようになっている。OpenStackプロジェクトもこうした「大オープンソース時代」の中にいる。その中で、高い価値を提供するものとして認められた上位レイヤのソフトウェアを、さらに使いやすくすることができれば、OpenStackのインフラとしての価値は高まる。連携にはAPIが必要であり、どのようなソフトウェアでもAPIは独自であり、カスタムだ。いずれにしても、上位レイヤのソフトウェアがインフラとしてのOpenStackとの連携の価値を認めてくれるのであれば、こうしたソフトウェアは進んで、OpenStackのAPIをサポートするはずだ。誰もサポートしてくれなければ、そのOpenStackプロジェクトは失敗だということになるだろうが、これもOpenStackにおける新陳代謝、あるいはCI/CD的な開発スタイルの表れだと表現することは可能だ。

 ただし、OpenStackプライベートクラウド担当者にとっては、コアサービス機能の安定化や機能強化、そして展開・運用の自動化は、まだまだ望まれるところだ。NTTドコモも、VXLANゲートウェイやGPU共有に関して、機能が不足していると指摘している。こうしたよりインフラのコアに近い部分の機能を成熟させることに、優先して取り組むべきだという意見はもっともだといえる。

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。