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

[アーティクル]
05/05/2024

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

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 を使用する場合は、動的な同時実行制御を有効にすることもできます。この構成では、動的な同時実行制御機能によって "インスタンスあたりのターゲット実行数" の値が自動的に決定されます。制限付きの同時実行制御から始まり、時間の経過に伴って最適な設定が特定されます。

サポートされる拡張機能

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 を設定すると、未処理のイベント数の合計がこの値で除算され、インスタンスの数が決定されます。これは、バランスの取れたパーティション分散を作成するワーカーインスタンス数に切り上げられます。

Note

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 拡張機能の 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"
        }
    ]
}

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

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 拡張機能ではサポートされていません。

次のステップ

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

次の方法で共有

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

考慮事項

オプトアウト

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

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

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

サポートされる拡張機能

Service Bus のキューとトピック

単一ディスパッチ処理

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

バッチ処理

Event Hubs

ストレージキュー

Azure Cosmos DB

Apache Kafka

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

考慮事項

オプトアウト

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

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

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

サポートされる拡張機能

Service Bus のキューとトピック

単一ディスパッチ処理

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

バッチ処理

Event Hubs

ストレージ キュー

Azure Cosmos DB

Apache Kafka

次のステップ

フィードバック

その他のリソース

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

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

ストレージキュー