Azure Functions でのイベント ドリブン スケーリング

イベント駆動型スケーリングは専用(App Service)プランには適用されません。 専用プランはイベントに応じて動的にスケールしません。 Dedicated プランのスケーリングオプションについては、「Azure App Service のアプリを拡大する」をご覧ください。

イベント駆動型スケーリングは、Azure Container Appsで関数を実行する際には適用されません。 コンテナアプリ上でホストされている場合、スケーリングはコンテナアプリ環境によって管理されます。 詳細については、「Azure Container Apps でスケーリング ルールを設定する」を参照してください。

実行時のスケーリング

Azure Functions は "スケール コントローラー" と呼ばれるコンポーネントを使用して、イベント レートを監視し、スケールアウトとスケールインのどちらを実行するかを決定します。 スケール コントローラーは、トリガーの種類ごとにヒューリスティックを使用します。 たとえば、Azure Queue ストレージ トリガーを使用している場合は、ターゲットベースのスケーリングが使用されます。

Azure Functions のスケールの単位は関数アプリです。 関数アプリがスケールアウトすると、Azure Functionsホストの複数のインスタンスを実行するためのリソースが増えます。 逆に、計算需要が減少すると、スケールコントローラーは機能ホストインスタンスを削除します。 関数アプリ内でどの関数も実行されていない場合、インスタンスの数は 最終的に "スケールイン" されます。

消費プラン内の各Functionsホストのインスタンスは制限されており、通常は1.5GBのメモリと1つのCPUに制限されています。 ホストのインスタンスは関数アプリ全体をサポートするため、アプリ内のすべての機能がリソースを共有し、同時にスケールします。 機能アプリが同じ消費プランを共有している場合でも、それらは独立してスケールします。

プレミアムプランの具体的なサイズによって、そのインスタンス内のすべてのアプリに利用可能なメモリとCPUが決まります。 このプランでは、プラン内のアプリのスケーリング ニーズに基づいてインスタンスがスケールアウトされ、アプリは必要に応じてプラン内でスケーリングされます。

他の動的プランとは異なり、フレックス消費プランは決定的な関数ごとのスケーリングモデルを使用しています。 このモデルでは、各関数はイベント数や並行性設定に基づいて独立してスケールされますが、HTTP、Blob、オーケストレーション(Durable)トリガー関数はそれぞれのグループでスケールします。 詳細については、「関数ごとのスケーリング」を参照してください。

プラットフォームはインスタンス数の増加速度(スケールカーブ)を最大インスタンス数とは別に管理します。 スケールカーブの仕組み、スロットリングの動作、高レートスケーリングのベストプラクティスについては、「 スケールアウトレート」を参照してください。

コールド スタート

関数アプリが数分間使えない場合、プラットフォームはアプリを実行しているインスタンス数をゼロに縮小するかもしれません。 次のリクエストは、0から1へのスケーリングによる追加の遅延を経験します。 この待機時間は、"コールド スタート"と呼ばれます。 機能アプリが必要とする依存関係の数はコールドスタート時間に影響を与えます。 コールド スタートは、応答を返す必要がある HTTP トリガーなどの同期操作においてよりいっそう問題です。 コールドスタートが機能に影響している場合は、緩和策をサポートするプランの活用を検討してください。

この表でご覧の通り、Flex ConsumptionプランとPremiumプランの両方がアプリ内のコールドスタートを排除する方法を提供しています。

スケーリングの動作について

スケーリングは、いくつかの要因によって異なる場合があります。 アプリはトリガーや選択した言語によってスケールが異なります。 スケーリング動作の複雑な点に注意してください:

• 最大インスタンス: 単一の機能アプリは プランで許容される最大限までスケールアップします。 ただし、単一のインスタンスで一度に複数のメッセージまたは要求を処理できます。 必要な場合は最大値を下げてスケーリングを制限できます。

• 新しいインスタンスレート: HTTPトリガーの場合、プラットフォームは最大で1秒に1回の新しいインスタンスを割り当てます。 HTTP以外のトリガーの場合、プラットフォームは最大30秒ごとに新しいインスタンスを割り当てます。 Premium プランで実行しているときは、スケーリングが速くなります。

