Ubuntu Weekly Recipe

第375回OpenStack Roadshow Tokyoレポート

今回のRecipeはいつもと異なり、2015年5月12日(火)に開催された「OpenStack Roadshow Tokyo」の様子をお伝えします。

OpenStack Roadshow Tokyo

このOpenStack Roadshowは平たく言うと、CanonicalのFounderであるマーク・シャトルワース氏が世界各地に訪れて「UbuntuだとOpenStackがこんなに便利に使えるよ」ということを伝えるツアーイベントです。

今回は初のアジアツアーとして、5月5日のシンガポールから始まり、香港、台北、ソウルを経て、最終日の東京までを約1週間でまわるスケジュールでした[1]⁠。ちなみに初日の前日である5月4日にはUbuntu Online Summitのプレイベントを行い、シンガポールのホテルから次のコードネームが「Wily Werewolf」であることをアナウンスしていたりします[2]⁠。

東京会場は六本木のグランドハイアット東京[3]で、70人から80人ぐらいの参加者相手に2時間近くシャトルワース氏がしゃべり続けるという体裁でした。

図1 会場の様子:壇上の垂れ幕
図1 会場の様子:壇上の垂れ幕
図2 会場の様子:ほぼ満席状態
図2 会場の様子:ほぼ満席状態
図3 会場の様子:軽食や飲み物が用意された
図3 会場の様子:軽食や飲み物が用意された

OpenStack in Action

開発コミュニティが成熟し大きくなってきたOpenStackにとって、目下の課題は「いかに活用するか」です。

図4 マーク・シャトルワース氏
図4 マーク・シャトルワース氏

シャトルワース氏は、どんな企業も競合他社や新興企業から挑戦を受け、その市場や技術において破壊的イノベーションが起きうる時代であることを踏まえて、いかに素早く経済的にビジネスを進化させるが重要になっていると語ります。たとえば衛星放送やCATVといった本来クラウドとは関係ない伝統的な企業であってもNetflixなどに勝負を挑まれていますし、迅速さや経済性が求められています。

コストを下げるうえで、原材料費のマージンはほとんどなくなっているのに対して、運用コストのマージンはまだ余裕があります。運用を自動化することで、数人のオペレーターが何千何万ものサービスを運用できるようになれば、このマージンを改善できます。

この分野にこそ、Ubuntu/OpenStackを活用する余地があるとシャトルワース氏は述べていました。

また、OpenStackである理由として、まず事実上すべてといって良いベンダーがサポートしているほどこの業界における明らかな勝者になりつつあること、そしてUbuntuはOpenStackに早くから標準のリファレンスプラットフォームとして参加していたことを挙げています。その結果、OpenStackユーザーの三分の二もの企業がUbuntu上でOpenStackを使うようになっているのです。

図5 本番環境でUbuntuとOpenStackを使っている企業
図5 本番環境でUbuntuとOpenStackを使っている企業

しかしながらOpenStackには数多くの機能が追加されてきた故に、複雑さが増しています。その複雑さはまさしく「Frustration as a Service」であるとシャトルワース氏は言います。その複雑な操作のために余分に人員を割くのでは、コスト削減の意味がなくなってしまうのです。

UbuntuではOpenStackの根幹とも言えるNetwork、Compute、Storegeに注力することで、自動化によるインストールの簡単さとオペレーションの効率化を追求しているそうです。

OpenStack Autopilot

ここまで説明したところで、Ubuntuで実現できるOpenStack体験のデモを行いました。

このデモはUbuntu上のChromiumブラウザを使って、CanonicalのAutopilotを実際に操作してみるというものです。Autopilotそのものは、MAASの上に第341回で紹介したUbuntu OpenStack Installerを使って[4]⁠、OpenStackとCanonicalが提供する商用のシステム管理ツールであるLandscapeを構築したものです。

Intel NUCが10枚入ったThe Orange Boxに、OpenStack Installerを使ってOpenStack環境をゼロから構築し、Compute用にKVMを、ネットワーク構成のためにOpen vSwitch、ストレージ用にSwiftやCephを選択していました。すべてWebブラウザ上の操作だけで設定完了し、セミナーの最後にはOpenStackのDashboardを表示する状態になっていました。

図6 Orange Boxの内部
図6 Orange Boxの内部
図7 Orange Boxの外観
図7 Orange Boxの外観

