各クラウドを運用する組織の半数以上がサーバーレスを導入

Datadog の 2020 年のレポートでは、AWS を利用する Datadog のお客様の半数が、最小限の運用オーバーヘッドでイベント駆動型のコードを実行するために Lambda を採用していることをご報告しました。AWS Lambda のような FaaS 製品の人気が高まるにつれ、Azure、Google Cloud、AWS が提供する他のタイプのサーバーレス技術の採用も大幅に増加しています。

この進化は、サーバーレス化を望む組織が利用できる選択肢の広がりと、サーバーレス技術の活用方法の変化を浮き彫りにしています。たとえば、イベント駆動型のコードを実行するために個々のサーバーレス関数を使用するだけでなく、多くの組織が Azure Container Instances、Google Cloud Run、Amazon ECS Fargate などのサーバーレスプラットフォームにコンテナ化したアプリケーションをデプロイするようになっています。これらのサービスを通じて得られるさまざまなメリットについては、このレポートの後半でさらに詳しく説明します。

注: この実証では、以下の技術のうち少なくとも 1 つを使用している組織を「サーバーレスを導入」と定義しています。

• AWS: AWS Lambda、AWS App Runner、ECS Fargate、EKS Fargate
• Azure:: Azure Functions、AKS (Azure Container Instances 上で動作)
• Google Cloud: Google Cloud Functions、Google App Engine、Google Cloud Run

Lambda ユーザーの間では Python と Node.js が引き続き主流に

以前のレポートでも傾向としてお伝えした通り、Python と Node.js は依然として Lambda ユーザーの間で最も人気のある言語として君臨しています。この 2 つは Lambda が最も早期にサポートした言語でもあり、サーバーレスコミュニティにおいて大規模かつ活発な支持を集めています。一般的に、組織が Lambda を使い始める場合、使いやすさとサポートされるライブラリ、プラグイン、学習教材の幅広さから、Python と Node.js を選ぶケースが多く見られます。その後、Lambda とサーバーレス技術の利点に慣れてくると、Python や Node.js で書かれていない既存のワークロードに移行する傾向が強くなってきます。この理由から、Lambda 関数において Go や Java といった言語の採用が進み、現在では Lambda を導入している組織の 30％ 以上がこの言語を使用しています。

TWEET SHARE

大規模組織の 60% 以上が、3 つ以上の言語で Lambda 関数を導入

Python と Node.js は依然として最も人気のある Lambda ランタイムですが、大規模組織の 63% は 3 つ以上のランタイムで Lambda 関数を導入しています。

この傾向から、サーバーレスアプリケーションの構築に万能なアプローチはないということが分かります。たとえば、エンジニアがすでに慣れ親しんでいるランタイム (Java など) でサーバーレス関数を書くことを好むチームもあるかもしれません。しかし、多くの組織が Java 関数をいくつか採用している一方で、それだけに頼っている組織は非常に少ないのが現状です。つまり、チームはユースケースに応じて異なるランタイムを選択しているのです。たとえば、Go には Goroutine が組み込まれているため、データ圧縮やビデオストリーミングなど、並行処理によって最適化できるワークロードに適しています。

AWS 技術の中でも、Lambda 関数の呼び出し頻度は API Gateway と SQS が最多

Lambda は AWS で最も人気のあるサーバーレスサービスですが、Lambda 関数が単独で実行されることはほとんどありません。その代わり、Lambda 関数は通常、さまざまな AWS サービスから発信されるイベントに応答してコードの小さなチャンクを実行します。Lambda 関数を呼び出す技術の幅はかなり広がっており、各組織が独自のニーズをサポートするために、さまざまな方法で Lambda を使用していることが伺えます。

注: このグラフには、AWS AppSync や Step Functions からの Lambda 関数呼び出しは含まれていません。

