Ich habe dieselbe Container-App zweimal mit derselben HTTP-Skalierungsregel unter Last gesetzt. Vierzig langsame Requests gleichzeitig bekamen sechs Replikate. Zehn schnelle Requests gleichzeitig bekamen zehn, das Maximum. Mehr wartende Requests, weniger Replikate. Und als der Traffic aufhörte, blieb das letzte Replikat fast zehn Minuten.
Dieser Explainer zeigt, was die HTTP-Skalierungsregel in Azure Container Apps wirklich zählt, warum Replikate nach dem Traffic bleiben und was Scale to Zero den ersten Nutzer kostet. Alles hier stammt aus einem echten Lauf in meinem eigenen Azure-Abonnement. Das Video ist auf Englisch.
Das Wichtigste
- Container Apps skaliert nur zwischen Minimum und Maximum. Die Übung aus Microsoft Learn startet die App mit min 1 und max 1: Vierzig Nutzer warteten, nichts lief auf einen Fehler, und die Zahl der Replikate bewegte sich nicht.
- Die HTTP-Regel zählt Requests pro Sekunde, nicht wartende Requests. Alle 15 Sekunden nimmt Container Apps die Requests der letzten 15 Sekunden und teilt durch 15. Schnelle Requests erzeugen mehr Requests pro Sekunde und bekommen deshalb mehr Replikate.
- Replikate gehen langsam. Zusätzliche Replikate gehen nach einem 5-Minuten-Fenster; das letzte hat eine eigene Abkühlzeit (Standard 5 Minuten). In meinem Lauf kam null 9 Minuten 47 Sekunden nach dem letzten Request.
- Null kostet nichts, außer der Wartezeit des ersten Nutzers. Der erste Request nach null dauerte 29,6 Sekunden. Mit einem Minimum von eins waren es 0,16 Sekunden, und ein Replikat im Leerlauf wird günstiger abgerechnet.
Ein Replikat
Ein Replikat ist eine laufende Kopie Ihres Containers, und Hochskalieren heißt: mehr Kopien. Ohne eigene Skalierungsregel nutzt Container Apps eine Standard-HTTP-Regel zwischen null und zehn Replikaten. Die Übung setzt beide Grenzen auf eins, es gibt also keinen Spielraum.
Mit vierzig Nutzern gleichzeitig und zwei Sekunden Arbeit pro Request gab es keinen einzigen Fehler. Der Webserver der App (gunicorn mit 2 Workern × 8 Threads) bearbeitet sechzehn Requests gleichzeitig; die übrigen vierundzwanzig warteten. Zwei Sekunden Arbeit dauerten im Median 4,15 Sekunden, und die Zahl der Replikate blieb die vollen 90 Sekunden bei eins.
Die HTTP-Regel aus der Übung:
az containerapp update -n agent-api -g rg-demo \--min-replicas 0 --max-replicas 10 \--scale-rule-name http-scaling \--scale-rule-type http \--scale-rule-http-concurrency 10
Dasselbe im Template:
scale:minReplicas: 0maxReplicas: 10rules:- name: http-scalinghttp:metadata:concurrentRequests: "10"
Skalierungseinstellungen gehören zum Template der Revision, deshalb erzeugt diese Änderung eine neue Revision (hier agent-api--v2). Eine Revision ist ein Schnappschuss von Image und Einstellungen Ihrer App.
Was die Regel zählt
Die Einstellung heißt concurrentRequests und klingt nach „Requests in Bearbeitung, zehn pro Replikat“. So gelesen bräuchten vierzig langsame Clients vier Replikate und zehn schnelle eines. Der Lauf zeigt etwas anderes:
| Test | Clients | Arbeit pro Request | Requests pro Sekunde | Replikate |
|---|---|---|---|---|
| Langsam | 40 | 2 s | etwa 20 | 6 |
| Schnell | 10 | 50 ms | etwa 120 | 10 (das Maximum) |
Die Dokumentation definiert den Wert als Rate: alle 15 Sekunden die Requests der letzten 15 Sekunden geteilt durch 15. Gezählt werden die Kunden, die durch die Tür kommen, nicht die Schlange an der Kasse. Die schnellen Clients kamen schnell zurück und schickten etwa 120 Requests pro Sekunde: geteilt durch das Ziel von 10 sind das 12 Replikate, begrenzt auf das Maximum von 10.
Die langsamen Clients schickten nur etwa 20 pro Sekunde, ein Sechstel der schnellen, und bekamen deshalb weniger Replikate. Nach der Formel allein ergeben 20 geteilt durch 10 zwei. Ich habe den langsamen Test neun Minuten lang wiederholt, und er blieb bei sechs. Die Dokumentation nennt die Zahl der Replikate ein Ziel, keine Garantie. Die Formel zeigt die Richtung; testen Sie mit Ihren echten Antwortzeiten und beobachten Sie die Zahl der Replikate.
Wie das Hochskalieren laut Dokumentation abläuft: desiredReplicas = ceil(aktueller Wert ÷ Ziel), Schritte von 1, 4, 8, 16 … bis zum Maximum, ohne Wartezeit vor dem Hochskalieren. In meinem langsamen Test ging es innerhalb von 11 Sekunden von 1 auf 4, dann von 4 auf 6.
Wenn der Traffic aufhört
| Phase | Standard laut Dokumentation | Mein Lauf (langsamer Test) |
|---|---|---|
| Zusätzliche Replikate gehen | nach einem 300-Sekunden-Fenster | 6 → 1 nach 329–345 s ab dem letzten Request |
| Das letzte Replikat → null | nach der Abkühlzeit von 300 Sekunden | nach 587 s (9 min 47 s) |
| Erster Request nach null | ein Kaltstart: neues Replikat, Image laden, App starten | 29,6 s, danach 0,14 s |
Solange Sie auf null warten, wird jedes Replikat oberhalb des Minimums zum aktiven Tarif abgerechnet. Bei null Replikaten fallen keine Nutzungskosten an.
Zwei Überraschungen
Ein Deployment mitten in einer Lastspitze. Direkt nach dem schnellen Test habe ich nur das Minimum geändert (min 1, Revision v3). Die neue Revision startete mit zehn Replikaten, so vielen wie die alte, und hielt sie fünf weitere Minuten. Das ist der Wechsel ohne Ausfallzeit: Eine neue Revision muss die aktuelle Last tragen können, bevor sie den Traffic bekommt. Lesen Sie diese Replikate nicht als Skalierungsfehler.
Kein Ingress und ein Minimum von null. Ohne Ingress gibt es keine HTTP-Requests zum Zählen. Wenn Sie zusätzlich kein Minimum und keine andere Skalierungsregel definieren, skaliert die App auf null und kann nicht mehr starten. Setzen Sie ein Minimum von eins oder skalieren Sie auf etwas anderes, zum Beispiel die Länge einer Queue.
Was passierte, als ich es ausgeführt habe
Getestet am 20. Oktober 2026 in meinem eigenen Azure-Abonnement (westeurope, Azure CLI 2.88.0); danach wurde alles gelöscht. Die App ist die Mock-Agent-API aus der Microsoft-Learn-Übung (Flask, POST /agent/process wartet eine angegebene Zahl von Millisekunden); watch.py, mein eigenes Skript, erzeugte die Last über Keep-Alive-Clients und fragte alle paar Sekunden az containerapp replica list ab. Mein erster Versuch in germanywestcentral scheiterte an der Umgebung, mit demselben Fehler AKSCapacityHeavyUsage wie am Vortag. In westeurope dauerte die Umgebung 15,7 Minuten, der Cloud-Build 68 Sekunden, die App 41 Sekunden.
Der Start der Übung, min 1 und max 1:
> az containerapp show -n agent-api -g rg-demo --query properties.template.scale -o json{"cooldownPeriod": 300,"maxReplicas": 1,"minReplicas": 1,"pollingInterval": 30,"rules": null}
Der schnelle Test (10 Clients × 50 ms); die ersten Requests warteten auf einen Kaltstart:
34 s replicas 1 | 48.7 req/s (last 15 s) 10 in flight median 0.08 s42 s replicas 10 | 112.8 req/s (last 15 s) 10 in flight median 0.08 s50 s replicas 10 | 120.3 req/s (last 15 s) 10 in flight median 0.08 ssummary: 11973 requests ok, 0 failed, median 0.08 s, p95 0.09 s, peak 10 replicas at 42 s
Der langsame Test, neun Minuten lang:
16 s replicas 4 | 7.5 req/s (last 15 s) 40 in flight median 4.13 s56 s replicas 6 | 20.9 req/s (last 15 s) 40 in flight median 2.03 s302 s replicas 6 | 18.7 req/s (last 15 s) 40 in flight median 2.03 s535 s replicas 6 | 20.9 req/s (last 15 s) 40 in flight median 2.03 ssummary: 10302 requests ok, 0 failed, median 2.03 s, p95 2.05 s, peak 6 replicas at 56 s
Scale to Zero und der Kaltstart:
126 s load stopped456 s replicas 2471 s replicas 1713 s replicas 0request 1 : HTTP 200 in 29.640707 srequest 2 : HTTP 200 in 0.137173 srequest 3 : HTTP 200 in 0.133291 s
Mit einem Minimum von eins, nach sechs Minuten Leerlauf:
request 1 : HTTP 200 in 0.162562 srequest 2 : HTTP 200 in 0.107679 srequest 3 : HTTP 200 in 0.101485 s
Zwei Details: az containerapp update gab in seiner Antwort "concurrentRequests": "" aus, während revision show danach den gespeicherten Wert "10" zeigte. Prüfen Sie also die Revision, nicht die Ausgabe des Updates. Und die Azure-Monitor-Metrik „Replicas“ (pro Minute) zeigte denselben Verlauf: 0 → 1 → 6 → 1 → 10.
Leerlauf- und Aktivtarif
Ein Replikat wird nur dann zum günstigeren Leerlauftarif abgerechnet, wenn seine Revision auf ihrem Minimum (≥ 1) läuft und das Replikat keine Requests bearbeitet, weniger als 0,01 vCPU nutzt und weniger als 1.000 Bytes pro Sekunde empfängt. In West Europe kostet die vCPU im Leerlauf etwa ein Achtel des aktiven Preises (USD 0,000004 gegenüber 0,000034 pro vCPU-Sekunde, Azure Retail Prices API, Oktober 2026); Arbeitsspeicher kostet in beiden Zuständen gleich viel. Jedes Abonnement hat pro Monat 180.000 vCPU-Sekunden, 360.000 GiB-Sekunden und 2 Millionen Requests frei.
Nicht im Video
Ereignisgesteuerte Skalierung mit KEDA (Queues, Event Hubs, Cron, Managed Identity für Skalierungsregeln), TCP-Regeln, CPU- und Speichergrößen (Speicher in GiB mindestens doppelt so viel wie CPU; Speicher über dem Limit startet ein Replikat neu, CPU über dem Limit wird gedrosselt), Workload-Profile, Revisionsmodi und Traffic-Splitting. Sie stehen im Microsoft-Learn-Modul unten; Queue-Skalierung und Traffic-Splitting bekommen in dieser Reihe eigene Videos.
