クラウド特捜部

OpenStackの次期リリース「Mitaka」、2016年4月に登場予定 多くのプロジェクトを集約

 OpenStack Foundationは、10月に12番目のリリースとなる「Liberty(リバティ)」を公開した。10月末には日本で初めて、OpenStack Summitと、OpenStackの将来リリースに入れ込むテクノロジーを検討するOpenStack Design Summitが、東京で開催された。

 特に基調講演の事例紹介では、日本のYahoo! Japanがサービスの基盤としてOpenStackを採用しており、実際に5万以上のインスタンスや4000台以上の物理マシン、20PBのデータ領域を持つプライベートクラウドを運用していることなどを説明した。こういった事例を見ていると、OpenStackは、目新しいモノではなく、現実に利用できるプラットフォームになってきているのかもしれない。

 特に最近では、SDN(Software Defined Network)から、NFV(Network Functions Virtualization)への対応が重視され、通信キャリアでOpenStackを採用している。

 本稿では、Libertyや次期リリースのMitaka(アルファベットでLの次のM。今回は日本の地名になっている)の機能、方向性などを取り上げていく。

Libertyの特徴は?

 Libertyは、さまざまな部分に改良や新しい機能が追加されている。最も大きな変更としては、Compute部のNovaの改良がある。

 Libertyでは、Compute部の分散化やスケーリングを行いやすくするために、新しくNovaにCells V2が搭載された。これにより、従来必要だったデータベースサービスやメッセージキューを使ったクラスタリングが必要なくなっている。

 Cells自体は、2013年に公開された7番目のリリース(Grizzly)で追加されていた。Cellsでは、仮想インスタンスをCellsという小さな単位にしてグルーピングできたが、Cellsの機能を利用するには、Novaの構成を大幅に変更する必要があった。このため、Cellsを利用できるユーザーは少なかったのだ。

 Cells V2では、シンプルな構成でCellsが利用できるように変更された。将来的には、Novaを展開する場合には、Cellsがデフォルトでインストールされるようになるだろう。

 また、Compute APIもV2.1にアップデートされている。これにより後方互換性を持ちながら、構造がシンプルになった。

 オーケストレーションのHeat、ネットワークのNeutronでは、役割ベースのアクセスコントロールが可能になった。これにより、OpenStackのさまざまなレベルで、セキュリティ設定を細かくコントロールできる。Neutronでは、帯域管理を行うQoS APIのサポート、役割ベースのアクセスコントロールを行うIPアドレス管理、スケーラブルな負荷分散機能(Octavia)などが提供されている。

 このほか、今話題のコンテナシステムDockerを前提にした、管理システムのMagnumも搭載されており、コンテナ管理のKubernetes、Mesos、Docker Swarmに対応している。

 コンテナでは、ネットワークとの連携が重要になってくる。このため、Neutronのサブプロジェクトとして誕生したKuryrがサポートされている。Kuryrは、コンテナとOpenStackを橋渡しすることで、コンテナと仮想マシンが簡単に同じように管理、運用できるようにしたものだ。

 コンテナがサポートされたことで、仮想マシン、物理マシン、コンテナなど、現在オープンソースで提供されているさまざまなテクノロジーをカバーするプラットフォームへと、OpenStackが進化したことになる。ユーザーのニーズに従って、仮想マシンでシステムを構成したり、Hadoopなどを動かすために物理マシンにデプロイしたり、マイクロサービスを構成するためにコンテナを利用したりと、さまざまな用途で利用することができる。

2016年4月にはMitakaをリリース予定

 Libertyの次としては、Mitakaが、2016年4月にリリースされる予定になっている。

 Mitakaに搭載されるテクノロジーの詳細は、OpenStack Design Summitで活発な議論が行われた。

Mitakaでカバーされるプロジェクト
Mitakaは、スケーラブル、高可用性、管理性、モジュラー性、相互互換性などが重視されている

 大きな目標として、ComputeのNova、ネットワークのNeutron、オブジェクトストレージのSwift、ブロックストレージのCinder、認証関連のKeystone、イメージサービスのGlanceなどでインプリメントされているさまざまな機能を、それぞれの機能ブロックで利用できるように、相互運用性を高めていく試みが行われている。

 OpenStack Foundationでは、これらの機能ブロックを「コアサービス」とし、OpenStackのベース機能として規定している。実際、これらの機能は、OpenStackにインプリメントされて、4〜6年たっている。

 Libertyまでに、さまざまな機能がインプリメントされたため、コアサービスにおいては、新機能を積極的に追加していくと言うよりも、より安定したシステムやほかの機能ブロックとの親和性を高めたり、パフォーマンスを高めていく方向での作業が進んでいる。OpenStackのベース機能となるため、コアサービスの信頼性を高めていくことが、多くの企業やクラウド事業者でOpenStackを利用してもらうためのキーポイントになっていくのだろう。

 一方、オプションサービス(Big Tent)として規定されているのは、ダッシュボードのHorizon、テレメトリーのCeilometer、オーケストレーションのHeat、データベースのTrove、Hadoop(Elastic Map Reduce)のSahara、ベアメタルプロビジョニングのIronic、メッセージングサービスのZaqar、共有ファイルシステムのManila、DNSサービスのDesignate、キーマネジメントのBarbicanなどだ。

