Azure Container Appsでスケーリングルールを設定する

Azure Container Appsは、一連の宣言型スケーリング規則を使用して自動水平スケーリングを管理します。コンテナーアプリのリビジョンがスケールアウトすると、プラットフォームはリビジョンの新しいインスタンスをオンデマンドで作成します。これらのインスタンスはレプリカと呼ばれます。

このスケーリング動作をサポートするために、Azure Container Appsは KEDA (Kubernetes イベントドリブン自動スケーリング) を使用します。 KEDA では、HTTP 要求、キューメッセージ、CPU とメモリの負荷、Azure Service Bus、Azure Event Hubs、Apache Kafka、Redis などのイベントソースなど、さまざまなメトリックに対するスケーリングがサポートされています。詳細については、 KEDA ドキュメントのスケーラーを参照してください。

スケーリングルールを追加または編集するときは、コンテナーアプリの新しいリビジョンを作成します。リビジョンとは、コンテナーアプリの不変スナップショットです。新しいリビジョンをトリガーする変更の種類を確認するには、リビジョンの変更の種類を参照します。

イベントドリブン Container Apps ジョブはスケーリングルールを使用し、イベントに基づいて実行をトリガーします。

スケール定義

スケーリングは、制限、ルール、動作の組み合わせです。

制限は、コンテナーアプリがスケーリングする場合に可能なリビジョンあたりのレプリカの最小数と最大数を定義します。

スケールの制限	既定値	最小値	最大値
リビジョンごとの最小レプリカ数	0	0	構成可能なレプリカの最大数は 1,000 です。
リビジョンあたりのレプリカの最大数	10	1	構成可能なレプリカの最大数は 1,000 です。

ルールとは、レプリカを追加または削除するタイミングを決定するためにコンテナーアプリによって使用される条件です。

スケールルールは、HTTP、TCP (伝送制御プロトコル)、またはカスタムとして実装されます。
動作は、時間の経過に伴うスケールの決定を決定するためのルールと制限の組み合わせです。

スケールの動作は、スケールがどのように決定されるか説明します。

スケーリングルールを定義するときは、次の点を考慮してください。

コンテナーアプリがゼロにスケーリングされている場合、利用料金は請求されません。
処理されていないがメモリ内に残っているレプリカは、より低い "アイドル" レートで課金される場合があります。詳細については、「課金」を参照してください。
リビジョンのインスタンスが常に実行されるようにする場合は、レプリカの最小数を 1 以上に設定します。
プラットフォームのアップグレードまたはメンテナンス中に、一時的に予想以上のレプリカが表示される場合があります。 Container Apps を使用すると、既定の Kubernetes の動作と同様に、トラフィックをシフトする前に、新しいレプリカを事前にウォームアップすることによって運用ワークロードの影響を受けないようにします。操作が完了すると、追加のレプリカが自動的に削除されます。

スケールルール

トリガーの 3 つのカテゴリによって、スケーリングの実行方法が決まります。

HTTP: あなたのリビジョンに対する同時 HTTP 要求数に基づいています。
TCP: リビジョンに対して同時に実行できる TCP 接続数に基づきます。
カスタム: 次のようなカスタムメトリックに基づいています。
- CPU
- 記憶
- サポートされているイベントドリブンデータソース:
  - Azure Service Bus
  - Azure Event Hubs
  - Apache Kafka
  - Redis

複数のスケールルールを定義した場合、任意のルールの最初の条件が満たされると、コンテナーアプリのスケーリングが開始されます。

注記

Container Apps で Functions を使用している場合、既定のエクスペリエンスでは、関数トリガーとバインドに基づいてスケールルールが自動的に構成されます。 Azure ポータルでは、これらのアプリの スケールルールの追加 ボタンが無効になります。顧客定義のルールが必要な場合は、「allowScalingRuleOverrideで説明されているように、を使用します。

HTTP