• ターゲット ベースのスケーリング: ターゲットベースのスケーリングは、お客様に迅速かつ直感的なスケーリング モデルを提供します。 現在、このスケーリング方法は、Service Bus のキューとトピック、ストレージ キュー、Event Hubs、Apache Kafka、Azure Cosmos DB 拡張機能でサポートされています。 必ずターゲットベースのスケーリングを確認して、スケーリングの動作を理解するようにしてください。

• 関数ごとのスケーリング: 注意が必要ないくつかの例外を除き、Flex 従量課金プランで実行される関数は、独立したインスタンスでスケーリングされます。 この例外としては、HTTP トリガーと BLOB ストレージ (Event Grid) トリガーがあります。 これらの種類のトリガーはそれぞれ、同じインスタンスでグループとしてまとめてスケーリングされます。 同様に、すべての Durable Functions のトリガーもインスタンスを共有し、一緒にスケーリングします。 詳細については、「関数ごとのスケーリング」を参照してください。

• 最大監視トリガー: 現在、スケールコントローラーは最大100トリガーまでしか監視できず、スケーリングの判断を下すことができます。 アプリに100以上のイベントベースのトリガーがある場合、スケール決定は最初に実行された100個のトリガーのみに基づいています。 詳細については、「スケーラブル アプリのベスト プラクティスとパターン」を参照してください。

スケールアウトを制限する

アプリがスケールアウトに使用できるインスタンスの最大数を制限することもできます。この制限は、データベースなどのダウンストリーム コンポーネントのスループットが制限されている場合に最も一般的です。 さまざまなホスティング プランを実行する場合の最大スケール制限については、スケールの制限に関するページを参照してください。

既定では、Flex 従量課金プランで実行されるアプリには、全体で 100 インスタンスの制限があります。 現在、最大インスタンス数の下限値は 1 であり、サポートされている最大インスタンス数の上限値は 1000 です。 az functionapp create コマンドを使用して、Flex 従量課金プランで関数アプリを作成する場合、--maximum-instance-count パラメーターを使用して、アプリのこの最大インスタンス数を設定します。

最大インスタンス数は、各 機能ごとのスケールグループ (関数グループ)内のオンデマンドインスタンスに適用され、アプリの統合インスタンスには適用されません。 Always Readyのインスタンス は最大インスタンス数に制限されておらず、そのカウントにも含まれません。

Flex Consumption アプリの最大インスタンス数は最大 1000 まで変更できますが、その数に達する前にアプリのクォータ制限に達します。 詳細については、「リージョン サブスクリプション メモリ クォータ」を参照してください。

次の例では、最大インスタンス数を 200 に設定してアプリを作成します。

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_ACCOUNT_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --maximum-instance-count 200

次の例では、az functionapp scale config set コマンドを使用して、既存のアプリの最大インスタンス数を 150 に変更します。

az functionapp scale config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --maximum-instance-count 150

従量課金または Elastic Premium プランでは、functionAppScaleLimit サイトの構成設定の値を変更して、アプリの最大インスタンス数をより少ない値に指定できます。 functionAppScaleLimit は、0 または null (無制限の場合)、あるいは 1 とアプリの最大値の間の有効な値に設定できます。

az resource update --resource-type Microsoft.Web/sites -g <RESOURCE_GROUP> -n <FUNCTION_APP-NAME>/config/web --set properties.functionAppScaleLimit=<SCALE_LIMIT>

$resource = Get-AzResource -ResourceType Microsoft.Web/sites -ResourceGroupName <RESOURCE_GROUP> -Name <FUNCTION_APP-NAME>/config/web
$resource.Properties.functionAppScaleLimit = <SCALE_LIMIT>
$resource | Set-AzResource -Force

スケーリングアウト率

Flex Consumptionプランでは、プラットフォームはインスタンス数の増減速度(スケールカーブ)も最大インスタンス数とは別に管理しています。 スケールカーブの仕組み、スロットリングの動作、高レートスケーリングのベストプラクティスについては、 スケールアウトレートを参照してください。

