Google Cloud Platformにおける「オープン」の正確な意味を、サム・ラムジ氏に聞いた：Kubernetesオープンソース化の背景（1/2 ページ）

　Googleは、Google Cloud Platform（GCP）が「オープン」であると強調している。しかし、「パブリッククラウドにおけるオープンとは何か」を考え出すと、奥の深い問題であることに気が付く。GCPが単なるマーケティング活動の一環でオープンを唱えているのではないとすれば、どういう理由で、何を、どうオープンにしているか、それは他のパブリッククラウドとどう違うのか。その答えを求めて、Google Cloud プロダクトマネジメント担当バイスプレジデントのサム・ラムジ（Sam Ramji）氏に、個別インタビューした。

関連記事：
Google Cloud Platformは、他と比べてどこが「オープン」なのか

「オープン」に関するGCPの違いとは

――GoogleがGoogle Cloud Next 17で、GCPのオープンさを訴えて以降、GCPにおけるオープンとは何なのかを考え続けてきました。例えばMicrosoftも、Microsoft Azureでは、オープンソースソフトウェアとの関係を深めています。GCPのオープンさは、他のクラウドとどう違うと考えていますか？

　私はオープンさが競争であるとは思っていません。「Microsoft Azureよりもオープンであるにはどうしたらいいか」などとは考えません。

――しかし、自社のサービスが（オープンさで）選ばれたいとは思うでしょう？

　確かにその通りです。ですが、「プロダクトが（後付けでなく）当初からオープンな設計になっているか」を考えています。これが中核的な戦略ですし、他のどんなクラウドベンダーとも異なっています。マーケティングではなく、エンジニアリングとして、製品が最初からオープンに作られることを保証するのが私の仕事です。

　Microsoftがやっていることは非常に興味深いと思っています。彼らは自らのプラットフォーム上にオープンなレイヤーを築いています。一方、私たちは、自らのシステム間のインタフェースについても、完全にオープンでなければならないと考えています。

　IT業界全体がオープンソースおよびオープンな標準に基づく基盤を求めていると考え、Kubernetesをオープンソースソフトウェアとしてコントリビューションしました。これをはじめとして、「人気のあるオープンソースプロジェクトを見てみると、Googleによる貢献から始まったものだった」というケースが増えていて、この点に関する開発者や顧客の認識が広まっています。

　私はこうした証拠を経営陣に持っていき、「オープンな戦略をもっと前進させるべきです。次にオープンソース化できるものは何かを考えるべきです」と伝えています。

　例えば、Bazelは大規模なソースコード管理のオープンソースソフトウェアですが、これはGoogleの開発者全員が使ってきた社内システム「Blaze」を基にしています。あまり広く知られていないかもしれませんが、こうして1つずつ、どのようにオープンソース化すべきかを考える一方で、社内の従来型システムに、オープンソース実装をどのように広げていくかという取り組みを進めています。

Kubernetesが人気になって、何がうれしいか

――例えばKubernetesに関して言えば、MicrosoftやRed Hatは、これを採用したサービスや製品を出してきていますよね。ユーザーにとっては、どれでも（基本的には）同じということになりませんか？

　違うと思います。

――なぜですか？

　世界はとても複雑だからです。多くの企業は、長期間にわたって多様なシステムを構築してきました。SolarisやHP-UXで動いているものがあり、さらにLinuxとWindows Serverがあり、一部はActive Directory、さらに一部はLDAPで管理されています。10、15カ所といった数のデータセンターを運用し、そのうちの幾つかを統合し、さらにその一部をクラウドに移行しています。

Google Cloud プロダクトマネジメント担当バイスプレジデントのサム・ラムジ氏

　現在のITインフラ市場は1.2兆ドル規模と言われていますが、そのうちクラウドに移行したのは250億ドルに過ぎません。企業のワークロードのほとんどはまだデータセンター内にあるにもかかわらず、クラウドは高率で成長しているため、注目を集めています。

　Microsoftを使ったシステムに関与してきた開発チームが、コンテナに基づいてDevOpsを推進したいと考えてKubernetesを採用するなら、Active DirectoryをID管理に使いたいでしょうから、Microsoft Azureを選択するのは理にかなっています。そうであっても、そのIDを他とブリッジしさえすれば、例えばBig QueryのためにGoogle Cloud Platformを併用するなどができます。Kubernetesのクラスター間連携機能を使って、ワークロードごとに最適な場所を選んで動かせます。

