Un chiffre d'appel, pas une décision
L'ordre de grandeur de 1 296 $ par mois pour un job Glue lancé toutes les 5 minutes circule comme argument d'autorité. Il ne suffit pourtant pas à décider. Le coût dépend d'abord du type de job, de sa version, du nombre de DPU alloués et de la durée réellement facturable. Sans ces quatre paramètres, le chiffre reste une hypothèse parmi d'autres.
Présenter un montant unique comme conclusion revient à masquer les variables qui le produisent. Un job Spark n'a pas le même comportement de facturation qu'un job d'une autre nature, et une version récente n'applique pas les mêmes règles qu'une version antérieure. La première prudence consiste donc à traiter le chiffre comme un point de départ, pas comme un verdict.
Le minimum de facturation n'est pas universel
AWS a annoncé le 10 août 2020 un minimum de facturation ramené de 10 à 1 minute pour les jobs Spark Glue 2.0. Présenter 10 minutes comme un minimum universel est donc trompeur. Le plancher applicable varie selon la version et le type de job. La première vérification consiste à relever ce minimum sur la configuration concernée, et non à le supposer.
Cette distinction change l'ordre de grandeur. Une durée facturable d'une minute et une durée facturable de dix minutes ne produisent pas le même coût pour un même nombre d'exécutions. Le débat sur le moteur ou sur l'alternative perd une partie de son sens tant que ce paramètre n'est pas établi.
Exemple illustratif : 2 DPU, 1 minute facturable
Prenons un exemple illustratif, avec 2 DPU, un tarif supposé de 0,44 $ par DPU-heure et une durée facturable d'une minute par exécution. Sur 30 jours, un déclenchement toutes les 5 minutes représente 8 640 exécutions. Le coût unitaire se calcule ainsi : 2 × 1/60 × 0,44 $, soit environ 0,01467 $. Le total atteint 126,72 $ par mois.
Si la durée facturable est de 10 minutes, les mêmes hypothèses donnent 1 267,20 $. Un détail compte : arrondir chaque exécution avant de multiplier fausse le total. Sur 8 640 lignes, l'écart d'arrondi se cumule et peut déplacer sensiblement le résultat. Mieux vaut conserver la précision jusqu'au total, puis arrondir une seule fois.
Ce que ces simulations laissent de côté
Ces montants sont des simulations de calcul. Ils excluent le stockage, les logs, les transferts et les autres services associés. Le tarif régional et la durée réellement facturée doivent être relevés sur votre configuration. Autrement dit, le coût complet d'un job ne se lit pas dans un seul chiffre générique. Il se reconstitue à partir de la facturation observée, service par service.
Un job Glue peut aussi entraîner des coûts indirects : orchestration, surveillance, stockage intermédiaire, reprises après incident. Ces postes ne figurent pas dans le calcul par DPU-heure. Les ignorer revient à comparer des périmètres différents, ce qui fausse l'arbitrage entre plusieurs options.
Quatre vérifications avant de changer de moteur
Avant d'envisager un changement de moteur, quatre points méritent d'être examinés. D'abord, vérifier le type de job, sa version, le nombre de workers et la durée facturable. Ensuite, compter les déclenchements qui se produisent sans nouvelles données à traiter. Puis tester le regroupement des traitements en fonction de la fraîcheur attendue par les usages. Enfin, comparer le coût complet, la maintenance et le délai avec les alternatives disponibles.
Ces étapes ne désignent pas une solution unique : elles éclairent l'arbitrage. Elles supposent aussi de disposer de mesures fiables. Sans relevé de la durée facturée, toute comparaison reste théorique. Un changement de moteur peut se justifier, mais il doit s'appuyer sur des chiffres propres à l'environnement concerné, pas sur un ordre de grandeur général.
La fréquence est souvent le vrai levier
La question la plus utile n'est peut-être pas le prix du moteur, mais le nombre de jobs fréquents qui se lancent sans donnée utile à traiter. Si ce nombre est élevé, le premier levier n'est pas nécessairement le changement de moteur : il peut résider dans la fréquence de déclenchement, dans les conditions de lancement ou dans le regroupement des traitements.
Une fréquence alignée sur la fraîcheur réellement attendue coûte souvent moins qu'une optimisation technique lourde. À l'inverse, réduire la fréquence sans vérifier le besoin peut dégrader le service rendu. Le calcul et l'usage doivent être examinés ensemble. La bonne question n'est pas seulement combien coûte un job toutes les 5 minutes, mais combien de ces exécutions servent réellement à quelque chose.
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 ↗