Sie haben Bereitschaft für einen Webdienst: ein Lastverteiler vor einer Flotte von Instanzen, ein Cache vor einer Datenbank und ein Verfügbarkeitsziel von 99,9 %. Jede Minute berechnet das Modell Warteschlangenverzögerung, Timeouts, Cache-Treffer und Datenbanklast aus Lehrbuchformeln — und was Ihre Entscheidungen kosten.
Untergrenze für die Flotte. Eine Erhöhung startet sofort Instanzen — sie brauchen trotzdem die Startverzögerung, bevor sie bedienen.
Zielwertregelung auf die Auslastung; keine neue Aufskalierung, solange noch Instanzen hochfahren. Aus = genau das Minimum.
Niedriger = mehr Reserve und mehr Kosten. Die gemessene Auslastung kann 100 % nicht überschreiten, daher wächst eine gesättigte Flotte nur schrittweise.
Längere TTL = mehr Treffer, aber Antworten können älter sein (mittleres Alter ≈ TTL/2).
Lädt 6 Minuten lang häufige Schlüssel (+12 % des Caches pro Minute) zum Preis von 600 zusätzlichen Datenbankabfragen/s.
Anteil der 30 % mit niedriger Priorität (Prefetch, Batch, Crawler), der am Lastverteiler mit „später erneut versuchen“ abgewiesen wird.
Das aufwendige Feature fügt 20 ms CPU und eine Datenbankabfrage pro Anfrage hinzu. Aus = kontrollierte Funktionsminderung.
Stellt den letzten guten Build auf einer frischen Flotte bereit (5 min, doppelt abgerechnet) und schaltet dann den Datenverkehr um. Erneutes Drücken startet die Vorbereitung neu; ohne schlechten Build im Livebetrieb kostet es nur Geld.
| Verbrauchsrate (1 h) | 0,0 × |
|---|---|
| Anfragen | 1125 req/s |
| Bedienende Instanzen | 10 |
| Hochfahrende Instanzen | 0 |
| Cache-Trefferquote | 77 % |
| Datenbankauslastung | 19 % |
| Abgeworfener Datenverkehr | 0 % |
| Flottenkosten | 4,00 $/h |
| Bisherige Kosten | 0,00 $ |
| Mittleres Alter der gecachten Antworten | 30 s |
| Datenverkehr auf dem fehlerhaften Build | 0 % |
| Empfehlungen verfügbar | 100 % |
Um 09:10 geht ein neuer Build live. Der Monat war schon holprig: Nur noch 20 % des Fehlerbudgets sind übrig. Minuten nach dem Deployment löst der Burn-Rate-Alarm aus. Schützen Sie das Budget.
Ein Link zum Dienst verbreitet sich schnell, und irgendwann an diesem Morgen wird eine Verkehrsspitze erwartet – niemand weiß, wann oder wie groß. Neue Instanzen brauchen heute 8 Minuten zum Hochfahren. Wenn sie kommt, halten Sie Fehler und Latenz niedrig, ohne Geld für ungenutzte Kapazität zu verbrennen.
In der Mittagsspitze leert ein Wartungsskript den gesamten Cache. Jede Anfrage geht jetzt an die Datenbank, die für die übliche Trefferquote von 85 % ausgelegt war. Bringen Sie den Dienst zurück, ohne die Datenbank zu überlasten.
Jede Beziehung, die der Simulator verwendet, mit ihrer Quelle. Als Annahmen gekennzeichnete Konstanten sind anschauliche Kalibrierungen.
λ(t) = base × (1 + 0.25·sin(2π(t + clock − 6 h)/24 h)) × surge(t), clock = time of day at the start (peak at 12:00); count/min ≈ N(60λ, √(60λ)) × (1 + N(0, 0.02))[6]Annahme: Workerzahlen, Bedienzeiten, Datenbankkapazität, Cachegröße, Auffüllgeschwindigkeit, Preise und die Fehlerrate des fehlerhaften Builds sind Anschauungswerte für einen mittelgroßen Webdienst.N = instances × 16 workers, a = λ·S; C(a, N) = B / (1 − (a/N)(1 − B)), B = Erlang B[3][6]P(W > t) = C·e^(−(N/S − λ)·t); timeouts = P(W > 2 s); a ≥ N ⇒ failed share = 1 − N/a[3]p99 ≈ S·ln 100 + ln(C/0.01)/(N/S − λ) (service + waiting quantile, an approximation)[3][6]Näherung: Das Addieren der Quantile von Bedienzeit und Wartezeit ist nicht das exakte p99 ihrer Summe (es kann etwas zu hoch oder zu niedrig sein); die Warteschlange wird innerhalb jeder Minute als stationär behandelt, weil Anfragen Millisekunden dauern.busy workers L = λ·S ⇒ utilization = λ·S / N[4]hit = warm × rT/(1 + rT), r = λ / 20,000 objects; mean age of a cached answer ≈ T/2[5]DB load = λ·q·(1 − hit); query time = 5 ms/(1 − ρ_db) (≤ 250 ms); S = S_app + (1 − hit)·q·query time[6]Annahme: Workerzahlen, Bedienzeiten, Datenbankkapazität, Cachegröße, Auffüllgeschwindigkeit, Preise und die Fehlerrate des fehlerhaften Builds sind Anschauungswerte für einen mittelgroßen Webdienst.budget = 1 − SLO = 0.1 %; burn = error rate / 0.1 %; Δbudget per min = burn / 43,200; burn (1 h) = mean error rate over the last 60 min / 0.1 % (window pre-filled with the opening minute)[1][2]desired = ⌈serving × utilization / target⌉ (utilization saturates at 100 %); new instances serve after the boot delay[6]Annahme: Workerzahlen, Bedienzeiten, Datenbankkapazität, Cachegröße, Auffüllgeschwindigkeit, Preise und die Fehlerrate des fehlerhaften Builds sind Anschauungswerte für einen mittelgroßen Webdienst.16 workers/instance · app time 50 ms (+20 ms and +1 query with the feature on) · 2 queries/request · DB 4,000 queries/s · 20,000 hot objects · cache refill τ = 30 min (slower while the DB is saturated) · warm-up job +12 %/min for 6 min, +600 queries/s · timeout 2 s · 30 % low-priority traffic · bad build +5 % errors, ×1.25 CPU · rollback 5 min · $0.40 per instance-hour · scale-in by ≤ 20 % of the fleet after 10 quiet minutes · up to 40 instancesAnnahme: Workerzahlen, Bedienzeiten, Datenbankkapazität, Cachegröße, Auffüllgeschwindigkeit, Preise und die Fehlerrate des fehlerhaften Builds sind Anschauungswerte für einen mittelgroßen Webdienst.Zufall: ein Mulberry32-Generator mit Seed; verwendete Verteilungen — gleichverteilt, exponentiell (inverse Verteilungsfunktion), normal (Box–Muller), Poisson (Knuth). Der Seed wird angezeigt und lässt sich teilen.
Lehrmodell — nicht für operative Entscheidungen geeignet. Reale Standorte kalibrieren jede Konstante auf ihre eigenen Anlagen und Daten.