ここから本文です

Google Cloud Platformにおける「オープン」の正確な意味とは

7/28(金) 7:55配信

@IT

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

●「オープン」に関する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カ所といった数のデータセンターを運用し、そのうちの幾つかを統合し、さらにその一部をクラウドに移行しています。

 現在の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カ月のうちに何らかの成果が出るでしょう。

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

●「オープンであること」とビジネスとの関係

――最も聞きたいと思っていたことの1つは、「オープンソースやオープン性から、どのように良いビジネスを築くことができるか」ということです。

 純粋に資本主義的な観点で言って、オープンであることは参入障壁を引き下げられます。LinuxとWindowsの関係にも、これが当てはまります。2000年代初期に、Microsoftは非常に高い壁を築いており、誰も破れないと考えていました。ところがLinuxはある程度の時間をかけて、これを崩しました。これにより、Linuxエコシステムの多数のベンダーが参入できました。

 「non-market forces」という言葉があります。自動車では「環境に優しい車」としてアピールするケースがよく見られますが、当初は製品が完全ではなくとも、あなたの考え方に訴えることが可能です。クラウドでは現在、AWSが高い壁を築いていますが、「オープン」「自由」を訴えることで、競争の場をよりフラットなものにすれば、私たちのインフラが競争に参加できる機会が生まれます。

 私は、GCPの仮想マシンやネットワーク、ストレージのパフォーマンスが、AWSやAzureに比べて優れていると思っていますが、オープンでないならば、誰が気にするでしょうか? プロプライエタリなクラウドサービス同士が競う世界しかありません。

 非常にプラグマティック(現実的)な意味で、ナンバー3であるGCPはオープンでなければならないのです。もちろん、正しいことでもあります。

 オープンであるという理由から、GCPを試してくれる人はいるでしょう。そして一度試してもらえれば、ダイアン(・グリーン)が話しているように、企業における商談の60%を勝ち取っています。GCPがクラウドサービスで第3位だということを考えれば、悪くない勝率です。

 私がGoogle Cloudに来た理由もここにあります。2016年7月、Cloud Foundryは現在のKubernetesに似た成長の苦しみを経験していました。

 コントリビューターの数は多く、スポンサーには大企業が並んでいるのですが、例えばリリースシステムには金を使ってくれる人がいませんでした。AWSへの支払いコストは、200万ドルに達しました。当時のCloud Foundry Foundationの年間予算は800万ドルでしたから、約4分の1をCI/CD(継続的インテグレーション/継続的デリバリー)システムに費やすことになっていました。そこでエンジニアがGCP上でCIシステムを動かしてみました。結果は驚くべきものでした。2倍高速なサービスを、2分の1以下のコストで運用できると分かったのです。9月には完全なGCPへの移行を決めました。

 私はその時に、品質レベルの異なるクラウドサービスだと認識しました。ですが、Google Cloudから誘われた際に、これを受け入れた理由は、「オープンを全面的に受け入れる組織なら、私も信じて仕事ができる」と考えたことにあります。

 誰も、進んでオープンになどなろうとしません。ナンバー1の企業なら、オープン化はあり得ません。オープンになろうと考えるのは、市場における競争で力を得たいと考えるからです。そして、オープンになるなら、完全にやり遂げなければならないと思います。マーケティング過多であれば、人々はその匂いを敏感に感じ取るからです。

 人は人を信じることができますが、組織を信じることは難しいと思います。組織の目標は容易に変わるからです。しかし、ある組織が成功のために、特定の物事をしなければならない状況に追い込まれているなら、この組織がそれを必ず実行すると信じることができます。Googleはこういう状況にあると思いますし、私はこれを信じて入社しました。

●クラウドサービスにおける抽象化と、オープンソースによる抽象化

