ターゲットベースのスケーリング

ターゲットベースのスケーリングは、お客様に高速で直感的なスケーリングモデルを提供します。このスケーリングは現在、次の拡張バインディングでサポートされています。

Apache Kafka
Azure Cosmos DB
Azure Event Hubs
Azure Queue Storage
Azure Service Bus (キューとトピック)

ターゲットベースのスケーリングは、これらの種類の拡張機能で既定で使用されていた以前の 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 を使用する場合は、動的な同時実行制御を有効にすることもできます。この構成では、インスタンスごとの_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 or maxMessageCount

Note

スケーリングの効率: Service Bus 拡張機能の場合、リソースに対して "管理" 権限を使用すると最も効率的なスケーリングを行うことができます。 リッスン権限では、スケーリングの決定を通知するためにキューまたはトピックの長さを使用できないため、増分スケーリングに戻ります。 Service Bus アクセスポリシーで権限を設定する方法の詳細については、「共有アクセス承認ポリシー」を参照してください。

単一ディスパッチ処理

このモデルでは、関数の各呼び出しで 1 つのメッセージが処理されます。 maxConcurrentCalls 設定で、"インスタンスあたりのターゲット実行数" を制御します。具体的な設定は、Service Bus 拡張機能のバージョンによって異なります。

v5.x 以降
v2.x+

次の例のように、host.json で maxConcurrentCalls 設定を変更します。

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxConcurrentCalls": 16
        }
    }
}

次の例のように、host.json で messageHandlerOptions の maxConcurrentCalls 設定を変更します。

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "messageHandlerOptions": {
                "maxConcurrentCalls": 16
            }
        }
    }
}

単一ディスパッチ処理 (セッションベース)

このモデルでは、関数の各呼び出しで 1 つのメッセージが処理されます。ただし、Service Bus のトピックまたはキューのアクティブなセッションの数に応じて、各インスタンスは 1 つ以上のセッションをリースします。具体的な設定は、Service Bus 拡張機能のバージョンによって異なります。

v5.x 以降
v2.x+

次の例のように、host.json で maxConcurrentSessions 設定を変更し、"インスタンスあたりのターゲット実行数" を設定します。

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxConcurrentSessions": 8
        }
    }
}

次の例のように、host.json で sessionHandlerOptions の maxConcurrentSessions 設定を変更し、"インスタンスあたりのターゲット実行数" を設定します。

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "sessionHandlerOptions": {
                "maxConcurrentSessions": 2000
            }
        }
    }
}

バッチ処理

このモデルでは、関数の各呼び出しでメッセージのバッチが処理されます。具体的な設定は、Service Bus 拡張機能のバージョンによって異なります。

v5.x 以降
v2.x+

次の例のように、host.json で maxMessageBatchSize 設定を変更し、"インスタンスあたりのターゲット実行数" を設定します。

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxMessageBatchSize": 1000
        }
    }
}

次の例のように、host.json で batchOptions の maxMessageCount 設定を変更し、"インスタンスあたりのターゲット実行数" を設定します。

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "batchOptions": {
                "maxMessageCount": 1000
            }
        }
    }
}

Event Hubs

Azure Event Hubs の場合、Azure Functions は、有効なインスタンス数の一覧内のイベントハブ内のすべてのパーティションに分散された未処理のイベントの数に基づいてスケーリングされます。既定では、"インスタンスあたりのターゲット実行数" に使用される host.json 属性は maxEventBatchSize と maxBatchSize です。ただし、ターゲットベースのスケーリングを微調整する場合は、オーバーライドする個別のパラメーター targetUnprocessedEventThreshold を定義すると、バッチ設定を変更せずに "インスタンスあたりのターゲット実行数" を設定できます。 targetUnprocessedEventThreshold を設定すると、未処理のイベント数の合計がこの値で除算され、インスタンスの数が決定されます。これは、バランスの取れたパーティション分散を作成するワーカーインスタンス数に切り上げられます。

Warnung

batchCheckpointFrequencyでサポートされるホスティングプラン上記 1 に設定すると、スケーリング動作が正しくない可能性があります。プラットフォームは、未処理のイベントを "現在位置 - チェックポイント位置" として計算します。これは、バッチが処理されたが、まだチェックポイント処理されていないときに未処理のメッセージを誤って示す可能性があり、メッセージが残っていないときに適切なスケールインを防ぎます。

スケーリングの動作と安定性

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 拡張機能のバージョンによって異なります。

v5.x 以降
v3.x 以降

次の例のように、host.json で maxEventBatchSize 設定を変更し、"インスタンスあたりのターゲット実行数" を設定します。

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "maxEventBatchSize" : 100
        }
    }
}

host.json で定義されている場合は、次の例のように、maxEventBatchSize の代わりに targetUnprocessedEventThreshold が "インスタンスあたりのターゲット実行数" として使用されます。

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "targetUnprocessedEventThreshold": 153
        }
    }
}

