はじめに
先日、エンジニア界隈では有名なポッドキャストであるfukabori.fmに出させていただきまして、そのときのトピックがサーバーレスでした。
ポッドキャストはこちらで聞けますのでぜひどうぞ。
そこでもいろいろお話ししたのですが改めて話せなかったことなども含めて書こうかなと。つまり、ポエムです。散らかった文章な上に少し長めなのでお時間のある方だけどうぞ。
なお、サーバーレスの黎明期の話とかそういう思い出話は以前に書いたこちらの投稿があります。
サーバーレスと僕のこれまでとこれから - Sweet Escape
今回は思い出話ではなく、サーバーレスに個人として魅力を感じ、仕事としてその良さを広めたり、実装のお手伝いをし続けてきた自分がそういった仕事から離れた2022年現在どういう風に向き合ってるかについてのポエムです。
前提
現在の自分は株式会社Singular Perturbationsという「いつ、どこで、未来の犯罪がおこるか」を予測するシステムとそれをもとにしたサービスを提供するシードステージのスタートアップでCTOをしています。
CTOなんて偉そうな肩書きはありますがシードステージなので世の中の多くの人がイメージするCTOな感じとはちょっと違うと思います。知らんけど。
とりあえず、そんな感じなのでエンジニアリソースもかなり限りがある状態です。
あと、基本的に知識としては大規模クラウドベンダー中心で、中でもAWSがメインです。その次がGoogle Cloud、MicrosoftのAzureについてはサーバーレス関連のサービスをいくつか名前と概要だけ知っているだけで詳細はもちろん触ったこともない状況です。
また、3大クラウドベンダー以外からもサーバーレスのサービスは多数提供されていますがそれらに関しては幅広く網羅的な知識があるわけではありません。
そして、私個人はあれこれと言ってはいるものの『Everything will be serverless』なことを信じています。
市場に対して勝手に思ってること
ぶっちゃけ2022年現在、サーバーレス自体は盛り上がっていません。これはハイプ・サイクルにおける幻滅期みたいなものともちょっと違うと思っています。
そういうと少し言い過ぎかもしれないですが少なくとも以前のような盛り上がりはないと思っています。それはもしかしたら普通に使われるようになったからというのもあるかもしれない。
でもそれとは別の理由があると思っていて、個人的にはサーバーレスというムーブメントの中心と言えるFaaSに関してはAWS Lambda一強の状態になっているからだと思っています。
もちろんGoogleのCloud Functionsなどもあるし、実際に自分も一部の処理で使ってます。でもシステムのメインとなるような部分にも使われているという事例はあまり見たことがない。とはいえ実際の数字があるわけではないので間違っていたらごめんなさい。
まず、『サーバーレス』と一言で言っても色んなパターンがあると思います。
いわゆるAWS Lambdaに代表されるようなFaaS（Function as a Service）と呼ばれるものやGoogle CloudのCloud Run、AWS Fargateのようなコンテナの実行基盤といったコンピューティング環境を中心にフルマネージドで提供してくれるもの、Firebase FirestoreやAmazon DynamoDBのようなデータベースなどの機能を独自の方式で提供してくれるもの、従来マネージドサービスとして提供されているものを拡張してインスタンス管理なども不要としたもの、Firebase Authenticationのようにアプリケーション機能とその基盤を提供してくれるもの、などがあるかと。
あとはあれですね、GoogleのAppEngine。このあたりはPaaS（Platform as a Service）とかBaaS（Backend as a Service）とかって言葉もあって正直よくわからん。
そんな『サーバーレス』というキーワード自体は以前から一部では使われていたようですが、今のような形で捉えられ広まったのはAWS Lambdaのあとに出たAmazon API Gatewayがリリースされたあたりからです。はい、なので具体的な技術ではなく概念といえます。
そしてサーバーレスの盛り上がりってのはほぼFaaSとそれに対抗するコンテナを中心とするコンピューティング基盤の盛り上がりと近しいと思っています。少なくともこれまでは。
さて、GoogleトレンドでFaaSについて見てみたところ過去1年ではこんな割合で推移しています。AWS Lambdaが飛び抜けてててその構図はほとんど変わらない状態。意外だったのはAzure FunctionsのほうがGoogleのCloud Functionsより検索されていることか。
この割合は各クラウドベンダ全体の割合とも異なる傾向なのも面白い。これはAWS、Google Cloud、Azureで比較したもの。
これだとAzureはAWSに肉薄しているし、Googleの割合はさらに少ない。そういう意味ではFaaSだけに限るとGoogleは頑張っているほうなのかもしれないです。
ここまでそんな話をしておいてなんですが、実はその多寡そのものではなく代わり映えしないまま年月が経過していることが一頃のような盛り上がりがなくなった原因なのではないかと思っています。つまりずっと同じ状況だからではないか。
過去5年くらいで比較してもCloud FunctionsとAzure Functionsの数字は2018年頃からずっと変わっていないんですね。クラウド全体だとこの2社がトップのAWSを追いつき、追い越せ的になってるのに。
言いたいのはAWS Lambdaすげーとかって話ではなくて、寡占化するとつまらないよねってこと。
AWS Lambdaが出てきてにわかに『サーバーレス』というキーワードが盛り上がった頃は各社競合となるFaaSを提供しだしたり、それ以外の基盤をサーバーレスというキーワードで打ち出すことも多かったと思いますが今やそういう打ち出しも減ったかなと思います。
とはいえ、GoogleにはFirebaseがいる。FirebaseはいわゆるBaaSと呼ばれるようなものだがこっちはこっちでデファクトと言える状態。新しいアプリを作るときの立ち上がりの速さは随一だと思っています。
特にFirestoreとFirebase Authentication。
クライアントが1種類だけでシンプルにCRUDするだけでいいならAPI Gateway + Lambda + DynamoDBじゃなくてFirestoreで全然いい。多少のロジックあってもクライアントサイドでなんとかしちゃえば問題ない。
この手軽さは最高の体験だと思う。規模大きくなってきたりデータの構造が複雑になってきたりすると辛い局面も出てくるけど。
AWSもこのあたり既存サービスの組み合わせで頑張ろうとしているが正直足元にも及んでいないと言ったら言い過ぎか。
また、少なくともAWSについてはサーバーレスも成熟しつつあり、あまり心踊るようなアップデートがなくなってきたのも事実。残り2社についてはもっとそう。
自分は以前にマンスリーで市場全体のサーバーレス関連のアップデートを紹介するというイベントをやっていたがそのときからそういう傾向はあった。
あとはやはり汎用的な技術ではなくベンダー固有・サービス固有の技術と知識の組み合わせになってしまうのであまり広がりを見せないのではないかなとも思います。
そうはいいつつもCloudflare Workersに代表されるエッジでのサーバーレスコンピューティングなど新たなプレイヤーも出てきていて楽しみは続きますね。
エッジ関連だとCloudflare Workers以外にもFly.ioやDeno Deployなんかがありますね。
DB関連は以前からFaunaなどいましたがこれまで意外となかったのがキャッシュ系のプレイヤー。これについてはAWSのDynamoDBを手掛けた二人が立ち上げたmomentというのがこの領域を攻めていて期待しています。
その他にもプラットフォームサービスは多々生まれていますが正直追いきれないのと、最終的にはどこか大手に買われてしまうんだろうなーとは思っています。
『サーバーレス』という技術選択について
技術選択におけるサーバレスについても少し。ここで話すのは主にWeb APIを作る場合の話です。
今の会社ではメインのワークロードがAWSで動いているのですが、結論から言うと現在自分が技術選定したシステムではメインのWeb APIでAmazon API Gateway + AWS Lambda + Amazon DynamoDBと言った典型的サーバーレスな構成を採用していません。
その理由は開発メンバーのスキルセットと世の中に存在するWebアプリケーションフレームワークを手軽に使いたいからです。
もちろん、人のいないシードスタートアップだからこそサーバーレスのスケーラビリティや運用性というのは捨てがたい魅力があるのも事実です。でも作るのに時間がかかるのを今回は嫌ったということになります。
ちなみにしばらくはFirebaseで頑張ってました。でもいろいろあってFirestore部分は自前でAPI用意して移行しています。そのあたりの話はこちらに書いています。
AWS DevDay Japan 2022 に「脱Firebase. 我々はどう生きるか 」というタイトルで登壇してきた - Sweet Escape
さて、この既存のWebアプリケーションフレームワークをそのまま動かしたいっていう要望はやっぱり以前からあって、いくつかそれに対する解も出てはきたもののどれも日の目を見たとは言えないのが現状です。
REST APIのようなWebシステムを作る場合の既存資産の有効活用が難しいというのが大きいと思います。つまり、短期的な生産性と長期的な運用性とのトレードオフとも言えるかと。
そんな死屍累々とも言える状況で新たに生まれたのがAWS Lambda Web Adapter。
これは端的に言うとあらゆる言語の使い慣れたWebアプリケーションフレームワークをAWS Lambdaとそれ以外（Amazon EC2、AWS Fargate）で実行可能にするという代物です。
GitHub - awslabs/aws-lambda-web-adapter: Run web applications on AWS Lambda
AWS Lambda Web AdapterはAWS LambdaのDockerコンテナサポートとLambda Extensionというサイドカーのサポートによって実現されています。
実際には任意のWebアプリとLambda Web Adapterのバイナリを同梱したDockerイメージを用意してこれをLambda関数として動かします。
そして、Lambda AdapterがLambda Extensionとして動き、リクエストのイベントを普通のHTTPリクエストに変換してWebアプリに転送し、またそのレスポンスをLambdaのレスポンスに変換して返すという処理を行う。
これそのものの詳細は他に譲るが、いずれにせよWebアプリケーションフレームワークをそのまま使いたいという希望だけは叶ったと言えます。
ただし、ちょっと前にTwitterでも書いたのですが、これはあくまでもLambda関数をコンテナイメージで動かす前提で、Lambda固有のリクエストイベントを標準のHTTPリクエストに変換することで普通のWebフレームワークでも処理可能にしてるというもの。
AWS Lambdaっていうのは単にサーバーレスというのではなくファンクションモデルがその特徴なんだけど当然ながらその恩恵は受けられなくなる。
ここに関してはそういうものなので割り切るしかないんだと思う。ただし、そうするとそこまでしてAPI Gateway + Lambdaで動かす意味は？とも思えてきてしまうのが正直なところ。
もちろんPay as you goなプライシングモデルによってコストとしてゼロスタートできることやスケーリングというメリットはあるものの、このソリューションがコンテナイメージで動かす前提であるためDockerfileを書かなければいけないわけで、それならもう普通にAWS Fargateとかでいいじゃないかって思ってしまう。
いや、言ってることがただのわがままなのはわかってる。
でも理想はこれをサービス側で吸収してくれることかな。フレームワーク側で吸収するにはあまりにベンダ依存な話になるので違うと思うし。
ちなみにここら辺の話はAWSの下川さんがスライドとしてまとめていて公開されてます。
AWS Lambda の上でいろんなWEB フレームワークを動かそう！ / Web Frameworks on Lambda - Speaker Deck
このスライドにもある通り、WebアプリケーションフレームワークはFaaSで実行されることを想定したモデルには当然なっていないので、そのまま動かすことがいいこととも言えない。
それ以外にもこれまでの進化の歴史などが書かれていて面白い資料なので一読を。
どれもあくまでもFaaSでなんとか動かすためにはどうするかっていう観点になっているのだが、個人的には別にFaaSであること自体よりアプリケーションの開発体験がいいかのほうが重要性は高い。
そうするとやはりGoogle AppEngineが理想に近い形なのかもしれない。が、いまいち流行りきらないのはなぜなのか。実際に自分もあまり使いたい！って思ったことがない。なぜなのか。
ちなみにFirebaseのCloud Firestoreから移行して、その後プロダクトやシステムとしての1つのメルクマールは無事に超えられたんだけどやっぱりああいうフルマネージドでサーバーレスなサービスは楽だったと改めて感じています。
障害が起きることは前提としつつも基本的には何も考えずにちゃんと動き続けてくれる、障害起きても対応されるってのは本当に楽。
さて、そんなサーバーレスアプリのDeveloper Experience（開発体験）向上は昔から課題になっていて今も解決できていない認識。
大きく汎用的なエコシステムの形成にはまだ至れてなくていろんなツールを自社が出すしかない状態。
サードパーティが提供するものもあるがServerless Framework以外はパッとしないと言えるのではないか。そのServerless Frameworkも開発体験そのものが良くなるものかと言われるとそうではない。
また、多くはフレームワークと言いつつIaCよりなものが多い印象だ。
そんな中、AWSからは新たにAWS Application Composerというのが提供されたがまた試行錯誤の新しいものが出てきたっていう印象しかない。道のりは長い。
そういう意味ではサーバーレスネイティブなWebアプリケーションフレームワークが欲しくなってきて、実際にそういうものもいくつかある。
AWSが提供するものではPython向けのChaliceのアプローチはやはりそれに近かったと思うし、Ruby向けだとRuby on JetsやSOULsなんてのもある。
ちなみにChaliceとRuby on JetsはAWS前提でSOULsはGoogle Cloud前提となる。
Node.jsだとMidwayってのが良さそうだが残念ながらドキュメントがほぼ中国語。対応するサーバーレスプラットフォームとしてAWS、Alibaba Cloud、Tencent CloudとなっているがサンプルにはAlibabaしか載ってなかった。
それ以外の言語だとあるのかどうかも知らない。
でもサーバーレスって結局ベンダ依存なのでそこを対応しようとすると使いにくいものになりそうな予感するし利用者が少なくて広がらないというのが実情だろう。
これは実は同じような話が人的な部分にもあって、仮にAWSでAPI Gateway + Lambda + DynamoDBで全部作ろうとすると結構大変だ。シンプルなものを作るならともかく、それなりの規模でそれなりに複雑なものを作ろうとするとサーバーレスで作るための専門的な知識がそこかしこで必要になってくる。
こういう専門的な知識を持つ人を抱える必要があるという点で、実は運用性や利用料としてのコストメリットはあるかもしれないが実は人的にはコストがかかるのではないかと思える。
サーバーレスで大規模なシステムを作るには大企業じゃないとってなるとそれはそれで皮肉な話。そもそも大規模なシステムをAWS Lambdaとかで作ろうとするとファンクションの数が多すぎて辛すぎるだろう。
追記 ---
ここまでの話はあくまでもWeb APIの話だ。fukabori.fmの中でも話したがサーバーレス、というよりもFaaSが一番向いているのはやはりイベント・ドリブンなシステムだと思う。
実際の現場でもメインのWeb APIはLambdaを使ったサーバーレスは採用しなかったと述べたが実はその周囲のパイプライン系のシステムなどはStep FunctionsとLambdaを使ったフルサーバーレスに近いものとなっているというのを付け加えておく。
サーバーレスの未来
という感じであーだこーど言ってきたのですが、そうは言っても個人的には『Everything will be serverless』を信じてます。
あとはFaaSとかのサーバーレスサービスはどちらかというとPrimitiveなサービスになっていってそれ上に直接アプリケーションをデプロイするのではなくて、それらの上に別のプラットフォーマーがプラットフォームを構築してくれてSDK的にフレームワークを提供してくれるといいのかもしれない。
あれ、これってまんまVercelとNext.jsじゃん。
