Cloud Native Days Tokyo 2019：IBMのDoug Davis氏がサーバーレスの未来を語る

CloudNative Days Tokyo 2019に合わせて来日したIBMのエンジニア、Doug Davis氏のインタビューをお届けする。Davis氏はIBMにおいてはKnativeをリードする主要なエンジニアであるが、同時にCNCFのサーバーレスワーキンググループ及びCloud Eventsワーキンググループの共同Chairという肩書も持っている。つまりCNCFにおいて、サーバーレスとサーバーレスに必須なイベント処理をいかに実装するのかを決定する大きな役割を担っていると言える。

自己紹介をお願いします。

IBMでデベロッパーアドボカシーに所属し、オープンソースソフトウェアの開発に関わっています。今はKnativeの開発をIBMの側からリードしています。またCNCFでは、サーバーレスワーキンググループとCloud Eventsのワーキンググループ（WG）の共同Chairをやっています。

IBMのDoug Davis氏

サーバーレスとCloud Eventsは同じグループのエンジニアが担当していると聞きましたが。

実際には同じエンジニアが参加していますが、組織としては別になっています。サーバーレスWGの仕事の一つに、CNCFとしてどのプロジェクトを支援するのかを調査するということがありました。その一環として、サーバーレスに関するホワイトペーパーを書くというのが具体的な活動だったのです。

その時にWGのメンバーと考えていたのは、サーバーレスがさまざまなオープンソースプロジェクトやパブリッククラウドのサービスとして実装されていくと、そのファンクションを実行するためのきっかけになるイベントの標準を作らないといけないのではないか？　そして相互運用性を保証する仕様を作らないといけないのではないか？　という結論にたどり着いたのです。

そこで、サーバーレスWGのエンジニアがホワイトペーパーを書くという仕事と並行して、イベントに関する仕様を決めるということを行っていたのです。しかし何度も言いますが、サーバーレスWGとCloud Eventsは別のプロジェクトとして存在しています。

Cloud Eventsはサーバーレスを実装する際に重要なパーツになると思いますが、あまり注目されていないようです。Cloud Eventsが目指すところは何ですか？

誤解されないようにしたいのですが、Cloud EventsはWeb上の共通のイベントフォーマットではないということです。イベントというのは、さまざまな種類や形態が存在するはずです。Cloud Eventsの目的は、それらを網羅することではないのです。例えば、私があなたにHTTPでイベントを送りたいと言う状況があったとします。それはGitHubのコミットかもしれませんし、何かPushするメッセージかもしれません。しかしメッセージそのものはHTTPのヘッダーを持ち、その後にボディーパートが来て、その中身はビジネスロジックによってさまざまな内容になるはずです。そのメッセージをどう処理するのか、どのようにルーティングするのか、そういうことを最低限伝えるためにどういうことをしなければいけないのか？　このようなことを考えると、メッセージのボディには手を加えないということが最善のはずです。ですからHTTPのヘッダーに誰からそれが送られてきたのかというソース、そしてそれが何に関するものなのかということを示すタイプ、そしてユニークなID、それだけを追加する形にしたのです。

他にもオプションとしてタイムスタンプなどがありますが、とにかくシンプルにしてそれをどうやってルーティングするのか、フィルタリングするのか。これについては、そのメッセージを受け取るアプリケーション側に任せるという発想なのです。これはHTTPが最初に出てきた時とかなり近い発想です。HTTPは、とてもシンプルなコマンドとURLで構成されていました。最近はだいぶ複雑ですが、それでも発想はシンプルです。HTTPを受け取ってどう処理するのかは、Webサーバー側に任されています。Cloud Eventsは、HTTPを大いに参考にしています。

それに関してはサーバーレスWGやCloud Eventsに参加しているすべてのベンダーも賛同していると？

そうです。IBMを始めとしてGoogle、Red Hat、AWS、VMware、Microsoftなどから参加しているエンジニアは、この考え方に賛同しています。そして仕様はもうすぐリリースできると思いますが、まだ0.1といったところですね。Microsoftは最も早くこの仕様に賛同して実装を始めてくれたベンダーですが、他のベンダーは最終的に仕様が固まるまで実装は待つという姿勢ですね。

あまり派手ではないですが、業界としてこういう仕様を決めてそれにベンダーが従って実装するというのは重要なことですね。

そうですね、あまりセクシーな仕事ではないですが、それがあるということが大事なのです（笑）。

ではサーバーレスの話をしましょう。上海のKubeConのサーバーレスWGのセッションで、あなたが参加者に質問をしたことを覚えています。サーバーレスを使っている人は手を挙げて、という質問に中国のエンジニアが「インスタンスがゼロにならないから私が実装したものはサーバーレスではないのでは？　それはサーバーレスと呼んで良いのですか？」というコメントがありました。サーバーレスを厳密に定義しようとする人がいることは事実ですが、それに関してコメントはありますか？

これはIBMのコメントではなく私、Doug Davisのコメントとして欲しいのですが、そのようなジャンル決め、カテゴリー決めを厳密に行うことにあまり意味はないのではないかと思っています。私がよりフォーカスしたいのは「顧客が何をしたいのか？」「何を実現したいのか？」という点です。

