Zenn
📜

AWS Lambdaの9年間を振り返る

2023/12/25に公開
Lambda
AWS Lambda
tech

この記事はAWS Lambda と Serverless Advent Calendar 2023シリーズ1、24日目の記事です。

今回はポエムに近いです。
テクニカルなことは出てきますが、過去のものだったりするので、注意です。

AWSJのSAの下川さんが素晴らしい記事を書かれているので、こちらもご覧ください
https://qiita.com/_kensh/items/9e0ed0154e2ddfb3f25d

AWS Lambdaについて

登場は、AWS re:Invent 2014でした。

https://press.aboutamazon.com/2014/11/amazon-web-services-announces-aws-lambda

動画もあります。
https://www.youtube.com/watch?v=_qh8t-fPU1I

詳しくは公式サイトを参照してください！っていうのも寂しいので、
せっかくなので、Amazon BedrockのClaud v2.1に聞いてみました。

 AWS Lambdaは、サーバーのプロビジョニングや管理が不要なサーバーレスコンピューティングサービスです。主な特徴は以下の通りです。

- コードをアップロードするだけで、自動的にコンピューティングリソースがプロビジョニングされる。
- リクエストが来た時のみコードが実行されるため、リクエストがない時は料金がかからない。
- 並列実行が最大1000万リクエスト/秒まで自動的にスケールする。
- 他のAWSサービスとの連携がしやすい。

用途としては、サーバーレスアプリケーションの作成、データ処理パイプラインの実行、他サービスとのイベント駆動型の連携などがあげられます。コード実行環境としてNode.js、Python、Java、C#などがサポートされています。

料金は、実行時間とメモリに応じた従量課金なので、スケールに合わせた最適なコストが実現できます。管理コストやサーバープロビジョニングコストが不要な点も大きなメリットです。

まあまああっているかな。

ちなみに、自分の中ではこんな感じで

• AWS Lambdaは現状、FaaS（Function as a Service）の代表格とも⾔える AWSのコンピューティングサービスです。
• マネージメントコンソールやAPIを利⽤して、コードのアップロードするだけで、実⾏することができます。
• つまり、開発者はサーバーの構築、管理は⼀切不要で、コードの実装のみに集中することができます。
• また、リクエストに応じて、⾃動的にスケーリングを⾏ってくれます。
• リクエスト毎の課⾦となるため、関数が実⾏されない時には、⼀切料⾦が発⽣しません。そのため、AmazonEC2を利⽤した場合に⽐べて⼤幅に料⾦が下がるケースもあります。
(弊書基礎から学ぶサーバーレス開発 SECTION-004より)

個人的には、コンソールのメニューにある「サーバーのことを考えずにコードを実行する」というフレーズが好きです。

さて、進化の歴史を振り返ってみたいと思います。

ランタイム

まずはランタイムベースでのアップデートを振り返ります。
なお、サポートされているランタイムおよびそのバージョンについては以下をご覧ください。
https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html

ランタイムとしては、

  • Node.js
  • Java
  • Python
  • Ruby
  • Go
  • C# (.NET Core)
  • PowerShell (.NET Core)

Node.js

登場当初から使えるランタイムです。
登場当初のランタイムのバージョンは、 Node.js 0.10 でした。

その後のランライムのサポートは以下です。

Node.js自体のアップデートに伴って、EOLになっていくランタイムが出てきます。
Node.jsの場合、新しいランタイムが出てくると、しばらく共存して、古いランタイムがEOLになります。

2023/12現在、Node.js 14.x、16.x、18.x、20.xの4つが選べますが、
すでに、Node.js 14.xは非推奨化、Node.js v14は2024/6/12に非推奨になることがアナウンスされています。

なお、他のランタイムにも言えることですが、
EOLになったからと言って、使えなくなるということではないです。
ただ、そのランタイムを更新することはできないので、更新する場合は、必然的にアップデートが必要になります。
ランタイムのバージョンを変えれば動くというレベルで済めば嬉しいですが、そうもいかなかったりするので、
アップデートの際にはテストを忘れずに！

Java

JavaはNode.jsに続いてサポートされたランタイムです。
2015/6/15にサポート開始がアナウンスされました。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-releases.html

2015年に登場したのはJava8でした。

その後のランライムのサポートは以下です。

提供開始当初のランタイムであるJava8(Amazon Linuxベース)が2023/12/31に非推奨になることがアナウンスされています。
AWSが提供するOpenJDKであるCorrettoのJava8のランタイムはまだ提供が続けられるようです。

Python

PythonはNode.js、Javaに続いて、提供されたランタイムで、
2015年のre:InventでVPC Lambda等とともに発表されました。

https://aws.amazon.com/jp/blogs/aws/aws-lambda-update-python-vpc-increased-function-duration-scheduling-and-more/

その後のランライムのサポートは以下です。

