Kubernetes・Serverlessとの出会いと、Knative入門

入門 Knative ～KubernetesとServerlessとの出会い～

杉田寿憲氏（以下、杉田）：『入門 Knative ～KubernetesとServerlessとの出会い～』というタイトルでお話しさせていただきます。この資料は#serverlesstokyoのハッシュタグで流してあります。途中、細かい図も出てくるので、よかったら手元のほうでも見てください。

まず自己紹介からしますと、杉田寿憲といいます。

toshi0607というアカウントでTwitterやGitHubをやっているので、よろしくお願いします。

メルペイという決済の会社で、バックエンドのエンジニアをやっています。Serverlessの技術がすごく好きで『GoとSAMで学ぶAWS Lambda』という本を書いたり、Serverless関連のOSSにコントリビューションしたりして、ふだん活動しています。

GoとSAMで学ぶAWS Lambda (技術の泉シリーズ（NextPublishing）)

今日は、ServerlessやKubernetesとの出会い、Knativeの概要、その構成などについて、順番にお話しさせていただきます。

Serverlesとの出会い

まず、僕とServerlessとの出会いについて話します。こちらは、AWS Lambdaを前職で導入したというお話です。

僕はもともとWindowsのアプリを開発していて、サーバーのほうも開発していたのですが、そのWindowsアプリのLogをzipファイルに固めてサーバーに送信する際の、パフォーマンスチューニングとしてAWS Lambdaを導入しました。

zipに固めたファイルをAmazon S3のバケットにアップロードして、そのイベントをもってAWS Lambdaを起動して、別のS3バケットに展開するという、よくある使い方をしていました。

WindowsアプリのほうをC#で書いていたので、LambdaもC#で書いてリリースしました。.NET core 1.0を実行環境に指定していたのですが、Lambdaを本番環境にリリースした2日後に.NET core 2.0がサポートされ始めたり、Goがサポートされたりして、けっこうびっくりしたこともご愛嬌という感じですね。

Serverlessを使ってみて、プロビジョニングをそこまで気にしなくていいことや、サーバー自体のメンテナンスはプロバイダーに任せられる、実行時のみサーバーのリソースを使用できる、負荷に応じてスケールできる、イベントドリブンな非同期処理を実行できるということをすごく便利に感じました。

当時は今以上にインフラの知識がなかったのですが、そういう自分にとっては、ちょっとした設定で、こんなにいろいろ整った状態で機能やサービスを世に出せるということに、すごく衝撃を受けた思い出があります。

Kubernetesとの出会い

時は流れて、僕とKubernetesとの出会いのお話です。去年の9月にメルペイに転職して、最近やっと、メルペイという決済サービスが世に出ました。こちらはメルカリの売上金や銀行でチャージしたお金を店舗で使えるサービスなので、よろしければぜひ使ってみてください。

メルペイは、Go、GCP、Kubernetes、gRPCなどを使ったマイクロサービスとして開発されています。僕はここで初めてKubernetesに出会いました。

Kubernetesを使ってどういうふうにマイクロサービスを開発していくかというと、もちろんコードは書きます。

コードを書くだけではなくて、Dockerのイメージをビルドして、それをレジストリに登録する。デプロイする。それがインターネットに公開されている状態にする。ロードバランシングを設定する。スケールを設定する。監視を設定する。

コードを書くのに加え、運用や実行環境、インフラなどを意識する頻度がすごく増えたように感じています。

監視したり運用していくことも大事だと思いますが、もっとコードを書くことや機能を世に送り出すことに注力できないか、という問題意識をすごく持つようになりました。

そこで登場するのがKnativeです。

Knativeとは何か？

Knativeについて、だいたい知ってるよって方はどれくらいいらっしゃいますか？

（会場挙手）

ちらほらといらっしゃるようで、ありがとうございます。このKnativeについて、今日はいろいろとお話しできればと思っています。

Knativeとは何か？　というと、これは、GitHubにあがっているOSSです。説明としては、デプロイやビルドをするKubernetesベースのプラットフォーム、モダンなServerlessのワークロードを管理するものである、と書いてあります。

（公式のドキュメントを）もう少し具体的に見ていくと、3つあります。

