Vous êtes d’astreinte pour un service web : un répartiteur de charge devant un parc d’instances, un cache devant une base de données, et un objectif de disponibilité de 99,9 %. Chaque minute, le modèle calcule le délai de file d’attente, les expirations, les succès de cache et la charge de la base de données à partir de formules de manuel — et ce que coûtent vos décisions.
Plancher du parc. L’augmenter lance des instances immédiatement — elles ont encore besoin du délai de démarrage avant de servir.
Suivi de cible sur l’utilisation ; pas de nouvelle montée en charge tant que des instances démarrent. Désactivé = exactement le minimum.
Plus bas = plus de marge et plus de coût. L’utilisation mesurée ne peut pas dépasser 100 %, donc un parc saturé ne grandit que pas à pas.
TTL plus long = plus de succès, mais des réponses plus anciennes (âge moyen ≈ TTL/2).
Charge les clés chaudes pendant 6 minutes (+12 % du cache par minute) au prix de 600 requêtes de base de données/s supplémentaires.
Part des 30 % de faible priorité (préchargement, batch, robots d’indexation) rejetée au répartiteur de charge avec « réessayez plus tard ».
La fonctionnalité lourde ajoute 20 ms de CPU et une requête de base de données par requête. Désactivé = dégradation gracieuse.
Redéploie la dernière bonne version sur un parc neuf (5 min, facturé deux fois), puis bascule le trafic. Appuyer à nouveau relance la préparation ; sans mauvaise version en production, cela ne coûte que de l’argent.
| Taux de consommation (1 h) | 0,0 × |
|---|---|
| Requêtes | 1125 req/s |
| Instances en service | 10 |
| Instances en démarrage | 0 |
| Taux de succès du cache | 77 % |
| Utilisation de la base de données | 19 % |
| Trafic délesté | 0 % |
| Coût du parc | 4,00 $/h |
| Coût à ce jour | 0,00 $ |
| Âge moyen des réponses en cache | 30 s |
| Trafic sur le mauvais build | 0 % |
| Recommandations disponibles | 100 % |
Un nouveau build est déployé à 09:10. Le mois a déjà été difficile : il ne reste que 20 % du budget d’erreur. Quelques minutes après le déploiement, l’alerte de burn rate se déclenche. Protégez le budget.
Un lien vers le service se propage vite et un pic de trafic est attendu à un moment de cette matinée — personne ne sait quand ni de quelle ampleur. Le démarrage de nouvelles instances prend 8 minutes aujourd’hui. Quand il arrivera, gardez les erreurs et la latence faibles sans brûler d’argent dans une capacité inutilisée.
Au pic de midi, un script de maintenance vide tout le cache. Chaque requête va maintenant à la base de données, dimensionnée pour le taux de succès habituel de 85 %. Rétablissez le service sans surcharger la base de données.
Chaque relation utilisée par le simulateur, avec sa source. Les constantes marquées comme hypothèses sont des calibrations illustratives.
λ(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]Hypothèse : le nombre de workers, les temps de service, la capacité de la base de données, la taille du cache, la vitesse de remplissage, les prix et le taux d’erreur du mauvais build sont des valeurs illustratives pour un service web de taille moyenne.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]Approximation : additionner les quantiles de service et d’attente ne donne pas le p99 exact de leur somme (il peut être un peu trop haut ou trop bas) ; la file est traitée comme stationnaire à l’intérieur de chaque minute, car les requêtes durent des millisecondes.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]Hypothèse : le nombre de workers, les temps de service, la capacité de la base de données, la taille du cache, la vitesse de remplissage, les prix et le taux d’erreur du mauvais build sont des valeurs illustratives pour un service web de taille moyenne.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]Hypothèse : le nombre de workers, les temps de service, la capacité de la base de données, la taille du cache, la vitesse de remplissage, les prix et le taux d’erreur du mauvais build sont des valeurs illustratives pour un service web de taille moyenne.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 instancesHypothèse : le nombre de workers, les temps de service, la capacité de la base de données, la taille du cache, la vitesse de remplissage, les prix et le taux d’erreur du mauvais build sont des valeurs illustratives pour un service web de taille moyenne.Aléa : un générateur mulberry32 à graine ; lois utilisées — uniforme, exponentielle (fonction de répartition inverse), normale (Box–Muller), Poisson (Knuth). La graine est affichée et partageable.
Modèle pédagogique — pas pour des décisions opérationnelles. Les sites réels calibrent chaque constante sur leurs propres équipements et données.