Node.jsほどではないですが、バージョンアップされていますね。
2023年に入って3.10と3.11、3.12が立て続けにサポートされてたんですね。

すでに、Python2.7、Python3.6はEOL、Python3.7も2023/11/27に非推奨化されています。

あまり使っていない以下のランタイムはちょっと怪しいかもしれませんが、続けます。

C# / .NET

2016年、Pythonの次に提供されたのは、C#(.NET Core 1.0)でした。
https://aws.amazon.com/jp/about-aws/whats-new/2016/12/aws-lambda-supports-c-sharp/

すでに.NET Core、.NET5はEOL、.NET7(これもコンテナイメージ)は2024/5/14に非推奨化がアナウンスれています。

Ruby

Rubyのサポート開始は、2018/11/29でした。
https://aws.amazon.com/jp/about-aws/whats-new/2018/11/aws-lambda-supports-ruby/

その後は、

Ruby2.5はすでにEOL、2.7も2023/12/7に非推奨化されています。

Go 1.x

Goのサポート開始は2018/1/15でした。
https://aws.amazon.com/jp/about-aws/whats-new/2018/01/aws-lambda-supports-go/

長らくGo1.xのみサポートされておりましたが、Amazon Linux1ベースのコンテナでの起動のため、
2023/12/31をもってGO1.xのランタイム自体も廃止されます。珍しいパターンですね。
Go2.xのランタイムは提供されませんが、Amazon Linux2のカスタムランタイム上でGo2.x関数を実行することができるようです。

他にもカスタムランタイムがありますが、割愛します。
ちなみに、PHPを使う場合はカスタムランタイムを使う必要があるようですが、結構大変っていう話を聞いたことがあります。

ランタイム以外で注目すべきアップデートに関して、触れたいと思います。
(個人的に注目したものなので、他にもいっぱいありますので、)

VPC Lambda

2016年2月にVPC内でLambdaを起動できるようになりました。
ただ、登場当初は起動時にLambdaが起動するコンテナにENIをアタッチしていたため、
ColdStart時にinit処理に最長で1分程度かかっていました。
これがネックになるケースもありました。

2019年の改善

2019年、それにようやく改善することになりました。
デプロイ時にSecurity Group単位でENIがアタッチされるようになりました。
起動時にはENIがアタッチされた状態で実行されるので、起動が画期的に速くなりました。
ただし、ENIが足りなく無くなるような大量のLambdaの起動が発生した場合は、別途ENIアタッチは発生しますが、
それでも著しい改善になり、
この改善で、RDSとの組み合わせはアンチパターンと言われていたのが、解消されました。(のはず)

RDS Proxy

こちらも2019年のre:Inventで発表されたサービスですね。
Previewで使えていて、2020年の7月にGAされたサービスで、
RDSのコネクションプーリングの機能です。
わかりやすい例だと、Lambdaが大量に起動された場合にコネクションを使い切ってしまい、接続できなくなってしまう。
というのを解消できる機能ですね。

RDS側の機能なので、AWS Lambdaだけではなく、EC2やECSからの接続にも使えます。

Provisioned Concurrency

2019年のVPC Lambdaのアップデートで、起動だいぶ早くなりましたが、
前述した通り、それでも大量のリクエストがあった場合にはENIアタッチが発生するケースがあります。
それを防ぐために、事前に大量のコンテナを起動した状態にしておくという機能です。
やってみた記事はこちら。

https://qiita.com/keni_w/items/f284a1bac64830a826dd

なお。Provisioned Concurrencyで起動されたLambdaは無料利用枠対象外になります。
上記の検証した時に、個人アカウントで初めてLambdaの料金が発生して、感動した記憶あります（普段使う場合は無料利用枠使い切らないので）

似て非なるもので、Javaランタイム専用でSnapStartという起動の高速化機能もありますが、
Javaランタイム専用な上で、同時リクエストには対応していないので、同時実行が必要なケースはProvisioned Concurrencyが必要です。

Lambda Function URLs

2022年4月に登場したAWS Lambda自体にAPIエンドポイントを
API Gatewayを使うほどではないケース(使い分けは重要です)で活用できます。
VPC Lambdaにもエンドポイント作れてしまうって話もありますが。

搭乗時結構いろんな方が試されていて、自分も面白いなと思って、AWS CDKで設定してみたり、
ハンズオン作ってみたりしました。

ループ検知

最近のアップデートで一番熱かったのはこれかな。
Lambdaでトリガー実行したことがある方なら一度はやったことがある、Lambdaの無限ループ。
私もあります。

このアップデートは、
SQSとSNSでのトリガー実行の際に、ループを検知した場合に自動的に停止してくれるというものです。
ただね・・・自分はS3トリガーでやらかしたんですよね。
※聞いた限り、周りでもS3トリガーのケースが多いようです。

とはいえ、興味深いアップデートだったので、やってみたのがこちら。

