re:Invent 2023の Werner Vogels のセッションスライドを振り返りつつ。
AWS Lambda は、2014年にGAしました。
Lambda 以外にこの年は Auroraや Codeシリーズなども発表されており、大変盛り上がった re:Inventになったことを記憶している人も多いのではないでしょうか。
Cost 効率を度外視して、Lambda 関数のようなものを実装するなら、関数ごとに専用の T2 インスタンスを割り当て、そこに Lambda fx 専用の環境とプロセスを用意すれば良い。
仮に、このような形で、現在までの Lambdaが運用され続けていたとしたらここまで多く利用され気軽にいろいろなユースケースで使える Lambdaにはならなかったでしょう。
やっぱり、、こんなやり方だと utilization percentage が低すぎて、Cost 効率が悪すぎますよね、、、
かといって、別のテナントリクエストを同じ環境で受け付けたら、Isolationが壊れセキュリティリスクが拡大します。
utilization percentage を上げたければ Shared にしたく、セキュリティを高めたければ Isolation したい、、、
このトレードオフ関係にある両者を同時に満たす方法があるのか、、、
2018年に Firecracker が登場します。
Firecracker は Serverless コンピューティングのための軽量な仮想化機能で、上記の問題を解決するために効果的に働きます。
- セキュア – これは常に最優先事項です! Firecrackerは複数レベルの分離と保護を使用し、攻撃面は最小限に抑えられています。
- ハイパフォーマンス – 今日時点でわずか125ミリ秒 (さらに2019年に高速化予定) でmicroVMを立ち上げることができ、一時的なものや短命のものを含む多くの種類のワークロードに最適です。
- Battle-Tested – FirecrackerはBattle-Testedであり、既にAWS LambdaとAWS Fargateを含む複数のハイボリュームなAWSサービスに利用されています。
- 低オーバーヘッド – Firecrackerは、microVMあたり約5 MiBのメモリを消費します。 同じインスタンス上で、さまざまなvCPUとメモリ構成を持つ数千のセキュアなVMを実行できます。
- オープンソース – Firecrackerはアクティブなオープンソースプロジェクトです。私たちはすでにpullリクエストを確認して受け入れる準備を完了しており、世界中の寄稿者とのコラボレーションを楽しみにしています。
Firecrackerを利用することによって、マルチテナンシーを実現し、それにより インスタンスの utilization percentage が非常に効率化します。
かつて、Lambdaの実行時間課金が 100ms 単位だったの覚えていますか？ これは 2msの実行時間であっても、100ms に切り上げて課金されていた時期がありまして。しかし Firecracker を含め Lambda Service としての Cost 効率性向上の努力により 2020年に、1ms 単位の課金に改善しています。
せっかくなので、ここで敬愛する友人であり Momento CEO の Khawaja Shams 氏の “The Five-Factor Serverless“ とも言える有名な The Litmus Test for Serverless を紹介したいと思います。
- Lambda はユーザにインフラストラクチャの管理を意識させません
- 1ms 単位の実行時間ベースの課金
- インスタンスを立ち上げている時間が課金されるわけではない。リクエストベースで課金。
- Sync/ Async ともに、単一 API でコールできます。
- かつて、Lambdaが計画停止したことがったであろうか、、そして今後もあるはずがない。
- そしてメンテナンス Window など設定した覚えがある人はいないはず。
- もちろんインステンス選択はないし、インスタンスを意識しない。
よって、幸せなことに、 “The Five-Factor Serverless“ を2014年時点で達成しており、その効率性は現在においても日々進化を続けています。”Serverless“ という誰も想像もしなかった、まったく新しいパラダイムを切り開き、そしてそのパラダイムは現在ではハイプカーブの安定期、そして普及期を迎えている。デベロッパーは当然のようにシステムのピースとしてあるいは全体として Serverless を利用しています。
Lambda は無限にスケールするのでしょうか？ 実はソフトウエア的にcapがかかっています。Invoke API という Restful API を受け付けた後に Rate limiting をかけています。
re:Invent 2023 でこのスケーリングに関して重要な発表がありました。これまでper アカウント、per リージョンベースでrate limitingされていた Lambda のburstについて、大きな進化となる発表でした。
この進化によって、1000 concurrency /10s の rate でLambdaは Function 単位でスケールします。全リージョンでこのメカニズムがすでに採用されています。
言葉で書くとなかなか伝えにくいですが、この進化こそ クラウドコンピューティングの醍醐味であり、Serverless の醍醐味における ゼロからのスケール、利用がない時はゼロに自動的に戻る Concurrency をこれまでにない速度で実現することが可能になっています。
Lambda は 2020年からContainer Image を利用することによって、最大10GBまでの Artifact を Function 単位にデプロイできるようになっています。
そして、さらに同年、Lambda は 10GB のメモリサイズ、6vCPU を実行環境ごとに得られるようになりました。
これらの事実を組み合わせると、10sで1000実行環境を用意できるので、6vCPU x 1000 = 6000 vCPU を 10秒以内に立ち上げ、関数実行時間が 数秒だとすると数秒後にはゼロまでスケールインする環境を利用できるということです。
そして並列実行の効率的な管理は 2022年に登場した AWS Step Functions の Distributed Map を使うと簡単に Map - Reduce 機構を Lambdaを使って実現できます。ファイル(in S3)、レコード(in Kinesis)、イベント(in SQS)などの形をとる数十万、数百万のデータが高速に運用されるワークロードにおいて、この Lambdaのスケーリングを利用することが可能になっています。
これだけのハイパフォーマンスなイベント駆動環境が手に入る現在においては、多くのワークロードを非同期にしてユーザー体験を損なうことなくシステムとして実現できます。
そして、気がついていない方も多いかもしれませんが、すでに世の中は非同期に組み立てられています。
Lambda は Developer が意識せざるを得なかったさまざまな非機能要件をサービスのケーパビリティとして提供しています。
- Cost
- Availability
- Accessibility
- Performance
- Security
- Resilience
- Sustainability
- Scalability
- Compliance
これらのことを開発者の関心ごとの外に置きたいというのが Serverless の根幹になっています。
ワクワクしてきましたか？ もし読者の方が現在は開発者でないとしても、今が始め時です。Serverless は Serverless Nativeとよばれる builder たちを生み出してきました。オンプレやデータセンター、ハードウエアの経験を持たなくとも関心事の外に置かれた非機能要件の上に、関心事である ビジネス、プロダクト、サービスを構築する新しい世代の developer が多く現れています。
ぜひ、Serverless を使って開発を楽しんでください！
2024年11月13日で誕生10周年になります。何かイベントやりたいなーと思いつつ考えが錯綜してなかなかまとまらないので誰かコンサルしてくれる人を募集しています。 https://twitter.com/_kensh にDMか メンションで何かご意見いただけると嬉しいです。
