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

　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にしても、何が起こっているのかを把握することは簡単ではない。

　もしかしたら、良いプログラミングプラクティスが求められるということなのかもしれない。オブジェクト指向プログラミングでは、次第に人々が良いプログラムを書くためのプログラミングパターンを理解するようになった。ファンクションにおけるプログラミングパターンとはどういうものなのか。やるべきこと、やるべきでないことの双方について、パターンが確立される必要があるのだろう。

　とはいえ、「非常に軽量なステップで、イベントドリブンなシステムを作る」というファンクションの考え方は、今後長きにわたって生き続けるべき、優れたコンセプトだと思う。