HTTP スケーリングルールを使用する場合は、コンテナーアプリのリビジョンのスケーリング方法を決定する同時 HTTP 要求のしきい値を制御します。 15 秒ごとに、同時要求数は、過去 15 秒間の要求数を 15 で割った値として計算されます。 Container Apps ジョブは HTTP スケーリングルールをサポートしていません。

次の例では、リビジョンが最大 5 レプリカまでスケールアウトし、ゼロにスケールダウンできます。スケーリングプロパティで、1 秒あたりの同時要求数を 100 に設定します。

例

http セクションで、HTTP スケールルールを定義します。

スケーリングプロパティ	説明	既定値	最小値	最大値
`concurrentRequests`	HTTP 要求の数がこの値を超えると、アプリは別のレプリカを追加します。アプリは引き続き、 `maxReplicas` の量までレプリカを追加します。	10	1	該当なし

resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 5
        rules: [
          {
            name: 'http-rule'
            http: {
              metadata: {
                concurrentRequests: '100'
              }
            }
          }
        ]
      }
    }
  }
}

注記

HTTP 以外のイベントスケールルールを使用する場合は、コンテナーアプリの properties.configuration.activeRevisionsMode プロパティを single に設定します。

http セクションで、HTTP スケールルールを定義します。

スケーリングプロパティ	説明	既定値	最小値	最大値
`concurrentRequests`	HTTP 要求の数がこの値を超えると、アプリは別のレプリカを追加します。アプリは引き続き、 `maxReplicas` の量までレプリカを追加します。	10	1	該当なし

{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [{
            "name": "http-rule",
            "http": {
              "metadata": {
                "concurrentRequests": "100"
              }
            }
          }]
        }
      }
    }
  }
}

注記

HTTP 以外のイベントスケールルールを使用する場合は、コンテナーアプリの properties.configuration.activeRevisionsMode プロパティを single に設定します。

--scale-rule-http-concurrency または create コマンドで update パラメーターを使用して、HTTP スケールルールを定義します。

CLI パラメーター	説明	既定値	最小値	最大値
`--scale-rule-http-concurrency`	同時 HTTP 要求の数がこの値を超えると、アプリは別のレプリカを追加します。アプリは引き続き、 `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 つのレプリカにスケールアウトされ、0 にスケールインできます。スケーリングしきい値では、1 秒あたりのコンカレント接続が 100 に設定されています。

例

tcp セクションで、TCP スケールルールを定義します。

スケーリングプロパティ	説明	既定値	最小値	最大値
`concurrentConnections`	同時 TCP 接続の数がこの値を超えると、システムは別のレプリカを追加します。システムは、同時接続の数が増えるにつれて、 `maxReplicas` の量までレプリカを追加し続けます。	10	1	該当なし

resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 5
        rules: [
          {
            name: 'tcp-rule'
            http: {
              metadata: {
                concurrentConnections: '100'
              }
            }
          }
        ]
      }
    }
  }
}

tcp セクションで、TCP スケールルールを定義します。

スケーリングプロパティ	説明	既定値	最小値	最大値
`concurrentConnections`	同時 TCP 接続の数がこの値を超えると、システムは別のレプリカを追加します。システムは、同時接続の数が増えるにつれて、 `maxReplicas` の量までレプリカを追加し続けます。	10	1	該当なし

{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [{
            "name": "tcp-rule",
            "tcp": {
              "metadata": {
                "concurrentConnections": "100"
              }
            }
          }]
        }
      }
    }
  }
}

--scale-rule-tcp-concurrency または create コマンドで update パラメーターを使用して、TCP スケールルールを定義します。

CLI パラメーター	説明	既定値	最小値	最大値
`--scale-rule-tcp-concurrency`	同時 TCP 接続の数がこの値を超えると、システムは別のレプリカを追加します。システムは、同時接続の数が増えるにつれて、 `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 \
  --transport tcp \
  --ingress <external/internal> \
  --target-port <CONTAINER_TARGET_PORT> \
  --scale-rule-name azure-tcp-rule \
  --scale-rule-type tcp \
  --scale-rule-tcp-concurrency 100

