本投稿はServerless Advent Calendar 2020の22日目です。
さらに、2020年12月23日の21時から開催予定のイベント(ライブストリーミング)で話す内容でもあります。もしお時間があればぜひこちらにもご参加ください。登録はこちら。
はじめに
今年は新型コロナウィルスによるリアルイベントの開催が難しくなったこともあって、僕自身としてもいろいろと変化がありました。このイベント自体もその1つといえ、自分のペースで好き勝手にオンラインで配信するという新しい形態になりました。
ま、立場上、他のクラウド事業者のサービスに言及するのは難しかったりするのですがAWSのものだけでもボリューム的にお腹いっぱい感あるので自身のキャパ的にもちょうどいいのかもしれません。というわけで年内最後はゆく年くる年ってことで今年の総括ならびに来年の展望なんかを徒然なるままに書いていきます。ポエムです。ポジショントークと言われるかもですが公私混同気味にいきます。
さて、今年の冒頭にこのようなツイートをしました。
今年がサーバーレス元年な理由. それはLambdaに以下が揃ったから.
— Keisuke Nishitani (@Keisuke69) 2020年1月19日
・カスタムランタイムで実質どんな言語でも利用可能
・VPC利用時のコールドスタート改善
・Provisioned Concurrencyでスパイク対応も可能
・RDS ProxyでRDBとの接続が現実的に
これまで5年で受けたフィードバックがついに結実. 強い
それは去年から今年にかけて発表されてきた数々のアップデートを踏まえた率直な感想でした。思えば2014年、AWSに入社した年のre:InventでAWS Lambdaが発表されてから今年で丸6年になります。当時、入社直後にこのサービスのコンセプトを知って興奮したことを今でも覚えていますし、僕のAWSJでの6年間はポジションややることは変わりつつもほぼサーバーレスとともに歩んだ6年間と言っても過言ではないです。
そんなサーバーレスの2020年を振り返るにあたって、各サービスの今年のアップデート数をカウントしてみました。なお、僕がサーバーレスといった場合の対象範囲はAWS Lambda、Amazon API Gateway、AWS Step Functionsを中心としています。いろんな観点ではAmazon EventBridgeなどもあったりするのですが、一旦そのあたりは置いておいて。また、Amazon DynamoDBなどは一緒に使うことの多い関連サービスって位置づけです、僕の中では。
さて、早速数えてみます。What's Newでアナウンスされた件数です。多少の漏れはあるかもしれません。
サービス | アップデート数 |
---|---|
AWS Lambda | 40 |
Amazon API Gateway | 13 |
AWS Step Functions | 14 |
こうやってみると数としてもLambdaが圧倒的ですね。というわけで、2020年の発表の中で個人的に熱い発表ベスト3をLambdaから、API GatewayとStep Functionsは1つずつ選んで紹介したいと思います。
AWS Lambdaのアップデート3選
Lambdaに関しては40もアップデートがあったので、3個選びたいと思います。あくまでも僕個人の意見ですからね。
Lambda Extensions
AWS Lambda Extensions: a new way to integrate Lambda with operational tools (in preview)
1つ目はLambda Extensionsですね。これはサードパーティを含む各種運用ツールを統合しやすくなったというものです。既に使えるようになってるサードパーティには有名どころ、例えばNew Relicとかが使えるようになってますね。これの何が嬉しいかっていうと、今回を機にこれまでは難しかったLambdaのライフサイクルに外部から関与することが可能になりました。ここで言っている『外部』というのはAWS以外のデベロッパーが、という意味です。
といってもよくわからないかと思うのでもう少しお話すると、まずLambda Extensionsと一言でいっても2つの種類があります。External ExtensionsとInternal Extensionsですね。ExternalのほうはLambdaファンクションのランタイムと同じ実行環境内で動く別プロセスとして実行できます。Internalの方は同じプロセスで実行されます。
一番嬉しいのはやはりExternalのほうではないかと思います。これってつまりコンテナでいうところのサイドカー的なアプローチが可能ってことなんですね。これは特にモニタリング用途で有用かと思います。今までサーバでアプリケーションを実行している場合のモニタリングはエージェントを入れることが多かったかと思います。これがコンテナであればサイドカーだったりしたわけですがこれと同じようなことがLambdaでもできるようになったということですね。
これまではLambdaの実行環境にアプローチできるのはAWSのサービス側しかなかったのでこれを個人の開発者含むサードパーティができるようになったのはとても大きいと思います。ログを自分の好きなところに出すようにできたり。
でも、多くの人はそんなにその恩恵を受けることは今すぐにはないかもしれませんw ただし、各種モニタリングサービスなどが対応していくことが期待されるのでサーバーレスアプリケーションのエコシステムの拡充という観点ではとても大きいアップデートだと思っています。
また、Internalの方はExternalとは異なりLambdaファンクションが実行されるランタイムプロセスそのものにアプローチすることが可能なのでランタイムの起動処理をカスタマイズしたりってことが可能になります。
PrivateLinkサポート
AWS Lambda now supports AWS PrivateLink
2つ目はPrivateLinkのサポートです。
もともと、AWS LambdaではVPC内にあるリソースに対してアクセスすることは可能です。ですが、この点について誤解している人がたまにいます。LambdaファンクションからVPC内のリソースにアクセスできるようにしてもファンクションの実行自体はユーザのVPCではなくサービスのVPCで行われます。
この場合、Lambdaファンクションの呼び出しAPIは通常Publicに公開されているInvoke API越しに行う必要があります。つまりLambdaファンクションの呼び出しはインターネット越しに行う必要があったんですね。
それがこの発表にあるPrivateLinkを使うことでVPC内からインターネットを介さずにLambdaファンクションを呼び出せるようになったということです。
これまで非常に厳しいセキュリティ要件をクリアする必要があるシステムでは採用が難しいケースも少なからずあったのですが、このアップデートでまた1つ大きな壁をクリアできるようになったと言えます。特にセキュリティ要件の中には意味があるないといった理屈ではなく、問答無用で対応する必要があったりするものも多々あると思うので…。
課金単位が1msに!
AWS Lambda changes duration billing granularity from 100ms down to 1ms
そして3つ目はつい先日発表のあった課金単位が1ms単位になったというものですね。
2020年のre:Inventではメモリ10GBまで対応したとか6vCPUまで使えるようになったとか、コンテナイメージでパッケージングしてデプロイできるようになったとか数々のアップデートがあったわけですが個人的に一番熱いのはこれです。
1msですよ、1ms。
これまでの100ms単位はまだ改善の余地があると思っていましたが、現状ではこれ以下にするのは意味がないレベルかと思います。
これまでもコードの実行時間のみ、しかも100ms単位なのでコストの効率がいいって話をしてきましたが1ms単位になってこの効率はさらに高まりました。むしろ、アプリケーション側の無駄がこれまで以上にコストに跳ね返るようになったと言ってもいいかもしれません。
恐ろしい時代になったものです。
Amazon API Gateway
API Gatewayは2020年のアップデートが13個だけなので1つだけ選びたいと思います。1つだけ選ぶならこれしかないです。
Amazon API Gateway now supports mutual TLS authentication
mutual TLS (mTLS) のサポートですね。
実はこの機能、今だから言えますがもう数年前から主に金融系のお客様からは強くご要望いただいていたのですがいろんな事情でなかなかサポートされたなかったものなので喜びもひとしおです。
内容的にはいわゆるmTLSをサポートするってだけなのですが、これによりクライアント認証が可能になるんですね。
クライアント認証ってのはつまり、サーバ側からみて接続してくる側(=クライアント)の信頼性を保証できるようになったということです。
ヨーロッパ方面でのOpen Banking APIやPSD2といった仕様やOpenID FoundationのFinancial APIでは必要とされているのでこれらに準拠するAPIを用意するにあたり必須機能だったのです。
いやー、めでたい。
AWS Step Functions
さて、Step Functionsというと最近にわかに注目度が上がっていると感じます。というのもLambdaだけでは大きく複雑なワークロードの実現は難しかったり、手間だったりするのですがそれらをオーケストレーションしたりするのに使われています。もちろんLambdaだけでなく他のサービスもTaskとして使用できます。
そんなStep Functionsの今年の1つを選ぶにあたっては結構悩みました。というのもぶっちゃけ目を引く大きなアップデートというのはなかったので…。というわけでその中でも今回はこれを選びたいと思います。
AWS Step Functions now supports Amazon API Gateway service integration
これはStep FunctionsからAPI Gatewayで作ったAPIを呼び出せるというものですね。
何が嬉しいかっていうとAPI Gatewayで公開されたMicroserviceを呼び出すようなワークフローを実現しやすくなったということです。例えばSagaパターンをStep Functionsで実装することってあると思いますがそういう場合ですね。
あとはワークフローの中で外部APIをコールしたい場合にこれまではLambda経由でコールする必要があったわけですが、シンプルなものであればこれもAPI Gateway経由でコールすることができるようになります。つまりLambdaファンクションの実装と実行時間課金が不要になるのです。
2020年のサーバーレス
今年は個人的にサーバーレスのスペシャリスト兼任をやめたので仕事の観点では割と自由にサーバーレスに取り組めました。
そんな僕の観点からは冒頭のツイートの通り今年はやはりサーバーレス元年だったかなと思います。昨年末はリリース依頼の大きな成長を遂げた年で、そのうえで今年はより強みを増すためのアップデートが多かったかなと。今年はその拡張性を高めるようなアップデートとスペックの両面でのアップデートが目立ったなーという感じです。
これらが大きく現実世界のワークロードとして花開くのは恐らく来年だとも思っています。
また、今年はコロナ禍がきっかけではあったものの結果としてサーバーレス関連のコミュニティは盛り上がったのではないかと感じています。これはサーバーレスに限らないかもしれませんが…。
Serverless Meetupは6月以降はServerless Meetup Japan Virtualとして2週間に1回という高頻度で開催が行われています。これは昨年までと比べて大きな違いかと思います。
手前味噌ですが自分がやっているサーバーレスアンチパターン今昔物語というイベントも7月から月に1回くらいのペースでやれています。こちらはAWS Japan主催のイベントとは異なり完全に個人の趣味なのでちょっと変わった切り口でもできているかと思っております。
ちなみに2019年はLambdaのアップデートは20個だったので年を経るにつれて頻度が下がるどころか2020年は倍増してるってのも興味深いですね。
2021年のサーバーレス
ロードマップ的なところはもちろん置いておいたとして、もっとフロントエンドエンジニアにもサーバーレスが広がってほしいなと思っています。
自分自身としても今年はサーバーレススペシャリストではなくなったこともあり、当初は改めてちゃんとKubernetesに向き合ってみようと思ったもののなぜか夢中になれず。一方で最近はその進化のスピードもどんどんあげているフロントエンド(というかJava Scriptを中心としたフロントエンドWeb界隈)に未来を感じています。
なお、現状ではサーバーレスに携わっている人っていうのは多くはサーバーサイドエンジニアです。これはサーバーレスで作るAPIに関してだけのアンケートですが、総得票291票の55%超がサーバーサイドエンジニアで今までの延長で使うようになったという回答でした。
サーバーレスでAPI開発する人ってサーバーサイドの人がこれまでの延長で始める人が多いのか、フロントエンドの人たちが全部自分たちで作るために始める人が多いのかどちらなのかな🤔
— Keisuke Nishitani (@Keisuke69) 2020年9月2日
次点がインフラの人ですね。これはシステム間のインテグレーションなどをもしかしたらインフラエンジニアがやるようになったのかもしれない。このあたりは深堀りしていないので想像ですが。
この結果自体は僕のTwitterでのアンケートなのでもちろんバイアスもかかっているとは思います。でも現状をある程度示しているのかなとも思います。
その上で、僕としてはフロントエンドの人こそサーバーレスを活用できると嬉しいことが多いと思っています。理由は単にフロントエンドといってもAPIがいることが多いわけで、そこのAPIを作るにはサーバーサイドが必要になるんだけどアプリ的にはJS繋がりでNode.jsを使うにしてもそのサーバを用意したり、スケーラビリティや可用性を確保したりってのはやはりフロントエンドエンジニアは負担が大きい。
また、フロントエンドの文脈で言うとServer Side Renderingなんかはやはりサーバが必要になってくるわけでこれも辛い。
もちろんサーバをお守りする専任の人がいればいいんだけどコスト的にそうもいかないケースであったり、自分たちだけでスピード感もってやってしまいたいケースもあると思います。
そういったときにサーバーレスを活用できるととてもいい世界が広がっているように思っています。
ただし、現状では手放しで喜べる状況にはまだまだなっていないと言えます。プラットフォーム的な制約も少なからずありますが、それ以上にDeveloper Experienceの観点でフロントエンドからはまだまだ使いづらいと感じています。特に各種ライブラリやフレームワークとの連携ですね。
このあたりはAWSのようなサーバーレスなサービス提供者自体が何らかの方法を提供するのか、Serverless Next.js Componentのようにサードパーティが橋渡し役になったほうがいいのかは正直わかりませんが個人的には後者のほうがいいと思っています。
プラットフォームはあくまでもプラットフォームとしてプリミティブなものがいいのではないかと。その上で周辺を取り囲むエコシステムがフロントエンド向けにも拡充していくといいなと願っています。こう書くとAmplifyの話が出てくると思いますが…。
というわけで2021年のサーバーレスもアップデートは続くと思いますが、サードパーティのエコシステムに期待です。
そして僕は『フロントエンド×サーバーレス』な感じでこのあたりの情報発信を続けていこうと思っています。
それではみなさん、これからもどうぞよろしく。