たとえば、API の作成とセキュリティを支援するフルマネージドサービスである API Gateway は、Datadog のお客様が実施する Lambda 関数の呼び出しの半分以上を担っています。この事実から、API コールを受け取り、Lambda 関数をトリガーし、レスポンスを返すというこのゲートウェイの機能が、多くのサーバーレス環境で極めて重要な役割を果たしているということが分かります。

Lambda 関数を呼び出す AWS サービスで次に人気が高いのが、アプリケーションのコンポーネント間におけるメッセージの送受信を管理する Amazon Simple Queue Service (SQS) です。SQS はマイクロサービスを切り離し、その間に非同期通信を実装するためによく使われており、複雑なサーバーレスアプリケーションのパフォーマンスを向上させるのに役立つことでも知られています。また、SQS は設定やスケールアップが容易であるほか、失敗したメッセージの再試行ロジックを処理するデッドレターキューと呼ばれるフォールトトレランス機能も備えています。

API Gateway からの Lambda 呼び出しの 80% は単一目的の関数宛

Lambda 関数から API を提供するための一般的なデザインパターンは、モノリシック関数 (「モノ Lambda」とも) と単一目的の関数の 2 つです。モノ Lambda は複数の HTTP エンドポイントに対応し、複数の異なる種類のタスクを実行するためのルーティングロジックを含んでいますが、単一目的の関数は単一の HTTP メソッドとエンドポイントにのみ応答します。

API Gateway による Lambda の呼び出しの大部分は単一目的の関数に対するものであり、当社のお客様の 60% 以上が利用しています。このデータは、単一目的関数の多くの主要な利点を反映するものです。たとえば、単一目的関数は互いに分離されているため、独立した形でデバッグやデプロイを行うことができます。さらに、単一目的関数を利用することで、AWS の Well-Architected フレームワークで定義されたベストプラクティスと一致する IAM ロールを関数ごとに割り当てて、チーム内でアプリケーションのセキュリティを効率的に維持することができます。また、単一目的の関数はパッケージサイズが小さいため、モノ Lambda よりもコールドスタート時間が短くなると考えられます。

TWEET SHARE

Lambda ユーザーの 5 人に 1 人は、関数をコンテナイメージとしてデプロイ

Lambda 関数が導入された当初、AWS がサポートするデプロイパッケージは、関数のコードと依存関係をすべて含む .zip ファイルのみでした。しかし 2020 年、AWS は Lambda 関数を Docker コンテナイメージとしてパッケージングし、デプロイするためのサポートを追加しました。それ以来、この形での Lambda 関数のデプロイはますます普及し、現在では Lambda を導入しているお客様の 5 人に 1 人がこれを利用しています。この傾向から、サーバーレス技術とコンテナ技術の組み合わせのメリット、そして両者の境界が曖昧になってきている状況への関心が高まっていることが分かります。

TWEET SHARE

Lambda 関数をコンテナイメージとしてデプロイすることには、さまざまなメリットがあります。例えば、.zip ファイルのサイズ制限が 250MB であるのに対し、コンテナイメージの容量は最大 10GB までです。このようにサイズが大幅に制限されているため、組織はデータ分析や機械学習タスクをサポートする NumPy や PyTorch のような依存関係の濃いライブラリを活用することができます。さらに、Lambda 関数をコンテナイメージとしてパッケージングすることで、既存の Docker ベースのデプロイや CI/CD パイプラインを持つ組織ではサーバーレスソリューションを容易に統合できるようになります。このように、サーバーレス関数を既存のワークフローにシームレスに組み込むことで、チームの作業時間を大幅に短縮し、生産性を高めることができます。

Lambda 導入済み顧客の 20% 以上が ECS Fargate も併用

AWS をご利用のお客様は、Lambda 関数の採用により大きなメリットを享受しており、その人気は依然として高いままです。この成功を受けて、Lambda ユーザーはサーバーレスの活用範囲を拡大するための新しい方法を模索するようになりました。最も注目すべきなのは、Lambda を導入しているお客様の 20% 以上が、EC2 インスタンスの管理およびプロビジョニングなしで、コンテナを起動するためにECS Fargateを併用していることです。

