Dérives avec les services tiers - Azure App Service
Cet article fait partie d'une série d'articles dans lesquelles je partage des expériences professionnelles réelles, où l'utilisation de services tiers pour nous décharger de fonctionnalités spécifiques a terriblement mal tourné... alors qu'une approche sur mesure aurait probablement permis d'éviter une telle situation.
Le projet
En 2021, un grand institut de recherche avec fait appel à mon équipe et moi pour mettre en place un micro-site. Celui-ci permettait de mettre de l'avant les rendus produits par un des modèles d'intelligence artificielle issue des recherches des chercheurs.
Il était convenu dès le départ que le projet allait avoir une portée internationale, alors l'infrastructure et les technologies devaient bien s'y prêter.
Le micro-site était principalement client-side : il présentait des informations, puis permettait à l'utilisateur de sélectionner une adresse. Ensuite, une requête à l'API mettait en file la requête de l'utilisateur afin qu'il puisse obtenir un rendu du modèle d'intelligence artificielle (généré sur mesure, selon les sélections de l'utilisateur).
Le modèle IA et son infrastructure (file d'attente, l'inférence, etc) était hors de notre mandat.
Infrastructure et choix de la solution
Nous avons opté pour une application Node.js, avec du caching pour les pages rendues (HTML/JS/CSS). À ce serveur web simple et unidirectionnel s'ajoutaient des endpoints d'API pour les fonctionnalités back-end. Il s'agissait principalement des fonctionnalités suivantes et de quelques opérations connexes :
- Ajout de l'utilisateur (et de l'adresse de sa maison) dans la file d'attente (requête à un RabbitMQ externe).
- Ajout de l'utilisateur (de son adresse courriel) à la liste d'envoi de courriels postdatés (requête à un MongoDB externe).
Comme le projet était à but non lucratif et luttait contre les changements climatiques, Microsoft s'est montrée généreux et a proposé des crédits d'utilisation de sa plateforme Azure à l'intention du projet. Nous avons donc développé l'infrastructure autour de leurs produits. Le choix du App Service comme plateforme pour le micro-site s'est avéré naturel :
- Prise en charge simple de CI/CD à partir de Github.
- Prise en charge du autoscaling.
- Prise en charge des mises à jour d'OS, Node.js et des mises à jour de sécurité.
- Prise en charge du certificat SSL et intégration de la gestion du domaine à même Azure.
Comme recommandé, nous avons mis en place un [end-point de Health] (/health)(https://learn.microsoft.com/en-us/azure/app-service/monitor-instances-health-check?tabs=dotnet) permettant aux services de Azure d'optimiser le scaling automatiquement.
Des tests de scaling à l'aide de petits groupes furent effectués avec succès quelques semaines avant le lancement.
Qu'est-ce qu'une plateforme de type App Service (ou PaSS)
Il s'agit de services permettant de créer, déployer et de scaler des applications web, des backends et des API RESTful. Ils permettent aux développeurs de se concentrer sur l'écriture de code et la création d'applications sans avoir à gérer l'infrastructure sous-jacente, tels que les serveurs, les systèmes d'exploitation et les équipements réseau et toute la maintenance à long terme liée.
Voici les principaux fournisseurs de App Services au moment d'écrire ces lignes :
Le problème
Le site était en soft-launch depuis quelques jours avec succès, sans avoir été partagé à grande échelle. Puis, de grands médias partout à travers le monde ont partagé le projet. D'un instant à l'autre, on passe de 10 à 200,000 visites par heure, sans que nous ayons pu prévoir avec précision l'impact de ces articles.
En théorie, le scaling automatique qui fait tout l'intérêt de ce type de plateformes aurait dû en moins de 5 minutes détecter l'achalandage et déclencher une opération de scaling horizontal. Toutefois, ce n'est pas ce qui se produit. On reçoit plutôt ce courriel :
Dans les journaux de Azure, on peut voir le message suivant apparaître à chaque tentative de scaling :
Failed to update configuration for 'ASP-xyz'.
This region has quota of 0 PremiumV2 instances for your subscription.
Try selecting different region or SKU.
Aussi incroyable que cela puisse paraître, le centre de données utilisé n'avait plus de VMs du type sélectionné au moment où nous en avions besoin, empêchant l'opération de scaling horizontal. Il n'y a donc qu'un seul serveur web pour répondre à tous l'achalandage, jusqu'à ce que nous changions de type de VM.
Les plateformes des App Service supposent qu'il est de notre devoir de nous assurer que suffisamment de VMs du type sélectionné sont disponibles dans notre région.
Quelles sont les solutions
La disponibilité des VMs et un problème sournois du cloud, ce dernier étant souvent représenté comme étant immatériel. Il n'est pas naturel de penser qu'un type de VM mis de l'avant pourrait ne plus être disponible en quantité suffisante, ou plus disponible du tout, du jour au lendemain. Aucune notification de cette indisponibilité ne nous avait été transmise.
D'abord, il faut noter qu'il aurait été sage d'augmenter le nombre de VMs minimal pour la période de dévoilement avec la presse. L'utilisation plus agressive de CDN aurait aussi soulagé l'application Node.js. Dans les deux cas, ça n'aurait en rien réglé le problème de scaling automatique, mais ça l'aurait au moins atténué.
Mais surtout, il aurait été sage d'effectuer des stress tests plus poussés quelques jours avant le lancement, ce qui aurait déclenché le scaling et peut-être mis en lumière le manque de VMs du type sélectionné dans la région (data center) sélectionnée. Cela est d'ailleurs applicable à tous les projets qui utilisent des fonctions de scaling, peu importe le fournisseur cloud.
D'ailleurs, l'offre de services de Microsoft Azure s'est beaucoup bonifiée en ce sens depuis la réalisation du projet. Désormais, un outil de Load Testing est disponible à même Azure App Service. C'est un outil indispensable et à grande valeur ajouté avant toute mise en production avec une plateforme de type App Service.
Les cauchemars des services tiers
Les limitations non naturelles d'un service tiers causent des cauchemars. Elles sont souvent documentées, mais elles ne sont pas mises en évidence. Alors, on ne peut qu'espérer lire la partie de la documentation qui l'évoque et en comprendre toutes les implications… ce qui relève plus de la chance que du professionnalisme. Et puisqu'il s'agit d'une limitation inhérente au design du service tiers lui-même (et non à la technologie impliquée comme telle), nous ne pouvons pas prévoir ou connaître à l'avance sa présence.
Parfois, la flexibilité et la compréhension d'une approche sur mesure est sans pareil. Les services tiers ne sont pas magiques...