Azure ポータルでは、この機能はサポートされていません。 TCP スケールルールを構成するには、Azure CLI、Azure Resource Manager、または Bicep を使用します。

カスタム

次の既定値を使用して、 ScaledObject ベースの KEDA スケーラーに基づいて、カスタム Container Apps スケーリングルールを作成します。

既定値	秒数
[ポーリング間隔]	30
クールダウン期間	300

注記

クールダウン期間は、最終的なレプリカから 0 にスケールインする場合にのみ有効になります。クールダウン期間は、他のレプリカが削除されるため、スケーリングには影響しません。

イベントドリブン Container Apps ジョブの場合は、ScaledJob ベースの KEDA スケーラーに基づいてカスタムスケーリングルールを作成します。

カスタムスケールルールを作成する方法を、次の例に示します。

例

この例では、Azure Service Bus スケーラーを Container Apps スケールルールに変換する方法を示しますが、他の ScaledObject ベースの KEDA スケーラー仕様でも同じプロセスを使用します。

認証では、KEDA スケーラーの認証パラメーターにより、Container Apps シークレット、またはマネージド ID が取得されます。

次の手順では、KEDA スケーラーをコンテナーアプリのスケールルールに変換する方法を示します。このスニペットは、各セクションがテンプレート全体のコンテキストに収まる場所を示す Bicep テンプレートの抜粋です。

resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    configuration: {
      ...
      secrets: [
        {
          name: '<NAME>'
          value: '<VALUE>'
        }
      ]
    }
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 5
        rules: [
          {
            name: '<RULE_NAME>'
            custom: {
              metadata: {
                ...
              }
              auth: [
                {
                  secretRef: '<NAME>'
                  triggerParameter: '<PARAMETER>'
                }
              ]
            }
          }
        ]
      }
    }
  }
}

次の例がBicep テンプレートにどのように適合するかについては、この抜粋を参照してください。

まず、スケールルールの種類とメタデータを定義します。

KEDA スケーラー仕様で、type 値を検索します。

triggers:
 - type: azure-servicebus ⬅️
  metadata:
    queueName: my-queue
    namespace: service-bus-namespace
    messageCount: "5"

Bicep テンプレートで、スケールルールの type プロパティにスケーラーのcustom.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"                ⬅️

Bicep テンプレートで、すべてのメタデータ値をスケールルールの custom.metadata セクションに追加します。

...
rules: [
  {
    name: 'azure-servicebus-queue-rule'
    custom: {
      type: 'azure-servicebus'
      metadata: {
        queueName: 'my-queue'              ⬅️
        namespace: 'service-bus-namespace' ⬅️
        messageCount: '5'                  ⬅️
      }
    }
  }
]
...

認証

Container Apps スケールルールでは、シークレットベースの認証がサポートされています。 Azure Queue Storage、Azure Service Bus、Azure Event Hubsなど、Azure リソースのスケールルールもマネージド ID をサポートします。可能な場合は、マネージド ID 認証を使用して、アプリ内にシークレットを格納しないようにしてください。

シークレットを使用する

認証にシークレットを使用するには、コンテナーアプリの secrets 配列にシークレットを作成します。スケールルールの auth 配列でシークレット値を使用します。

KEDA スケーラーは、プロパティが参照する authenticationRef でシークレットを使用できます。 TriggerAuthentication オブジェクトをコンテナーアプリのスケールルールにマップできます。

KEDA TriggerAuthentication 仕様によって参照される ScaledObject オブジェクトを検索します。

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

Bicep テンプレートで、シークレットごとに次の手順を実行します。

シークレットの名前と値を含むコンテナーアプリの配列に、secretsを追加します。

スケールルールの auth 配列にエントリを追加します。

triggerParameter プロパティの値を、secretTargetRef の parameter プロパティの値に設定します。

secretRef プロパティの値を、secretTargetRef の key プロパティの名前に設定します。

resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    configuration: {
      ...
      secrets: [
        {                                          ⬅️
          name: 'connection-string-secret'         ⬅️
          value: '<SERVICE_BUS_CONNECTION_STRING>' ⬅️
        }                                          ⬅️
      ]
    }
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 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 テンプレートにリストされている環境変数の最初のコンテナーを確認します。

