Alternative Architecture DOJO

オルターブースのクラウドネイティブ特化型ブログです。

Azure Function Flex Consumptionを試してみた

こんにちは、もうすぐ娘の誕生日なのですが、昨年の誕生日の朝に娘が飛び起きて「6歳になったー!」と叫びながら走ってきたので今年はどんな誕生日になるのか楽しみにしている木村です。

さて、今回は5月のMicrosoft Build2024でパブリックプレビューになった、Azure Funcitons Flex Consumpitonプランを試してみましたので、その感想をまとめたいと思います。

Flex Consumptionプランとは

Flex Consumptionプランは、Azure Functionsの新しいプランです。これまでのConsumptionプランと同様に、使った分だけの課金がされるのですが、これまではPremiumプランで提供されていたVNET統合や常時起動などの機能を個別に追加できるのが特徴です。
また、プラットフォーム自体がアップデートされており、より高速な起動時間や、より高いスケーラビリティが提供されています。

パブリックプレビューになったことで、Azure portalからもFlex Consumptionプランの関数を作成できるようになりましたので早速触ってみました。

Flex Consumptionプランの関数を作ってみる

まずはいつものように新規に関数を作成します。これまでと違い、最初にプランを選択する画面が表示されます。ここでFlex Consumptionプランを選択します。

プランの選択

最初にリージョンやランタイムを選択します。現在Flex Consumptionが提供されているリージョンのうち、今回はEast USにしました。 また、ランタイムは最新の.NET 8(isolated)を選択しました。これまでのプランですとここでOSがWindowsとLinuxから選択できるのですが、Flex ConsumptionプランではLinuxのみの提供となっていますので選択肢自体が表示されません。逆に、instance sizeという選択肢が表示されています。

Flex Consumpitonプランの場合

Consumptionプランの場合

ネットワークの設定では、VNET統合を設定することができます。ここでは一旦設定せずに進みます。

ネットワーク設定

デプロイの設定では、まだCI/CDの設定はできませんでした。

デプロイ設定

全ての設定を確認したら「create」ボタンを押して関数を作成します。

メニューを確認する

作成が完了したら、リソースの画面に移動します。メニューを確認すると、ConsumptionプランにあったApp Service planに関するメニューの代わりに、「Scale and concurrency」というメニューがあります。

Flex Consumptionプランのメニュー(抜粋)

Consumptionプランのメニュー(抜粋)

このメニューの中を見てみると、Flex Consumptionプランの特徴である「スケール設定」や「常時起動」が個別に設定できることがわかります。常時起動するインスタンス数も、トリガーごとに変えられることが分かります。

Scale and concurrencyメニュー

ネットワーク設定で、NET統合も設定できるようになっています。

ネットワーク設定

関数アプリのデプロイ

関数アプリをデプロイしてみます。2024/6/18現在では、Visual Studio 2022はFlex Consumptionのデプロイに対応していないので、Visual Studio Codeを使います。
こちらの手順に従ってテンプレートで作成したhttp triggerの関数をそのままデプロイしますが、私が試したときにはデプロイ先の関数の設定(環境変数)でWEBSITE_RUN_FROM_PACKAGE設定を削除する必要がありました。

このあとの比較のために、同じ関数アプリをConsumptionプランで作成した関数にもデプロイしておきます。

パフォーマンスの比較

それでは、Flex ConsumptionプランとConsumptionプランで作成した関数のコールドスタートを比較してみます。apache benchコマンドを使い、両方の関数に対して100並列で10000回リクエストを送ります。コマンドは以下の通りです。

ab -n 10000 -c 100 https://xxxx.azurewebsites.net/api/HttpTrigger1?code=XXXXXXXXXXXXX

結果は以下の通りです。Connection Times (ms)を確認します。

[ Flex Consumption ]

min mean [+/-sd] median max
Connect: 511 547 94.1 538 1635
Processing: 174 193 86.5 184 1447
Waiting: 173 191 85.1 183 1433
Total: 686 740 129.2 722 1966

[ Consumption ]

min mean [+/-sd] median max
Connect: 511 539 16.6 538 1569
Processing: 175 327 271.5 194 3477
Waiting: 175 324 270.5 192 3453
Total: 687 866 272.4 736 4026

Waitingの最大値(≒コールドスタートでの待ち時間)が大きく減少していることが分かります。また、平均値や最小値ではあまり差がないものの、最大値が大きく減少し、標準偏差も小さいので安定してパフォーマンスがアップしていることが分かります。

測定誤差もありますのでもう少し繰り返し測定する必要はあるかと思いますが、今回試した範囲では全体的にFlex Consumptionの方がパフォーマンスに優れ、コールドスタートでの待ち時間も小さくなっていました。

まとめ

Flex Consumptionプランは、これまでのConsumptionプランと同様に使った分だけの課金がされますが、VNET統合や常時起動などの機能を個別に追加できるのが特徴です。

また、プラットフォーム自体が変わったことにより、これまでのConsumptionプランよりも高速にレスポンスを返すことが確認できました。もうこれからはFlex Consumptionプランを選ばない理由はないと感じましたので、是非皆様もお試しいただければと思います。

みなさまのお役に立てれば幸いです。

サービス一覧 www.alterbooth.com cloudpointer.tech www.alterbooth.com