ターゲットベースのスケーリング
ターゲットベースのスケーリングは、お客様に高速で直感的なスケーリング モデルを提供します。このスケーリングは現在、次の拡張バインディングでサポートされています。
ターゲットベースのスケーリングは、これらの種類の拡張機能で既定で使用されていた以前の 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 値 | Default Value |
---|---|---|
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
パッケージの v6.0.0 で変更されました。 以前のバージョンでは、この値は 10 でした。
一部のバインディング拡張機能では、"インスタンスあたりのターゲット機能拡張" は関数属性を使用して設定されます。
拡張子 | 関数トリガーの設定 | Default Value |
---|---|---|
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 を使用する場合は、動的な同時実行制御を有効にすることもできます。 この構成では、動的な同時実行制御機能によって "インスタンスあたりのターゲット実行数" の値が自動的に決定されます。 制限付きの同時実行制御から始まり、時間の経過に伴って最適な設定が特定されます。
サポートされる拡張機能
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 or 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
を設定すると、未処理のイベント数の合計がこの値で除算され、インスタンスの数が決定されます。これは、バランスの取れたパーティション分散を作成するワーカー インスタンス数に切り上げられます。
Note
Event Hubs はパーティション分割されたワークロードであるため、Event Hubs のターゲット インスタンス数はイベント ハブ内のパーティションの数によって制限されます。
具体的な設定は、Event Hubs 拡張機能のバージョンによって異なります。
次の例のように、host.json
で maxEventBatchSize
設定を変更し、"インスタンスあたりのターゲット実行数" を設定します。
{
"version": "2.0",
"extensions": {
"eventHubs": {
"maxEventBatchSize" : 100
}
}
}
host.json
で定義されている場合は、次の例のように、maxEventBatchSize
の代わりに targetUnprocessedEventThreshold
が "インスタンスあたりのターゲット実行数" として使用されます。
{
"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}");
}
次のステップ
詳細については、以下の記事をお読みください。