セキュリティ関連の詳細については、「考慮事項」セクションを参照してください。

マネージド ID の使用

Container Apps スケールルールでは、マネージド ID を使用して、Azure サービスで認証できます。次の Bicep テンプレートは、Azure キュースケーラーに対して認証するために、システムベースのマネージド ID を渡します。

次のコードを使用する前に、 <> で囲まれたプレースホルダーを実際の値に置き換えます。

scale: {
  minReplicas: 0
  maxReplicas: 4
  rules: [
    {
      name: 'azure-queue'
      custom: {
        type: 'azure-queue'
        metadata: {
          accountName: '<ACCOUNT_NAME>'
          queueName: '<QUEUE_NAME>'
          queueLength: '1'
        },
        identity: 'system'
      }
    }
  ]
}

スケールルールでマネージド ID を使用する方法の詳細については、マネージド IDに関するページを参照してください。

次の手順では、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 テンプレートで、スケールルールの type プロパティにスケーラーの custom.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 TriggerAuthentication 仕様によって参照される ScaledObject オブジェクトを検索します。

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 テンプレートで、シークレットごとに次の手順を実行します。

シークレットの名前と値を含むコンテナーアプリの配列に、secretsを追加します。
スケールルールの auth 配列にエントリを追加します。
1. triggerParameter プロパティの値を、secretTargetRef の parameter プロパティの値に設定します。
2. secretRef プロパティの値を、secretTargetRef の key プロパティの名前に設定します。

{
  ...
  "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"         ⬅️
                  }                                          ⬅️
                ]
              }
            }
          ]
        }
      }
    }
  }
}

セキュリティ関連の詳細については、「考慮事項」セクションを参照してください。

マネージド ID の使用

Container Apps スケールルールでは、マネージド ID を使用して、Azure サービスで認証できます。次の ARM テンプレートは、システム割り当てマネージド ID を渡して、Azure キュースケーラーの認証を行います。

次のコードを使用する前に、 <> で囲まれたプレースホルダーを実際の値に置き換えます。

"scale": {
  "minReplicas": 0,
  "maxReplicas": 4,
  "rules": [
    {
      "name": "azure-queue",
      "custom": {
        "type": "azure-queue",
        "metadata": {
          "accountName": "<ACCOUNT_NAME>",
          "queueName": "<QUEUE_NAME>",
          "queueLength": "1"
        },
        "identity": "system"
      }
    }
  ]
}

スケールルールでマネージド ID を使用する方法の詳細については、マネージド IDに関するページを参照してください。

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"

認証

シークレットを使用する

Container Apps スケールルールのシークレットベースの認証を構成するには、コンテナーアプリでシークレットを構成し、スケールルールでそれらを参照します。

KEDA スケーラーは、プロパティが参照に使用する authenticationRef 内のシークレットをサポートします。 TriggerAuthentication オブジェクトを Container Apps スケールルールにマップできます。

KEDA TriggerAuthentication 仕様によって参照される ScaledObject オブジェクトを検索します。 secretTargetRef オブジェクトの各 TriggerAuthentication を識別します。

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"                ⬅️

マネージド ID の使用

Container Apps スケールルールでは、マネージド ID を使用して、Azure サービスで認証できます。次のコマンドは、ユーザー割り当てマネージド ID を持つコンテナーアプリを作成し、それを使用して Azure Queue スケーラーの認証を行います。

次のコードを使用する前に、 <> で囲まれたプレースホルダーを実際の値に置き換えます。

az containerapp create \
  --resource-group <RESOURCE_GROUP> \
  --name <APP_NAME> \
  --environment <ENVIRONMENT_ID> \
  --user-assigned <USER_ASSIGNED_IDENTITY_ID> \
  --scale-rule-name azure-queue \
  --scale-rule-type azure-queue \
  --scale-rule-metadata "accountName=<AZURE_STORAGE_ACCOUNT_NAME>" "queueName=queue1" "queueLength=1" \
  --scale-rule-identity <USER_ASSIGNED_IDENTITY_ID>

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 仕様メタデータセクションに各項目の名前と値を入力します。

