コンテナ時代のOpenStack、現在を理解するための4つのポイント：OpenStack Days Tokyo 2017直前スペシャル（2）（1/2 ページ）

2017年7月20、21日に、OpenStack Days Tokyo 2017が開催される。本記事では、「直前スペシャル」として、「コンテナ時代には不要」とも誤解されるOpenStackの今を、4つのポイントで解説する。

[三木泉，＠IT]

ポイント1：コンテナの時代にOpenStackは不要なのか

　OpenStackについて語られる誤解の中で最も多いのは、「コンテナや（コンテナオーケストレーションの）Kubernetesの登場により、OpenStackのようなクラウド基盤は意味を失うのではないか」というものだという。

　OpenStackプロジェクトを運営する非営利組織であるOpenStack Foundationのテクノロジー担当バイスプレジデントであるティエリー・カレズ氏（2017年7月20、21日に開催予定のOpenStack Days Tokyoでも講演予定）は、上記の疑問に答え、次の点を説明している。

• OpenStackは、仮想化環境だけではなく、物理マシンもオープンな形で制御できる
• OpenStackが仮想マシンあるいは物理マシン上で提供されるさまざまなアプリケーションを統合したインフラを提供することで、コンテナ環境を信奉するアプリケーション開発者も、コンテナ環境外のデータやアプリケーションを活用できる
• コンテナ環境に対して、コンテナ外のアプリケーションと共有できるストレージおよびネットワーキング環境を提供できる
• 異なるコンテナオーケストレーション環境を、混在運用できる
• Kubernetesなどのコンテナオーケストレーション環境の展開を、開発者に代わってインフラ側で自動的に行える（「Magnum」というOpenStackのサブプロジェクトがこの機能を提供している）。開発者は自身でセルフサービス的にKubernetesなどのクラスタを作成し、利用できる
• 「シンプルなコンテナ環境が欲しいだけで、コンテナオーケストレーションは不要」という場合は、OpenStackから直接コンテナ環境を利用できる（「Zun」というプロジェクトがこの機能を提供している）

　カレズ氏の説明の趣旨を、筆者なりに言い換えると、次のようになる。

　開発者は、「コンテナオーケストレーションツールなどの登場によって、コンテナ環境を物理マシンの上で直接展開できるようになったため、今後サーバ仮想化レイヤーは不要になる」と考える傾向がある。だが、OpenStackは「サーバ仮想化プラットフォーム」ではない。仮想マシンに加えて物理マシンを対象とし、これらを通じたリソース利用を制御する役割を持っている。従って、物理マシン上で直接Kubernetesなどを動かし、コンテナ環境を利用するような利用方法にも対応できる。

　閉じたアプリケーション開発・運用環境を構築し、使うだけでいいのであれば、OpenStackも他のリソース管理ツールも要らないかもしれない。だが、実際には他のデータを活用し、あるいは他のアプリケーションと連携するケースが多い。例えばスケールアウト型のデータベースは、仮想マシンとして稼働していることが多い。

　こうしたサービスと接続するアプリケーションを開発したいのなら、ストレージやネットワーク、アイデンティティなどを統合運用できるプラットフォームがあった方がいい。

　もともと、コンテナでアプリケーション開発を進める開発者にとっては、サーバ仮想化か物理マシンかなど、意識しないで済むに越したことはない。目の前にコンテナ環境がある、または自分で即座にクラスタを構築できるといった形が望ましい。OpenStackではコンテナオーケストレーションと連動して、ニーズに応じ仮想マシンを起動することで、コンテナ環境を自動的にスケールさせられる仕組みなど、コンテナ利用ニーズに応じたインフラ運用自動化を通じ、コンテナ環境を開発者にサービスとして提供できるよう、複数のツールを備えている。

　アプリケーション開発者やアプリケーション運用担当者が、コンテナ対応ネットワーキングやコンテナ対応ストレージをはじめ、コンテナ周辺の面倒な作業について考えたり、こうした作業に時間を費やしたりしなくて済むような、プラットフォームとしての機能を、OpenStackでは今後も充実させていく。

ポイント2：用途ありきのプラットフォームとしてのOpenStackへの回帰

　OpenStackプロジェクトは、急速に拡大してきた。特に2013年以降、次々と新たなサブプロジェクトが立ち上がり、守備範囲も広がった。サブプロジェクトの数は、執筆時点で50以上に達している。だが、その過程で混乱も生じた。「全てのサブプロジェクトを含めてOpenStackインフラを導入、バージョンアップしなければならないのか」「必須のサブプロジェクトとは何なのかが分かりにくい」といった意見が寄せられた。

　こうした声に応えるべく、「DefCore」、つまりコアを定義するための委員会が発足、必須のコンポーネントをコアプロジェクトとして認定した。一方で他のサブプロジェクトを「Big Tent」と呼び、OpenStackにおける革新を推進していくための先兵として、こちらについては機動的な開発環境を確保していくことになった。

　それでも、多数のBig TentプロジェクトがOpenStackの一部だとしてある程度自律的に開発を進めている現状は、「OpenStackは膨張主義」との批判につながっていた。そこで現在、Big Tentの呼称を廃止するなどの議論がなされている。

　OpenStack Foundationは、膨張主義との誤解を払拭する活動を強化する一方、他のオープンソースプロジェクトとの連携を深めてきた。これは、OpenStackの用途をあらためて調べると、クラウドネイティブアプリケーションの開発・運用環境と通信事業者におけるNFV（Network Function Virtualization）が2大ユースケースになっているという事実に基づいている。どちらの場合も、オープンソースソフトウェアに対する期待が大きいため、OpenStackがフィットしやすい側面もある。

　OpenStackの利用が目立つのは、上記の通り開発・運用環境とNFV。とはいえ、いずれの場合も、OpenStackはプライベートあるいはパブリックで運用されるクラウド基盤としての役割を果たすが、それ以上ではない。

　開発・運用環境におけるOpenStackは、ほぼ必ず「PaaS基盤ソフトウェア」「アプリケーション開発プラットフォーム」「コンテナプラットフォーム」などの名称で呼ばれるソフトウェアが稼働する。開発者や運用担当者が気にするのはこうしたツールが便利に使えるかどうかであり、その下のプラットフォームについては二の次だ。

　NFVの場合も、基本的には変わらない。「VNF（Virtualized Network Function）」と呼ばれる通信機能関連ソフトウェアが良好にオーケストレーションされて動き、サービスを高度化あるいは柔軟にスケールさせられるかが重要だ。

　そこでポイント1でも触れたように、OpenStackはコンテナ環境について、コンテナオーケストレーションソフトウェアの展開自動化や、コンテナオーケストレーションソフトウェアとの連動による、インフラプロビジョニングの自動化などを進めてきた。

　また、NFVについては、一部のベンダーがインテルなどとの連携により検証した、ネットワーク高度化をはじめとする機能を、OpenStackに持ち込む一方、NFVのための仮想マシンオーケストレーションプロジェクトを推進。さらにSDN（Software Defined Networking）のコントローラーを開発するOpenDaylightプロジェクトと連携、また通信事業者のニーズをコードレベルのニーズに翻訳する取り組みであるOPNFVとの関わりを強めてきた。

　OpenStackでは、上記のように、これまで数年にわたり、上位レイヤーのオープンソースプロジェクトとの関係を強化してきたが、OpenStack全体のメッセージとして、強く押し出すことはなかった。