Azure Container Apps でスケーリング ルールを設定する
Azure Container Apps では、宣言型スケーリング ルールのセットにより、自動水平スケーリングが管理されます。 コンテナー アプリのリビジョンがスケールアウトされるときは、リビジョンの新しいインスタンスがオンデマンドで作成されます。 これらのインスタンスはレプリカと呼ばれます。
スケール ルールを追加または編集すると、コンテナー アプリの新しいリビジョンが作成されます。 リビジョンとは、コンテナー アプリの不変スナップショットです。 新しいリビジョンをトリガーする変更の種類を確認するには、リビジョンの変更の種類を参照します。
イベントドリブン Container Apps ジョブはスケーリング ルールを使用し、イベントに基づいて実行をトリガーします。
スケール定義
スケーリングは、制限、ルール、動作の組み合わせです。
制限は、コンテナー アプリがスケーリングする場合に可能なリビジョンあたりのレプリカの最小数と最大数を定義します。
スケールの制限 既定値 最小値 最大値 リビジョンあたりのレプリカの最小数 0 0 構成可能なレプリカの最大数は、Azure portal では 300 個、Azure CLI では 1,000 個です。 リビジョンあたりのレプリカの最大数 10 1 構成可能なレプリカの最大数は、Azure portal では 300 個、Azure CLI では 1,000 個です。 ルールとは、レプリカを追加または削除するタイミングを決定するためにコンテナー アプリによって使用される条件です。
スケール ルール は、HTTP、TCP (伝送制御プロトコル)、またはカスタムとして実装されます。
動作 は、時間の経過に伴うスケールの決定を決定するためのルールと制限の組み合わせです。
スケールの動作は、スケールがどのように決定されるか説明します。
スケーリング ルールを定義するときは、次の点を考慮することが重要です:
- コンテナー アプリがゼロにスケーリングされている場合、利用料金は請求されません。
- 処理は行われていなくても、メモリ内に残っているレプリカは、より低い "アイドル" レートで課金される可能性があります。 詳細については、「課金」を参照してください。
- リビジョンのインスタンスが常に実行されるようにする場合は、レプリカの最小数を 1 以上に設定します。
スケール ルール
スケーリングは、3 つの異なるカテゴリのトリガーによって実行されます。
- HTTP: リビジョンに対して同時に実行できる HTTP 要求数に基づくスケーリング。
- TCP: リビジョンに対して同時に実行できる TCP 接続数に基づくスケーリング。
- カスタム: CPU、メモリ、またはサポートされているイベント ドリブン データ ソースに基づいて、次のように示します。
- Azure Service Bus
- Azure Event Hubs
- Apache Kafka
- Redis
複数のスケール ルールを定義すると、いずれかのルールの最初の条件が満たされたときにコンテナー アプリでスケーリングが開始されます。
HTTP
HTTP スケール ルールを使用すると、コンテナー アプリのリビジョンのスケーリング方法を決定する同時 HTTP 要求のしきい値を制御できます。 15 秒ごとに、同時要求数は、過去 15 秒間の要求数を 15 で割った値として計算されます。 Container Apps ジョブは HTTP スケーリング ルールをサポートしていません。
次の例では、リビジョンが最大 5 レプリカまでスケールアウトし、ゼロにスケールダウンできます。 スケーリング プロパティで、1 秒あたりの同時要求数を 100 に設定します。
例
http
セクションで、HTTP スケール ルールを定義します。
スケーリング プロパティ | 説明 | 既定値 | 最小値 | 最大値 |
---|---|---|---|---|
concurrentRequests |
HTTP 要求数がこの値を超えると、レプリカがもう 1 つ追加されます。 レプリカは引き続き maxReplicas 量までプールに追加されます。 |
10 | 1 | 該当なし |
{
...
"resources": {
...
"properties": {
...
"template": {
...
"scale": {
"minReplicas": 0,
"maxReplicas": 5,
"rules": [{
"name": "http-rule",
"http": {
"metadata": {
"concurrentRequests": "100"
}
}
}]
}
}
}
}
}
Note
HTTP 以外のイベント スケール ルールの使用時には、コンテナー アプリの properties.configuration.activeRevisionsMode
プロパティを single
に設定します。
create
コマンドまたは update
コマンドで --scale-rule-http-concurrency
パラメーターを使用して、HTTP スケール ルールを定義します。
CLI パラメーター | 説明 | 既定値 | 最小値 | 最大値 |
---|---|---|---|---|
--scale-rule-http-concurrency |
同時に実行される HTTP 要求数がこの値を超えると、レプリカがもう 1 つ追加されます。 レプリカは引き続き max-replicas 量までプールに追加されます。 |
10 | 1 | 該当なし |
az containerapp create \
--name <CONTAINER_APP_NAME> \
--resource-group <RESOURCE_GROUP> \
--environment <ENVIRONMENT_NAME> \
--image <CONTAINER_IMAGE_LOCATION>
--min-replicas 0 \
--max-replicas 5 \
--scale-rule-name azure-http-rule \
--scale-rule-type http \
--scale-rule-http-concurrency 100
Azure portal でコンテナー アプリに移動します。
[スケール] を選択します。
[Edit and deploy](編集してデプロイ) を選択します。
[スケール] タブを選択します。
レプリカの最小範囲と最大範囲を選択します。
[追加] を選択します。
[ルール名] ボックスに、ルールの名前を入力します。
[種類] ドロップダウンから [HTTP スケーリング] を選びます。
[同時要求数] ボックスに、コンテナー アプリに指定する同時実行要求数を入力します。
TCP
TCP スケール ルールを使用すると、アプリのスケーリング方法を決定する同時 TCP 接続のしきい値を制御できます。 15 秒ごとに、コンカレント接続数は、過去 15 秒間の接続数を 15 で割った値として計算されます。 Container Apps ジョブは TCP スケーリング ルールをサポートしていません。
次の例では、コンテナー アプリのリビジョンが最大 5 レプリカまでスケールアウトし、ゼロにスケールダウンできます。 スケーリングしきい値では、1 秒あたりのコンカレント接続が 100 に設定されています。
例
tcp
セクションで、TCP スケール ルールを定義します。
スケーリング プロパティ | 説明 | 既定値 | 最小値 | 最大値 |
---|---|---|---|---|
concurrentConnections |
TCP のコンカレント接続数がこの値を超えると、レプリカがもう 1 つ追加されます。 コンカレント接続の数が増えるにつれて、maxReplicas の数までレプリカが追加されます。 |
10 | 1 | 該当なし |
{
...
"resources": {
...
"properties": {
...
"template": {
...
"scale": {
"minReplicas": 0,
"maxReplicas": 5,
"rules": [{
"name": "tcp-rule",
"tcp": {
"metadata": {
"concurrentConnections": "100"
}
}
}]
}
}
}
}
}
create
コマンドまたは update
コマンドで --scale-rule-tcp-concurrency
パラメーターを使用して、TCP スケール ルールを定義します。
CLI パラメーター | 説明 | 既定値 | 最小値 | 最大値 |
---|---|---|---|---|
--scale-rule-tcp-concurrency |
TCP のコンカレント接続数がこの値を超えると、レプリカがもう 1 つ追加されます。 コンカレント接続の数が増えるにつれて、max-replicas の数までレプリカが追加されます。 |
10 | 1 | 該当なし |
az containerapp create \
--name <CONTAINER_APP_NAME> \
--resource-group <RESOURCE_GROUP> \
--environment <ENVIRONMENT_NAME> \
--image <CONTAINER_IMAGE_LOCATION>
--min-replicas 0 \
--max-replicas 5 \
--scale-rule-name azure-tcp-rule \
--scale-rule-type tcp \
--scale-rule-tcp-concurrency 100
Azure portal ではサポートされていません。 Azure CLI または Azure Resource Manager を使用 して、TCP スケール ルールを構成します。
Custom
次の既定値を使用して、任意の ScaledObject ベースの KEDA スケーラー を基にコンテナー アプリのカスタム スケール ルールを作成できます。
既定値 | 秒 |
---|---|
[ポーリング間隔] | 30 |
クールダウン期間 | 300 |
イベントドリブン Container Apps ジョブの場合は、任意の ScaledJob ベースのKEDA スケーラーを基にカスタム スケール ルールを作成できます。
カスタム スケール ルールを作成する方法を、次の例に示します。
例
この例では、Azure Service Bus スケーラーをコンテナー アプリのスケール ルールに変換する方法を示しますが、他の ScaledObject ベースの KEDA スケーラー 仕様にも同じプロセスを使用します。
認証では、KEDA スケーラーの認証パラメーターを コンテナー アプリ シークレットに変換します。
次の手順では、KEDA スケーラーをコンテナー アプリのスケールルールに変換する方法を示します。 このスニペットは、各セクションがテンプレート全体のコンテキストに収まる場所を示す ARM テンプレートの抜粋です。
{
...
"resources": {
...
"properties": {
...
"configuration": {
...
"secrets": [
{
"name": "<NAME>",
"value": "<VALUE>"
}
]
},
"template": {
...
"scale": {
"minReplicas": 0,
"maxReplicas": 5,
"rules": [
{
"name": "<RULE_NAME>",
"custom": {
"metadata": {
...
},
"auth": [
{
"secretRef": "<NAME>",
"triggerParameter": "<PARAMETER>"
}
]
}
}
]
}
}
}
}
}
以下の例が ARM テンプレートにどのように適合するかについては、この抜粋を参照してください。
まず、スケール ルールの種類とメタデータを定義します。
KEDA スケーラー仕様で、
type
値を検索します。triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5"
ARM テンプレートで、スケール ルールの
custom.type
プロパティにスケーラーのtype
値を入力します。... "rules": [ { "name": "azure-servicebus-queue-rule", "custom": { "type": "azure-servicebus", "metadata": { "queueName": "my-queue", "namespace": "service-bus-namespace", "messageCount": "5" } } } ] ...
KEDA スケーラー仕様で、
metadata
値を検索します。triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5"
ARM テンプレートで、すべてのメタデータ値をスケール ルールの
custom.metadata
セクションに追加します。... "rules": [ { "name": "azure-servicebus-queue-rule", "custom": { "type": "azure-servicebus", "metadata": { "queueName": "my-queue", "namespace": "service-bus-namespace", "messageCount": "5" } } } ] ...
認証
KEDA スケーラーは、authenticationRef
プロパティによって参照される TriggerAuthentication でのシークレットの使用をサポートします。 TriggerAuthentication オブジェクトをコンテナー アプリのスケール ルールにマップできます。
Note
コンテナー アプリのスケール ルールでは、シークレット参照のみがサポートされます。 ポッド ID など、他の種類の認証はサポートされていません。
KEDA
ScaledObject
仕様によって参照されるTriggerAuthentication
オブジェクトを検索します。KEDA 仕様で、
TriggerAuthentication
オブジェクトの各secretTargetRef
とそれに関連付けられているシークレットを検索します。apiVersion: v1 kind: Secret metadata: name: my-secrets namespace: my-project type: Opaque data: connection-string-secret: <SERVICE_BUS_CONNECTION_STRING> --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: secretTargetRef: - parameter: connection name: my-secrets key: connection-string-secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-rule namespace: default spec: scaleTargetRef: name: my-scale-target triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5" authenticationRef: name: azure-servicebus-auth
ARM テンプレートで、スケール ルールの
auth
配列にすべてのエントリを追加します。シークレット値を含むコンテナー アプリの
secrets
配列に、シークレットを追加します。triggerParameter
プロパティの値を、TriggerAuthentication
のkey
プロパティの値に設定します。secretRef
プロパティの値をコンテナー アプリ シークレットの名前に設定します。
{ ... "resources": { ... "properties": { ... "configuration": { ... "secrets": [ { "name": "connection-string-secret", "value": "<SERVICE_BUS_CONNECTION_STRING>" } ] }, "template": { ... "scale": { "minReplicas": 0, "maxReplicas": 5, "rules": [ { "name": "azure-servicebus-queue-rule", "custom": { "type": "azure-servicebus", "metadata": { "queueName": "my-queue", "namespace": "service-bus-namespace", "messageCount": "5" }, "auth": [ { "secretRef": "connection-string-secret", "triggerParameter": "connection" } ] } } ] } } } } }
一部のスケーラーでは、環境変数内の値を参照するために、
FromEnv
サフィックスを持つメタデータがサポートされています。 コンテナー アプリは、ARM テンプレートにリストされている環境変数の最初のコンテナーを確認します。セキュリティ関連の詳細については、「考慮事項」セクション を参照してください。
KEDA スケーラー仕様で、
type
値を検索します。triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5"
CLI コマンドで、
--scale-rule-type
パラメーターを仕様のtype
値に設定します。az containerapp create \ --name <CONTAINER_APP_NAME> \ --resource-group <RESOURCE_GROUP> \ --environment <ENVIRONMENT_NAME> \ --image <CONTAINER_IMAGE_LOCATION> --min-replicas 0 \ --max-replicas 5 \ --secrets "connection-string-secret=<SERVICE_BUS_CONNECTION_STRING>" \ --scale-rule-name azure-servicebus-queue-rule \ --scale-rule-type azure-servicebus \ --scale-rule-metadata "queueName=my-queue" \ "namespace=service-bus-namespace" \ "messageCount=5" \ --scale-rule-auth "connection=connection-string-secret"
KEDA スケーラー仕様で、
metadata
値を検索します。triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5"
CLI コマンドで、
--scale-rule-metadata
パラメーターをメタデータ値に設定します。コマンド ラインで使用するために、値を YAML 形式からキーと値のペアに変換する必要があります。 各キーと値のペアをスペースで区切ります。
az containerapp create \ --name <CONTAINER_APP_NAME> \ --resource-group <RESOURCE_GROUP> \ --environment <ENVIRONMENT_NAME> \ --image <CONTAINER_IMAGE_LOCATION> --min-replicas 0 \ --max-replicas 5 \ --secrets "connection-string-secret=<SERVICE_BUS_CONNECTION_STRING>" \ --scale-rule-name azure-servicebus-queue-rule \ --scale-rule-type azure-servicebus \ --scale-rule-metadata "queueName=my-queue" \ "namespace=service-bus-namespace" \ "messageCount=5" \ --scale-rule-auth "connection=connection-string-secret"
認証
KEDA スケーラーは、authenticationRef プロパティによって参照される TriggerAuthentication でのシークレットの使用をサポートします。 TriggerAuthentication オブジェクトをコンテナー アプリのスケール ルールにマップできます。
Note
コンテナー アプリのスケール ルールでは、シークレット参照のみがサポートされます。 ポッド ID など、他の種類の認証はサポートされていません。
KEDA
ScaledObject
仕様によって参照されるTriggerAuthentication
オブジェクトを検索します。TriggerAuthentication
オブジェクトの各secretTargetRef
を識別します。apiVersion: v1 kind: Secret metadata: name: my-secrets namespace: my-project type: Opaque data: connection-string-secret: <SERVICE_BUS_CONNECTION_STRING> --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: secretTargetRef: - parameter: connection name: my-secrets key: connection-string-secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-rule namespace: default spec: scaleTargetRef: name: my-scale-target triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5" authenticationRef: name: azure-servicebus-auth
コンテナー アプリで、
secretTargetRef
プロパティに一致するシークレットを作成します。CLI コマンドで、各
secretTargetRef
エントリのパラメーターを設定します。--secrets
パラメーターを使用してシークレット エントリを作成します。 シークレットが複数ある場合は、スペースで区切ります。--scale-rule-auth
パラメーターを使用して、認証エントリを作成します。 複数のエントリがある場合は、スペースで区切ります。
az containerapp create \ --name <CONTAINER_APP_NAME> \ --resource-group <RESOURCE_GROUP> \ --environment <ENVIRONMENT_NAME> \ --image <CONTAINER_IMAGE_LOCATION> --min-replicas 0 \ --max-replicas 5 \ --secrets "connection-string-secret=<SERVICE_BUS_CONNECTION_STRING>" \ --scale-rule-name azure-servicebus-queue-rule \ --scale-rule-type azure-servicebus \ --scale-rule-metadata "queueName=my-queue" \ "namespace=service-bus-namespace" \ "messageCount=5" \ --scale-rule-auth "connection=connection-string-secret"
Azure portal でコンテナー アプリに移動します。
[スケール] を選択します。
[Edit and deploy](編集してデプロイ) を選択します。
スケールとレプリカ タブを選択します。
レプリカの最小範囲と最大範囲を選択します。
[追加] を選択します。
[ルール名] ボックスに、ルールの名前を入力します。
[種類] ドロップダウンから [カスタム] を選びます。
KEDA スケーラー仕様で、
type
値を検索します。triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5"
[カスタム ルール タイプ] ボックスに、スケーラー
type
値を入力します。KEDA スケーラー仕様で、
metadata
値を検索します。triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5"
ポータルで、[メタデータ] セクションを検索し、[追加] を選択します。 KEDA の
ScaledObject
仕様メタデータ セクションに各項目の名前と値を入力します。
認証
KEDA スケーラーは、authenticationRef プロパティによって参照される TriggerAuthentication でのシークレットの使用をサポートします。 TriggerAuthentication オブジェクトをコンテナー アプリのスケール ルールにマップできます。
Note
コンテナー アプリのスケール ルールでは、シークレット参照のみがサポートされます。 ポッド ID など、他の種類の認証はサポートされていません。
コンテナー アプリで、参照するシークレットを作成します。
KEDA
ScaledObject
仕様によって参照されるTriggerAuthentication
オブジェクトを検索します。TriggerAuthentication
オブジェクトの各secretTargetRef
を識別します。apiVersion: v1 kind: Secret metadata: name: my-secrets namespace: my-project type: Opaque data: connection-string-secret: <SERVICE_BUS_CONNECTION_STRING> --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: secretTargetRef: - parameter: connection name: my-secrets key: connection-string-secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-rule namespace: default spec: scaleTargetRef: name: my-scale-target triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5" authenticationRef: name: azure-servicebus-auth
[認証] セクションで [追加] を選択して、各 KEDA の
secretTargetRef
パラメーターに対するエントリを作成します。
既定のスケール ルール
スケール ルールを作成しない場合は、既定のスケール ルールがコンテナー アプリに適用されます。
トリガー | 最小レプリカ数 | 最大レプリカ数 |
---|---|---|
HTTP | 0 | 10 |
重要
イングレスを有効にしない場合は、スケール ルールを作成するか、minReplicas
を 1 以上に設定してください。 イングレスが無効になっていて、minReplicas
またはカスタム スケール ルールを定義しない場合、コンテナー アプリはゼロにスケーリングされ、バックアップが開始されません。
スケーリングの動作
スケーリングには、以下の既定の動作があります。
パラメーター | 値 |
---|---|
[ポーリング間隔] | 30 秒 |
クールダウン期間 | 300 秒 |
スケール アップ安定化期間 | 0 秒 |
スケール ダウン安定化期間 | 300 秒 |
スケール アップ ステップ | 1、4、電流の 100% |
スケール ダウン ステップ | 電流の 100% |
スケーリング アルゴリズム | desiredReplicas = ceil(currentMetricValue / targetMetricValue) |
- ポーリング間隔 は、KEDA によってイベント ソースが照会される頻度です。 この値は、HTTP および TCP のスケールルールには適用されません。
- クール ダウン期間 は、最後のイベントが観察されてからアプリケーションが最小レプリカ数にスケールダウンするまでに経過した期間を示します。
- スケールアップ安定化期間は、スケールアップ条件が満たされてからスケールアップの決定を実行するまでの待機期間です。
- スケールダウン安定化期間は、スケールダウン条件が満たされてからスケールダウンの決定を実行するまでの待機期間です。
- スケール アップ ステップは、新しいインスタンスが追加される比率です。 1、4、8、16、32、... と増えていき、設定された最大レプリカ数まで続きます。
- スケール ダウン ステップ は、レプリカが削除される比率です。 既定では、シャットダウンする必要があるすべてのレプリカが削除されます。
- スケーリング アルゴリズムは、現在必要なレプリカ数を計算するために使用される計算式です。
例
次のスケール ルールでは、
"minReplicas": 0,
"maxReplicas": 20,
"rules": [
{
"name": "azure-servicebus-queue-rule",
"custom": {
"type": "azure-servicebus",
"metadata": {
"queueName": "my-queue",
"namespace": "service-bus-namespace",
"messageCount": "5"
}
}
}
]
アプリがスケールアウトすると、KEDA は空のキューから始まり、次の手順を実行します:
my-queue
を 30 秒ごとにチェックします。- キューの長さが 0 の場合は、(1) に戻ります。
- キューの長さが 0 より大きい場合は、アプリを 1 にスケーリングします。
- キューの長さが 50 の場合は、
desiredReplicas = ceil(50/5) = 10
と計算します。 - アプリを
min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount))
にスケーリングします。 - (1) に戻ります。
アプリが最大レプリカ数の 20 にスケーリングされた場合、スケーリングは同じ前の手順を実行します。 スケールダウンは、条件が 300 秒間満たされた場合 (スケール ダウン安定化期間) にのみ発生します。 キューの長さが 0 になると、KEDA はアプリを 0 にスケーリングするまで 300 秒間 (クールダウン期間) 待機します。
考慮事項
"複数のリビジョン" モードでは、新しいスケール トリガーを追加するとアプリケーションの新しいリビジョンが作成されますが、古いリビジョンも引き続き前のスケール ルールで使用できます。 [リビジョン管理] ページを使用してトラフィックの割り当てを管理してください。
アプリケーションがゼロにスケーリングされているとき、利用料金は発生しません。 価格の詳細については、「Azure Container Apps での課金」を参照してください。
Azure Container Apps 上のすべての .NET アプリに対してデータ保護を有効にする必要があります。 詳細については、「Azure Container Apps での ASP.NET Core アプリのデプロイとスケーリング」を参照してください。
既知の制限事項
垂直方向のスケーリングはサポートされていません。
レプリカの数は目標値であり、保証はされません。
Dapr アクターを使用して状態を管理しようとしている場合は、ゼロへのスケーリングがサポートされないことに注意してください。 Dapr では仮想アクターを使用して非同期呼び出しが管理されます。つまり、メモリ内表現は、ID や有効期間に関連付けられません。