認証

シークレットを使用する

コンテナーアプリで、参照するシークレットを作成します。

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 パラメーターに対するエントリを作成します。

マネージド ID の使用

マネージド ID 認証は、Azure portalではサポートされていません。マネージド ID を使用して認証するには、Azure CLI または Azure Resource Manager を使用します。

既定の尺度規則

スケールルールを作成しない場合は、既定のスケールルールがコンテナーアプリに適用されます。

トリガー	最小レプリカ数	最大レプリカ数
HTTP	0	10

重要

イングレスを有効にしない場合は、スケールルールを作成するか、minReplicas を 1 以上に設定してください。イングレスが無効で、 minReplicas またはカスタムスケールルールを定義していない場合、コンテナーアプリはゼロにスケーリングされ、バックアップを開始する方法はありません。

スケーリング動作

スケーリングの動作は次のとおりです。

行動	価値
[ポーリング間隔]	30 秒
クールダウン期間	300 秒
スケールアップ安定化期間	0 秒
縮小安定化期間	300 秒
スケールアップステップ	1, 4, 8, 16, 32, ...構成された最大レプリカ数まで
スケールダウンステップ	シャットダウンする必要があるレプリカの 100%
スケーリングアルゴリズム	`desiredReplicas = ceil(currentMetricValue / targetMetricValue)`

ポーリング間隔 は、KEDA がイベントソースを照会する頻度です。この値は、HTTP および TCP のスケールルールには適用されません。
クールダウン期間 は、アプリケーションがレプリカの最小数にスケールダウンされるまでに、KEDA が最後のイベントを待機した後の時間です。
スケールアップ安定化ウィンドウ は、スケールアップ条件が満たされた後に、KEDA がスケールアップの決定を実行するまでの待機時間です。
スケールダウン安定化ウィンドウ は、スケールダウン条件が満たされた後に、KEDA がスケールダウンの決定を実行するまでの待機時間です。
スケールアップ手順 は、コンテナーアプリがスケールアウトされるときに追加されるレプリカの数です。1 から始まり、構成済みの最大レプリカ数まで 4、8、16、32 まで増加します。
スケールダウン手順 は、コンテナーアプリのスケールイン時に削除されるレプリカの数です。 KEDA は、シャットダウンする必要があるレプリカの 100% を削除します。
スケーリングアルゴリズムは、現在必要なレプリカ数を計算するために使用される計算式です。

例

スケールルールは次のようになります。

"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を参照してください。

既知の制限事項

垂直方向のスケーリングはサポートされていません。
レプリカの数は目標値であり、保証はされません。
Dapr アクターを使用して状態を管理している場合は、ゼロへのスケーリングはサポートされていないことに注意してください。 Dapr では仮想アクターを使用して非同期呼び出しが管理されます。つまり、メモリ内表現は、ID や有効期間に関連付けられません。
プロキシ設定を使用した KEDA プロキシの変更はサポートされていません。 NAT ゲートウェイまたはユーザー定義ルート (UDR) でワークロードプロファイルを使用して、ネットワークアプライアンスにトラフィックを送信することを検討してください。ここで、トラフィックを検査またはプロキシできます。

次のステップ

シークレットを管理する

フィードバック

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

Last updated on 2026-05-24

Azure Container Appsでスケーリング ルールを設定する

スケール定義

スケール ルール

HTTP

例

TCP

例

カスタム

例

認証

シークレットを使用する

マネージド ID の使用

認証

シークレットを使用する

マネージド ID の使用

認証

シークレットを使用する

マネージド ID の使用

認証

シークレットを使用する

マネージド ID の使用

既定の尺度規則

スケーリング動作

例

考慮事項

既知の制限事項

次のステップ

フィードバック

その他のリソース

Azure Container Appsでスケーリングルールを設定する

スケールルール