今年のQCon San Francisco 2019カンファレンスで、講演者のJames Ward、Ryan Knight両氏が、Knativeフレームワークを使用したサーバレステクノロジに関するワークショップを開催した。James Ward氏はRay Tsang氏とともに、QCon New York 2019カンファレンスでも同じワークショップを実施している。InfoQは氏らに、Knativeについて詳しく聞いた。
Kubernetesは、コンテナベースのアプリケーションを管理およびオーケストレーションする方法として、一般的な選択肢になりつつある。サービス対サービスのコミュニケーションや監視には、Istioに代表されるサービスメッシュテクノロジが使用できる。この２つ、すなわちKubernetesとIstioの上に構築されたプラットフォームであるKnativeを導入することで、サーバレスアーキテクチャを用いたワークロードの構築、デプロイ、管理が可能になる。
InfoQはWard、Tsang両氏と、クラウドネイティブアプリケーション開発におけるサーバレスの役割について論じるとともに、Knativeがそれらの目標に対してどのように役立つのかを聞いた。
InfoQ: Knativeフレームワークとはどのようなものか、Kubernetesコンテナ管理プラットフォームにどのようにフィットするのか、読者に説明して頂けますか？
James Ward/Ray Tsang: KnativeはKubernetes上のレイヤで、アプリをソースから構築するためのコンポーネント、HTTP経由でのアプリのサービス、パブリッシャ/サブスクライバ間のイベントのルーティングといった、サーバレスプラットフォームのビルディングブロックを提供するものです。
スケール・トゥ・ゼロ、クラッシュ・リスタート、ロードバランシングなど、Kubernetesの機能を強化すると同時に、Google Cloud上のフルマネージド、Google Kubernetes Engine(GKE)上、あるいは独自に構築したKubernetesクラスタなど、どのような場所でもサーバレスワークロードの実行を可能にします。最初はGoogle Cloud Runなどのプラットフォームで手軽にスタートして、後にGKE上のCloud Runに移行したり、あるいは自身のKubernetesクラスタから始めて、将来的にCloud Runにマイグレーションすることも簡単です。
元々Googleで開発されたKnativeはオープンソースで、詳細はWebサイトで確認することができます。
InfoQ: ユースケースに関してですが、マイクロサービスやモノリスアプリといった他のアーキテクチャと比較した場合、サーバレスベースのソリューションを使うべき場合、使うべきでない場合というのは、どのようなものでしょう？
Ward/Tsang: サーバレスは、必要に応じてスケールアップやダウンが可能な運用モデルです。クラウド環境であれば、これによって完全に実使用量のみをベースとした費用負担が可能になりますし、自己管理の環境下ならば、基盤となるサーバリソースを共有プールに返却して他の目的に使用することができます。
サーバレスはマイクロサービスにもモノリシックなアーキテクチャにも適用可能ですが、アプリが迅速に起動してグローバル状態を使用しないサーバレスは、ほとんどのモノリスには不向きでしょう。
InfoQ: ワークショップではCNCF Buildpacksが話題になっていましたが、このBuildpacksがサーバレスアプリケーション一般、あるいは特にKnativeベースのアプリケーションにとってどのように役に立つのか、説明して頂けますか？
Ward/Tsang: Tektonオープンソースプロジェクト(Githubレポジトリ)は、ソースをKnative上で動作可能なように変換するための補完的なものです。TektonはKubernetes上で動作して、ビルドやCI/COパイプラインのためにオンデマンドでリソースをアロケートするサーバレスエクスペリエンスを提供します。
CNCF Buildpacksは、プロジェクトタイプを検出してコンテナイメージ生成のためのビルドを実行するための、標準的な環境です。MavenやGradle(Javaプロジェクト用)、Python、Ruby、Go、Nodeなどのツール用のビルドパックが用意されています。Tektonのカタログを見れば、ソースをKnative内で実行可能なコンテナイメージに簡単に変換できるようなBuildpackサポートが見つかるでしょう。
InfoQ: 同じアプリケーションやユースケースで、マイクロサービスとKnative関数を併用することは可能なのでしょうか？
Ward/Tsang: Knativeの実行可能なデプロイメントユニットはすべてコンテナイメージですから、最終的にはKubernetesポッドとして動作します。実行可能なユニット(invokable)とは、HTTP経由、およびHTTP経由でCloud Eventを送信するイベントを受け取るアプリです。ですからWeb HTTP要求、REST、Cloud Eventのすべてを、ひとつのコンテナイメージで処理することができるのです。
InfoQ: サービスメッシュテクノロジがここ最近の注目を集めていますが、サービスメッシュベースのアーキテクチャにおいて、Knativeアプリケーションはどのような動作が可能なのでしょうか？
Ward/Tsang: 現時点のKnativeは、IstioとKubernetes上に構築されています。ですからKnativeアプリケーションは自動的に、Istioサービスメッシュ環境内で動作することになります。つまりこれは、分散トレーシングサンプリングやメトリクス監視といった、Istioのメリットをすべて自動的に受け継いでいる、ということになります。Knative内でトラフィック分割を設定すれば、Istioでもトラフィック分割をサポートするように、対応するコンフィギュレーションが自動生成されます。
InfoQ: ワークショップではCloud Eventにも触れていましたが、サーバレスアプリケーションではCloud Eventをどのように利用できるのでしょうか？
Ward/Tsang: Cloud EventはRESTfulなイベントペイロードのパッケージングを対象とした、新しいCNCF(Cloud Native Computing Foundation)の仕様です。マイクロサービスやファンクション・アズ・ア・サービスのフレームワークは、入力メッセージの解析を容易にするため、ルーティング用のメタデータを提供するために、Cloud Eventをサポートし始めています。
KnativeはEventingコンポーネントで、バックサービスにCloud Eventを送信することでCloud Eventをサポートしています。Cloud Eventを処理するサービスからの応答もCloud Eventであれば、Eventingシステムによってさらにルーティングが行われます。イベントのコンシューマは、KnativeのServingコンポーネントにおいてHTTP要求を処理するようなサービスです。これはつまり、他のサービスと同じようなスケールアップやスケールダウン(0サイズまで)が可能だということです。
InfoQ: Knativeベースのアプリケーションを開発する場合、どのようなツールが使用できるのでしょうか？
Ward/Tsang: KnativeはどのようなDockerコンテナイメージをKubernetes上で実行できますが、これらのイメージはローカルでの開発やテスト用にDockerで直接実行することも可能なのです。ですから開発時には、実際にはKnativeを使う必要はありません。また、KnativeはKubernetesのエクステンションなので、Kubernetesで動作するツールはKnativeでも動作します。従って、監視用のPrometheusやロギングのFluentd、ログ検索のKibanaなど、多くのツールを使用することができます。
InfoQ: サーバレスやKnativeテクノロジを学びたいと願う読者に対して、推奨できるベストプラクティスはありますか？何を考慮し、何を回避するべきでしょうか？
Ward/Tsang: テクノロジとそのユースケース、つまり、どのような時に使うべきで、どのような時は使うべきでないのかを学んでください。KnativeはIstioやKubernetesといったテクノロジの上でに位置するため、高レベルも高くなります。Knativeを運用するには、下位層を十分理解する必要があります。そうすれば、プラットフォーム上の問題があった場合でも、どこを見て、何を修正すべきかが分かるはずです。