　Red Hatについても同様なことが言えます。同社は基本的に、オンプレミスでのKubernetesおよびOpenShiftの導入にフォーカスしています。大企業で、「Google Cloud Engine（GKE）をクラウドとオンプレミスの双方で使いたい」という顧客がいます。Googleはオンプレミス用のソフトウェアを提供する計画はありませんが、その顧客がRed Hat Enterprise LinuxなどのRed Hat製品を使ってきたのであれば、OpenShiftを使うという選択肢があります。

　これら1つ1つの要素は違った役割を果たせます。その背景にはテクノロジーの風景が複雑化してきていることがあります。

　Kubernetesがもたらす価値は、ワークロードをポータブルで流動的なものにできる点にあります。もし、私たちがKubernetesをやらなかったとしたらどうでしょうか。もっとロックダウンされた、プロプライエタリな世界があったでしょう。あらゆるものが、AMI、Hyper-V、VMware（ESXi）などのプラットフォームに接着した世界にとどまったでしょう。「VMware Cloud on AWS」で、VMwareはAmazon Web Servicesと提携していますが、ワークロードが流れるように移動できるわけではありません。

　私は、オープンエコシステムおよびオープンな環境の構築に、人生の多くを費やしてきました。2004〜2009年には、Microsoftでオープンソースプログラムを指揮しました。Linuxとの混在環境を顧客が望んでいたからです。そこで私は、Microsoftによるオープンソースへの貢献や相互運用性の向上を支援しました。

　しかし、顧客は相互運用性だけでなく、ポータブルな世界を欲しがりました。ちょうど当時、Open Nebulaなどの初期のクラウドソフトウェアプロジェクトなどがありましたが、Microsoftはクラウドでは非常に遅れていたため、API管理のApigeeに移りました。「あなたの求めるポータビリティを実現する技術はまだ存在しませんが、いろいろなところでAPIを立ち上げればどことでも通信ができますよ」と言いたかったのです。

　次に2015年の初めには、Cloud FoundryのCEOになりました。とうとうクラウドポータビリティを実現する技術が登場したと考えたからです。

　それでも、多少の限界を感じました。必ず2種類のオーディエンスがいるからです。開発者はいつでも、PaaSを求めています。一方、インフラ側の人たちは、仮想マシンやコンテナ、ストレージ、ネットワークといった、土台の部分を気にします。後者は、Kubernetesの得意な分野です。

　KubernetesとCloud Foundryはどちらも必要です。あなたがインフラを気にする人なら、Kubernetesでポータビリティを確保し、開発者なら、Cloud Foundryでポータビリティを確保したいと考えるでしょう。これら2つは、私たちが提供すべきとても重要な技術です。ITがユーティリティーモデルに移行する過程で大きな役割を果たします。

　例えば30年後に、ITが巨大なクラウドプロバイダーによってロックダウンされ、ポータビリティを妨げるさまざまなわなを解消できないままなら、IT業界は悪質な業界だということになると思います。

――関連して、なぜCloud Native Computing Foundation（CNCF）は今の姿なのでしょうか？　もっと共通仕様策定活動を前面に押し出すことはできないのでしょうか？　各分野から1つあるいは少数のプロジェクトを選んでいくというのは、誤解を招く可能性があります。

　素晴らしい質問だと思います。私はCloud FoundryのCEOからCNCFのボードメンバーになったわけですが、2017年夏にボードミーティングを開催し、「私たちは何をやっているのか」「何を達成したいのか」を率直に話し合いたいと思っています。

　前任者の考えは良かったと思います。Kubernetesを生かすためにはロギング、DNS、サービスメッシュなど、分散アーキテクチャを構成するさまざまな要素が必要です。こうした要素に共通の「家」に当たる場所がないと混乱します。そこでCNCFのような組織ができました。

　共通仕様に関して、約1年前私はCloud Foundryにいた時期に、業界として4つのインタフェースを標準化すべきだと話しました。コンテナ、ストレージ、ネットワーキング、そしてサービスです。このうち3つについて標準化が実現しました。コンテナに関してはContainerdとOCI、ネットワーキングについてはContainer Networking Interface（CNI）、サービスに関しては、Cloud FoundryのOpen Service Broker APIをKubernetesで採用しました。Open Service Broker APIは今後、Kubernetesのサービスネットワーキングの中核になるでしょう。ストレージについては約1年前に議論が始まり、今後2、3カ月のうちに何らかの成果が出るでしょう。

　私はあなたと同意見です。さまざまな技術のために「家」を提供する必要はありますが、各分野で単一の技術を選ぶべきではないと思います。誰も、正しい判断ができるほど賢くはありません。これは市場が決めるべきことです。ただし、ガバナンスモデルなどの問題もありますので、考えているところです。