サーバーレス技術の今と未来についてServerlessDays Tokyo 2024 直前イベントで話してきました
ServerlessDays Tokyo 2024 PreEvent
2024-09-21のServerlessDays Tokyo 2024にむけて、去年に引き続き、直前イベントでサーバーレス技術の今と未来について話してきました。
いよいよ明日からメインイベントですので参加お待ちしています！
Serverless Update 2024 文字起こし
スライド全体はDocswellさんで公開しています。
PreEventはYouTubeでアーカイブがあります。
サーバーレスのおさらい
「サーバーレス」は、誤解を招きやすい技術用語で様々な定義がありますが、ここでは2つの視点で定義します。
運用者の視点としてのサーバーレスは、物理的なマシンや仮想マシン、EC2インスタンスのような「サーバー」を自分で管理するのではなく、その管理をクラウド事業者に任せるという考え方で、要するに完全従量課金型のフルマネージドサービスであることです。つまり、使った分だけ料金を支払い、リソースは自動的にスケールされる、まさに「0円からいくらでも使える」サービスを指します。
これが最も一般的に言われているサーバーレスの定義でしょう。
開発者の視点で考えると、個々のサーバーの存在に依存しないプログラミングモデルがサーバーレスという技術ムーブメントの重要な要素です。WordPressのアップロードファイル保存先のように、ファイルシステムやプロセスのメモリーといったリクエストをまたいで共有されるサーバー上のリソースに依存しないということです。
AWS LambdaやAzure Functionsのようなプロセスやファイルを共有しないプログラミングモデルがその代表例ですが、Database as a Service（DBaaS）など、裏側で分散システムのテクニック（レプリケーションやシャーディング）を使いつつ、保存先のサーバーを意識せずSQLのような言語で開発者が操作できるようなものも、サーバーレスなプログラミングモデルの一つと言えます。
まとめると、サーバーを所有しないという運用の視点と、サーバーに依存しない開発を意識する視点の2つがポイントです。
「サーバーレス」の全体像
サーバーレスと言われている技術ムーブメントとしていろいろな試みが行われています。それを、先ほどの2つにもうひとつ加えた3つの視点から整理します。
- フルマネージドサービス
- プログラミングモデル
- イベントドリブンアーキテクチャ
小さな課金単位、AWS Lambdaではリリース当初に100ミリ秒単位で課金されていたのが、今は1ミリ秒単位で実行時間に対して課金されるようになりました。大昔の仮想サーバ、EC2では1時間単位の1台単位で課金をされていたのが、今や1ミリ秒でメモリも128MBごとの単位で課金されます。クラウドコンピューティングの特徴として言われるように、確保した量ではなくて使用した量という考え方の変化を表しています。これが完全従量料金というところに表されているわけですね。
サーバーレスなサービスを実現するために、フルマネージドサービスとして、例えばこの弾力性という観点では、クラウド事業者がこの裏側で動いているマシンを増やすオートスケールだったりとか、あるいは使わない時は0台まで減らす、つまり使わない時にはリクエストが来ない時には割り当てマシンを0台にするといった、「ゼロスケール」と言われる動作をします。
1リクエストごとに動く処理として、ファイルや仮想メモリのあり方といったリソースの抽象化、仮想化みたいなところも、コンピューターサイエンスの文脈に綺麗に乗っています。例えばAWS Lambdaだとアカウントをまたいでリクエストが飛ばないように、あるいはメモリが共有されないように、microVMだったりとかコンテナランタイムで分離したりとか、最近だと例えばNode.jsのJavaScriptのサンドボックスを使ってプロセスごとにちゃんと隔離をしてお客さんのデータ、動いているプロセスのメモリを守るみたいことをやっています。
その一方で、セキュリティを守っていくために1リクエストごとにいちいちプロセスを全部1から立ち上げているんだと、やっぱり時間がかかってしまうので、そういったスタートアップの高速化のテクニックというところが色々と試みられています。
そういった中で、やっぱり1リクエストごとにプロセスもファイルシステムも共有されないというのをそのまま書くのはやっぱりなかなか辛いので、プログラミングモデルとしてどう開発をやすくしていくかとして、開発者として一番実現したいのはお客さんの、プログラムを使う人への価値をちゃんと上げていくことが大事になるわけです。
面倒くさいところはライブラリーだったりフレームワークだったり、あるいはクラウドベンダーが管理しているマネジメントの仕組みというところにうまく載せてあげたいので、いろんなシャーディングとかレプリケーションみたいな、データを保存するレイヤーだとそういった分散システムが必要になります。そういったものも全部隠蔽しようというのが、当然の動きとして出てきます。
例えばDatabase as a Serviceのような形で提供されたり、抽象化のグラデーションとして例えばAWSで言うとStep Functionsみたいなものがあります。Step Functionsの記述言語「ASL」なんかは、去年のパネルセッションでも色々な愚痴が出ましたが、ASLみたいな独自の言語、こういった特化型用語をDSLと呼びます。DSLとして抽象化したり、あるいは抽象化をどんどん下げていき、最終的にはコンテナーまで広がっているのかなというのが昨今のサーバーレスの話です。
コンテナというところから、あるいは関数というモデルがあったり、ASLのようなDSL、独自言語があったり、突き詰めて言うとコンフィギュレーション、YAMLだったりJSONの設定ファイルというところに最終的にはいきます。設定まで行くと、用意された設定項目しかできないのですが、そういった自由と抽象化のグラデーションがあります。
そんな感じで、DSLとかを使ってStep Functionsで例えば処理を実行しようとなると、この時にStep FunctionsとかApache Airflowとかそういったものを使ったことがある人だと、イベントドリブンに非同期にシステムを使って繋げていくという設計が大事になります。
例えば分散システムの複数サービスをイベントで繋げていくためには、どういう風に管理するかというところで、オーケストレーションだとかコレオグラフィーみたいなキーワードも出てきます。あるいはシステムをまたぐ間の認証や認可の連携をどうするのか、そういった問題とかもあります。複数の細かい分散システムがある中で、データの整合性をどうやって取るのかみたいな話から、リアクティブシステムみたいな考え方の上に、アクターモデルみたいな考え方が出てきたりだったりとか、イベントドリブンのアーキテクチャーというところをどう実現していくかがあります。
ここまでフルマネージドサービスというところからスタートして、プログラミングモデルを色々考えつつ、その上でいろんなシステムを作っていくためには、イベントドリブンのアーキテクチャーというところの解像度を上げていく必要があるというところまで、サーバーレスの全体像として話をしました。
去年のServerless Updates2023で、イベントドリブンアーキテクチャの話をさせてもらいました。
いろんなクラウドサービスをどう管理するかというところ、LambdaやAzure Functionsで繋いでいくみたいな生で繋げていくという考え方はやっぱりもう古くなりつつあるというか、面倒くさいわけです。例えば失敗した時に再送したりとかということを考えると、いろんな賢い道具が増えているので、例えばEventBridge Pipesだったりとかみたいなそういう道具が増えてきているので、そういったものを使っていきましょうという話を去年させていただきました。
詳しくは昨年のスライドを参考にしてください。
今年は新しいキーワードを持ってきました。
AI拡張型開発：LLMによる開発
AI拡張型開発というキーワードが出てきています。
プログラムを自分で全部1から10まで書いてきたのが今までのプログラミングです。もちろんコードジェネレーターのようなものも使われてきましたが、より積極的にAIにプログラムを書かせよう、あるいはそもそも処理そのものをLLMのプロンプトとして記述・実装しようみたいな試みがされています。
ここでいくつかの例を挙げます。
UIではVerceoのv0、GoogleのAI Generated UIのような、プロンプトからUIを定義できる事例が出てきました。
処理の本体そのものを、ローコードとして、その「コード」の部分もLLMのプロンプトで書いてしまおうというのが、AWSのApp Studioかなと思います。
AIのプロンプトから直接動かすのではなく、プログラマとペアプロ的にコードを書いてもらうのが、皆さんおなじみGitHub Copilotですね。
面白い試みとして、そもそもLLMが理解しやすい中間言語を書かせるSudoLangという試みもあるようです。ほかにも、要はデータの形ををLLMに教えておいてSQLをLLMに書いてもらおう、というPostgres.newだったりとか、あるいは古い塩漬けになったコードを更新するのをLLMに任せるAmazon Q Code Transformationみたいな試みがあります。GitHub Copilotとか使った人は試したことがある方もいるかもしれないんですが、LLMは既にあるコードの意図を読み取らせるみたいなところも結構得意だったりするので、そういったところを元にして古いコードを今のライブラリーとかに書き換えてもらうわけです。
というわけで、いろんなAI拡張型開発というのが結構盛んになってきたのかなと思います。
コストに基づいたアーキテクチャ
この1年で特に注目を浴びているのが、コストに基づいたアーキテクチャという考え方です。
よく考えると当たり前の話ですが、巨大なクラウドほどコストの小さな改善から受ける影響というのはもちろん大きいわけですね。要は絶対金額が多いからですし、さらに今後10年間でデータセンターの電力消費量が今の2倍以上に増えるという予想が今出ています。
クラウドの市場規模は非常に大きく、その最終的なコストはデータセンターの電力消費量に行き着きます。そこを例えば1%減らせるだけでも巨大な金額になるわけです。この1%でも性能を良くするという最適化によって、利益が増え、例えば機能拡張などの成長の原資に繋がるという、大きなクラウドほど正のフィードバックが顕著になります。
去年のAWSのre:InventにおけるWerner Voegels氏基調講演で、コスト構造というのがアーキテクチャ設計における重要な要件の1つになるという、The Frugal Architectという整理が紹介されました。
このような文脈を考える上で1つ例を挙げると、共通機能のコストがあります。
例えば、AWS Lambdaは「ゼロスケール」だと言われていて、使ってない時には1円もかからりません。でも実際には、リクエストが来た時にそのHTTPのリクエストを受け取るロードバランサーが存在したり、あるいはログの基盤とかも動いている必要があります。「リクエスト」が来ていないからといって、その本当に0にはできないコストというのは、どこかにあるわけです。
そういったコストはクラウド事業者が実は無料で負担してる場合多いと思います。その一方で、Momentoさんのような「本当のサーバーレス」を謳うクラウドベンダーでは、いわゆるこうマルチテナントを前提とすることにより、みんなでそういったコストを負担していくというモデルというのが、1つアーキテクチャの設計としてあるわけです。そんなアーキテクチャを、私自身の言葉で言うと「広く薄いアーキテクチャ」と昔から呼んでいます。
というわけで、コストに基づいてアーキテクチャーを決めるという視点を持っておくと、今後のサーバーレスに限らずクラウド事業者の動きをより深く理解でき、未来の予測がしやすくなるでしょう。
NewSQLとDBaaS
この何年かで、NewSQLなどを言われる新しいデータベースサービスが、Database-as-a-Service(DBaaS)というクラウドサービスとしてさらに普及してきています。これを3つの軸から整理してみました。
1つはプロトコル互換です。全く新しいプロトコルによって提供されるサービスもありますが、DBaaSで存在感が大きいものは、PostgreSQLやMySQL、MongoDBなど既存のオープンソースデータベースにプロトコルを合わせて出しています。プロトコルを合わせるということは、同じ機能が同じように使えるわけです。もちろん、性能特性などデータベースの性質や特徴というのは違いはありますが、表から見たいわゆる機能的な機能というとプロトコル互換というところで1つ見えるのかなと。
次はマルチモデルな計算機層（コンピュート層）です。AzureのCosmos DBや、GoogleのSpannerでは、いわゆるSQLとかドキュメントDBみたいな形だけではなく、同じ枠組みの上でグラフDBや、最近だとAIの文脈でよく使われるベクトル検索、あるいは全文検索など、様々なデータモデルを扱える処理層を乗せられるというのが、最近のトレンドの1つになっています。
最後に、ストレージと計算機層の分離というコンテキストにおけるストレージの話です。
例えばオブジェクトストレージから直接クエリーができる。今までもAmazonだったらAthenaがS3から直接クエリを投げたりできました。AmazonのAthenaがS3にクエリできるのはそりゃそうだよねって感じですが、例えばBigQuery Omniが直接Amazon S3からクエリできるような、他社ストレージに直接クエリできるようなデータベースサービスが出てきています。あるいは独立したオープンソースとして、DuckDBは、シングルバイナリーで動いてS3からファイルを取ってきて直接クエリができるみたいな、そういう新しい動きというのがあります。
今後に向けてひとつ覚えておくと良いのが、マルチクラウドとクロスクラウドという考え方です。
たとえばメインのウェブサービスの基盤はAmazonで動かしているけれど、集計のところだけBigQueryに転送しているといったパターンは以前から良く聞きますが、それぞれ全てのクラウドを使える状態にないとサービスが劣化してしまうという点で、マルチクラウドは可用性の観点から厳しいところがあるという見方がありました。このマルチクラウドからもう1歩さらに踏み込んで、データがどこにあってもいいよみたいな、クロスクラウドという考え方が増えて行くのではないかと思っています。
というわけで、これらの考え方の整理というところで、プロトコルの互換という話、プロトコルの話と計算機層とストレージ層という3つに分けて考えると、DBaaSがこれだけ広く出てきている理由について整理できるのかなと思っています。
フロントエンドとバックエンドの接点
昨年のServerless Updates 2023ではHonoを中心にしたCDNの話をしました。
フロントエンドとバックエンドの接点というところで、これはCDNエッジコンピューティングやAWS LambdaなどのFunction as a Serviceに限らず、新しいプログラミングのパラダイムで新しい「Ruby on Rails」を探そう、新たなレールはどう敷いたらよいだろう、というのが今まさに今模索の段階にあります。
この1年の動きとしては、例えばNext.jsがフロントエンドを中心にしたコードの中にサーバー側のクエリの実装を埋め込むServer Actionsだったり、昨年も紹介したHonoはウェブスタンダード技術（fetch()やJavaScriptの標準関数、標準インターフェース）に則った枠組みをベースに、NodeやDenoといったバックエンド側の技術からスタートしてフロントエンド側にどんどん浸透していくみたいな、こういったいろんな双方からの動きっていうのがあります。
バックエンドもフロントエンドも、最終的にはデータをどう扱うかというところがサービスの1番大事な部分ですが、データをどういう風に守っていくか、もう少し踏み込んで言うと、そのデータのスキーマをどうやって定義して、それをプログラミング上でどう強制するかといった型安全性のような話が重要です。今までだとGraphQLやgRPC向けにスキーマを作って、それをもとに各言語で自動生成するようなやり方が結構多かった。新しいパターンだと、このNext.js Server Actionsなんかもそうですが、TypeScriptのスキーマをフロントエンドとバックエンド全部で使い大統一するような、tRPCのような試みもあります。
フロントエンドとバックエンド両方にまたがってデータを守っていくために、今までだったらバックエンドでバリデーションかけてフロントエンドも一応バリデーションかけるけど最終的にはサーバー側で掛けるからいいよねみたいな二度手間をしています。フロントエンド側とバックエンド側で実装の詳細が違うと、なんかフロントエンド側ではパスしちゃったがバックエンド側でエラーとして弾かれた時にこれはユーザー体験悪いよねみたいな話になります。そういったスキーマをどう一貫して扱うかみたいなところまでセットで、その新しい「on Rails」を模索していく感じになるのかなと思います。
FaaS Updates
FaaSの分野でもアップデートは色々あります。
AWS LambdaやAzure Functionsではかなり力がかけられていて、性能改善、例えばAuto Scalingの性能がもう何倍にもなったみたいな話や、長時間実行やHTTPのストリーミングなどがあります。
これまでレスポンスの内容はファンクションの戻り値でJSONの全体を一括で返す仕様になっていたのを、ChatGPTの1文字ずつ出てくる体験を実現するために、HTTPのストリーミングとして少しずつクライアントに返すための仕様を、プログラミングモデルとして定義されたというわけです。
開発体験の向上として、例えばAmazonだとサーバーレスアプリケーションをビジュアルプログラミングで構成できるApplication ComposerからIaCのコードを吐き出すみたいな話や、AmplifyのUIといったものが登場しました。Azure Functionsでは今までのNode.jsとかでもとてもプリミティブに、パスごとにファンクションを用意し、それぞれのファンクションがたとえばJavaScriptのオブジェクトでレスポンスを返してましたが、新しいプログラミングモデルとしてExpressのようにパスとレスポンスを定義できるといった開発体験になりました。
AWSでおもしろい動きでいうと、いわゆるオープンソースソフトウェアをマネージドで提供するものが結構増えています。、例えば以前Kinesis Data Analytics for Flinkのような名前で提供されたものが、今Amazon Managed Service for Apache Flinkみたいな感じでリブランディングされています。Flink以外にも、Amazon Timestream for InfluxDBとか、Amazon Managed Workflows for Apache Airflowのような、これらはそこまでサーバーレスっぽくはないのですが、マネージドオープンソースソフトウェアというのが結構Amazonでも提供が増えてきてるように感じています。
今までだとAmazonは独自路線で最初から最後まで新規に自社設計した「新しい画期的なサービス」を提供するパターンが多かったように思いますが、最近はオープンソースに注力してるように感じます。例えばFaaSと関連が深いものとしてはKafkaです。今までだったらKinesis Data StreamからLambdaにつぎ込むみたいなパターンがメインでしたが、今だとKafkaのマネージドサービスであるMSKへの統合に対して深く対応してきているなと感じます
一方それと真逆というか全然違う動きをしてるのがGoogleです。皆さんご存知の人も多い通り、Google Cloudはやっぱりコンテナをベースに成長してきてるので、Google Cloud Functionsは今Cloud Runに完全統合されてCloud Run Functionsに統合されました。元々Cloud Functionsが第2世代になった時からほとんどCloud Runでしたが、完全にCloud Runに統合されたので、例えば今年入ったGPUの対応がCloud Runに入りましたが、ファンクションからGPUを使ったコードが書けるようになりました。まだ使うところは限定的ですが、それでも音声合成とかではGPU積極的に使えるます。これからどんどんAIのモデル、小さな言語モデルみたいなものが今後増えてくると、このようなGPU対応もかなり生きてくる場面が増えてくるでしょう。
共通して言えるところは、各社開発のしやすさに注力してきてるということです。去年もコンテナ技術との統合の話はしましたが、コンテナ技術をファンクションと統合していく流れは今年も引き続き続いてるのかなと思います。
まとめ
FaaSそのものについても引き続き完成度を上げているのは続いていますが、今年いくつかの視点として、4つの話をしました。
AIをどんどん積極的にコード生成させたり、LLMプロンプトをコードそのものとして使うといったAI拡張型開発が出てきています。
コストに基づいたアーキテクチャっていう考え方。なぜ1%でも性能を良くする必要があるのかどんなインパクトがあるのかを考えると、クラウドベンダーが最終的には電気を負担するってところがコストそのものなので、そこにそこを考えていくといろんなアーキテクチャの技術的選定が腑に落ちるのでは無いかと思います。
DBaaS、もちろんデータベースに限らず、例えばMemcacheのようなメモリキャッシュや、Pub/Sub基盤などもありますが、そういったデータストア系のサービスがクラウドサービスとして提供される中で、マルチクラウドとして複数のクラウドを単に併用するだけではなく、クロスクラウドという形で、クラウドをまたいでデータを共通化して使うといった考え方、あるいはクラウド同士でデータを、例えばS3からGoogle Cloud Storageに全部引っ越しても同じような計算機層あるいはプロトコルが使えるといったクロスクラウドの考え方が今後重要になるでしょう。
というわけで、このファンクションサービスの紹介と、サーバーレスを寄り深く知るための視点として4つキーワードを今年は紹介させていただきました。
ServerlessDays Tokyo 2024
ServerlessDays Tokyo 2024まだまだ参加募集しているのでぜひお越しください！
Discussion