ちなみにこのAutopilotは現在ベータ版という扱いで、発表時点で数週間以内にGAとなる予定、とのことでした。

さらに将来的な目標として、Landscapeのマネージメントビューの拡張を考えているそうです。今はCPUやメモリのワークロードがリアルタイムに表示されている状態で、ここに障害検知や冗長化の操作を追加することも考えているとのことでした。またハイパーバイザ、ストレージ、ネットワークのそれぞれのコンポーネントについても、選択肢を増やしていくことも述べています。

図8 OpenStack Autopilot Roadmap - Vendors
図8 OpenStack Autopilot Roadmap - Vendors

ここまで説明した段階で、会場から「自動化を進めすぎると、トラブルシュートが難しくなってしまうことはないのか?」という質問がありました。シャトルワース氏曰く、Autopilotを支える技術はすべてオープンソースになっていること、そしてそのレイヤーは注意深く分離していることから、問題の切り分けを行いやすくしてある、とのことです。

また「AutopilotでOpenStackを導入した場合、バージョン間のアップグレード、特にライブアップグレードはできるのか?」という質問もありました。まず、現時点でAutopilotがインストールできるのはJuno/14.04のみということです。今後はJunoからKilo、さらにはLibertyへのアップグレードやOS部分も14.04から16.04へとアップグレードできるようになるとのことでした。ただ、カーネルのアップグレードを行う場合は当然再起動が必要になりますし、OpenStackの場合はバージョン間でコンポーネントの構成が変わることも考えると、移行パスによってはライブマイグレーションは難しくなるかもしれないとも回答していました。

Autopilotを支える技術:MAAS

ここからはAutopilotを支えるオープンソースの技術の説明となりました。

