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

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

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

実行モデル IsBatched IsSessionsEnabled "インスタンスあたりのターゲット実行数" に使用される設定
単一ディスパッチ処理 false false maxConcurrentCalls
単一ディスパッチ処理 (セッション ベース) false true maxConcurrentSessions
バッチ処理 true false maxMessageBatchSize or 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 属性は maxEventBatchSizemaxBatchSize です。 ただし、ターゲット ベースのスケーリングを微調整する場合は、オーバーライドする個別のパラメーター targetUnprocessedEventThreshold を定義すると、バッチ設定を変更せずに "インスタンスあたりのターゲット実行数" を設定できます。 targetUnprocessedEventThreshold を設定すると、未処理のイベント数の合計がこの値で除算され、インスタンスの数が決定されます。これは、バランスの取れたパーティション分散を作成するワーカー インスタンス数に切り上げられます。

Note

Event Hubs はパーティション分割されたワークロードであるため、Event Hubs のターゲット インスタンス数はイベント ハブ内のパーティションの数によって制限されます。

具体的な設定は、Event Hubs 拡張機能のバージョンによって異なります。

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

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

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

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

次のステップ

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