次の方法で共有


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

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

ターゲットベースのスケーリングは、これらの種類の拡張機能で既定で使用されていた以前の 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 つの実行モデルがサポートされています。 IsBatchedIsSessionsEnabled の既定値は false です。

実行モデル IsBatched IsSessionsEnabled "インスタンスあたりのターゲット実行数" に使用される設定
単一ディスパッチ処理 false false maxConcurrentCalls
単一ディスパッチ処理 (セッション ベース) false true maxConcurrentSessions
バッチ処理 true false maxMessageBatchSize または maxMessageCount

Note

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

単一ディスパッチ処理

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

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

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

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

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

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

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

バッチ処理

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

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

{
    "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.jsonmaxEventBatchSize 設定を変更し、"インスタンスあたりのターゲット実行数" を設定します。

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

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

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

ストレージ キュー

Storage 拡張機能の v2.x 以降の場合は、host.jsonbatchSize 設定を変更して、"インスタンスあたりのターゲット実行数" を設定します。

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

次のステップ

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