Azure Load Testing を使って Azure Functions Flex Consumption の HTTP Trigger のパフォーマンスとコストを最適化する

Azure Functions Flex Consumption が東日本リージョンで使えるようになりました。
Azure Load Testing を使って HTTP Trigger Function のパフォーマンスとコストを最適化する方法を試してみました。公式ブログの重要なポイントのみを取り上げていますので、詳細は下記の記事を参照してください。
techcommunity.microsoft.com

Flex Consumption とは

Flex Consumption は、Azure Functions に新しく追加されたホスティングオプションで、刷新されたバックエンド（Legion）による高速なスケーリングが最大の特徴です。さらに、従来の Consumption Plan では対応していなかった VNET Integration にも対応しています。

詳細は公式ドキュメントを参照していただくとして、パフォーマンスとコストに影響するスケーリングの設定を補足します。

スケーリングの動作

Flex Consumption は Function 毎に独立したインスタンスでスケーリングされますが、下記の３種類の Trigger については同じインスタンスでグループとしてまとめてスケーリングされます。

HTTP triggers
Blob storage triggers(Event Grid-based)
Durable Functions

インスタンスのメモリサイズ

現時点では、512 MB と 2,048 MB と 4,096 MB の 3 種類のサイズが提供されています。

インスタンス毎のコンカレンシー

コンカレンシーとは、インスタンスが処理できる並列リクエストの数です。Flex Consumption では、HTTP Trigger に新しい同時実行性が導入されました。

既定のコンカレンシーは、下記の通りです。基本的には既定値を使いますが、パフォーマンスとコストを最適化する場合、この値を調整することになります。

インスタンスの最大スケーリング数

既定ではインスタンス数 0 台からスケーリングが開始され、最大数は 40 ～ 1,000 台まで設定できます。

コールドスタート削減

Flex Consumption にはコールドスタート削減として Always-ready が導入されており、常時実行させておくインスタンス数を設定できます。

Performance Optimizer とは

Azure Functions には、Azure Load Testing を使った Performance Optimizer が提供されており、パフォーマンスとコストの適切なバランスを見つけやすくなっています。

なお、Azure Load Testing の Test Profile を実行するためには、Azure Functions の Access control（IAM）で Website Contributor ロールにアカウントを追加する必要があります。

テストの設定と実行

それでは実際に Performance Optimizer を使って HTTP Trigger Function のパフォーマンスとコストの最適化を分析します。

前準備

Azure Functions Flex Consumption を東日本リージョンに作成します。Runtime Stack には、.NET9 を選択しました。

Visual Studio で HTTP Trigger の Function を作成し、1 秒間のスリープを入れました。

[Function(nameof(Function1))]
public async Task<IActionResult> Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] HttpRequest req)
{
    _logger.LogInformation("C# HTTP trigger function start.");

    await Task.Delay(1000);
    
    _logger.LogInformation("C# HTTP trigger function end.");
    return new OkObjectResult("Welcome to Azure Functions Flex Consumption!");
}

この Function App を Visual Studio から Azure にデプロイします。

Performance Optimizer で Test Profile を作成する

テストプランには、インスタンスのメモリサイズを 2,048 MB と 4,096 MB、コンカレンシーを 8、16、32 の組み合わせで 6 パターンを設定します。

テスト対象には、先ほどデプロイした HTTP Trigger Function を設定します。

3 分間にわたって10 ユーザーからリクエストを投げるミニマムな設定にしました。

Test Profile の作成が完了するとテストが開始されるので、完了まで待ちます。

テスト結果の分析

Performance Optimizer のテスト結果を確認します。メモリサイズ 4,096 MB とコンカレンシー 32 の構成が最もスループットが高い結果となりました。

どのくらいのインスタンス数がスケーリングされているのかを確認します。メモリサイズ 2,048 MB とコンカレンシー 8 の構成が最大 8 台で、それ以外の構成は最大 10 台でした。

requests
| where timestamp >= datetime(2025-5-7T07:50:00.0000000Z) and timestamp <= datetime(2025-5-7T09:50:00.0000000Z)
| summarize dcount(cloud_RoleInstance) by bin(timestamp, 1s)
| render columnchart

最もスループットが高かったメモリサイズ 4,096 MB とコンカレンシー 32 の構成のみを確認します。開始 1 秒で 10 台まで高速にスケーリングしていることが分かります。
この構成が最もスループットが高いことは分かりましたが、これに伴うコストはまだ分かりません。

Flex Consumption の Functions メトリクスのうち、OnDemandFunctionExecutionUnits メトリクスを確認します。mb-milliseconds 単位で測定されるので分かりにくいですが、インスタンスがアクティブな時間を表しています。右端の山（メモリサイズ 4,096 MB とコンカレンシー 32）の 800M が最もスループットが高い構成です。

パフォーマンス要件次第ですが、2 番目にスループットが高い左端の山（メモリサイズ 2,048 MB とコンカレンシー 8）が要件を満たしていれば、600 M 弱の実行時間に相当するコストで済むため、この構成も選択肢に含めて検討することができます。

まとめ

Azure Load Testing を使って Azure Functions Flex Consumption の HTTP Trigger のパフォーマンスとコストを最適化する方法を試してみました。

Flex Consumption は、実行時に使用されたメモリとコンピューティング時間に基づいて課金されます。メモリ設定を高くすると実行時間は速くなりますが、リクエストあたりのコストは高くなります。逆に、メモリ設定を低くするとコストは削減されますが、実行時間は長くなる可能性があります。
このトレードオフに対して、Performance Optimizer を活用することで、コストとパフォーマンスの最適なバランスを見つけやすくなります。