まず、Kubernetesのリソースを抽象化するものというふうになっています。もちろん中身自体は普通のKubernetesと変わらないですが、開発者から見て、少しシンプルに扱えるようにするものです。

2つ目は、独自のFaaSを構築するためのパーツを提供するというふうになっています。Knative自体はFaaSではなく、それを組み立てるパーツであるということです。具体的にはServing、Build、Eventingというメインのコンポーネントがあって、のちほど、それぞれの仕組みや構成についてお話します。

3つ目、ありがちな難しい課題を解決するということが、公式のドキュメントにも書いてあります。コンテナのデプロイや、ソースコードからコンテナなどのビルド、Build、Run、Shipですね。それを含めて、URLでアクセスできるアプリケーションになるまでもっていく。

次が、ブルーグリーンデプロイを伴うルーティングとトラフィックの管理。そして、オートスケーリングと需要に基づくワークロードのサイズ設定。最後は、実行中のサービスをイベントのエコシステムに結び付ける。以上が説明です。

Knativeの構成要素

次に、Knativeの構成要素を具体的に見ていきます。Kubernetesの上で使うモジュールではあるのですが、Kubernetesでサービスメッシュを実現するIstioに依存するかたちになっています。

まず、Serving。これが、Knativeの中でスケール度合の調整を行う、メインのコンポーネントです。

コンテナの迅速なデプロイとオートスケールアウト、使わないときはリソースをなくし0までスケールインする機能、Istio向けのトラフィックやネットワークなどの設定、コードと設定のバージョン管理が役割です。

具体的に図で見ていきます。

（スライドを指して）これは概要ですが、Configurationというものがまず最初に書いてあります。これは、どのコンテナのイメージを使ってどういう環境変数をセットしてアプリケーションを実行するかに関する設定です。

その下のRevisionが、Configurationを設定するたびに履歴として保持されていくコンポーネントです。Revisionはイミュータブルになっていて、Configurationが更新されると1個1個作られます。イミュータブルなので、更新されたり削除されたりすることはありません。

次のRouteは、入ってきたトラフィックをRevisionにルーティングするものです。例えばRevision Aに90パーセント、Revision Bに10パーセントというふうに、どのRevisionにどれだけ流すかを設定できたり、それを応用して、ブルーグリーンデプロイやカナリアリリースを実現できるコンポーネントです。

このConfigurationからRouteまでは、個別にも設定できるのですが、最後に書いてあるServiceを使うと一括で管理できるようになっています。

このRevisionの管理する範囲ですが、Kubernetes自体のほうのリソースであるServiceだったり、具体的なDockerが実行されたり、その管理をするDeploymentや、ReplicaSet、Podなどが裏にいます。

Knativeを使わない場合はDeploymentやServiceなどの設定を個別に書きながら開発するのですが、KnativeだとServiceを設定するだけでほかの部分をよしなに調整してくれるという意味で、開発者にとってシンプルに扱えたり、抽象化されているというふうに捉えられます。

（スライドを指して）さらにRouteからRevisionにリクエストが流れていく図が、このスライドです。ここで登場するAutoscalerとActivatorが大事な役割を果たします。

AutoscalerがRevisionの同時リクエスト数を監視して、一定以上だったらDeploymentで指定されているレプリカ数を増やし、30秒間ぜんぜんリクエストが来なかったら、そのRevisionの状態をリザーブ状態にして、Scale to 0を実現できるようになっています。

Activatorは、Revisionでアクティブなものがないときにリクエストを受け付ける役割を持っています。リクエストが来たらそのRevisionの状態をアクティブに変更して、リクエストを受けられるようにする仕組みです。

Buildの役割と構成要素

次はBuildです。

こちらのコンポーネントは、ソースコードをコンテナのイメージに変換する役割です。Buildの中には複数のstepで構成されるパイプラインがあって、それぞれのstepがコンテナのイメージになっています。

そのコンテナのビルドが、Kubernetesが動いているクラスタの中で実行されます。Buildに（直接）どういうstepで実行していくかを書くこともできるのですが、BuildTemplateを使うと、パラメタをいくらか渡したらそれをもとにBuildを作って、そのコンテナのビルドをしてくれる仕組みになっています。

先ほどServiceやConfigurationで、使用するDockerイメージを指定するというお話をしました。そのイメージを指定する代わりにBuildを指定することで、Serviceを適用してデプロイするときに、コンテナのデプロイも一緒にクラスタの中でチャチャっとやってくれるという代物です。

