Un débit provisionné calé sur le pic, pas sur l'usage réel
Le point de départ est simple à décrire et fréquent dans les bases distribuées : un débit provisionné de 30 000 RU/s en permanence, alors que les pics de charge ne duraient que deux heures par jour. Le dimensionnement est donc calé sur le pire moment de la journée, mais payé sur les vingt-quatre heures.
Les RU/s servent d'unité de débit : c'est la capacité réservée au conteneur, indépendamment du nombre de requêtes réellement exécutées. Provisionner en continu sur la base du pic revient à réserver une salle de réunion pleine capacité pour une réunion d'une heure, toute la journée. Le chiffre de 30 000 RU/s et la durée de deux heures sont rapportés dans un cas précis ; ils décrivent une situation, pas une norme.
Ce qu'Autoscale change, et ce qu'il ne change pas
Autoscale ajuste le débit provisionné entre 10 % et 100 % du maximum configuré. Avec un maximum à 30 000 RU/s, la plage de fonctionnement théorique va donc de 3 000 à 30 000 RU/s — une arithmétique dérivée directement de la règle énoncée, à vérifier dans la documentation Microsoft pour chaque configuration.
La nuance décisive est ailleurs : il ne s'agit pas d'une facturation purement « à la requête ». Pour chaque heure, la facturation dépend notamment du niveau maximal de RU/s atteint par l'autoscale pendant cette heure. Autrement dit, une heure où la charge monte brièvement près du maximum est facturée sur ce niveau-là, même si le reste de l'heure est calme. Le lissage horaire joue donc un rôle central : la question pertinente n'est pas seulement « combien de temps dure le pic », mais « à quel niveau la consommation culmine-t-elle à l'intérieur de chaque heure ».
Cette règle explique aussi la limite du raisonnement inverse : un conteneur actif ne descend pas à zéro. Le plancher de 10 % du maximum continue de produire un coût de base, ce qui plaide pour un maximum configuré au plus juste.
La méthode de migration en quatre étapes
La démarche rapportée tient en quatre mouvements, et leur ordre compte : 1) une analyse de 30 jours du trafic réel par conteneur ; 2) le maintien du maximum Autoscale à 30 000 RU/s pour absorber les pics ; 3) une comparaison avec Serverless pour les conteneurs réellement sporadiques ; 4) la vérification des partitions, des régions et des niveaux de cohérence.
La fenêtre de 30 jours sert à distinguer la variabilité réelle de la variabilité perçue : beaucoup d'équipes surestiment la fréquence des pics. Conserver le même maximum évite de changer deux variables à la fois — on isole l'effet du mode de facturation sans rogner la marge de sécurité en pointe. La comparaison avec Serverless vise les conteneurs dont le trafic est réellement épisodique, où un modèle sans débit provisionné peut être plus pertinent, mais ce choix reste à arbitrer conteneur par conteneur, selon la latence attendue et le profil d'accès.
Le quatrième point est celui qu'on oublie le plus souvent : changer de mode de débit sans revoir la stratégie de partitionnement, la distribution géographique ou le niveau de cohérence peut déplacer la facture… et la performance. La cohérence a un coût en RU, et les régions en multiplication de débit : ce sont des leviers de coût au même titre que le mode de facturation.
Le calcul : 5 700 $ à 2 280 $ par mois
Les montants rapportés sont les suivants : 5 700 $ par mois avant, 2 280 $ par mois après, soit un écart de 3 420 $ par mois, ou 60 %. Sur douze mois, 3 420 × 12 = 41 040 $, arrondi à 41 000 $ par an.
Ces chiffres proviennent d'un cas unique et ne constituent pas une règle générale : ils dépendent du nombre de conteneurs, du profil horaire réel, des régions répliquées et du niveau de cohérence retenu, éléments qui ne figurent pas dans le calcul. Le pourcentage de 60 % doit donc être lu comme un ordre de grandeur issu d'une situation donnée, à rejouer sur ses propres métriques avant toute décision. Il suppose également une performance constante entre les deux configurations : c'est une hypothèse à valider par des mesures, pas un acquis.
Autoscale, Serverless ou débit provisionné : les critères de choix
Trois régimes, trois profils. L'autoscale est présenté comme adapté aux charges variables : il absorbe les pics sans payer le maximum en continu. Serverless s'adresse aux charges vraiment sporadiques, avec la contrainte de latence et de plafond qu'implique ce modèle. Le débit provisionné, en revanche, peut rester plus économique pour une charge stable proche du maximum : dans ce cas, l'ajustement automatique n'apporte rien et la facturation horaire sur le niveau atteint ne joue pas en faveur du changement.
Les questions utiles à se poser : quelle proportion d'heures dépasse réellement un seuil élevé de consommation ? Les pics sont-ils prévisibles ou erratiques ? Le trafic par conteneur est-il homogène ou très dispersé ? Chaque conteneur justifie-t-il son propre arbitrage ? La réponse à ces questions détermine le mode bien davantage que le volume global.
Le KPI qui compte : le coût par million de requêtes ou par transaction métier
Le RU/s est un indicateur intermédiaire, pas un indicateur de valeur. Le KPI proposé — coût par million de requêtes ou par transaction métier, à performance constante — replace la facture dans son contexte : baisser le coût en dégradant la latence ou le niveau de cohérence n'est pas une optimisation, c'est un transfert de coût vers les utilisateurs.
La mention « à performance constante » est essentielle : elle interdit de comparer deux configurations dont l'une a été silencieusement dégradée. C'est ce garde-fou qui rend l'écart de 60 % interprétable dans le cas rapporté.
Checklist suggérée avant de basculer
La liste suivante est une suggestion méthodologique, à adapter à votre contexte ; elle ne découle pas du cas cité. 1) Mesurer sur au moins 30 jours le trafic par conteneur, heure par heure, pour identifier les niveaux maximaux atteints et non seulement les moyennes. 2) Calculer la facture théorique dans les deux modes, en intégrant le plancher de 10 % du maximum configuré. 3) Fixer le maximum Autoscale au niveau du pic réel observé, pas au niveau provisionné existant par habitude. 4) Identifier les conteneurs réellement sporadiques et tester l'option Serverless sur ceux-là uniquement. 5) Vérifier le partitionnement, les régions et le niveau de cohérence avant et après le changement. 6) Définir un KPI de coût unitaire à performance constante et le suivre dans le temps. 7) Prévoir un point de sortie : si la charge se stabilise près du maximum, le mode provisionné peut redevenir le bon choix.
Le vrai enseignement est méthodologique : un mode de facturation ne réduit pas une facture par lui-même, c'est l'adéquation entre le mode et le profil de charge qui la réduit. Le calcul ne vaut que si le profil de charge a été mesuré avant d'être supposé.
Le post à l’origine de cette analyse
Article développé à partir du post LinkedIn. Les liens ci-dessous sont ceux du post d’origine ; leur présence ne constitue pas une vérification indépendante.
LinkedIn ↗