30 bis. Capacité, coût et efficience : tenir le service dans la durée
Pourquoi ce chapitre existe
Un service peut satisfaire ses tests et ses SLO actuels tout en devenir économiquement ou opérationnellement fragile lorsque le volume change. Une montée de trafic peut saturer une dépendance ; une requête peu coûteuse à l'unité peut dominer la facture ; une surprovision peut masquer un défaut de conception jusqu'au prochain seuil. La capacité et le coût ne sont pas seulement des préoccupations d'infrastructure : ils révèlent comment le système transforme une demande utilisateur en ressources limitées.
Les idées essentielles
- La planification de capacité part des parcours, des volumes, des pointes et des modes de défaillance pertinents.
- Le coût est un attribut de qualité lorsqu'il limite la viabilité ou le rythme d'évolution du produit.
- Les optimisations doivent être mesurées ; réduire une facture en dégradant la fiabilité déplace le risque.
- Les budgets, limites et alertes sont utiles lorsqu'ils relient une consommation à une décision d'ingénierie ou de produit.
Modéliser la relation entre usage et ressources
Pour un parcours critique, identifier la demande, les étapes les plus coûteuses, les limites connues et le comportement au-delà de ces limites. Le modèle peut être simple au début : demandes par seconde, taille des objets, latence d'une dépendance, coût par transaction, capacité de file. Sa valeur est de rendre les hypothèses discutables avant qu'une pointe réelle ne les invalide.
| Question | Signal | Décision possible |
|---|---|---|
| Le volume augmente-t-il ? | Débit, files, saturation, taux de rejet | Répartir, mettre en file, limiter ou planifier la capacité |
| Quel parcours coûte ? | Coût par transaction ou tenant | Optimiser une requête, mettre en cache, revoir la tarification |
| Quelle pointe est dangereuse ? | Charge de pointe et temps de récupération | Tester la surcharge, dégrader, réserver une marge |
| Quelle ressource est gaspillée ? | Utilisation, dimensionnement, données inutiles | Réduire, archiver, adapter les contrats |
Préparer la surcharge comme un comportement
Lorsque la demande dépasse la capacité, choisir : limiter une action non critique, mettre une demande en attente, prioriser certains flux, afficher un délai ou refuser explicitement. Ne rien concevoir laisse les files, timeouts et retries décider à la place du produit, souvent en aggravant la saturation.
Cache, compression, batch et parallélisme peuvent réduire un coût réel ; ils peuvent aussi introduire cohérence, invalidation, risques de données et difficulté d'exploitation. Mesurer la contrainte dominante avant et après évite de payer une complexité qui ne protège rien.
Anti-patterns
Réagir à la facture uniquement en fin de mois
À ce stade, la consommation est souvent devenue une surprise et les équipes ne savent pas quel parcours l'a causée. Des indicateurs de coût et de volume proches de l'usage rendent les décisions plus précoces et plus justes.
Dimensionner pour le maximum théorique partout
La surcapacité peut être nécessaire pour une promesse critique ; l'appliquer uniformément immobilise un budget qui pourrait améliorer récupération, sécurité ou produit. Les objectifs de service doivent guider la marge et la priorité.
Optimiser un composant isolé sans regarder le parcours
Réduire la latence d'un appel peut déplacer la charge vers une base ou multiplier les retries. L'efficience se juge sur le résultat utilisateur, le coût global et les modes de défaillance associés.
Bonnes pratiques
Relier capacité, SLO et budget
Un objectif de fiabilité indique le niveau de service à tenir ; le modèle de capacité explique les ressources et comportements nécessaires pour le tenir à la charge attendue. Les deux doivent être revus ensemble avant un lancement, un événement commercial ou une migration de volume.
Rendre les compromis visibles au produit
Une limitation de débit, un délai de traitement ou une fonctionnalité plus coûteuse est un choix d'expérience autant qu'un choix technique. Le discuter avec le produit évite que les mécanismes de protection deviennent des surprises pour les utilisateurs.
Checklist — Le service tient-il son usage et son coût ?
- Quels parcours, volumes moyens et pointes définissent la capacité nécessaire ?
- Quelle ressource ou dépendance limite en premier, et comment le système réagit-il ?
- Quels coûts sont rattachés à une transaction, un tenant ou un usage mesurable ?
- Quelle surcharge est acceptable et quel comportement de dégradation la protège ?
- Les optimisations proposées sont-elles mesurées contre leurs nouveaux risques ?
- Les SLO, la capacité et les décisions de produit sont-ils cohérents ?
À retenir
La capacité et le coût sont des contraintes de conception continues. Les relier aux parcours, aux objectifs de service et aux comportements de surcharge permet de tenir une promesse viable plutôt que de découvrir ses limites par une panne ou une facture.