BuildTemplateは、もうすでに準備されているものがたくさんあって、有名なところだとkanikoやBuildpackなどが使えます。ソースコードはこれ、Dockerイメージのpush先はここ、と指定するだけでソースコードからアプリケーションとして動くようにビルドするのが、このBuildTemplateやBuildの役割です。

Eventingの役割

最後がEventingです。

これは名前のとおりで、イベントドリブンなアーキテクチャをサポートするためのものです。イベントの発行元と受け手を抽象化して、いろんなサービスを接続できるようにするのが役割です。

CNCFのServerless Working Groupというところで、クラウドイベントがどういうものであるかということが議論されているのですが、Eventingはそれにある程度準拠していて、サービス間の相互運用性も実装上保証しようとしています。

（スライドを指して）今表示している図が、Eventing関連の流れです。主なコンポーネントが3つあります。まず1個目がSourceで、その名のとおりイベントソースです。そのSourceの種類ごとにリソースが定義されています。

次のスライドで具体的にどんなものがあるかを示すのですが、イベントソースとして指定できるのは、AWSのSQSだったり、GoogleのCloud Pub/Subだったりです。

次がChannelで、スライドの図でいうと青い円柱形の部分です。イベントのバッファリングを行って、Service自体が落ちてても最終的にはちゃんと届けるようにというリトライの処理などを責務として行うようになっています。

最後がSubscriptionです。これは、Channelからイベントを取り出して、最終的にServiceに渡すという責務を持っています。実際にどういうふうに動くかというと、まず、Simple Deliveryという使い方があります。これは、Sourceでなにかしらイベントが起こったときに、それをServiceに直接流すやり方です。

もう少し複雑な使い方もできます。Sourceでイベントが起こったときに、まずいったんChannelで受けて、（次に）それに関心があるSubscriptionという（図の）緑の三角形で受けてから、ServiceやほかのChannelに流すやり方です。複雑なイベントのやりとりが実現できるようになっています。

（スライドを指して）こちらがイベントソースですね。1つ1つがKubernetesのがリソースです。先ほども少しお話ししたように、AWS SQSやCP PubsubやGitHub、GitLabなど、POCも多いのですが、今後いろいろと対応されていく予定になっています。

ここにあるものだけではなくて、ContainerSource Event Sourceを作ることで、自分でイベントソースを作っていくことも可能です。

（スライドを指して）僕とServerlessとの出会いのところでお話ししたように、Serverlessアーキテクチャのいろんな特徴を挙げてみました。

実行時のみサーバーリソースを使用したり、負荷に応じてスケールしたり、イベントドリブンな非同期処理を行っていけるというようなことが、なんとなく、Knativeを使うと実現できそうな雰囲気があります。

一方で、最初にこれはFaaSではないというお話をしましたが、けっこう自分たちで基盤を作らないといけなさそうな雰囲気がしています。

Knativeの方向性

というところで、いったん「Knativeとは？」に戻ってみると「独自のFaaSを構築するためのパーツを提供」ということで、我々はこれに一体どう向き合えばいいんだと思うかもしれないですが、そこでKnativeの方向性について確認してみようと思います。

ちょうど、KnativeやIstioは何を目指しているのかという、Googleの方に対するインタビュー記事がありました。

ここで強調されているのが、複数のクラウド間でAPIを標準化するということで、今はバラバラだけどそれを統一していきたいという意志を感じ取ることができます。

さらに、Knativeの開発に関わっているRed Hatの方が書かれたブログ記事にあるように、consistent way、一貫した方法で開発や運用などをやっていけたらいいよねという意図を汲み取ることもできます。

実際Knativeを使っていろんなプロダクトも世に出始めているという状況ですね。

例えばGKEの上でServerlessの機能を付けるためのAdd-onや、その他OpenFaaS、Pivotal Functionなど、ファンクション系のサービスも世に出てたりするものがあります。

あとはGitLab Serverlessも、内部的にKnativeを使ってKubernetes上で運用されていたりします。

ただここで考えたいのが、一貫性やポータビリティという言葉が出てくるけど、それは本当に必要なのかどうかが、僕にとってはあんまりピンとこないことです。これからも調べていきたいなと思っています。謎を明らかにしていきたいですね。