――クラウドサービスの魅力の1つは、さまざまな機能を抽象化して提供することです。抽象化してしまえば、ユーザーはあなたのサービスのAPIを使うのであり、その下で使っているのがオープンソースソフトウェアだろうが、プロプライエタリなソフトウェアだろうが、ユーザーには見えませんし、関係ありませんよね。

 非常に良いポイントだと思います。ある場合には、オープンソースソフトウェア自体が抽象化の機能を果たします。例えばコンテナやコンテナオーケストレーションがこれに当たります。

 Google社内や社外のさまざまな人々に、「どういう場合にオープンソース化すべきなのか」と頻繁に聞かれます。

 あるソフトウェアがもたらす抽象化が非常に強力で、そのため多くの人に採用してもらう必要があるとき、オープンソース化は、このソフトウェアを広げるための有効な手段になります。このことは、ソフトウェアをオープンソース化すべき、非常に良い理由となります。

 一方、サービスがあります。サービスはインフラそのものではありませんが、オープンなAPIを提供する必要があります。サービスにおけるオープンAPIは、非常に各分野特有です。Cloud Spannerの場合、データベースのクエリについてはSQL ANSI 2011が使えます。標準が存在する場合には、できるだけこれを採用すべきです。

 (標準が存在しない)新しい分野については、APIをドキュメント化し、知的財産権を主張しないことで、他の人々によるコピーを許すべきです。他がやっていないことなら、あなたが抽象化したものですから、そのAPIはポータブルではありません。しかし、誰か他の人がインタフェースをコピーして別の実装を生み出せば、話は変わってきます。

 あなたの指摘は正しいと思います。オープン戦略を語るとき、「何をコミットしているのか」「どれだけ余分なエンジニアリングを負担しようとしているのか」「参照実装を提供するつもりがあるか」「オープンソースにするのか、APIより下をオープンにすべきか、市場はそれを求めているか」、といったことを、ソフトウェア1つ1つについて熟考しなければなりません。

 現在に至るまで、こうしたことを考えた組織はありませんでした。オープンソース、オープンクラウド、オープンAPIを1つに融合したことで、Googleが初めて取り組むことになりました。

 この点で、私が頼りにしている方策の1つは、顧客諮問委員会です。顧客に「何が欲しいですか」と聞いています。現在、クラウドは第2の段階に入っており、マルチクラウドに興味を持つ組織が増えています。

●サーバレスコンピューティングとオープンソース

――サーバレスコンピューティングに関する戦略はどのようなものですか?

 大好きなトピックです。幾つかのことが言えます。

 サーバレスは現時点では、大部分がクラウドネイティブなサービス間の「接着剤」のような機能を果たしています。Node.jsをはじめとするオープンな開発言語を、関数中心の考え方で活用し、各クラウドサービス特有の抽象化された機能にアクセスします。AWS Lambdaを使うなら、Amazon S3やAmazon Red Shiftにアクセスするわけです。そのコードは別の環境に持っていっても機能しません。通常、このクラウドネイティブな統合を、別のクラウドで動かしたいとは思いませんので、一部を除いて問題はありません。

 もう1つの面白い議論は、「開発者が望む抽象化とは何なのか」ということです。関数に基づくサーバレスが、次のPaaSなのか。開発者がインフラを完全に考えなくてよくなる世界を本当に求めているなら、先ほどの議論に出たように、オープンソースによる抽象化が役立つ分野となり得ます。

 現在のサーバレスコンピューティング分野における主要オープンソースソフトウェアは、ほぼ全てがKubernetesを使っています。これを非常に興味深く感じています。開発者が関数のみによるプログラミングを本格的に始めるとしたら、デスクトップ環境からローカルのテスト環境、クラウドの本番環境まで、全て同じ環境が欲しいというニーズが出てくるからです。

 今は非常に初期の段階ですが、私の目標は、開発者が単一の共通な環境を活用できるようにしていくことです。その下でどんなスタックを使っていたとしても、関係がない。そうした世界を目指したいと思います。

最終更新:7/28(金) 7:55
@IT