FaaS だけじゃない Knative

本記事では、Kubernetes 上でサーバーレスワークロードを制御するソフトウェアである Knative を紹介します。
これまで名前だけは聞いたことはあるという方もいるかもしれませんが、実際に Knative で何ができるのか? どんな特徴があるのか? といった点は実際に触ってみないと十分な理解は得られません。そこで Knative で提供される "Serving", "Eventing" といったコンポーネントから Knative の理解を深めていきたいと思います。

Knative とは

Knative は 2018 年に Google 社によって発表されたオープンソースソフトウェアであり、IBM/Red Hat, SAP, VMware（当時は Pivotal 社）等がコミュニティに賛同しており、多くのコントリビューションがなされています。当初はコンテナイメージをビルドするための "Build", リクエストに応じて処理を受け付ける "Serving", イベントドリブンな処理を実現する "Eventing" といったコンポーネントがありました。後に、Build をベースとした CI/CD ツールとして Tekton が開発され、2019 年には Tekton への移行手順等が整備されるとともに Build は Deprecate となりました。

そして昨年の11月には v1.0.0 がリリースされ、Knative を構成するコンポーネントが同じライフサイクルでバージョン管理されるなど運営面も強化されました。これによりユーザーにとっては、コンポーネント間の互換性がバージョン毎に担保される等といったことが今後期待されます。

Knative は Kubernetes 上でサーバーレスワークロードのデプロイを簡略化するため Serving, Eventing といったリソースを定義することで、Deployment, Service, Ingress といった Kubernetes 標準のリソースを抽象化しており、ユーザーはわざわざ Pod を作成する、サービスを外部に公開するといった作業を意識することはありません。

サーバーレス処理を実現する "Serving"

Knative を構成する Serving ではその名の通りリクエストを受け付ける処理を担当し、HTTP リクエストを受け付けるための Route、Pod の構成情報を管理する Configuration、構成の変更履歴を管理する Revision といったリソースを管理します。

Serving は単体で動作することができ、リクエストを受け付けると指定したコンテナイメージから Pod を作成、ビジネスロジックに従った処理をしたのちクライアントに対しレスポンスを返します。

その際、リクエスト数（rps）、処理並列数（concurrency） といったメトリックを元に実際に処理を行う Pod 数をオートスケールすることができ、大きな特徴として Pod 数を 0～N でスケール可能な "Scale to Zero" と呼ばれる機能があります。そのため、数秒間リクエストが発生しなかった場合は Pod 数を 0 にし、初めてリクエストを受け取った際に改めて Pod を作成・処理を実施するといったサーバーレスの特性を生かした制御が可能となっています。

また、構成の変更履歴を Revision というリソースにて管理しており特定リビジョンにトラフィックを流すといったことも容易です。そのため徐々に新しいリビジョンにトラフィックを切り替える Canary Release のような戦略をとることもできます。

イベントのルーティングを行う "Eventing"

Eventing ではイベント駆動型アーキテクチャを実現するためのリソースを管理しており、イベントの受け渡しを行うための Broker、イベントを受け付け Broker に格納するための Source、Broker からイベントを取得し Sink に受け渡す Trigger、そして最終的なイベントの受け渡し先である Sink によって実装されます。

ここでいう "イベント" とは現実世界におけるなんらかの出来事であり、実際のシステムにおいては "ユーザー情報が更新された" や "AWS S3 上にファイルがアップロードされた" といった出来事を起点とします。

そのようなイベントデータを取得する Source においては、GitHub で発生したイベントデータ取得といった Pull 型の取得方法や Webhook のエンドポイントを用意し、Push 型でのイベントデータの取得を行う等、既にコミュニティや 3rd Party によって開発されているものが存在しており、ユーザーはそれらのカスタムリソースをインストールし必要なマニフェストを用意するだけで対象のイベントを取得することができます。

Broker はメッセージキューのように取得したイベントを格納するコンポーネントとなりデフォルトでは 、Knative 独自の Broker が使われていますが GCP Broker, Apache Kafka Broker, RabbitMQ Broker などの代替を利用することも可能です。

Trigger は、Broker からイベントを取得し指定した Sink に受け渡します。Trigger が Broker からイベントを取得する際は属性値のフィルターを設定することができるため例えば特定 Source からのイベントのみ Broker から取得するといった制御が可能になり Broker, Sink 間の無限ループやパイプラインの処理状態を管理することができます。

Sink は前述した通りイベントの最終的な受け渡し先であり、実際は Broker や Serving などが対象として作成されます。そのため Serving にて渡されたイベントデータを外部サービスに転送する、イベントデータを整形し Broker に再度格納するといった柔軟な処理が可能になります。

実際のユースケース

それでは Knative を利用したシステムとしてどのようなユースケースが考えられるでしょうか? ここでは Knative コミュニティで紹介されているいくつかのサンプルをご紹介したいと思います。

1つはストレージにアップロードされた画像の処理となります。S3 や GCS のようなオブジェクトストレージに画像がアップロードされた際に "ファイルがアップロードされた" というイベントを起点に Knative Eventing がイベントデータを受信し、Cloud Vision API にて画像が不適切な内容を含んでいないか判断します。その後、Trigger が不適切か否かという属性値で処理を分岐させ、もし不適切な内容であれば対象のファイルを隔離する、問題が無ければ解析結果から画像にメタデータを付与するといった複雑な処理を実現します。

https://github.com/akashrv/knative-samples/blob/master/docs/image-processing.md

2つ目は BigQuery を用いたデータのパイプライン処理になります。こちらの例では Cloud Scheduler によって定期的なイベントを発生させ、最初の Service である "Query Runner" は受け取ったイベントを起点に、BigQuery で公開されている Covid-19 のデータセットに対しクエリを発行します。その後、クエリ処理が完了したことを確認すると "Chart Creator" と呼ばれる別 Service にイベントを引き渡しクエリ結果のデータセットからグラフを作成しバケットに格納します。最後の Service である "Notifier" では処理が完了したというイベントを Cloud Storage から受け取ったら SendGrid のサービス経由でユーザーに完了通知を送信します。

https://github.com/meteatamel/knative-tutorial/blob/master/docs/bigquery-processing-pipeline.md

まとめ

これまで Kubernetes 上でサーバーレスワークロードを管理するための Knative について主要コンポーネントである "Serving", "Eventing" の2つを取り上げその特徴をご紹介しました。また、どのようなユースケース存在するのかコミュニティのサンプルを元に説明させていただきました。

Knative と聞くと多くの人は Knative = サーバーレス、つまり AWS Lambda みたいなもの? と捉えがちかもしれませんが、Lambda のような FaaS 機能を提供するのは Knative の一部の機能（Serving）であり、ユースケースで紹介したデータパイプラインのようなイベント駆動型のシステムも Eventing により実現可能となります。Knative 自体は昨年 v1.0.0 に到達したばかりであり、一部の機能に関してはまだ Alpha, Beta ではありますが、Kubernetes の複雑性を抽象化することで手軽にサーバーレス, イベント駆動型のアーキテクチャを実現できる点は魅力的といえるでしょう。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。