Vous êtes de garde pour un service Web : un équilibreur 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 — ainsi que ce que coûtent vos décisions.
Plancher du parc. L’augmenter lance des instances immédiatement — elles ont quand même 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 encore. Désactivé = exactement le minimum.
Plus bas = plus de marge et plus de coûts. 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 les réponses peuvent être plus anciennes (âge moyen ≈ TTL/2).
Charge les clés populaires 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, traitement par lots, robots d’indexation) rejetée à l’équilibreur 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ée = dégradation gracieuse.
Redéploie la dernière bonne version sur un nouveau parc (5 min, facturé deux fois), puis bascule le trafic. Appuyer de nouveau relance la préparation; sans mauvaise version en ligne, cela ne fait que coûter 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 jusqu’ici | 0,00 $ |
| Âge moyen des réponses en cache | 30 s |
| Trafic sur la mauvaise version | 0 % |
| Recommandations disponibles | 100 % |
Une nouvelle version est déployée à 09:10. Le mois a déjà été difficile : il ne reste que 20 % du budget d’erreurs. Quelques minutes après le déploiement, l’alerte de taux de consommation 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.
À la pointe 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 %. Remettez le service en état sans surcharger la base de données.
Chaque relation utilisée par le simulateur, avec sa source. Les constantes signalé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 de la mauvaise version 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 exactement le p99 de leur somme (il peut être un peu trop haut ou trop bas); la file est traitée comme stable à 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 de la mauvaise version 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 de la mauvaise version 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 de la mauvaise version 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), de Poisson (Knuth). La graine est affichée et partageable.
Modèle éducatif — non destiné aux décisions opérationnelles. Les sites réels calibrent chaque constante selon leur propre équipement et leurs propres données.