Traitements lot dans le cloud

26-03-2019 par Martin Lessard

À force de travailler depuis plus d'un an en mode service qui traitent des commandes et des événements, on en vient à ne voir que ça (c'est comme le gars qui a juste un marteau, tout lui apparait comme un clou). Donc, quand on a dû changer le modèle d'indexation pour la recherche ce qui a entrainé de réindexer l'ensemble des informations, on a tout simplement fait un traitement qui lit les données et envoie une commande au service d'indexation pour chaque enregistrement afin de le ré-indexer. Or, lire des dizaines de milliers d'enregistrements, transmettre des dizaines de milliers de messages, "spinner" des "functions" qui permettent de traiter cette charge, ça prend que quelques secondes, au pire quelques minutes. Dans notre solution cependant, le morceau en bout de piste (Azure Search) a vite croulé sous la charge. C'est un des pièges des fonctions en mode consommation: la capacité de traitement d'Azure est tellement importante que si un des éléments de la chaîne ne supporte pas cette charge, ça brise le concept.

Quelques solutions s'offraient à nous:

  • Augmenter la capacité de façon permanente
    • provisionner de la capacité qui va servir seulement 2-3 fois par année, c'est tellement 2018.....
  • Augmenter la capacité de façon temporaire
    • je pense que c'est ça qui aurait été le mieux mais malheureusement, Azure Search ne permet pas de changer le plan lorsque l'index existe
  • Catcher les exceptions, attendre et relancer
  • Gérer le flux

Finalement, on a choisi cette dernière option. On a donc mis en place un traitement qui lit chaque record et qui l'index. C'est évidemment plus long mais c'est très bien supporté par un plan plus petit de Azure Search, un plan amplement suffisant pour nos opérations de tous les jours. On aurait très bien pu héberger ce nouveau traitement dans un webjob mais on en a profité pour explorer Azure Batch au cas où on aurait réellement besoin de traitement lot costaud éventuellement.

Le concept en fait, c'est d'allouer sur demande les noeuds nécessaire à l'exécution. On peut par la suite soit exécuter un traitement qui a déjà été déployé dans le compte Azure Batch ou bien tout simplement déployer une image Docker sur le(s) noeud(s) et exécuter le traitement présent sur cette image. Tout est en place pour transmettre des paramètres à chaque exécution, on pourrait donc séparer la charge entre plusieurs noeuds (dans notre cas, on n'a pas eu besoin de ça).  Comme la facturation est dépendante des nodes qu'on crée et non pas du type de job qu'on roule, on a choisi l'option Docker afin d'apporter une plus grande portabilité à notre solution (j'vous l'avais dit que j'étais pas contre Docker en tant que tel).

Plutôt que d'expliquer en long et en large comment ça fonctionne, voici quelques articles qui nous ont guidés dans la mise en place de notre solution:

https://kiltandcode.com/using-azure-batch-to-orchestrate-and-execute-code-at-large-scale/
https://vincentlauzon.com/2018/01/10/finding-a-vm-image-reference-publisher-sku/
https://www.muspells.net/blog/2018/11/azure-batch-task-in-containers/

Étiquettes : technologie, cloud, Azure

Comments powered by Disqus
back to top