Canonicalのマーク・シャトルワース、ビッグソフトウェアの必要性を語る

OpenStackを稼働させるために利用されるOSの55％がCanonicalがオープンソースとして開発しているUbuntuであるという。Austinで開催されたOpenStack Summitに際してCanonicalの創業者、Mark Shuttleworth（マーク・シャトルワース）氏にインタビューを行った。OpenStackの複雑さ、IT部門の運用コストの高さ、ハイパーバイザーを不要にするコンテナー技術そしてIoTのエッジ向けの新しいコンテナーパッケージなどについて語った。

Canonicalの創業者マーク・シャトルワース氏と日本代表の中島 健氏

OpenStackがエンタープライズでも使われるようになってきました。Canonicalの戦略を教えて下さい。

いや、その前に君に聞きたいことがある。オープンソースソフトウェアでコストが安くなった、イノベーションも起きている、でも本当に日本のビジネスマンはそういうふうに思っていると思うかい？

実際にプライベートクラウドを構築しようとしている、つまりOpenStackを使うようなお客さんはイノベーションはともかくコストに関してはちょっと疑問ですね。なぜなら現時点でOpenStackを自社に入れてメンテナンスできる会社はNTTやNECなど、社内に多くのエンジニアを抱えている会社がほとんどですから。

その通り。大企業においては社員は給料さえ払えばどれだけでも使えるリソースなんだよ。つまりそれに関わるエンジニアの人的コストが運用コストとしては計算されていない。そしてクラウドを構築するソフトウェアはどんどん複雑になる。それはちょうどビッグデータにおいても起こったことで、かつてのデータ、つまりリレーショナルデータベースを使ったシステムはそれほど複雑ではなかった。でも膨大なデータを処理するビッグデータシステムは非常に複雑だ。データも膨大だが、システムも巨大になる。そこにはパターンがあると思う。つまりソフトウェアの機能が増え、よりアジャイルに開発されるようになり、新しいソフトウェアのモジュールが常に追加される。それはOpenStackでもマシンラーニングでもビッグデータでも起きていると感じている。我々はそのようなソフトウェアをビッグソフトウェアと呼んでいる。

新しいソフトウェアもどんどんリリースされるし、常に学習しなければいけない。だからライセンスが無料であるオープンソースソフトウェアを使ったとしても、実際のコストは実はそれほど安くならないんじゃないかい？ エンジニアにとっては常に新しいツールを学習しなければいけないし、穿った見方をすれば、そういう新しい多くのツールを使っていれば、自分の履歴書にも経験した履歴として書き込めるし、エンジニアにとっては良いことなのかもしれない。でもそれではビジネスとしては良くないと思うね。我々のゴールはクラウドを構築するだけではなく運用することを簡単にしてコストを押さえること、なんだよ。Ubuntuのソフトウェアを予め設定してすぐに使えるクラウドの例としてOrangeBoxという航空機でも持ち運べるクラスターがあるが、我々は別にハードウェアを売りたいわけではないんだ。ただ、構築そのものよりも運用を如何にラクにするか？ という部分も大事であるということを分かってもらいたいんだ。

ではCanonicalはそれに対して何か解決策はあるんですか？

それに対してCanonicalはJujuというソリューションとエコシステムを提供している。ソリューションに関して言えば、JujuではCharmというパッケージを用意してビッグソフトウェアの複雑さを既にそれを行ったエキスパートの知見として再利用可能にしているんだ。JujuはOpenStackだけではなく他の様々なソフトウェア、つまり複雑でインストールが難しいビッグソフトウェアに対しても使える。そしてエコシステムという意味では、それこそ毎週5つの企業が新たにCharmを作っているというぐらいのスピードで増えているということを分かっていただきたい。IBMやCiscoを始めとした世界中のITベンダーが毎日Charmを作って、公開している。特にOpenStackやビッグデータのように複雑なソフトウェアに対しては効果が高い。もちろん、初めてJujuを使う場合にはそれを学ぶための時間と労力が必要だ。でも一度、それを学べばOpenStackだけではなくビッグデータにもマシンラーニングにも応用できる。