TWEET SHARE

この事実は、組織がますますサーバーレス化に取り組んでいること、およびワークロードと運用を最適化するにあたってサーバーレス技術の実力を深く信頼していることを示しています。Fargate を使用すれば、ECS または EKS でアプリケーションを実行しているチームは大規模なリファクタリングを行わずにコードベースを簡単に移行できるため、このコミットメントを実行するためには魅力的な方法だと言えます。また、Fargate はリソースの割り当てを細かく制御できるため、バッチ処理や機械学習ジョブなど、リソースを大量に消費するワークロードに適しています。

Google Cloud Run は、Google Cloud におけるサーバーレスアプリケーションのデプロイ方法として最も急速に普及

Google Cloud を運用する Datadog 顧客の 40% 近くが Google Cloud Functions を採用しており、これは同クラウドで最も人気のあるサーバーレス製品です。しかし、この採用率は、Google Cloud のサーバーレスコンテナ製品である Google Cloud Run の採用率を 3% 程度上回っているに過ぎません。この結果は、サーバーレスの導入に際して、インフラ管理を必要としないコンテナ化されたアプリケーションを立ち上げる機会を模索しようとする Google Cloud ユーザーが増加していることを示唆しています。

TWEET SHARE

組織が Cloud Run を採用するのにはいくつかの理由があります。Cloud Functions のような従来の FaaS 製品は、ほんの一握りの言語のみをサポートし、一度に 1 つのリクエストを実行しますが、Cloud Run の場合ユーザーは任意の言語でコードを書くことができ、複数の同時リクエストを実行するよう構成が可能です (実際、Cloud Run を使用しているすべての Datadog ユーザーが、複数の同時リクエストを定期的に実行しています)。並行処理に対応しているという特性から、レイテンシーを減らしてパフォーマンスを向上させることができ、特に大きな I/O バウンドワークロードを持つ RESTful API に有用です。さらに、既存のコンテナイメージを Google Cloud の Artifact Registry にアップロードし、Cloud Run 上でマイクロサービスとして展開できるため、移行プロセスを簡略化できます。これに対して、レガシーコードをサーバーレス関数に移行するには、既存のアプリケーションを個別のサービスに分解し、特定のイベントに対応するハンドラを追加で構築する必要があり、大幅に複雑化してしまいます。

Azure サーバーレスシリーズでは Azure Functions が一番人気を博すも、Azure Container Instances の導入が急増

Azure の FaaS 製品である Azure Functions は最も人気のあるサーバーレス製品であり、Azure を導入しているお客様の 40% 以上で使用されています。しかし、組織がフルマネージド型のサーバーレスコンテナを実行できる Azure Container Instances (ACI) の採用が大幅に増加しており、現在 Azure の顧客の 30％ 近くが使用しています。これは Google Cloud や AWS でみられる傾向とほぼ同じで、組織は従来の FaaS パラダイムを超え、サーバーレスを使用してコンテナ化されたワークロードを起動するようになっていることが伺えます。また、マネージドサーバーレス環境でコンテナ化されたアプリケーション全体の構築とデプロイを可能にする Azure Container Apps など、その他の Azure サーバーレスコンテナテクノロジーの採用もさらに増加すると予想されます。

TWEET SHARE

ACI の主な特徴の 1 つは、インフラストラクチャー管理を気にすることなく、コンテナを数秒で立ち上げられることです。また、すでにAzure Kubernetes Service (AKS) を利用している場合は、ACI と統合することで通常のワークロードに十分な容量を自動的にプロビジョニングし、トラフィック急増時にはクラスタ内のポッドを動的にスケールさせることが可能です。

Datadog Serverless Monitoringは、サーバーレスアプリケーションの健全性をエンドツーエンドで可視化し、サーバーレステクノロジーを通じた運用オーバーヘッドの削減というメリットを最大限に享受しながら、製品開発と顧客満足度アップに集中できる環境づくりをサポートします。