Knativeが目指すもの、考え方を見てみよう

初めてKnativeを触ると、これServerlessなのかな…PaaS…FaaS…？と感じることがありました。このモヤモヤをすっきりさせるべく、コアコンポーネントの1つであるKnative Servingが何をゴールとしているのか、どういう思想なのかを見てみます。

Knative Servingのゴール、対象とするワークロードは何か

motivation.mdに、Servingがどのようなゴールを目指しているのか、対象としてるワークロードは何か、ということが書かれています。これを知ることで、なぜそのような挙動となるのかを理解する助けになります。

まずServingプロジェクトのゴールですが、「サーバーレスなワークロードのための、コモンツールキットとAPIフレームワークを提供すること」と書かれています。そして、Servingが定義するサーバーレスワークロードが以下の3つです。

1. ステートレス
2. プロセスのスケールアウトモデルが適用可能
3. 主にアプリケーションレベル（L7、例えばHTTP）からリクエストされるトラフィックによって駆動

Kubernetesはこのワークロードをサポートする機能（DeploymentやService）を持っています。Knativeはさらに上位レイヤの機能を提供することで開発者がリッチな体験をできるようにする、ということのようですね。ここまで、ゴールとワークロードを見てみると、「PaaS」「FaaS」というキーワードが登場していません。でも、触ってみるとPaaSっぽいな…と感じたりします。ファンクションも扱える…Knativeはいったい何なのでしょうか？

重要なのはワークロードの3つめである、「クライアントからのリクエストによって駆動する」という点じゃないか、と考えました。ここではKnative上で動くコードがRailsやHTTPサーバーのような従来のアプリケーションなのか、FaaSで扱われるファンクションなのかは区別していません。ここを抽象化することで、どちらも使えるようになっています。逆に、これによってServerless…？PaaSなのかFaaSなのか…？と、わかりにくいと感じたのかもしれません。

Knative Servingの考え方とFastContainer

Knativeのサンプルを触っていた時、リクエストをしばらく投げないでいたらデプロイしたアプリケーションのPodが勝手に終了して、1台もいなくなってしまいびっくりした。Knativeを触った人なら同じ体験があるかもしれません。この挙動について、おいおいアプリケーションが動いてないのにユーザーからのリクエストをどう処理するのだ！と疑問に思っても、モチベーション（ゴール、ワークロード）を知っていると理解できます。

要は、1プロセスも動いていない状態だとしても、ユーザーからリクエストが届いたらそれをトリガーとして起動すればよい、という考え方なんですね（最小起動台数のようなものも設定できるのじゃないかなあとは思っています）。これはFaaSではなじみのある考え方ですが、従来のアプリケーションではそうではないので、混乱するのではないでしょうか。

僕が割とすんなり理解できたのはゴールとワークロードを読んだから、というのもありますが、FastContainerアーキテクチャを知っていたから、というのも大きいと思います。このアーキテクチャも、「リクエスト単位でスケールアウト」「一定時間経過・リクエスト処理がなければコンテナを停止」という、Servingと似た思想を持っています。

Knativeという新しいソフトウェアが登場した時、そのアーキテクチャについて既にモデル化されていたことで割とすんなり理解できました。コンテナオーケストレーションツールとしてデファクトスタンダードとなりつつあるKubernetes上に同じようなアーキテクチャで作られたことから、このアーキテクチャが今後重要になる可能性がある、といえるかもしれません。

Knativeのゴール、対象とするワークロード、考え方について見てきましたが、触り始めたばかりの時は既存の概念に引きずられて見てしまっていたなあと実感しました。Serverlessについてもあまり追えていないので、そちらもキャッチアップすることで、さらにKnativeが目指すものが見えてくるのではないか、と考えています。なお次はより詳細について、フローやServing内部のコンポーネントを見ていく予定です。