MAAS(Metal as a Service⁠⁠」はマシンのデータベースであり、そのマシンにOSをインストールするためのツールです。興味深いのはここでのOSは、Ubuntuに限ったことではないことです。会場ではシャトルワース氏が実際にOrange Box上の空のノードにWindowsとデスクトップ版のCentOSをインストールしてみせていました[5]⁠。

MAASはインストールされたOSの設定管理やサービスのインストールなどは行わず、マシンが空いているかどうかと、どのユーザーに割り当てるか、そしてOSをインストールするという限定された役割を担うことで、シンプルさと汎用性を保っています。

図9 MAAS稼働画面
図9 MAAS稼働画面

MAASは大量のハードウェアの管理に向いていると言います。ロンドンやウォールストリートの証券会社でも、Windowsのシンクライアントのデプロイにも採用されていますし、HPのMoonshotや高密度ARMサーバー、新しいPowerプロセッサでも使えること胸をはっていました。

最近ではCanonicalとChefの協力の手始めとして、ChefとMAASを用いたベアメタルサーバーのインストールといった話も出てきています。

さまざまなOSや設定管理ツール、プロビジョニングツールと連携することで、オープンソースでなおかつクロスOS、クロスハードウェアなSoftware Defined Data Centerを実現し、物理層の完全な自動化を実現することがMAASの目標だとシャトルワース氏は語っていました。

Autopilotを支える技術:Juju

MAASの上で動いているのがJujuです。Jujuを語るうえでシャトルワース氏は最初に「Jujuは構成管理のツールではない」ということを強調していました。元々構成管理の機能はJujuにはなく、構成管理を実現したければChefやPuppet、シェルスクリプトをを使う必要があるためです。Jujuはあくまで「構成管理を再利用するためのツール」なのだそうです。

Jujuの発端はクラウド上へOSをインストールすることの自動化でした。さまざまなインストールオプションを手動で設定することなく自動的にインストールできることを目指して作られました。結果的にインストールは簡単になったものの、今度は設定作業に時間をかけるようになることが判明したのだそうです。しかもプロジェクトごとに好みの構成管理ツールを使って、似たようなことを行っていることも。そこで、各プロジェクトが作った構成管理の設定を「再利用」できるようにしようとした結果、今のJujuとなったのです。

図10 JujuでWordPressをデプロイしている途中
図10 JujuでWordPressをデプロイしている途中

具体的なシナリオとしてシャトルワース氏は、⁠ベンチャー企業が6週間以内に何かを立ち上げる」ケースを挙げました。その中では、プロダクトの紹介をするブログを用意する必要があるでしょう。従来であればWordPressなどをインストールして、設定ファイルをどこかからコピー&ペーストするようなことも考えられます。でも、これはその企業のビジネスそのものにはあまり関係ないので時間はかけたくありません。

会場では実際のデモとして、Juju GUIからMySQLとWordPressを検索しドラッグアンドドロップ、デプロイ先のマシンを割り当て、マウスでリレーションを設定するだけでWordPress環境ができあがる様子を示していました。シャトルワース氏は、Jujuの中で「何かが」設定管理をやっているはずだけれども、使う人は感知しなくて良いこと(カプセル化されていること⁠⁠、デプロイ先のOSですらなんでも良いことを強調していました。とにかく「WordPressのサービス」を時間をかけずに用意したいだけの人のためのツールだと言うのです。

WordPressに限らず、さまざまなスクリプト(Charm)が存在します。会場ではさらにNagiosとNRPEを導入してMySQLとWordPressを監視するようにしたり、WordPressをスケールアウトしつつHAProxyを導入したりということを、マウスだけで実現してみせていました。

図11 NRPEやHAProxyなどが追加された
図11 NRPEやHAProxyなどが追加された

理想的にはCharmはベンダーが提供してくれると良いとシャトルワース氏は言います。ベンダーが提供する複雑なインストールマニュアルの代わりに、そのベンダーの専門家が作った「ちゃんと動く」Charmを提供するということです。

このあと会場からは、Jujuに関して様々な質問が出てきました。たとえば「Jujuのメインユーザーは誰か?」という質問がありました。曰く「アプリケーション開発者には難しそうだし、SIerなら自分でスクリプトを作ることに慣れているだろう」と言うのです。それに対してシャトルワース氏は、SOAなソフトウェア、マイクロサービスを大量にまとめた新しいタイプのソフトウェアを毎日デプロイするような人たちに使われていると回答していました。OpenStackもまた、このタイプのソフトウェアに該当するそうです。逆に単純にデータベースのみをデプロイするようなユーザーには使われていない印象とのことでした。

またここまでのデモがすべてWeb UIで完結していたことを踏まえて、⁠設定内容をスクリプトに落としたり、別のJujuにインポートするといった機能はないのか?」という質問もありました。それに対しては、JujuがCLIでも操作できること、REST APIがあることを伝えたうえで、⁠Jujuはオーケストレーターではない」と回答しています。つまり設定セットを取り込んだり、エクスポートするのはJujuではなく、AutopilotのようなJujuのAPIをドライブするオーケストレーターの役割という扱いです[6]⁠。そうすることでJuju/Charmの再利用性を高めていると説明していました。

ちなみにWeb UIの国際化については、プランはあるものの未着手ということでした。

発表のまとめ

OpenStackの用途としてビッグデータや機械学習があります。またラムダアーキテクチャでは、いろいろなデータやソフトウェアの組み合わせが存在します。OpenStackに限らず、Docker+Kubernetesを使うこともあるでしょう。

図12 Cloudera+Kafka+Stormを構築したJujuの例
図12 Cloudera+Kafka+Stormを構築したJujuの例
図13 Docker+Kubernetesのクラスタ
図13 Docker+Kubernetesのクラスタ

シャトルワース氏はJujuを使って構築したさまざまなモデルを示しながら、Jujuを見れば、何がどこでどうつながっているかもわかるようになると言います。このため、どんなクラウド用途であっても、そのサービスの専門家を雇えなかったとしても、その複雑な環境を構築できるようになるとのことでした。

ちなみに、発表の合間にはCanonicalが提供するBootStackや、近々発表されるであろうQuontaとの提携サービスについての紹介もありました。

マーク・シャトルワース氏へのインタビュー

プレゼンテーション後、マーク・シャトルワース氏やCanonicalの中島様にインタビューする機会がありましたので、その内容をかいつまんでお伝えします。

図14 マーク・シャトルワース氏
図14 マーク・シャトルワース氏

―― AndroidやiPhoneのアプリストアがそうであるように、ストアからエンドユーザーが「良いアプリ」を探し出すのは非常に難しい問題です。今後、Charmストアにさまざまなベンダーが数多くのCharmを提供するようになると、同じような問題が発生すると思うのですが、どのようにお考えでしょうか?

現在私たちは、さまざまな観点から品質を上げるプロセスに重点を置いています。

たとえばあるマシンにソフトウェアをインストールするようにCharmを書くことができますし、まずはそのように作るでしょう。しかしながらJujuは「スケール可能である」ことから、そのCharmがどう作られているかに関係なく、ユーザーはスケールさせようとするかもしれません。またそのスケールの適切な記述方法はソフトウェアの種類によって変わります。MySQLをスケールさせる方法はMongoDBとは異なるのです。そこで私たちは、そのCharmが確かにスケールするかを確認します。

セキュリティの観点からもCharmをチェックしますし、アップグレードできるかどうかも確認します。ユーザーがそれぞれ期待するソフトウェアライフサイクルの、すべての観点において「ちゃんと動く」ように留意しています。

―― Charmのレビュープロセスはどれくらいの人数で行っているのでしょうか?

コミュニティチームを形成し、できるだけ素早くレビューするようにしています。

オープンソースソフトウェアと同様に、素早いフィードバックを提供すれば、その改善もより早くなることがわかっているからです。今朝もIBMが、そのソフトウェアの一部のために作成したCharmがありましたので、より良くなるようにレビューしたところです。

―― OpenStackのIronicは、機能的にMAASと被るところもあるかと思いますが、どのように住み分けるのでしょうか?

Ironicはベアメタルにイメージをインストールする機能をOpenStackに追加します。これは便利ではありますが、Ironicを動かすためにはOpenStackのコンポーネントが必要にるということでもあります。

それに対してMAASはOpenStackとは関係なく、もっとシンプルなものです。シンプルであるが故にWindowsやRHEL、SUSE、CentOSなどさまざまOSをインストールできます。ChefのコミュニティもベアメタルへのデプロイにはMAASを利用を推奨していています。Ironicを採用するとNovaのAPIが制約になってしまうことを避けたかったことも理由の一つのようです。

―― CanonicalはもともとオープンソースのOSの企業という印象です。しかしながらJujuは、DevOps向けのモデリングツールという話でした。将来的にCanonicalはDevOps向けを目指していくことになるのでしょうか?

私たちが最も興味を抱いているのは、⁠何か難しいことを簡単にする」ということです。Ubuntuも、Linuxのインストールの難しさから始まりました。人びとは常に「もっと簡単にできないのか?」と言い続けています。

ある特定のOpenStackならインストールはそれほど難しくないかもしれません。しかしそれでも、⁠OpenStackのインストールは難しい」⁠Hadoopのインストールは難しい」⁠機械学習のインストールは難しい」⁠CloudFoundryのインストールは難しい」なんて言葉を見てきました。これらに共通するのは、データベースやメッセージング、APIサービスといった複数のソフトウェア部品を協調させなくてはいけない「新しいクラスのソフトウェア」であるということです。しかもこれらの部品は数多くのマシン上に配置されます。

これはUbuntuだけで解決できることではありません。なぜなら、特定のOSに限った話ではないからです。よって他の多くのOSにも開かれた形で対応しました。

―― 「簡単にする」という明確な哲学についてはわかります。これをどのように収益化していくのでしょうか?

もともとの私たちの焦点は「人びとがクラウドを使うようにするにはどうすれば良いか」ということでした。そのためクラウド上でのUbuntu体験を素晴らしいものにするべく注力してきました。その体験をより良いものにすればするほど、クラウド上で最初に使う人が増えて、結果的にお金を出してくれるユーザーが増えると考えています。

たとえば6週間で何かを成し遂げなければならないスタートアップを考えてみます。Hadoopをapt-getでインストールするとして、何十台ものマシンにインストールするのは大変です。そもそも何十台もの仮想マシンを用意しなくてはいけないかもしれません。Jujuはこういう作業コストをできるだけ小くします。Jujuを操作することで、既存のスクリプトを素早く再利用できるのです。

このとき、その中で動いているOSについて感知することはありません。実際どのOSを選択するかは、Charmを作成するソフトウェアベンダーに任されているのです。あるデータベースソフトウェアであれば、UbuntuではなくOracle Linuxにするかもしれません。Active DirectoryのCharmならWindows上で動かすことになるでしょう。多くのCharmはUbuntuでも動きますが、その選択を制限するようなことはしたくないと考えています。

―― Juju/CharmとSnappyの関係性について教えてください。

これらはそれぞれ異なる分野向けの、異なる目的を持ったツールです。クラウド分野においては、さまざまなソフトウェアをユーザーが望む形で動的に切り替えながら、使いたいと考えるでしょう。デバイスの分野においては、特定のソフトウェアをデバイスを壊すことなく使いたいと考えることでしょう。

Snappyは、単一のデバイス上に含まれるソフトウェアコンポーネントを持ったシステムを作ることを目的にしています。スピーカーやWi-Fiステーションといったデバイスに新しい機能を追加するために、他のソフトウェアに影響を与えることなく、新しいソフトウェアをインストールするといったシナリオです。それ以外にも、ソフトウェアを簡単にアップグレードしたり、アンインストールすることも考えています。

JujuとSnappyは現在、異なるチームが開発を行っています。Jujuのチームでは、どのようにすればクラウドの世界により多くの品質の高いソフトウェアを導入できるかを考えています。Snappyのチームでは、単一のデバイスに対して、ソフトウェアの追加や削除、アップグレードの信頼性を高められるかを考えています。それぞれ異なる哲学を持っているのです。ただし、将来的には一緒になるだろうと思います。

たとえばNTTのように、大量のネットワークデバイスの機能追加や更新をリモートで行わなくてはならない場合、その処理・手順には高い信頼性が求められます。マルチデバイスへの対応について考えるようになった時、JujuとSnappyの連携を考える必要がでてくるでしょう。

Jujuは5年たちましたが、Snappyはまだ1年ほどの若いプロジェクトです。今はまだシングルデバイスの操作の信頼性を高めることに注力したいと考えています。

―― OIL(OpenStack Interoperability Lab)について、日本のベンダーの取り組み状況について教えてください。

OILには今は主にサーバーメーカーに参画していただいています。日本のメーカーで言えばNEC様のAvotonサーバーも入っています。現在はストレージベンダーも含めて話をしているところで、おそらく近々に発表できるものと思います。ちなみに、どこがパートナーに入ったらいいと思います?

ベンダーとの協業は私たちも重要であると考えています。OILはデータベース、メッセージングシステム、Software-Defined Network、スケーラブルストレージといったさまざまなコンポーネントの組み合わせから、数多くのデータを生成するからです。特に「うまく動かなかった」とき、OILはそのすべてのログやマシンの情報をベンダーに提供できます。

OpenStack上に特定のベンダーのソフトウェアをデプロイしようとしてうまく動かなかった時、必ずしもそのソフトウェアが悪いとは限りません。OpenStack上の別のベンダーが提供するコンポーネントが悪いのかもしれませんし、Charmに問題があるかもしれません。OpenStackのすべてのコンポーネントを単一のベンダーで網羅するのは難しいので、CanonicalがOILに参画するベンダーの統合的なテスト環境を用意し、自動的にテストを回すことで、何か問題が発生した時に真に関連するベンダーへと素早く情報を提供します。

ユーザー側から見た場合も、OILで使われているものであればある程度安心して導入できるのではないでしょうか。

―― Juju/MAASでホワイトボックススイッチをデプロイ・コントロールするプランはありますか?

はい。ただし先程も言ったように、JujuについてはSnappyとの連携ができるまでは使わないでしょう。主にスイッチの管理はSnappyが担当します。Snappyが機能の追加を行い、SnappyそのもののインストールはMAASが行う形です。

ラックにOSがないホワイトボックススイッチが接続された時、MAASが新しいボックスがあることを検知し、OSとしてSnappyをインストールします。あとはSnappyを使って機能を追加していき、MAASのクラスタコントローラーによってスイッチ設定を行うイメージです。ここまでが完全に自動化されます。

―― たとえばOrange Boxに対するOrange Rackみたいなものを作られるのでしょうか?

私たちはハードウェアを作ることはありません。ただ、Ubuntuを利用するあらゆるマニュファクチャーとパートナーシップ契約を結びサポートすることはもちろんあり得ます。個人的にホワイトボックススイッチのマーケットには興味を抱いています。とてもイノベーティブな分野だからです。

明日にでも最初のパートナーシップについて発表できるでしょう[7]⁠。

―― 日本におけるCanonicalのビジネスの今後について教えてください。

日本は私たちにとって非常に重要なマーケットであると考えています。なぜならPaaSやIaaS、DaaSなどソフトウェアのスケールを先導するさまざまなビジネスが存在するからです。これらはいずれも私たちにとっても興味のある事柄です。

日本は、新しく柔軟でスケールするシステムへと加速しています。私たちも共に歩みたいと考えています。

おすすめ記事

記事・ニュース一覧