杉田氏とKnativeの方向性

ここで、僕とKnativeの方向性ということで、自分がどういう検証や取り組みをしていこうと思っているかについてお話しさせてください。技術書典というイベント、ご存知の方もけっこう多いかもしれないですが、そこでKnativeについて本を書きたいと思っています。

先ほども海外のServerlessconfのお話がありましたが、今年も10月にニューヨークで開催されるので、プロポーザルを出したいと思っています。

最後、CloudNative Days Tokyoというイベントが7月くらいにあるのですが、これにKnativeについてのプロポーザルを出しています。もしご興味ある方がいらっしゃいましたら、いいねやツイートで応援していただけたらすごく嬉しいです。

付録です。

Knativeが出てまだそこまで時間が経っていないですが、すでにいろんな資料が世に出ています。なによりも公式ドキュメントがとても整理されていて、図も豊富でわかりやすいです。

2つ目、『Getting Started with Knative』というebookがあって、こちらはさっきも出てきたriffやPivotal Cloud Functionsを開発しているPivotalの方が執筆した、81ページくらいの本なのですが、なんと無料で読めます。

最後、ハンズオンですね。『Using Knative to deploy serverless applications to Kubernetes』というものがあります。これが、GKEを使って、先ほど出てきたうちのServingとBuildのハンズオンを行うものになっています。準備がめちゃくちゃ楽で、Cloud Shell上で何個かコマンドをインストールしてサクサク進められるので、パッと試してみたい方にはすごくおすすめです。

ほかにもハンズオンがすでにServing、Eventing、Buildだったり、個別に出てるものがあったり、いろんなカンファレンスや勉強会などでの資料もすでにあるので、ご関心がある方はぜひ見てみてください。

ここではあまりしゃべりませんが、なんでKnativeっていう名前なの？　ということが少しわかる資料も載せています。

これこそ本当におまけではありますが、メルペイでは色々な種類のエンジニアを募集しているので、ご関心がある方はぜひアクセスしてみてください。

以上で終わります。ご静聴ありがとうございました。

（会場拍手）

まだ本番では使っていない

司会者：ありがとうございます。なにか質問がある方はいらっしゃいますか？　じゃあ、僕から1つ質問を。僕、今はAzureをよく使うんですが、AzureのAKSでまだ動いた試しがなくて（笑）。

杉田：そうなんですね（笑）。

司会者：チュートリアルみたいなドキュメントがあるじゃないですか。そこで試してるとGKEしか動いていない（笑）。

杉田：なるほど（笑）。一応、Kubernetesに対して、インストールできるはずではあります。あんまり試したことがないのでわからないですが。

司会者：会場のみなさんに僕が伝えたいこととしては、GKEが一番簡単にできるかなと。

杉田：じゃあ、さっき紹介したGKEのハンズオンとかやってみるといいかもしれないですね。ありがとうございます。

司会者：なにか質問ある方いらっしゃいますか？　はい、ありがとうございます。

（会場挙手）

質問者1：ありがとうございました。私もKnativeについて調べているんですが、ドキュメントを見る限り、Work In ProgressやPOCという単語が乱れ飛ぶような状況なんですけど、実際にアプリケーションを使って試してみたりはされていますか？

杉田：アプリケーションは、本番で使ったことはないです。僕もPOCだったり、アーキテクチャがどんどん変わっていってることは感じていて、例えば今日お話ししたEventingのアーキテクチャも、ものすごく変わっています。今回の発表で、去年の資料も載せていたんですが、本当にガラっと、違うものみたいに変わっていました。

最近だとServingの0.4.0がリリースされたんですが、そこでもIstio IngressGatewayの扱いがガラっと変わっていて、まだまだ本番で使うには怖い状況ということは間違いないと思います。

質問者1：わかりました。私も技術書典で本を書こうとしてるんです。私メルカリの人なので……。

杉田：（笑）。

質問者1：それが言いたかったので質問しちゃいました（笑）。また後日お話しさせてください。

杉田：ぜひぜひ（笑）。ありがとうございます。

質問者1：ありがとうございます。

司会者：ほかになにか質問ある方はいらっしゃいますか？　ないようですね。はい、ありがとうございます！

（会場拍手）