オンプレミスのクラウドインフラストラクチャーを作ることは技術的には難しいが、ビジネスにとってのクラウドインフラストラクチャーの意味は至ってシンプルだ。それは「パブリッククラウドよりも安くプライベートクラウドを作ること」だ。そのためには構築と運用が簡単で安く、つまり時間と労力がかからないものにする必要がある。それに対する回答がJujuだ。

－－ではJuju以外に何かトピックはありませんか？

LXDをぜひ知っていただきたい。LXDはUbuntu 16.04で搭載されたコンテナーマネージャーだが、コンテナーをハイパーバイザーのように使えることが特長だ。つまり仮想マシンを立ち上げてその上でコンテナーを動かすのではなく、コンテナーの中に様々なイメージを入れて稼働できる。仮想マシンというオーバーヘッドが無いことで高速に実行ができ、また高い密度でコンテナーを稼働できる。LXDの中にDockerのコンテナーを入れて動かす事ができるし、Dockerのコンテナーを実行するよりも数倍の密度で実行できる。LXDが実行のためのイメージを共有できるためだ。

これはOpenStackの上でアプリケーションを開発するデベロッパーにとってもとても重要で、例えば、開発に使うラップトップでコンテナーを実行しようとしても数十のコンテナー程度しか実行できないよね？ でも実際に試さないといけないのは数百のコンテナーが協調して動く本番環境だ。High Availabilityの環境を試そうと思ってもラップトップだけでは無理な相談だ。そこにLXDを使えばより密度を上げて多くのコンテナーを利用できる。そういう意味でOpenStackのエンジニアにも良いソリューションを提供できる。

LXDについて：https://linuxcontainers.org/ja/lxd/introduction/

最後はデバイスに関する話をしよう。今、多くのデバイス、自動運転の自動車やロボットなどがUbuntuで動いている。それらのデバイスがもっともっと増えていった時にもっとコストを下げていかなければいけないことになる。なぜかといえばそういうデバイスはデータセンターで動いているサーバーとは本質的に違うからだ。メンテナンスを行うのに高価なエンジニアの時間を使うわけにはいかない。なのでコストを下げ、必要なリソースを下げる必要がある。そこで我々はSnappy Ubuntu Coreをリリースした。これはより小さなフットプリントでアプリケーションを実行させるためのパッケージだ。これを使えば、安く安全にIoTなどに利用されるエッジデバイスでアプリケーションを稼働させることができる。我々は常に機能も重要だが、それを稼働させることの経済性も強く意識しているんだよ。だってそれが企業のCIOが最も望んでいることなのだから。

－－サミット中という忙しい中、時間を割いて頂いてありがとうございました。ところで去年のラグビーワールドカップでの日本対南アフリカ戦は残念でしたね。私たちにとってはとてもうれしい勝利でしたが。

いや、君たちが謝る必要は無いよ。とても素晴らしいゲームだったし、日本代表はとても印象的だった。南アフリカにとっては眼を覚ませてくれて感謝している。なにごとにも当然ということはないのだということを気づかせてくれた。ありがとう。中島さん、そろそろ私に日本代表チームのジャージをプレゼントしてくれないか？（笑）

忙しいOpenStack Summitの会期中の朝8時にインタビューに応えてくれたシャトルワース氏だったが、クラウドが複雑になって文字通り、ビッグソフトウェアになっている現状に対して機能よりも運用コストのほうがビジネスには重要、その運用コストを下げるためのイノベーションを指向する発想は非常に興味深った。これも多くのCIOと対話をしている帰結なのだろう。今後もJujuやLXD、Snappyの動向を追いかけて行く予定だ。

約1年前のインタビュー記事はこちら：https://thinkit.co.jp/story/2015/05/29/6046