OpenStack Foundationでは、各プロジェクトを大多数の利用者が利用するコアサービスと、それ以外のオプションとなるもの(Big Tent)に分けることにした。これは、どんどん生み出されるプロジェクトを整理するためだ
Big Tentには、現状では10個のプロジェクトが入っている
OpenStackのWebサイトでは、各プロジェクトの開発状態を把握できるようにProject Navigatorが用意された
Big Tentの開発状況もProject Navigatorで簡単に把握できる

 ここ数年間、OpenStackを見ていると、パブリッククラウドだけでなく、データセンターを運用するためのデファクトスタンダードとして、OpenStackが利用されるようになってきているようだ。そのため、多くのオープンソースプロジェクトや企業が、OpenStackにさまざまな機能を提案したり、OpenStackと連携するプロダクトを販売するようになっている。

 こうしたこともあって、あまりにもOpenStack関連のプロジェクトが大きくなりすぎてきた印象があった。OpenStackのカバーする範囲が広がりすぎているということから、OpenStack Foundationは、コアサービス、Big Tentといった切り分けをしたのだろう。

各プロジェクトを5つのポイントで整理。Libertyでは管理性が多くのプロジェクトで高くなっている
Liberty、Mitaka、Nリリース(Mitakaの次リリース)では、これらの機能がサポートされる

 Mitakaでの強化としては、例えばオブジェクトストレージのSwiftでは暗号化が検討されている。企業においては、データの暗号化は重要な事柄だ。またSwiftで、パフォーマンスのチューニングやスケーラビリティも改善される。

 ベアメタルプロビジョニングのIronicは、ComputeのNovaとのインテグレーションやNeutronのサポート、HA機能のサポートなどを検討した。

ベアメタル プロビジョニングのIronicは、MitakaでNeutronとの連携を深めていく
コンテナ管理のMagnumは、MitakaでダッシュボードのHorizon向けにプラグインを提供する
サーバー管理ツールのAnsibleをDockerコンテナで利用するためのKollaも、Mitakaにおいて、Nova、Neutron、Cinderなどもコアサービスと連動する
ダッシュボードのHorizonは、MitakaでUIの改良が行われる。より分かりやすいUIに変更されるようだ
MapReduceのSaharaは、Mitakaにおいて、HA機能や新しいプラグインをサポートする
ネットワークのNeutronは、ネットワークの自動配置、external DNS、ダイナミックルーティング、仮想マシンごとにVLANが設置できるようになる
NeutronのサブプロジェクトKuryrは、MitakaではNeutronに対するプラグインが整う。Libertyでも機能は搭載されているが、本格的に活用できるのはMitakaからだろう

 またMitakaでの改良として、OpenStackの共通ライブラリ「Oslo」の整備が挙げられている。OpenStack自体のコード量が増えることで、同じような機能を個々の機能ブロック内部で実装することが多くなっているが、これを共通ライブラリ化することで、コード量を減らし、デバッグを容易にする。

 以前から、Osloはインプリメントされていたが、個々の機能ブロックが必要とするモジュールがライブラリ化されているわけではなかった。このため、Osloを使ったコードの再利用はなかなか進んでいなかった。そこで、MitakaではOslo自体を大きく改良して、多くの機能ブロックで利用される共有ライブラリにすることを目指している。

 また、Mitaka世代のOsloでは、新しいメッセージングドライバも検討されており、ApacheのKafkaプロジェクト(メッセージング)からインプリメントされたドライバとZeroMQなどの搭載が検討されている。

Osloは、Libertyで、キャッシュやRabbitMQなどが入っているが、Mitakaでは新しいメッセージング機能が入る

 なおMitakaの機能に関しては、10月末のDesign Summitにおいて大枠が検討されているが、今までのリリースを見ていれば分かるように、個々の機能モジュール開発の進ちょく状況によっては、4月のMitakaリリース時に間に合わなかったり、プログラムの熟成度が高まらなかったために次リリースに持ち越されたり、といったこともあるだろう。このためMitakaの機能に関しては、リリース間近にならないと確定しない。

*****

 年に2回、新しいリリースが出されるOpenStackにおいて、大きな問題になってきているのは、企業が利用する場合に、リリース頻度が速すぎるということだ。先進的なIT企業は、OpenStackの最新リリースを使ってシステムを構築しているが、これには新しいテクノロジーを知るエンジニアを多く必要とする。

 そのため、一般的な企業においては、Red Hatなどがリリースしている商用のOpenStackディストリビューションを利用することになるだろう。各社の商用ディストリビューションは、OpenStack Foundationの最新リリースから1〜2世代前のモノをベースに提供されている。

 OpenStack Foundationが提供している、いわゆる“素の”最新リリースは、一般の企業が積極的に採用できるレベルではないのかもしれない。このあたりは、LinuxとLinuxのディストリビューションの関係に似ているだろうか。

 いずれにしても、OpenStackが多くの企業で利用されるようになるには、OpenStackのリリース自体がもう少し高い信頼性を持つ必要があるだろう。最近の流れとして、新機能をどんどん追加するよりも安定したシステムへと方針が変化し始めたことで、OpenStackが企業に浸透しやすくなっていくと思われる。

 また別の側面では、アップグレードが大きな問題となってきている。多くのユーザーが本格的に採用したIcehouse(2014年4月リリース)から、新しいリリースへアップグレードを行うには、システムを停止する必要がある。しかし、現用システムとして運用されているOpenStackシステムを止めて新しいリリースに入れ替えるのは、ハードルが高い。

 やはり、ライブアップグレード機能、スムーズなデータベースのマイグレーション機能などが必要になってきている。そうでないと、いったん構築されたOpenStackのシステムは、メインフレームのように、バージョンアップせずに一定のリリースで固定化されてしまう。このようになってしまうと、OpenStackのメリットが失われてしまう。また、トラブルがあったときには簡単に古いリリースに戻せるような仕組みも必要になるだろう。

 このあたりは、今後の議論が必要な部分だ。

(山本 雅史)