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）に比べて優れているかどうか。大局的に言えば、ユーザーはそんなことを気にしない。やり方を統一すれば、全てのツールやスクリプトが自動的にクロスプラットフォーム対応できる。
Kubernetesは、コンテナのデプロイに関するアクションやオートスケーリングに関する多くの部分で、事実上の統一を実現した。だが、どちらかと言えば実装レベルにとどまっている。
Istioはその自然な延長線上にある。サービスそのもの、すなわちAPIエンドポイント自体を対象とし、それぞれにディスクリプションを与えて、お互いに呼び出す際の認証などを提供できる。Kubernetesよりも1つ上のレイヤーで、サービスに立ち入った詳細なコンフィグができる。
誰もがサービスエンドポイントを持ち、認証し、ロギングを行っている。こうした共通の機能については、やり方を統一すべきだ。Istio自体はロギングをしない。ログサービスを呼び出すだけだ。呼び出す相手はGCPのログサービスでも、あなたが書いたログソフトウェアでもいい。コンフィグさえすれば、後でより良いサービスを選んで使える。あなたのプログラムはどんなログサービスを使うかを知る必要はない。運用担当者にしても、ログソフトウェアを変える際に大きな設定変更をする必要はない。ロギングのためのプラグインインタフェースは標準化されているためだ。
いずれにしても重要なのは、例えばセキュリティポリシーについて、表現方法のみを標準化すること。そして実装については、好きなものを選べるようにすることだ。
例えばアカウント情報をActive Directoryに持っているなら、プラグインを通じてActive Directoryを使えばいい。Google Cloud Directoryを使ってもいい。各認証システムに独自の作業をする必要はない。どれを使う場合でも、コンフィグは同じだ。
――関連する質問として、今後IstioとApigeeの関係はどうなっていくのだろうか。
Apigeeは、Istioプロキシのアップグレード版だと考えてもらえばいい。どれかのサービスエンドポイントについて、Istioの代わりにApigeeを使いたいと思ったら、ボタンをクリックするだけですぐに切り替えられる。使い勝手としては統合されている。
ユーザーは、一般的なIstioエンドポイントについてはIstioプロキシ（注：すなわちEnvoy）を適用すればいい。Apigeeは機能が豊富な代わりに重量級であり、全てのエンドポイントに適用するわけにはいかない。だが、ビジネスクリティカルであり、外部に提供するためにきめ細かな制御や機能が必要なエンドポイントについては、Apigeeを選べばいい。ここで重要なのは、システムを構築する際に、Apigeeを使うかの選択をしなくていいということだ。後で必要に応じて切り替えればいい。
――では、FaaSについて聞くが、GCPでは、ファンクションで複雑なアプリケーションを構築するようなユースケースに対応したいのか。直接的に聞くと、AWS Step Functionsに相当するようなサービスプロダクトを提供しようとしているのか。
それはいい質問だ。
まず、（Step Functionsのような機能が将来求められるからこそ、）FaaSに関しても標準化が必要だ。共通のAPIについて合意ができれば、全ての主要プレイヤーにおけるサービスや製品に対し、同一の機能を共通に適用できるようになる。
また、AWS Step Functionsは非常にハイレベルなツールとして、数十、数百のファンクションを管理することを目的としている。ただし、同様なことを実現するアプローチは、他にも多数存在する。
例えばGoogle App Engineはその一つだ。App Engineはハンドラの集合体であり、これをまとめ上げてアプリケーションの構築に使える。しかし、FaaSにおけるファンクションと同様に、それぞれのハンドラは独立している。本質的に、App Engineは非常にイベントドリブンだ。
私は何が正解なのか、（現時点では）分からない。だが、ファンクションを管理できるようにする何かが必要であることは明らかだ。例えば「ストレージバケットを作成して、これに対するイベントが発生したときに最小限の作業を行い、このプロセスが消える」といった簡単な処理ではなく、100にも上るようなハンドラが相互につなぎ合わされたイベントベースのシステムを構築した場合、（システムの中で）何が起こっているのかを理解することがとても難しくなる。Step Functionsにしても、何が起こっているのかを把握することは簡単ではない。
もしかしたら、良いプログラミングプラクティスが求められるということなのかもしれない。オブジェクト指向プログラミングでは、次第に人々が良いプログラムを書くためのプログラミングパターンを理解するようになった。ファンクションにおけるプログラミングパターンとはどういうものなのか。やるべきこと、やるべきでないことの双方について、パターンが確立される必要があるのだろう。
とはいえ、「非常に軽量なステップで、イベントドリブンなシステムを作る」というファンクションの考え方は、今後長きにわたって生き続けるべき、優れたコンセプトだと思う。
0 件のコメント:
コメントを投稿