カテゴリー決めの欠点は、とかくそのカテゴリーにロックインした発想になりがちであるという点です。つまり「これをやったらサーバーレスではなくなってしまう」というように、発想がそのカテゴリー内に収まらないことを気にし過ぎてしまうということがあるからですね。まだ未成熟なテクノロジーをカテゴリーに当てはめてしまうのは良くないと思います。

例えば、Cloud Foundryはグレートなサーバーレスプラットフォームになれたと思いますし、グレートなDockerコンテナのプラットフォームにもなれたはずです。しかし、そうはならなかった。その理由は、彼らがあまりにPaaSにこだわり過ぎたからではないか。私はそのように思っています。私がKnativeを素晴らしいと思うのは、その自由さですね。サーバーレスとして使うこともできますし、デーモンのように永続的なプロセスを実行するためにも使えます。

ではKnativeの話をしましょう。Knativeの目指すところはどこですか？

Knativeはさきほども話したようにサーバーレスとしても使えますし、OpenWhiskのプラットフォームとしても使えますし、Cloud Foundryのベースのプラットフォームとしても使えるのです。Kubernetesをより簡単に使おうと思った時に、最初に考慮すべきプラットフォームがKnativeになることを望んでいます。

つまり、より高度で複雑な使い方をしたい時はKubernetesのCLIを使えば良いですが、もっと一般的な使い方をするのであれば、Knativeが最善の選択というようになることですね。コミュニティの中にはさまざまな議論があって、Knativeがどんどん機能を拡張するべきという声もあります。それについては技術的にできないということではなく、コントリビューションを行っているエンジニアである私達が、そうなることをポリシーとして許可していないというだけのことなのです。つまり技術的にKubernetesのKubectlと同じことをKnativeにさせることは可能ですが、ポリシーとしてそれを行っていないということですね。

他にも、実際にはKnativeができないということはあります。例えば、Kubernetesでは一つのPodに多くのコンテナを入れることは可能ですが、Knativeの初期状態では一つのPodには一つのコンテナしか入れられないようになっています。後からそれを変更することは可能ですが、それはそういう仕様にしたわけです。他にもコミュニティの中には、Knativeの使い方をもっと強制的に定めるほうが良いという人もいますが、それに関しては推薦するといった程度に収めたいと思っています。なぜなら、ユーザーはツールをさまざまな用途に使いたいということが自然だからと思っているからですね。

個人的には、Kubernetesの機能の95％はKnativeで実装できることを目指しています。残りの5％については、非常に高度で複雑、一般的ではない使い方としてKubernetesを直接使うというようになれば良いかなと思っています。それが私の目指すゴールですね。

サーバーレス、Knativeにとってのチャレンジはなんですか？

どのようにサーバーレスを適用していくか？　という部分の啓蒙ですね。多くのエンジニアはモノリシックなアプリケーションをコンテナ化して、さらにその先でマイクロサービス化しようとしています。そのマイクロサービスの部分をサーバーレスにして欲しいと思っていますが、多くのエンジニアはモノリシックなものをどうやって分解していくのか？　そしてそれを運用していくのか？　この部分についてまだ経験がないのです。つまりこれまでは一つのアプリケーションだったものを、コンテナ化、マイクロサービス化することで1ダース程度のプロセスに分解したとします。そしてその先にサーバーレスになれば、50や60というもっと細かいプロセス、ファンクションを運用する必要があるわけです。つまり運用そのものがまったく変わってしまいます。それをリスクと捉えるエンジニアは、少なくないでしょう。

もう一つは、モノリシックなアプリケーションをいきなりマイクロサービス化するのは危険だということですね。多くの保守的なエンジニアは、フローチャートのような発想でアプリケーションを考えています。それをいきなり分解しようとしてもうまくいきません。サイズに関係なく、ユーティリティとして使える部分の機能を切り出して、分解するという発想を少しずつ進めていくしかありません。そのユーティリティはクラスライブラリ程度のサイズかもしれませんし、あるビジネスロジックそのものの大きなものかもしれません。いずれにせよ、他のアプリケーションから使える共通の部分を切り出して使う。それを繰り返すことが重要です。大きなモノリシックのアプリケーションを、一度に分解するのはとても危険はやり方だと思います。サーバーレスの実装のためにはこのような考え方が必要であるというエンジニアの理解が広まることを望んでいます。

IBMとKnativeの関係

Davis氏は、上海のKubeConでのWGセッションの質問の際にも「あぁ、あなたは最前列にいましたよね。覚えていますよ」とコメントし、PaaSなどのカテゴリーにこだわることの欠点を、Cloud Foundryを例に挙げて説明してくれた。カテゴリーにこだわることで、Knativeがサーバーレスだけのプラットフォームとして認識されるよりも、よりジェネリックなプラットフォームとして成長させたいという強い意志を感じるインタビューとなった。Cloud Eventsのスペックのリリースも近々予定されており、2019年11月のサンディエゴでのKubeConでは、より多くのニュースが発表されるだろう。今から楽しみである。