Event Hubs 拡張機能の v3.x 以降の場合は、host.json で eventProcessorOptions の下にある maxBatchSize 設定を変更して、"インスタンスあたりのターゲット実行数" を設定します。

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "eventProcessorOptions": {
                "maxBatchSize": 10
            }
        }
    }
}

host.json で定義されている場合は、次の例のように、maxBatchSize の代わりに targetUnprocessedEventThreshold が "インスタンスあたりのターゲット実行数" として使用されます。

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "targetUnprocessedEventThreshold": 23
        }
    }
}

Storage キュー

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}");
            }
        }
    }
}

function.json を使用する Functions 言語の場合、次の Azure Cosmos DB トリガーの例のように、MaxItemsPerInvocation パラメーターが特定のバインドで定義されます。

{
    "scriptFile": "main.py",
    "bindings": [
        {
          "type": "cosmosDBTrigger",
          "maxItemsPerInvocation": 100,
          "connection": "MyCosmosDb",
          "leaseContainerName": "leases",
          "containerName": "collectionName",
          "databaseName": "databaseName",
          "leaseDatabaseName": "databaseName",
          "createLeaseContainerIfNotExists": false,
          "startFromBeginning": false,
          "name": "input"
        }
    ]
}

Python v2 プログラミングモデルの例は、まだ提供されていません。

{
  "bindings": [
    {
      "type": "cosmosDBTrigger",
      "maxItemsPerInvocation": 100,
      "connection": "MyCosmosDb",
      "leaseContainerName": "leases",
      "containerName": "collectionName",
      "databaseName": "databaseName",
      "leaseDatabaseName": "databaseName",
      "createLeaseContainerIfNotExists": false,
      "startFromBeginning": false,
      "name": "input"
    }
  ]
}

Node.js v4 プログラミングモデルの例は、まだ提供されていません。

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}");
}

public class KafkaTriggerMany {
    @FunctionName("KafkaTriggerMany")
    public void runMany(
            @KafkaTrigger(
                name = "kafkaTriggerMany",
                topic = "topic",  
                brokerList="%BrokerList%",
                consumerGroup="$Default", 
                username = "$ConnectionString", 
                password = "EventHubConnectionString",
                authenticationMode = BrokerAuthenticationMode.PLAIN,
                protocol = BrokerProtocol.SASLSSL,
                LagThreshold = 100,
                // sslCaLocation = "confluent_cloud_cacert.pem", // Enable this line for windows.
                cardinality = Cardinality.MANY,
                dataType = "string"
             ) String[] kafkaEvents,
            final ExecutionContext context) {
            for (String kevent: kafkaEvents) {
                context.getLogger().info(kevent);
            }

function.json を使用する Functions 言語の場合、次の Kafka Event Hubs トリガーの例のように、LagThreshold パラメーターが特定のバインドで定義されます。

{
      "scriptFile": "main.py",
      "bindings": [
        {
          "type": "kafkaTrigger",
          "name": "kevent",
          "topic": "topic",
          "brokerList": "%BrokerList%",
          "username": "$ConnectionString",
          "password": "EventHubConnectionString",
          "consumerGroup" : "functions",
          "protocol": "saslSsl",
          "authenticationMode": "plain",
          "lagThreshold": "100"
        }
    ]
}

Kafka 拡張機能は現在、Python v2 プログラミングモデルをサポートしていません。

function.json を使用する Functions 言語の場合、次の Kafka Event Hubs トリガーの例のように、LagThreshold パラメーターが特定のバインドで定義されます。

{
    "bindings": [
      {
            "type": "kafkaTrigger",
            "name": "kafkaEvent",
            "direction": "in",
            "protocol" : "SASLSSL",
            "password" : "EventHubConnectionString",
            "dataType" : "string",
            "topic" : "topic",
            "authenticationMode" : "PLAIN",
            "consumerGroup" : "$Default",
            "username" : "$ConnectionString",
            "brokerList" : "%BrokerList%",
            "sslCaLocation": "confluent_cloud_cacert.pem",
            "lagThreshold": "100"
        }
    ]
}

Node.js v4 プログラミングモデルは現在、Kafka 拡張機能ではサポートされていません。

次のステップ

詳細については、以下の記事をお読みください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-08-16

次の方法で共有

ターゲットベースのスケーリング

考慮事項

オプトアウト

ターゲットベースのスケーリングのカスタマイズ

ランタイム スケールの監視が有効になっている Premium プラン

動的な同時実行制御のサポート

サポートされる拡張機能

Service Bus のキューとトピック

単一ディスパッチ処理

単一ディスパッチ処理 (セッション ベース)

バッチ処理

Event Hubs

スケーリングの動作と安定性

Event Hubs の有効なインスタンス数

Event Hubs の設定

Storage キュー

Azure Cosmos DB

Apache Kafka

次のステップ

フィードバック

その他のリソース

ランタイムスケールの監視が有効になっている Premium プラン

単一ディスパッチ処理 (セッションベース)