単独インタビュー：Googleのウルス・ヘルツル氏に聞いた、「IstioやKnativeで目指すのはクラウドのアンロックイン」 (1/2)

Googleのウルス・ヘルツル氏は、Google CloudのIstioやKnativeに関する取り組みの長期的な目標が、複数クラウド間のAPI標準化にあると話している。

Googleテクニカルインフラストラクチャ担当シニアバイスプレジデント／Googleフェロー、ウルス・ヘルツル氏

　Googleのデータセンターインフラおよび開発プロセスの構築に貢献してきた同社テクニカルインフラストラクチャ担当シニアバイスプレジデント、ウルス・ヘルツル（Urs Hölzle）氏は、近年同社のクラウドコンピューティングプラットフォーム、Google Cloud Platform（GCP）を支える活動への関わりを強めている。

　＠ITでは、「クラウドを支える技術 ―データセンターサイズのマシン設計法入門」（Morgan＆Claypool Publishers／2013年）の著者の一人としても知られる同氏に単独インタビューし、Google CloudがGoogle Cloud Next ’18で発表した、Istio、Knative、Cloud Services Platformなどへの取り組みについて聞いた。

　ヘルツル氏は、インタビューの中で、IstioやKnativeの目標が、複数クラウド間のAPI標準化にあると答えている。Cloud Native Computing Foundation（CNCF）における活動との関連でも、このコメントは注目される。

アプリケーション運用に共通の手法を持ち込みたい

――まず、Cloud Services Platformとは結局、プロダクトなのか、ビジョンなのか、フレームワークなのか、コンセプトなのかを聞きたい。

　Cloud Services Platformは、Istio、Knativeなどのオープンソースソフトウェア群と対になるGoogle Cloud Platform上のサービスだ。顧客はまず、これらのソフトウェア――IstioやKnativeを、GCP以外のパブリッククラウドやオンプレミスなど、どこでも動かし、活用できる。一方、GCPではこれらをはじめとしたソフトウェアを統合した、利用しやすい環境を提供する。これがCloud Services Platformだ。

　ここで最も重要な要素はIstioだ。1年以上開発を進めてきており、本番運用に使えるものになったという判断から、バージョン1.0のリリースに至った。実際にeBayなど多数の組織で、本番運用が始まっている。そこでGoogle Cloudでは、これを（マルチクラウドのアプリケーション運用技術として）推進していく。

――しばらく前、「Istioはスケーリングが不十分」と言っている人がいた。

　1年前くらいなら、そうした言われ方もされていた（が、その後改善された）。また、現在においても、非常に高いパフォーマンスを求められるアプリケーションについては当てはまるだろう。マイクロサービス単位でプロキシを導入するので、パフォーマンス上のオーバーヘッドは避けられない。

　だが、そうした場合でも、ハードウェアの負荷分散製品を使って対応できる。こうした製品に入れ替えたからといって、ユーザーにとってはAPIや構成内容が変わることはない。負荷分散製品は舞台裏でプログラムされるからだ。ユーザーは存在を知る必要がない。従って、ハイパフォーマンスアプリケーションにIstioが適用される日も遠くはないと考えている。

　とはいえ、Istio 1.0では一般的なITアプリケーションを対象としている。こうしたアプリケーションの運用管理に大きなコストが掛かっていることが多いからだ。

――人々は仮想マシンからコンテナ、PaaS、Functions as a Service（FaaS）まで、さまざまなレベルでアプリケーションやマイクロサービスコンポーネントを開発・運用する。こうした多様な抽象化レベルにまたがる統合的な管理を目指そうとしているのか。

　もちろんだ。さまざまなものを統一的に運用できるようにすることが、私たちの目標だ。仮想マシン、コンテナ、ファンクション。これらの実装は大きく異なる。だからといって、認証、ディスカバリ、ロギングなどのやり方が違わなければならない理由はない。同一であるべきだ。例え昔に書かれたMS-DOSベースのバイナリであっても、コンテナ化し、Istioプロキシを適用すれば、このバイナリがモダンなマイクロサービスとして使えるようになる。言いたいのは、コードを基本的には書き直すことなく、クラウドネイティブなサービスのエコシステムに組み込めるということだ。そしてこのエコシステムは、共通の手法、ツール、コンフィグを通じて運用管理ができる。

　最終的には、Google Cloud Functions、Google Kubernetes Engine、Google App Engineなどの上の全てのアプリケーションがIstioのエンドポイントとして同じように見え、管理できなければならない。各アプリケーションの実装が変わっても、呼び出す側はそのことを知る必要がない。システム運用担当者も知らなくていい。こうなれば、大幅なシンプル化ができる。まだそこまでは実現できていないが、私たちの目標であることは確かだ。

　言い直すと、サービスは仮想マシン、ファンクションなど、多様な実装方法によって構築される。しかし、アクセス権限管理やサービス間の認証をはじめとした運用管理については、標準化されなければならない。標準化さえできれば、そこにエコシステムが生まれ、ツールから実践ノウハウ、トレーニングまでを共通化できる。将来、新しいアプリケーション開発・運用プラットフォーム技術が登場したとしても、運用担当者はそれをことさら意識する必要がない。さらに、どこで動かしても、運用のやり方は同じだ。

――では、サーバレスでは既存のサービスがあるにもかかわらず、Knativeという新たなソフトウェアを始めたのはなぜか。

　既存サービスとの互換性は今後確保していくことになる。私たちの実装はおそらくKnativeに移行していくことになるだろう。なぜなら、大局的に考えれば、実装は大した問題ではないからだ。Kubernetes上に実装すれば、どこでも動かせるようになる。

　（クラウドベンダーは、）実装の優劣を競うことはできる。だが、運用APIは統一されるべきだ。このため、運用APIはオープンソースでなければならない。これを実現する取り組みの1つがKnativeだ。

　現在の状況は、Kubernetesをオープンソース化した頃に似ている。当時少なくとも1ダース以上のコンテナオーケストレーションシステムがあったが、その後Kubernetesが事実上の標準になった。「どれ」が勝つかよりも、どれかが「事実上の標準になる」ことが重要だ。

　私たちはKnativeについて、業界内の有力パートナーと協力し（筆者注：オープンソースプロジェクト開始時点では、Googleの他にPivotal、IBM、Red Hat、Cisco Systemsが参加している）、サーバレスをどのように見せるかについてのコンセンサスを醸成しようとしている。繰り返すが、Knativeにおける私たちの目標は、実装ごとに独自であってはならないものを統一することだ。

――今の話を敷衍（ふえん）すると、サーバレスだけでなく、クラウド全般について同じことが言えるということなのか。つまり、「現在、さまざまなクラウドが差別化すべきでないところで異なっており、これが（柔らかな）ロックインにつながっている。こうした状況を変える」ということなのか。

　クラウドは未来永劫、それぞれが異なるものであり続ける。GCPのプロダクトでいえば、BigQueryやCloud Spannerはそれぞれがユニークな機能を果たしており、オープンソースではない。こうしたプロダクトで差別化を図っていくのは当然のことだ。私たちが注目しているのは、「クラウドにおけるAPIの80％が、同じような機能を果たすにもかかわらず、異なっている」という事実だ。

　例えば、GCPにおける仮想マシンの起動方法がAmazon Web Services（AWS）に比べて優れているかどうか。大局的に言えば、ユーザーはそんなことを気にしない。やり方を統一すれば、全てのツールやスクリプトが自動的にクロスプラットフォーム対応できる。