スケーリングアウト率

消費プランとプレミアムプランでは、スケールコントローラーが新規インスタンスの追加速度を管理します。 HTTP トリガーの場合、新しいインスタンスは最大で 1 秒間に 1 回割り当てられます。 非HTTPトリガーの場合、新しいインスタンスは最大30秒に1回割り当てられます。 Premium プランで実行しているときは、スケーリングが速くなります。

スケールインの動作

イベントドリブン スケーリングを使うと、関数に対する需要が減少したときに、自動的に容量を削減できます。 これにより、現在の関数実行のインスタンスをドレインしてこの削減を行い、それらのインスタンスを削除します。 この動作はドレイン モードとしてログに記録されます。 現在実行中の関数の猶予期間を、従量課金プラン アプリの場合は最大 10 分まで、Flex 従量課金アプリおよび Premium プラン アプリの場合は最大 60 分まで延長できます。 イベントドリブン スケーリングとこの動作は、Dedicated プランのアプリには適用されません。

スケールイン動作には、次の考慮事項が適用されます。

• 従量課金プランで Windows で実行されているアプリの場合、2021 年 5 月以降に作成されたアプリでのみ、ドレイン モードの動作が既定で有効になっています。
• Service Bus トリガーを使う関数の正常なシャットダウンを有効にするには、バージョン 4.2.0 以降の Service Bus 拡張機能を使います。

関数ごとのスケーリング

Flex 従量課金プランは、"関数ごとのスケーリング" 動作を実装するという点で独特です。 関数ごとのスケーリングでは、HTTP トリガー、BLOB (Event Grid) トリガー、Durable Functions を除き、アプリ内の他のすべての種類の関数トリガーが、独立したインスタンスでスケーリングされます。 すべての BLOB (Event Grid) および独自の共有インスタンスを持つすべての Durable Functions トリガーと同様、アプリ内の HTTP トリガーはすべて、同じインスタンスでグループとしてまとめてスケーリングされます。

次の機能を備えた Flex Consumption プランによってホストされる関数アプリについて考えてみましょう。

例においては、

• HTTP でトリガーされる 2 つの関数 (function1 と function2) は両方とも、独自のインスタンスでまとめて実行され、HTTP コンカレンシー設定 に従ってまとめてスケーリングされます。
• 2 つの Durable 関数 (function3 と function4) は両方とも独自のインスタンスでまとめて実行され、構成されたコンカレンシー スロットルに基づいてまとめてスケーリングされます。
• Service Bus でトリガーされる関数 function5 は、独自に実行され、Service Bus キューとトピックのターゲットベースのスケーリング規則に従って、独立してスケーリングされます。
• Service Bus でトリガーされる関数 function6 は、独自に実行され、Service Bus キューとトピックのターゲットベースのスケーリング規則に従って、独立してスケーリングされます。
• Event Hubs トリガー (function7) は独自のインスタンスで実行され、Event Hubs のターゲットベースのスケーリング規則に従って、独立してスケーリングされます。

スケーラブルなアプリのベスト プラクティスとパターン

関数アプリの多くの側面がスケールに影響を与えます。ホスト構成、実行時のフットプリント、リソース効率などです。 詳細については、パフォーマンスの考慮事項に関する記事のスケーラビリティのセクションをご覧ください。 関数アプリがスケールするにつれて、接続がどのように変化するかを認識する必要もあります。 詳細については、「How to manage connections in Azure Functions」(Azure Functions で接続を管理する方法) を参照してください。

もしアプリにイベントベースのトリガーを使う機能が100個以上ある場合は、1つ以上のアプリに分けて、各アプリが100未満のイベントベースの機能を持つことを検討してください。

Python と Node.jsでのスケーリングの詳細については、Azure Functions Python 開発者ガイドのスケーリングとパフォーマンスに関するセクションと、Azure Functions Node.js 開発者ガイドの「スケーリングとコンカレンシー」セクションを参照してください。