今回のRecipeはいつもと異なり、
OpenStack Roadshow Tokyo
この
今回は初のアジアツアーとして、
東京会場は六本木のグランドハイアット東京
OpenStack in Action
開発コミュニティが成熟し大きくなってきたOpenStackにとって、
シャトルワース氏は、
コストを下げるうえで、
この分野にこそ、
また、
しかしながらOpenStackには数多くの機能が追加されてきた故に、
UbuntuではOpenStackの根幹とも言えるNetwork、
OpenStack Autopilot
ここまで説明したところで、
このデモはUbuntu上のChromiumブラウザを使って、
Intel NUCが10枚入ったThe Orange Boxに、
ちなみにこのAutopilotは現在ベータ版という扱いで、
さらに将来的な目標として、
ここまで説明した段階で、
また
Autopilotを支える技術：MAAS
ここからはAutopilotを支えるオープンソースの技術の説明となりました。
「MAAS
MAASはインストールされたOSの設定管理やサービスのインストールなどは行わず、
MAASは大量のハードウェアの管理に向いていると言います。ロンドンやウォールストリートの証券会社でも、
最近ではCanonicalとChefの協力の手始めとして、
さまざまなOSや設定管理ツール、
Autopilotを支える技術：Juju
MAASの上で動いているのが
Jujuの発端はクラウド上へOSをインストールすることの自動化でした。さまざまなインストールオプションを手動で設定することなく自動的にインストールできることを目指して作られました。結果的にインストールは簡単になったものの、
具体的なシナリオとしてシャトルワース氏は、
会場では実際のデモとして、
WordPressに限らず、
理想的にはCharmはベンダーが提供してくれると良いとシャトルワース氏は言います。ベンダーが提供する複雑なインストールマニュアルの代わりに、
このあと会場からは、
またここまでのデモがすべてWeb UIで完結していたことを踏まえて、
ちなみにWeb UIの国際化については、
発表のまとめ
OpenStackの用途としてビッグデータや機械学習があります。またラムダアーキテクチャでは、
シャトルワース氏はJujuを使って構築したさまざまなモデルを示しながら、
ちなみに、
マーク・シャトルワース氏へのインタビュー
プレゼンテーション後、
―― 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などソフトウェアのスケールを先導するさまざまなビジネスが存在するからです。これらはいずれも私たちにとっても興味のある事柄です。 日本は、
新しく柔軟でスケールするシステムへと加速しています。私たちも共に歩みたいと考えています。