2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
入門 Knative ~KubernetesとServerlessとの出会い~(全1記事)
リンクをコピー
記事をブックマーク
杉田寿憲氏(以下、杉田):『入門 Knative ~KubernetesとServerlessとの出会い~』というタイトルでお話しさせていただきます。この資料は#serverlesstokyoのハッシュタグで流してあります。途中、細かい図も出てくるので、よかったら手元のほうでも見てください。
まず自己紹介からしますと、杉田寿憲といいます。
toshi0607というアカウントでTwitterやGitHubをやっているので、よろしくお願いします。
メルペイという決済の会社で、バックエンドのエンジニアをやっています。Serverlessの技術がすごく好きで『GoとSAMで学ぶAWS Lambda』という本を書いたり、Serverless関連のOSSにコントリビューションしたりして、ふだん活動しています。
今日は、ServerlessやKubernetesとの出会い、Knativeの概要、その構成などについて、順番にお話しさせていただきます。
まず、僕と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との出会いのお話です。去年の9月にメルペイに転職して、最近やっと、メルペイという決済サービスが世に出ました。こちらはメルカリの売上金や銀行でチャージしたお金を店舗で使えるサービスなので、よろしければぜひ使ってみてください。
メルペイは、Go、GCP、Kubernetes、gRPCなどを使ったマイクロサービスとして開発されています。僕はここで初めてKubernetesに出会いました。
Kubernetesを使ってどういうふうにマイクロサービスを開発していくかというと、もちろんコードは書きます。
コードを書くだけではなくて、Dockerのイメージをビルドして、それをレジストリに登録する。デプロイする。それがインターネットに公開されている状態にする。ロードバランシングを設定する。スケールを設定する。監視を設定する。
コードを書くのに加え、運用や実行環境、インフラなどを意識する頻度がすごく増えたように感じています。
監視したり運用していくことも大事だと思いますが、もっとコードを書くことや機能を世に送り出すことに注力できないか、という問題意識をすごく持つようになりました。
そこで登場するのがKnativeです。
Knativeについて、だいたい知ってるよって方はどれくらいいらっしゃいますか?
(会場挙手)
ちらほらといらっしゃるようで、ありがとうございます。このKnativeについて、今日はいろいろとお話しできればと思っています。
Knativeとは何か? というと、これは、GitHubにあがっているOSSです。説明としては、デプロイやビルドをするKubernetesベースのプラットフォーム、モダンなServerlessのワークロードを管理するものである、と書いてあります。
(公式のドキュメントを)もう少し具体的に見ていくと、3つあります。
まず、Kubernetesのリソースを抽象化するものというふうになっています。もちろん中身自体は普通のKubernetesと変わらないですが、開発者から見て、少しシンプルに扱えるようにするものです。
2つ目は、独自のFaaSを構築するためのパーツを提供するというふうになっています。Knative自体はFaaSではなく、それを組み立てるパーツであるということです。具体的にはServing、Build、Eventingというメインのコンポーネントがあって、のちほど、それぞれの仕組みや構成についてお話します。
3つ目、ありがちな難しい課題を解決するということが、公式のドキュメントにも書いてあります。コンテナのデプロイや、ソースコードからコンテナなどのビルド、Build、Run、Shipですね。それを含めて、URLでアクセスできるアプリケーションになるまでもっていく。
次が、ブルーグリーンデプロイを伴うルーティングとトラフィックの管理。そして、オートスケーリングと需要に基づくワークロードのサイズ設定。最後は、実行中のサービスをイベントのエコシステムに結び付ける。以上が説明です。
次に、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の中には複数のstepで構成されるパイプラインがあって、それぞれのstepがコンテナのイメージになっています。
そのコンテナのビルドが、Kubernetesが動いているクラスタの中で実行されます。Buildに(直接)どういうstepで実行していくかを書くこともできるのですが、BuildTemplateを使うと、パラメタをいくらか渡したらそれをもとにBuildを作って、そのコンテナのビルドをしてくれる仕組みになっています。
先ほどServiceやConfigurationで、使用するDockerイメージを指定するというお話をしました。そのイメージを指定する代わりにBuildを指定することで、Serviceを適用してデプロイするときに、コンテナのデプロイも一緒にクラスタの中でチャチャっとやってくれるという代物です。
BuildTemplateは、もうすでに準備されているものがたくさんあって、有名なところだとkanikoやBuildpackなどが使えます。ソースコードはこれ、Dockerイメージのpush先はここ、と指定するだけでソースコードからアプリケーションとして動くようにビルドするのが、このBuildTemplateやBuildの役割です。
最後が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とは?」に戻ってみると「独自の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について本を書きたいと思っています。
先ほども海外の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:ありがとうございます。
司会者:ほかになにか質問ある方はいらっしゃいますか? ないようですね。はい、ありがとうございます!
(会場拍手)
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには