Lambda 関数の呼び出し回数が 2 年前の 3.5 倍に増加

AWS Lambda はインフラストラクチャーに捉われない拡張性の高いアプリケーションを構築できることが特徴で、開発者のイノベーションを加速させます。今日、チームは単にサーバーレスを実験的に使うだけではなく、ソフトウェアスタックに欠かせない要素として採用しています。実際、当社の調査によると、2019 年以降に Lambda を使い始めた企業ではその使用量が大幅に増加しており、2021 年初頭には 1 日あたりの関数の起動回数が 2 年前に比べて平均 3.5 倍にまで増加しました。さらに、Lambda ユーザーの同じコホート内では、各組織における関数は平均して 1 日に合計 900 時間稼働していました。

TWEET SHARE

Azure Functions と Google Cloud Functions の勢いが加速

AWS Lambda を火付け役として勢いを増したサーバーレス・ムーブメントですが、Lambda が唯一の選択肢ではありません。Azure Functions と Google Cloud Functions も、それぞれのクラウドプラットフォームにおける採用を加速させています。過去 1 年間で、Azure Functions を利用している組織の割合は 20% から36% に上昇しました。また、Google Cloud に至っては、約 4 分の 1 の組織が現在 Cloud Functions を使用しています。Cloud Functions は 3 つの FaaS のうち最後に登場したサービスですが、Google Cloudにとってサーバーレスは新しい概念ではありません。Google Cloud プラットフォームは 2008 年に最初の完全なサーバーレスコンピューティングサービスである Google App Engine を導入しています。しかし現在では、Google の新しいサーバーレスサービスである Cloud Functions と Cloud Run に勢いが移ってきていると言えます。

TWEET SHARE

1 年前と比べて、Lambda 起動時間の大幅短縮を実現

低レイテンシーを必要とする顧客向けのアプリケーションを動作させるために、Lambda の利用率はますます増加しています。2020 年には、Lambda の呼び出し時間の中央値は 60 ミリ秒で、前年の約半分に短縮されました。これは、Lambda のベストプラクティスに基づき、ワークロードに合わせて機能を設計する企業が増えたことで呼び出し時間が短縮されたためと考えられます。また、レイテンシー分布の末尾が長いことも見逃せません。これは、Lambda が短時間のジョブだけではなく、より計算量の多いユースケースにも対応していることを示唆しています。

TWEET SHARE

Web アプリケーションからデータパイプラインまで、Step Functions があらゆる場面で活躍

AWS Step Functions は、開発者が複数の Lambda 関数や AWS サービスを組み込んだイベントドリブンなワークフローを構築することを可能にします。これらのワークフローの中で、Step Functionsはエラー処理、再試行、タイムアウト、その他のアプリケーションロジックを調整し、サーバーレスアプリケーションの拡張に伴う運用の複雑さを軽減します。当社の調査によると、Step Functions の平均的なワークフローには 4 つのLambdaファンクションが含まれており、この数は月を追うごとに増加しています。

Step Functions では「Standard」と「Express」という 2 種類のワークフローを利用することができます。ワークフローの 40% 以上が 1 分未満で実行されていることから、大量のイベント処理ワークロードをサポートするためにExpress ワークフローを使用している企業が多いと考えられます。しかし、多くのワークフローが短時間で実行される一方で、1 日以上かかるワークフローもあります。実際、最も長いステップファンクションのワークフローは 1 週間以上実行されます。Step Functions のワークフローには、例えば Amazon ECS や EC2 インスタンス上で動作するアクティビティワーカーを含めることができるため、Lambda 関数のタイムアウトである 15 分を超えて関数を実行することができます。このような理由で、Step Functions は Web リクエスト処理のようなレイテンシーが重要なタスクから、ビッグデータ処理のように複雑で長時間実行されるジョブまで膨大な数のユースケースをサポートすることができるのです。

TWEET SHARE

CloudFront ユーザーの 4 人に 1 人がサーバーレスエッジコンピューティングを導入

データ処理を確実に高速化できるエッジコンピューティングは、今かなりの旋風を巻き起こしています。現在、Amazon CloudFront を利用している企業の 4 分の 1 は、Lambda@Edge を活用して世界中のユーザーによりパーソナライズされた体験を提供しています。例えば、Lambda@Edge を通じてユーザーの特徴 (デバイスタイプなど) に基づいて画像を動的に変換したり、A/B テスト用に Web アプリケーションの異なるバージョンを生成したりすることができます。

TWEET SHARE

Lambda@Edge は、CloudFront のエッジロケーションのネットワークを活用することで、オリジンサーバーの設定や管理の複雑さに悩まされることなく、エンドユーザーにより親しみやすい形で機能を実行することができます。当社のデータによると、Lambda@Edge の機能の 67% が 20 ミリ秒以下で実行されており、サーバーレスエッジコンピューティングは「最もレイテンシーが重要なアプリケーションでも、最小限のオーバーヘッドでサポートできる」という大きな可能性を秘めていることを示しています。この技術が成熟するにつれ、エンドユーザーの体験を向上させるために Lambda@Edge を利用する企業がさらに増えることを期待しています。

TWEET SHARE

機能のほとんどで Provisioned Concurrency の過剰利用を確認

Lambda 関数を一定期間使用していなかった場合、呼び出し時にコールドスタートと呼ばれる短い実行遅延が発生します。しかし、ミリ秒レベルの応答時間を必要とするアプリケーションではコールドスタートは望ましくありません。そこで 2019 年末、AWS は Provisioned Concurrencyを導入し、実行環境を初期化してリクエストに応答できる状態に保つことで、Lambda ユーザー向けのコールドスタート対策を実施しました。

当社のデータによると、Lambda 関数に最適な量の Provisioned Concurrency を設定することは、ユーザーにとって既知の課題となっているようです。関数の半分以上が、設定された Provisioned Concurrency の 80% 未満しか使用していない一方で、割り当てのすべてを使用している関数は 40% 以上にのぼります。これは、依然としてコールドスタートが発生する可能性があり、さらに多くの同時実行を行うことでよりメリットが得られることを意味しています。アプリケーションのオートスケーリングを利用し、使用率に応じて Provisioned Concurrency を自動的にスケーリングすることでこれらの問題を回避することができます。

TWEET SHARE

また、これらのランタイム特有の性質から、Provisioned Concurrency は Python や Node.js よりも起動時間が遅いJava や .NET Core 関数でよく使用されていることがわかっています。例えば、Java ではユーザーコードを実行する前に仮想マシン (JVM) を初期化し、さまざまなクラスをメモリにロードする必要があります。

Serverless Framework は、Lambda アプリケーションを AWS CloudFormation で展開するための優れた選択肢

サーバーレスアプリケーションの規模が大きくなると、Lambda 関数やその他のリソースの手動デプロイはたちまち複雑化します。AWS インフラストラクチャーやサードパーティのリソースを (スタックと呼ばれる) コレクションにプロビジョニングできる AWS CloudFormation は、AWS Cloud Development Kit (CDK)、AWS Serverless Application Model (SAM)、Serverless Framework などのフレームワークの基本的なデプロイメントメカニズムです。

中でもオープンソースの Serverless Frameworkは圧倒的に人気があり、現在、AWS CloudFormation でサーバーレスリソースを管理している組織の 90% 以上で使用されています。Serverless Framework 以外では、19% の組織が Vanilla CloudFormation、18% が AWS CDK、13% が AWS SAM を使用しています (注: 各組織で複数のデプロイメントツールを使用している可能性があるため、これらの値の合計は100%を超えています)。

TWEET SHARE

サーバーレスアプリケーションで使用されている CloudFormation スタックの 65% には、 Lambda 関数が 1 つしか含まれていません。さらに、関数全体の過半数 (57%) は、CloudFormation でデプロイされていません。これは、多くの組織が、Infrastructure as Code によるサーバーレスワークフローの自動化と最適化の初期段階にあることを示唆しています。しかし、Kubernetes や Amazon Elastic Container Service (ECS) などのオーケストレーターが大規模なコンテナ群を管理するのに不可欠となったように、サーバーレスアプリケーションを大規模にデプロイする上で Infrastructure as Code ツールはより重要な役割を果たすようになると予想されます。

TWEET SHARE

Python は、特に大規模環境で最も人気のあるLambda ランタイム

2018 年以降、Lambda は Node.js、Python、Java、Go、.NET Core、Ruby の 6 種類のランタイムサポートを提供しています。しかし、Lambda ユーザーの間では Python と Node.js が引き続き優勢で、これらが関数の90% 近くを占めています。導入された Lambda の 58% が Python (前年比 11 ポイント増)、また 31％ が Node.js を実行しています (前年比 8 ポイント減)。

TWEET SHARE

環境の規模別にランタイム使用率の内訳を調査したところ、興味深い傾向が明らかになりました。小規模な AWS 環境では Node.js が Python を上回っていますが、環境の規模が大きくなるにつれて Python の人気が上がっていたのです。最大規模の AWS 環境を持つ企業では、 Python が Node.js の 4 倍も使用されています。

TWEET SHARE

2021 年 3 月時点での、バージョン別上位ランタイムは次の通りです。

1. Python 3.x
2. Node.js 12
3. Node.js 10
4. Python 2.7
5. Java 8
6. Go 1.x
7. .NET Core 2.1
8. .NET Core 3.1

Python で書かれた関数のうち、90% 以上が Python 3 を使用しており、バージョンでは Python 3.8 が最も人気です。Python 2.7 は 1 年前に比べて 25 ポイント減少しており、ユーザーの Python 3 への移行が進んでいます。また、AWS は 2021 年 5 月に Node.js 10 のサポートを終了する計画を発表しており、Node.js 12 だけでなく、新たにサポートが開始された Node.js 14 の利用も増えることが予想されます。Java に関しては 2019 年後半から Java 11 のサポートが始まったにも関わらず、Lambda ユーザーの間では Java 8 が Java 11 の 5 倍の人気を誇っています。