https://zenn.dev/keni_w/articles/acbfd69a2c7dbb

いや、ちゃんと止まるんですねー(おいおい)

S3トリガーのケースでもSQSとか間に挟むことで回避はできそうな感じはあるので、S3トリガー使うな？ってことなんですかねぇ・・・。

他にもありますが、とりあえずこんなところで。

アップデートに関しては、検索すれば出てきますが、以下のサイトも参考にしました。

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-releases.html

AWS Lambdaに出会って人生が変わった1人の９年間

前の職場で、ちょっとAWSを触ったのがきっかけで、JAWS-UGにも参加するようになりました。
そして、運営もやってみたいということで、JAWS-UG千葉支部の運営に参加することにもなりました。(現在も)
運営初参加の勉強会がこちら。2015年9月の「JAWS-UG 千葉支部 Vol.5 ～秋のAWS Lambda & API Gateway 祭り！！～」でした。
https://jawsug-chiba.doorkeeper.jp/events/29864

ここで色々な話を聞いて、AWS Lambda使って仕事したい！って思うようになって、現在の会社に転職することに。

結構初期にVPC　Lambda使ってた

転職した当初、担当した案件がVPC Lambdaを使った案件でした。
事例化とかされていませんが、結構最初の方で使っていたんじゃないかなと思っています。

ちなみに構成はこんな感じ。
よくある構成かと、そして、みた方はお気づきになると思いますが、まあ色々ありました。

API Gatewayが先にタイムアウト

上記した通り、稼働当初というか2019年のアップデートまでは、VPC Lambdaの起動時にENIがアタッチされるので、
API Gatewayが先にタイムアウトしてしまう事象が頻繁に発生しました。
その対処としては、とりあえず、定期的にLambdaを実行させる。いわゆるポーリングを仕掛けていました。
ポーリング用のインスタンスとか作ってCronで実行ってめっちゃ古典的な方法でした。
今は不要(他の手段で回避可能だし、別の方法ありそう)なので、もう二度と使わないでしょうね。

魔の9月、10月

あまり外で話したことないんですが、
re:Invent前に色々と不具合が起きるということがありました。
大抵9月〜10月に起きていたので、魔の2ヶ月と呼んでました。
いや、ほんと不思議でしたね。
サポートに問い合わせてもそんな事象、他では起きていないって言われるし。
まあ、re:Invent前なので、色々アップデートしてたのかな？って思っていました。

アップデートで苦戦

稼働当初はNode.js v4.3で構築していましたが、
v6.10、v8.10へのバージョンアップを行いました(この後プロジェクトから離脱)
同期処理をうまくやるために、モジュール追加してたら、そのせいでアップデートうまくいかなかったりして、
すんなりいかなかったイメージあります。

ちなみに、同期処理についても、今はasync/awaitとか使えば、うまくできるのでだいぶ楽になりましたね。

本を書いた

そして、一番大きいのは、やはり本を書いたことじゃないかと。

https://www.c-r.com/book/detail/1352

昔からお世話になっていた、数多くのAWS関連の書籍を執筆されているNRIネットコムの佐々木拓郎さんから、
絶対本書いた方がいいから！って言われたこともあり、
会社内で募集がかかったので、手を挙げてみました。

いやはや、ほんと大変でした。
2019年10月ぐらいから執筆スタートし、途中で、re:inventがあるのはわかっていたので、アップデートは覚悟して執筆に入りましたが、
そのアップデートを盛り込んだり、
執筆が遅れて、その間に別のアップデートが入ったりして、なんだかんだ、最終校まで修正してたと思います。
RDS Proxyも盛り込んでいたのですが、一通り執筆終えて、チェック段階に入った時にGAされたので、大慌てで、「今はPreviewですよ」的な文言を外したりしてましたね。
しかし、佐々木さんの言ってた通り、自分で書く、他の方が書いた内容を読むことで、大変勉強になりましたし、すごく良い経験になりました。

一応界隈の方にそれなりに注目していただけたと思っています。

もう3年経って、だいぶアップデートされて、内容は陳腐しかしていると思いますが、
最近、懇親会で、めっちゃ助かりましたってコメントをいただけたことがあったので、よかったです。

え、印税生活？できるほど売れませんでした（笑）

できれば、改訂したいんですけどね。無理だなぁ・・・(別の本出した方が早そう)

今

今なお、AWS Lambdaは一番好きなサービスです。 他にもいいなと思うサービス、Amazon Location Serviceとか出てきましたが、
好きなサービスのNo.1であることは変わらないです。

まとめ

来年はAWS Lambda登場10周年です。(なぜ今年書いた？w)
日本でもなんかイベントあるのかな？と思いますし、あったら何らか関与したいなって思う今日この頃です。

そういえば、Step Functionsとかめっちゃ進化してて、そのうちLambda入らなくなるんじゃない？って思ってたりしますが、
どうなるんでしょうか・・・。

Discussion