年次のre:Inventで、AWSはFunction-as-a-Serviceを提供するLambdaのいくつかのアップデートを発表した。新しく発表された機能は、課金、メモリ容量、およびコンテナイメージのサポートを中心とした進化だ。
AWSサービスの請求は、TCOに関して重要な側面だ。Lambda関数の時間の課金の粒度が100ミリ秒から1ミリ秒に短縮されたことで、短時間の関数に対する顧客への請求が少なくなる。同社は、計算時間は、呼び出しごとに最も近い100ミリ秒の増分に切り上げられるのではなく、1ミリ秒の増分で請求されると発表した。前者は、2014年のLambdaの発売以来の課金モデルだった。
Amazon Web Servicesのチーフエバンジェリスト (EMEA) であるDanilo Poccia氏は、新しい1ミリ秒の課金粒度に関するブログ投稿でサンプルを提供している:
以前の100ミリ秒の切り上げ価格でのLambdaの月額計算料金は次のようになります:
60 million invocations * 100ms * 1G memory * $0.0000166667 for every GB-second = $100
新しい1ミリ秒の課金粒度では、期間のコストは次のとおりです:
60 million invocations * 28ms * 1G memory * $0.0000166667 for every GB-second = $28
また、Duckbill GroupのクラウドエコノミストであるCorey Quinn氏は、ツイートで次のように述べている:
ああ、今公開されています! Lambda呼び出しの課金粒度が100ミリ秒ではなく1ミリ秒になりました。これにより、頻繁に呼び出される小さな関数に多くのお金を節約できますが、プログラミングが苦手なので、巨大な恐ろしい関数にはほとんどお金を節約できません。#reinvent
出典: https://www.reddit.com/r/aws/comments/k9svpy/why_would_we_save_79_with_the_switch_to_lambda/
12月以降、中国リージョンを除き、AWS Lambdaが利用可能なすべてのリージョンでLambda関数に対して1ミリ秒の課金粒度が利用可能になる。
AWS Lambdaの新しい請求に加えて、同パブリッククラウドプロバイダは、顧客が最大10,240 MB (10 GB) のメモリでLambda関数をプロビジョニングできるようになったと発表した。これは、以前の制限である3,008 MBの3倍以上の増加だ。バッチ、抽出、変換、ロード (ETL) ジョブ、メディア処理アプリケーションなど、メモリを大量に消費する操作を実行するワークロードの場合、メモリの増加が役立つ。さらに、Lambdaはプロビジョニングされたメモリの量に比例してCPUパワーを割り当てるため、顧客は最大6つのvCPUにもアクセスできる。これは計算量の多いアプリケーションに役立つ。
追加のCPUパワーと追加のメモリにより、関数呼び出しの時間が短縮され、コストが削減される。別のブログ投稿で、Poccia氏はコスト削減について説明している:
Lambdaの料金はメモリと時間に関連しているので、メモリを増やし、これが同じ割合で時間を減らしている場合、全体の料金はほぼ同じです。たとえば、上のグラフを見ると、5 GBのメモリを構成すると、1 GBのメモリを使用する場合と同じコストがかかります (100万回の呼び出しで約$ 61) が、関数は5倍高速です。より低いレイテンシーが必要な場合は、メモリを最大10 GBまで増やすことができます。この場合、関数は7.6倍高速で、少し支払いが増えます (100万回の呼び出しで80ドル)。
AWS Management Console、AWS Command Line Interface (CLI)、AWS SDK、およびServerless Application Modelを介して、ユーザは新規または既存のLambda関数用に最大10 GBのメモリを設定できる。また、追加のメモリとコンピューティングのサポートは、さまざまなAWSリージョンで利用できる。
AWS Lambdaの1ミリ秒の課金粒度とより多くのメモリに加えて、同パブリッククラウドプロバイダは、パッケージ形式としてのコンテナイメージのサポートも発表した。これにより、顧客はAWS Lambda関数を最大10 GBのコンテナイメージとしてパッケージ化してデプロイできる。
出典: https://aws.amazon.com/blogs/aws/new-for-aws-lambda-container-image-support/
AWSは、最大10 GBをパッケージ化する機能を備えており、機械学習やデータ集約型ワークロードなど、かなりの依存関係に依存する大規模なワークロードを顧客が迅速に構築およびデプロイできるよう支援したいと考えている。さらに、Poccia氏の別のブログ投稿によると、コンテナイメージとしてデプロイされた関数は、同じ操作の単純さ、自動スケーリング、高可用性、および多くのサービスとのネイティブ統合の利点がある。
同パブリックベンダは、サポートされているすべてのLambdaランタイム (Python、Node.js、Java、.NET、Go、Ruby) のベースイメージと、開発者がLambda Runtime APIの独自のランタイム実装を含めるように拡張できるAmazon Linuxベースのカスタムランタイムのベースイメージも提供する。さらに、ベースイメージの構築を容易にするために、サポートされているすべてのランタイムにRuntime APIを実装するLambda Runtime Interface Clientsを使用できる。
Lambda Runtime Interface Clientsの次に、オープンソースのLambda Runtime Interface Emulatorが利用可能になった。これにより、開発者はコンテナイメージのローカルテストを実行し、Lambdaにデプロイしたときに実行されることを確認できる。エミュレータは、AWSが提供するすべてのベースイメージに含まれており、AlpineやDebian Linuxベースのイメージなどの任意のイメージで使用できる。さらに、開発者はLambda Extensions APIを使用して、モニタリング、セキュリティ、その他のツールをイメージ内のLambda実行環境と統合することもできる。
Hacker Newsのスレッドの回答者は、イメージのAWS固有のカスタマイズについてコメントしている:
コンテナ化の全体的なポイントは、さまざまなサービスやプラットフォーム間での移植性です。それでもコンテナ内でプラットフォーム固有のカスタマイズが必要で、チームが「コンテナのサポート」を売り込むのは大きな失敗に思われる。
開発者は、コンソール、AWS Command Line Interface (CLI)、AWS SDK、AWS Serverless Application Model (SAM)、 AWS Cloud Development Kit (CDK)、AWS Toolkits for Visual Studio、VS Code、およびJetBrains、およびDatadog、HashiCorp Terraform、PulumiなどのAWSパートナのソリューションを使用してAWS Lambdaのコンテナイメージサポートを使用できる。さらに、Lambdaのコンテナサポートは一般利用可能であり、いくつかのAWSリージョンにある。価格に関しては、ECRリポジトリの料金と標準のLambda価格のみを支払う。
最後に、AWSはAWS Protonと呼ばれる別のサービスもリリースした。これにより、ユーザはLambdaアセットを管理し、インフラストラクチャの状態を監視してコードの更新をロールアウトするための単一の場所を提供できる。さらに、Amazon CloudWatch Lambda Insightsが一般提供されるようになり、ユーザはAWS Lambda関数のパフォーマンスを監視、トラブルシューティング、最適化できるようになった。