ターゲットベースのスケーリングは、お客様に高速で直感的なスケーリング モデルを提供します。このスケーリングは現在、次の拡張バインディングでサポートされています。
ターゲットベースのスケーリングは、これらの種類の拡張機能で既定で使用されていた以前の Azure Functions 増分スケーリング モデルに代わるものです。 増分スケーリングでは、新しいインスタンスの頻度ごとに最大 1 つのワーカーが追加または削除され、スケーリングするタイミングに関する決定が複雑でした。 これに対し、ターゲット ベースのスケーリングでは、一度に 4 つのインスタンスをスケールアップでき、次の簡単なターゲットベースの式に基づいてスケーリングが決定されます。
この式では、"イベント ソースの長さ" は、処理する必要があるイベントの数を表します。 インスタンスごとの既定のターゲット実行値は、Azure Functions 拡張機能で使用されるソフトウェア開発キット (SDK) から取得されます。 ターゲット ベースのスケーリングを機能させるために変更を加える必要はありません。
考慮事項
ターゲットベースのスケーリングを使用するときには、以下の考慮事項が適用されます。
- ターゲットベースのスケーリングは、従量課金プラン、Flex 従量課金プラン、および Elastic Premium プランの関数アプリに対して既定で有効になっています。 専用 App Service プランで実行する場合、イベント駆動型スケーリングはサポートされません。
- ターゲット ベースのスケーリングは、Functions ランタイムのバージョン 4.19.0 以降で既定で有効になっています。
- ターゲット ベースのスケーリングを使用する場合、スケール制限は引き続き適用されます。 詳細については、「スケールアウトを制限する」を参照してください。
- メトリックに基づく最も正確なスケーリングを行うには、関数アプリごとに 1 つのターゲット ベースのトリガー関数のみを使用します。 関数ごとのスケーリングを提供する Flex 従量課金プランでの実行も検討する必要があります。
- 同じ関数アプリ内の複数の関数がすべて同時にスケールアウトを要求している場合、それらの関数全体の合計を使用して、目的のインスタンスにおける変更が決定されます。 スケールアウトを要求する関数は、スケールインを要求する関数をオーバーライドします。
- スケールイン要求があり、スケールアウト要求がない場合は、最大のスケールイン値が使用されます。
オプトアウト
ターゲットベースのスケーリングは、従量課金プランまたは Premium プランでホストされる関数アプリでは既定で有効です。 ターゲット ベースのスケーリングを無効にして増分スケーリングにフォールバックするには、次のアプリ設定を関数アプリに追加します。
| アプリ設定 | 値 |
|---|---|
TARGET_BASED_SCALING_ENABLED |
0 |
ターゲットベースのスケーリングのカスタマイズ
"インスタンスあたりのターゲット実行数" を調整すると、アプリのワークロードに基づいてスケーリング動作の頻度を増やしたり減らしたりできます。 "インスタンスあたりのターゲット実行数" の設定に使用できる設定は、拡張機能ごとに異なります。
次の表は、"インスタンスあたりのターゲット実行数" の値に使用される host.json 値と、その既定値を示しています。
| 拡張機能 | host.json 値 | 既定値 |
|---|---|---|
| Event Hubs (拡張機能 v5.x 以降) | extensions.eventHubs.maxEventBatchSize | 100* |
| Event Hubs (拡張機能 v3.x 以降) | extensions.eventHubs.eventProcessorOptions.maxBatchSize | 10 |
| Event Hubs (定義されている場合) | extensions.eventHubs.targetUnprocessedEventThreshold | 該当なし |
| Service Bus (拡張機能 v5.x 以降、単一ディスパッチ) | extensions.serviceBus.maxConcurrentCalls | 16 |
| Service Bus (拡張機能 v5.x 以降、セッション ベースの単一ディスパッチ) | extensions.serviceBus.maxConcurrentSessions | 8 |
| Service Bus (拡張機能 v5.x 以降、バッチ処理) | extensions.serviceBus.maxMessageBatchSize | 1000 |
| Service Bus (Functions v2.x 以降、単一ディスパッチ) | extensions.serviceBus.messageHandlerOptions.maxConcurrentCalls | 16 |
| Service Bus (Functions v2.x 以降、セッション ベースの単一ディスパッチ) | extensions.serviceBus.sessionHandlerOptions.maxConcurrentSessions | 2000 |
| Service Bus (Functions v2.x 以降、バッチ処理) | extensions.serviceBus.batchOptions.maxMessageCount | 1000 |
| ストレージ キュー | extensions.queues.batchSize | 16 |
* 既定値 maxEventBatchSize は、 パッケージの Microsoft.Azure.WebJobs.Extensions.EventHubs で変更されました。 以前のバージョンでは、この値は 10 でした。
一部のバインディング拡張機能では、 インスタンス構成ごとのターゲット実行 は、関数属性を使用して設定されます。
| 拡張機能 | 関数トリガーの設定 | 既定値 |
|---|---|---|
| Apache Kafka | lagThreshold |
1000 |
| Azure Cosmos DB | maxItemsPerInvocation |
100 |
詳細については、サポートされている拡張機能の構成の例を参照してください。
ランタイム スケールの監視が有効になっている Premium プラン
ランタイム スケール監視が有効になっている場合、スケール コントローラーは仮想ネットワークによってセキュリティ保護されたサービスにアクセスできないため、拡張機能自体が動的スケーリングを処理します。 ランタイム スケール監視を有効にした後、追加のターゲット ベースのスケーリング機能をロック解除するには、拡張機能パッケージを次の最小バージョンにアップグレードする必要があります。
| 拡張機能の名前 | 必要な最小バージョン |
|---|---|
| Apache Kafka | 3.9.0 |
| Azure Cosmos DB | 4.1.0 |
| Event Hubs | 5.2.0 |
| Service Bus | 5.9.0 |
| ストレージ キュー | 5.1.0 |
動的な同時実行制御のサポート
ターゲットベースのスケーリングでは、より高速なスケーリングが導入され、"インスタンスあたりのターゲット実行数" の既定値が使用されます。 Service Bus、Storage キュー、または Kafka を使用する場合は、動的な同時実行制御を有効にすることもできます。 この構成では、インスタンスごとの_target実行の値は、動的コンカレンシー機能によって自動的に決定されます。 制限付きの同時実行制御から始まり、時間の経過に伴って最適な設定が特定されます。
サポートされる拡張機能
host.json ファイルでターゲット ベースのスケーリングを構成する方法は、特定の拡張機能の種類によって異なります。 このセクションでは、ターゲット ベースのスケーリングを現在サポートしている拡張機能の構成の詳細について説明します。
Service Bus のキューとトピック
Service Bus 拡張機能では、Service Bus トリガーの IsBatched 属性と IsSessionsEnabled 属性で決定される 3 つの実行モデルがサポートされています。
IsBatched と IsSessionsEnabled の既定値は false です。
| 実行モデル | IsBatched | IsSessionsEnabled | "インスタンスあたりのターゲット実行数" に使用される設定 |
|---|---|---|---|
| 単一ディスパッチ処理 | false | false | maxConcurrentCalls |
| 単一ディスパッチ処理 (セッション ベース) | false | true | maxConcurrentSessions |
| バッチ処理 | true | false | maxMessageBatchSize または maxMessageCount |
Note
スケーリングの効率: Service Bus 拡張機能の場合、リソースに対して "管理" 権限を使用すると最も効率的なスケーリングを行うことができます。 リッスン権限では、キューまたはトピックの長さを使用してスケーリングの決定を通知できないため、スケーリングは増分スケールに戻ります。 Service Bus アクセス ポリシーで権限を設定する方法の詳細については、「共有アクセス承認ポリシー」を参照してください。
単一ディスパッチ処理
このモデルでは、関数の各呼び出しで 1 つのメッセージが処理されます。
maxConcurrentCalls 設定で、"インスタンスあたりのターゲット実行数" を制御します。 具体的な設定は、Service Bus 拡張機能のバージョンによって異なります。
次の例のように、host.json で maxConcurrentCalls 設定を変更します。
{
"version": "2.0",
"extensions": {
"serviceBus": {
"maxConcurrentCalls": 16
}
}
}
単一ディスパッチ処理 (セッション ベース)
このモデルでは、関数の各呼び出しで 1 つのメッセージが処理されます。 ただし、Service Bus のトピックまたはキューのアクティブなセッションの数に応じて、各インスタンスは 1 つ以上のセッションをリースします。 具体的な設定は、Service Bus 拡張機能のバージョンによって異なります。
次の例のように、host.json で maxConcurrentSessions 設定を変更し、"インスタンスあたりのターゲット実行数" を設定します。
{
"version": "2.0",
"extensions": {
"serviceBus": {
"maxConcurrentSessions": 8
}
}
}
バッチ処理
このモデルでは、関数の各呼び出しでメッセージのバッチが処理されます。 具体的な設定は、Service Bus 拡張機能のバージョンによって異なります。
次の例のように、host.json で maxMessageBatchSize 設定を変更し、"インスタンスあたりのターゲット実行数" を設定します。
{
"version": "2.0",
"extensions": {
"serviceBus": {
"maxMessageBatchSize": 1000
}
}
}
Event Hubs
Azure Event Hubs の場合、Azure Functions は、有効なインスタンス数の一覧内のイベント ハブ内のすべてのパーティションに分散された未処理のイベントの数に基づいてスケーリングされます。 既定では、"インスタンスあたりのターゲット実行数" に使用される host.json 属性は と maxEventBatchSize です。maxBatchSize ただし、ターゲット ベースのスケーリングを微調整する場合は、オーバーライドする個別のパラメーター targetUnprocessedEventThreshold を定義すると、バッチ設定を変更せずに "インスタンスあたりのターゲット実行数" を設定できます。
targetUnprocessedEventThreshold を設定すると、未処理のイベント数の合計がこの値で除算され、インスタンスの数が決定されます。これは、バランスの取れたパーティション分散を作成するワーカー インスタンス数に切り上げられます。
スケーリングの動作と安定性
Event Hubs の場合、頻繁なスケールイン操作とスケールアウト操作によってパーティションの再調整がトリガーされ、処理の遅延と待機時間の増加につながります。 これを軽減するには:
- プラットフォームでは、有効なワーカー数の定義済みリストを使用して、スケーリングの決定をガイドします。
- プラットフォームにより、スケーリングが安定して意図的に行われ、パーティション割り当ての破壊的変更が回避されます。
- 目的のワーカー数が有効な一覧にない場合 (たとえば、17) は、次に大きい有効な数 (この場合は 32) を自動的に選択します。 さらに、迅速な繰り返しスケーリングを防ぐために、スケールイン要求は前回のスケールアップ後 3 分間調整されます。 この遅延は、不要な再調整を減らし、スループットの効率を維持するのに役立ちます。
Event Hubs の有効なインスタンス数
Event Hubs のパーティション数ごとに、有効なインスタンス数の対応する一覧を計算して、最適な分散と効率的なスケーリングを保証します。 これらの数は、パーティション分割とコンカレンシーの要件に合わせて選択されます。
| パーティション数 | 有効なインスタンス数 |
|---|---|
| 1 | [1] |
| 2 | [1, 2] |
| 4 | [1, 2, 4] |
| 8 | [1, 2, 3, 4, 8] |
| 10 | [1, 2, 3, 4, 5, 10] |
| 16 | [1, 2, 3, 4, 5, 6, 8, 16] |
| 32 | [1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 16, 32] |
これらの定義済みカウントは、インスタンスがパーティション間で可能な限り均等に分散され、アイドルまたはオーバーロードされたワーカーを最小限に抑えるのに役立ちます。
Note
注: Premium および Dedicated イベント ハブレベルの場合、パーティション数は 32 を超える可能性があり、有効なインスタンス数セットを大きくできます。 これらのレベルでは、より高いスループットとスケーラビリティがサポートされ、有効なワーカー数の一覧は、インスタンス間でイベント ハブ パーティションを均等に分散するように拡張されます。 また、Event Hubs はパーティション分割されたワークロードであるため、イベント ハブ内のパーティションの数は、ターゲット インスタンスの最大数の制限です。
Event Hubs の設定
具体的な設定は、Event Hubs 拡張機能のバージョンによって異なります。
次の例のように、host.json で maxEventBatchSize 設定を変更し、"インスタンスあたりのターゲット実行数" を設定します。
{
"version": "2.0",
"extensions": {
"eventHubs": {
"maxEventBatchSize" : 100
}
}
}
host.json で定義されている場合は、次の例のように、targetUnprocessedEventThreshold の代わりに が "インスタンスあたりのターゲット実行数" として使用されます。maxEventBatchSize
{
"version": "2.0",
"extensions": {
"eventHubs": {
"targetUnprocessedEventThreshold": 153
}
}
}
ストレージ キュー
Storage 拡張機能の v2.x 以降の場合は、host.json で batchSize 設定を変更して、"インスタンスあたりのターゲット実行数" を設定します。
{
"version": "2.0",
"extensions": {
"queues": {
"batchSize": 16
}
}
}
Note
スケール効率: ストレージ キュー拡張機能の場合、visibilityTimeout を含むメッセージは、引き続きストレージ キュー API によってイベント ソースの長さにカウントされます。 これにより、関数アプリのオーバースケールが発生する可能性があります。 Service Bus キューを使用して、スケジュールされたメッセージをキューに入れ、スケールアウトを制限するか、ソリューションで visibilityTimeout を使用しないことを検討してください。
Azure Cosmos DB
Azure Cosmos DB では、関数レベルの属性 MaxItemsPerInvocation を使用します。 この関数レベルの属性の設定方法は、関数言語によって異なります。
コンパイル済みの C# 関数の場合は、次のインプロセス C# 関数の例に示すように、トリガー定義で MaxItemsPerInvocation を設定します。
namespace CosmosDBSamplesV2
{
public static class CosmosTrigger
{
[FunctionName("CosmosTrigger")]
public static void Run([CosmosDBTrigger(
databaseName: "ToDoItems",
collectionName: "Items",
MaxItemsPerInvocation: 100,
ConnectionStringSetting = "CosmosDBConnection",
LeaseCollectionName = "leases",
CreateLeaseCollectionIfNotExists = true)]IReadOnlyList<Document> documents,
ILogger log)
{
if (documents != null && documents.Count > 0)
{
log.LogInformation($"Documents modified: {documents.Count}");
log.LogInformation($"First document Id: {documents[0].Id}");
}
}
}
}
Note
Azure Cosmos DB はパーティション分割されたワークロードであるため、コンテナー内の物理パーティションの数はターゲット インスタンス数の制限です。 Azure Cosmos DB のスケーリングの詳細については、物理パーティションに関する記事とリース所有権に関する記事を参照してください。
Apache Kafka
Apache Kafka 拡張機能では、関数レベルの属性 LagThreshold が使用されます。 Kafka の場合、"望ましいインスタンス" の数は LagThreshold 設定で除算されたコンシューマー合計に基づいて計算されます。 特定のラグの場合、ラグのしきい値を減らすと、望ましいインスタンスの数が増えます。
この関数レベルの属性の設定方法は、関数言語によって異なります。 この例ではしきい値が 100 に設定されます。
コンパイル済みの C# 関数の場合、次の Kafka Event Hubs トリガーのインプロセス C# 関数の例に示すように、トリガー定義で LagThreshold を設定します。
[FunctionName("KafkaTrigger")]
public static void Run(
[KafkaTrigger("BrokerList",
"topic",
Username = "$ConnectionString",
Password = "%EventHubConnectionString%",
Protocol = BrokerProtocol.SaslSsl,
AuthenticationMode = BrokerAuthenticationMode.Plain,
ConsumerGroup = "$Default",
LagThreshold = 100)] KafkaEventData<string> kevent, ILogger log)
{
log.LogInformation($"C# Kafka trigger function processed a message: {kevent.Value}");
}
次のステップ
詳細については、以下の記事をお読みください。