Azure Functions on Azure Container Appsのスケーリングを細かく制御したい場合、今回のGAは重要な更新です。従来はFunctionsのトリガーからKEDAスケールルールが自動生成され、利用者が個別にルールを差し替えることは前提になっていませんでした。今回一般提供されたallowScalingRuleOverrideにより、管理者や開発者はプラットフォーム管理のスケールルールを無効化し、自分で定義したKEDAスケールルールを使えるようになります。対象はAzure Container Apps上でkind=functionappとして動作するAzure Functionsであり、既定値のままなら既存環境への影響は限定的です。(Microsoft Azure)
Azure Functions on Azure Container Appsのスケールルール上書きとは
Azure Functions on Azure Container Appsでは、通常、FunctionsホストがHTTP、Queue、Timerなどのトリガーを検出し、Azure Container Appsが対応するKEDAトリガー構成をアプリのリビジョンに作成します。つまり、開発者はFunctionsのトリガーやhost.jsonを中心に設定し、KEDA側のスケールルールはプラットフォームに任せる設計でした。(Microsoft Learn)
今回の更新では、properties.template.scale.allowScalingRuleOverrideをtrueに設定することで、この自動マッピングを無効化できます。そのうえで、template.scale.rulesに独自のスケールルールを定義します。たとえば、Azure Queueのキュー長やHTTPの同時リクエスト数を、既定の変換ルールではなく自社の処理能力やSLAに合わせて指定できます。(Microsoft Learn)
この機能の本質は「Azure FunctionsをContainer Apps上で使いながら、スケーリングの判断基準だけはKEDAルールとして明示的に管理できる」点にあります。自動スケーリングを捨てる機能ではなく、自動生成されたルールから、運用者が設計したルールへ責任範囲を切り替える機能と考えると理解しやすいでしょう。
何が変わるのか
これまでのAzure Functions on Container Appsでは、Functionsトリガーの設定がKEDAスケールルールへ自動変換されていました。Azure Storage QueueならbatchSize、Service BusならmaxConcurrentCalls、Event HubsならtargetUnprocessedEventThresholdのように、Functions側の設定がKEDAのメタデータへマッピングされます。(Microsoft Learn)
allowScalingRuleOverrideがGAになったことで、次のような変更が実務上のポイントになります。
| 項目 | 従来の考え方 | 今回のGA後にできること |
|---|---|---|
| スケールルールの管理主体 | Azure側がFunctionsトリガーから自動生成 | 利用者がtemplate.scale.rulesで明示的に定義可能 |
| 設定対象 | Functionsトリガー、host.json、最小/最大レプリカが中心 | KEDAスケーラーのルールも直接管理対象になる |
| 適用範囲 | Azure Functions on Azure Container Apps | kind=functionappのContainer Appsリソースのみ |
| 既定動作 | プラットフォーム管理のまま | allowScalingRuleOverrideをtrueにした場合のみ上書き |
| 戻し方 | 自動生成ルールに任せる | allowScalingRuleOverride=falseかつrules: []で戻す |
特に重要なのは、既定値がfalseまたはnullであることです。この場合、Azureは従来どおりFunctionsトリガーからKEDAルールを作成・管理します。つまり、GAになったからといって既存アプリのスケーリング挙動が自動的に変わるわけではありません。(Microsoft Learn)
影響を受ける環境、受けにくい環境
今回の更新は、すべてのAzure Functions利用者に同じ影響があるわけではありません。まず確認すべきなのは、Functionsをどのホスティング環境で動かしているかです。
| 環境 | 影響 |
|---|---|
Azure Functions on Azure Container Appsでkind=functionappを使っている | 直接の対象。上書き機能を利用できる |
| Azure Container Apps上の通常のコンテナーアプリ | 対象外。allowScalingRuleOverrideはFunctionsアプリ向け |
| App Serviceプラン、従量課金プラン、Flex Consumptionなどの通常のAzure Functions | この更新の直接対象ではない |
| 既存のAzure Functions on Container Appsで上書きを有効化しない環境 | 既定では従来どおりのプラットフォーム管理 |
Microsoft Learnでは、allowScalingRuleOverrideの適用対象はContainer Apps上のFunctions、つまりkind=functionappに限られると説明されています。Functions以外のアプリでこのプロパティを設定すると、適用対象外としてエラーになります。(Microsoft Learn)
管理者が最初にやるべきことは、Azure上のFunctionsアプリ一覧を見ることではなく、Container Apps側のリソース定義を確認することです。kindがfunctionappで、かつproperties.template.scale配下にどの設定が入っているかを確認します。
使うべきケースと使わないほうがよいケース
allowScalingRuleOverrideは便利ですが、すべての環境で有効化すべき機能ではありません。スケールルールを自分で持つということは、処理性能、キュー滞留、コールドスタート、コスト、障害時の戻し方まで自分たちで設計するという意味です。
使うべきケース
次のような環境では、上書き機能の価値が出やすくなります。
| ケース | 具体例 |
|---|---|
| 既定のマッピングではスケールアウトが遅い | キューが短時間に急増し、処理遅延がSLAに影響する |
| 処理先システムを守りたい | DBや外部APIのレート制限に合わせて同時実行数を抑えたい |
| 複数のシグナルでスケール判断したい | QueueとHTTPの両方を見てレプリカ数を制御したい |
| 負荷試験で適切な閾値が分かっている | 1レプリカあたり20メッセージまでなら安定処理できる、などの根拠がある |
| 運用チームがKEDAルールを標準化している | BicepやCI/CDでスケール設定をコード管理したい |
たとえば、Service Busキューを処理するFunctionsで、既定の同時実行設定では下流の基幹DBに負荷がかかりすぎる場合があります。その場合、Functionsの処理ロジックを変えるだけでなく、KEDAのスケール条件を明示的に調整することで、レプリカ数の増え方を制御できます。
使わないほうがよいケース
一方で、次のような状況ではプラットフォーム管理のままにしておくほうが安全です。
| ケース | 理由 |
|---|---|
| スケーリングの問題が起きていない | 独自ルールは運用負荷と障害要因を増やす |
| KEDAのメタデータ設計に詳しい担当者がいない | 閾値の誤設定で過剰スケールや処理遅延が起きやすい |
| 負荷試験を実施できない | 適切なqueueLengthやconcurrentRequestsを判断できない |
| 環境ごとの差分管理が未整備 | 開発・検証・本番で異なる挙動になりやすい |
| 一時的な問題を設定で隠そうとしている | 根本原因がアプリコード、DB、外部APIにある可能性がある |
特に「たまにキューが詰まるから、とりあえず閾値を小さくしてスケールアウトを速くする」という対応は危険です。下流サービスがボトルネックの場合、レプリカ数を増やすほどタイムアウトやリトライが増え、結果として障害を拡大することがあります。
管理者が確認すべき設定
管理者は、まず現状のスケーリングがプラットフォーム管理なのか、上書き済みなのかを確認します。確認すべき観点は次のとおりです。
| 確認項目 | 見る場所 | 判断ポイント |
|---|---|---|
kind | Container Appsリソース定義 | functionappであるか |
allowScalingRuleOverride | properties.template.scale | trueなら独自ルール管理 |
rules | template.scale.rules | 上書き時に必要なルールが定義されているか |
minReplicas / maxReplicas | scale設定 | 最小・最大レプリカが業務要件に合うか |
| Ingress | Container Apps設定 | イベントベースの自動スケール要件を満たしているか |
| Application Insights / Log Analytics | 監視設定 | スケールイベントと処理遅延を追跡できるか |
Azure Functions on Container Appsでは、最小/最大レプリカ数を設定してスケーリング境界を持たせることができます。また、監視ではApplication InsightsやLog Analyticsを使い、コンテナーのライフサイクルやスケーリングイベントを確認する設計が推奨されます。(Microsoft Learn)
実務では、次のような観点で棚卸しすると安全です。
# Container Appsリソースの定義を確認する例
az containerapp show \
--name <APP_NAME> \
--resource-group <RESOURCE_GROUP> \
--query "properties.template.scale"ここでallowScalingRuleOverrideが表示されない、またはfalse/null相当であれば、基本的にはプラットフォーム管理の状態です。trueになっている場合は、rules配下の内容が本番運用に耐える設計になっているかを確認します。
開発者が確認すべきポイント
開発者側では、アプリコードそのものよりも「1レプリカがどれだけ安全に処理できるか」を見積もることが重要です。KEDAルールを手動で定義する場合、処理能力の前提が曖昧だと、スケーリングが早すぎる、遅すぎる、増えすぎるといった問題が起きます。
まず測るべき指標
| 指標 | なぜ必要か |
|---|---|
| 1件あたりの平均処理時間 | キュー滞留時に必要なレプリカ数を見積もるため |
| 95パーセンタイル、99パーセンタイルの処理時間 | ピーク時や遅い処理の影響を見るため |
| 1レプリカあたりの安全な同時実行数 | queueLengthやconcurrentRequestsの根拠になる |
| 下流DB/APIの許容量 | スケールアウトによる二次障害を防ぐため |
| リトライ回数と失敗率 | スケール設定が過負荷を招いていないかを見るため |
たとえば、1レプリカで同時に20件まで安定処理できることが負荷試験で分かっているなら、Azure QueueのqueueLengthを20前後に設定する判断ができます。逆に、その根拠がない状態で値だけを変更すると、処理遅延やコスト増の原因になります。
設定例：上書きを有効化して独自ルールを指定する
公式ドキュメントでは、allowScalingRuleOverrideをtrueにし、Azure QueueルールとHTTP同時実行ルールを指定する例が示されています。PATCHリクエストでproperties.template.scaleを更新し、rulesにカスタムルールを定義します。(Microsoft Learn)
{
"properties": {
"template": {
"scale": {
"allowScalingRuleOverride": true,
"rules": [
{
"name": "my-queue-rule",
"custom": {
"type": "azure-queue",
"metadata": {
"queueName": "my-test-queue",
"queueLength": "20",
"connectionFromEnv": "AzureWebJobsStorage"
}
}
},
{
"name": "my-http-rule",
"http": {
"metadata": {
"concurrentRequests": "50"
}
}
}
]
}
}
}
}適用はaz restで行います。
az rest --method PATCH \
--uri "https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.App/containerApps/<APP_NAME>?api-version=2026-03-02-preview" \
--headers "Content-Type=application/json" \
--body @patch-enable-override.jsonこの設定を適用すると、新しいリビジョンではトリガーから派生したルールは生成されず、指定したカスタムルールがスケール判断に使われます。公式例では、キューの深さqueueLength=20とHTTP同時リクエストconcurrentRequests=50に従ってスケールアウト動作が決まります。(Microsoft Learn)
戻し方：プラットフォーム管理に戻すときの注意点
上書き設定をやめて、従来のプラットフォーム管理に戻す場合は注意が必要です。allowScalingRuleOverride=falseにするだけではなく、同じPATCHでrules: []を送信してカスタムスケールルールを明示的に空にします。カスタムルールが残った状態でfalseへ戻そうとすると、要求は拒否されます。(Microsoft Learn)
{
"properties": {
"template": {
"scale": {
"allowScalingRuleOverride": false,
"rules": []
}
}
}
}az rest --method PATCH \
--uri "https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.App/containerApps/<APP_NAME>?api-version=2026-03-02-preview" \
--headers "Content-Type=application/json" \
--body @patch-disable-override.json戻し作業では、変更後に新しいリビジョンが生成され、Azureが検出されたFunctionsトリガーからスケールルールの作成を再開します。切り戻しを本番で行う場合は、リビジョン、トラフィック分割、キュー滞留、エラー率を同時に監視してください。
移行・展開時に失敗しやすいポイント
この機能はスケーリングの自由度を高めますが、設定ミスの影響も大きくなります。特に次のポイントは本番展開前に確認しておくべきです。
trueにしたのにルールを入れていない
allowScalingRuleOverride=trueにしてrulesを指定しない場合、Azureはトリガーベースのルール生成をスキップします。この場合、プラットフォームのベースラインHTTPスケーラー動作のみが有効な状態になります。Queue、Service Bus、Event Hubsなどのイベント駆動処理では、意図したスケールアウトが起きない可能性があるため注意が必要です。(Microsoft Learn)
Functions以外のContainer Appsに設定してしまう
allowScalingRuleOverrideは、kind=functionappのFunctions on Container Apps向けです。通常のContainer Appsに同じプロパティを設定しようとすると、適用対象外としてエラーになります。インフラコードを共通化している場合は、通常のContainer AppsとFunctions用Container Appsでテンプレートを分けるか、条件分岐を入れてください。(Microsoft Learn)
既存のhost.json設定との関係を誤解する
プラットフォーム管理では、Functions側の設定がKEDAスケーラーのメタデータへ変換されます。たとえばAzure Storage QueueのbatchSizeはKEDAのqueueLengthへ、Service BusのmaxConcurrentCallsはmessageCountへ対応します。上書き後は、こうした自動生成ルールではなく、自分で定義したルールがスケール判断に使われます。(Microsoft Learn)
そのため、host.jsonを変えればスケールルールも変わる、という従来の感覚のまま運用すると、期待した効果が出ないことがあります。上書きを有効化した環境では、アプリ設定とインフラ設定のどちらがスケール挙動を決めているのかを明確にしてください。
下流システムの制限を見落とす
スケールアウトは処理能力を増やす一方で、データベース、ストレージ、外部API、メッセージブローカーへのアクセスも増やします。キュー滞留だけを見てレプリカ数を増やすと、下流の接続数やスロットリング制限にぶつかることがあります。
展開前には、少なくとも次の条件を確認してください。
| 確認項目 | 例 |
|---|---|
| DB接続数 | 最大レプリカ数 × 1レプリカあたり接続数が上限内か |
| 外部API制限 | 1分あたりのリクエスト数が契約上限を超えないか |
| Storage/Service Bus制限 | スロットリングや競合が起きないか |
| リトライ設計 | 過負荷時に指数バックオフやDLQへ逃がせるか |
| 監視アラート | キュー長、失敗率、処理時間、レプリカ数を検知できるか |
本番適用前のチェックリスト
本番環境でallowScalingRuleOverrideを使う場合は、いきなり有効化するのではなく、検証環境で同じ負荷パターンを再現してから展開します。
| チェック | 内容 |
|---|---|
| 対象確認 | リソースがkind=functionappである |
| APIバージョン | 2026-03-02-preview以降を使う |
| ルール定義 | allowScalingRuleOverride=true時に必要なrulesがある |
| 最小/最大レプリカ | コストとSLAに合う値になっている |
| 負荷試験 | 通常時、ピーク時、滞留復旧時の動作を確認した |
| 監視 | Application Insights、Log Analytics、アラートを設定済み |
| 切り戻し | allowScalingRuleOverride=falseとrules: []の手順を用意した |
| IaC反映 | Bicep、ARM、CI/CDの設定差分をレビューした |
| 運用手順 | 障害時に誰がどの値を変更するか決めている |
特に、切り戻し手順は事前に検証しておくべきです。スケール設定は障害時に触りたくなる箇所ですが、焦ってrulesを残したまま戻そうとするとエラーになり、復旧が遅れます。
今回の更新をどう判断すべきか
今回のGAは、Azure Functions on Azure Container Appsを本格運用するチームにとって、スケーリング設計の自由度を高める更新です。これまでのようにプラットフォーム管理に任せる選択肢は残りつつ、必要な環境ではKEDAスケールルールを自分たちで定義できます。
一方で、安易に有効化する機能ではありません。スケールルールを上書きするなら、処理能力の測定、下流システムの上限、監視、切り戻しまでをセットで設計する必要があります。
まずは、Azure Functions on Azure Container Appsを使っている環境を棚卸しし、次の順番で確認するとよいでしょう。
- 対象アプリが
kind=functionappか確認する - 現在のスケール設定と
allowScalingRuleOverrideの状態を確認する - 既定の自動生成ルールで困っている課題を明確にする
- 負荷試験で1レプリカあたりの処理能力を測る
- 検証環境でカスタムルールを適用し、監視値を比較する
- 本番展開時の切り戻し手順を用意する
スケーリングに明確な課題がない環境では、既定のプラットフォーム管理を維持するのが堅実です。反対に、キュー滞留、ピーク時の遅延、下流サービス保護、SLA達成のために細かな制御が必要な環境では、allowScalingRuleOverrideは検討する価値があります。
コメント