Dark Launch est le meilleur Light Launch

Des œufs de Pâques partout

Dans mon dernier emploi, nous avions l'habitude de créer des systèmes de recommandation de produits pour les entreprises de commerce électronique, ce qui signifie que nos API étaient disponibles sur chaque page de leur site Web. Nous avons eu un nouveau client, notre première offre à 7 chiffres et nous étions si prudents à son égard que nous l'avons initialement intégré en mars avec des recommandations basées sur des règles. Nous ne voulions pas risquer une mauvaise expérience utilisateur avec nos nouveaux modèles d'apprentissage automatique.

Plus tard en avril, nous avons élaboré des modèles d'apprentissage automatique et effectué de nombreux tests hors ligne et effectué de nombreux tests d'assurance qualité manuels. Enfin, nous étions convaincus que notre modèle fonctionnerait bien. Nous l'avons ensuite lancé et deux choses se sont produites :

1. Appel d'urgence : Nous avons reçu un appel d'urgence de leur part en quelques minutes alors que nous étions déjà intrigués par les résultats des recommandations et que nous essayions de les déboguer. Nous avions des recommandations d'œufs de Pâques sur presque toutes les pages de leur site Web. Il s'avère que nous avions mal configuré l'identifiant du modèle avec le modèle que nous avons entraîné en avril avec ses données d'achats de Pâques ! Nous avons immédiatement remplacé l'identifiant du modèle par le nouveau et ce problème a été résolu.
2. Augmentation de la latence p90: Il s'avère que nous utilisions des descriptions de produits comme caractéristiques dans notre modèle et que certaines descriptions étaient très longues, ce qui augmentait notre temps de calcul des caractéristiques. Cela n'a pas été facile à détecter lors de nos tests hors ligne car la latence du modèle semblait correcte dans la plupart des cas. Il n'y avait pas de solution immédiate à ce problème et nous avons dû revenir au système basé sur des règles jusqu'à ce que nous corrigions notre fonctionnalité et que nous testions à nouveau le modèle.

Dans l'ensemble, cela s'est traduit par de nombreux efforts de lutte contre les incendies, une perte de crédibilité importante et une quasi-perte de client. Lors de notre rétrospective interne ultérieure, nous avons réalisé que si #1 n'était qu'un échec manuel, il était presque impossible de détecter des problèmes tels que #2 hors ligne. Depuis, nous sommes passés au bon côté des lancements dans l'obscurité !

Qu'est-ce que Dark Launch ?

Dark Launch est une stratégie de déploiement qui vous permet de retransmettre votre trafic de production réel à votre service nouvellement déployé et d'ignorer la réponse avant de la renvoyer à l'utilisateur. Il se comporte comme si le service était réellement actif mais n'affecte en rien les utilisateurs. Cela vous permet de vérifier que votre nouveau service ne comporte aucune erreur, qu'il présente des performances comparables ou supérieures à celles de votre ancien service et qu'il peut gérer la charge de production. Une fois que tout cela est vérifié, il est presque facile de passer progressivement à votre nouveau service. Donc, d'une certaine manière,

Dark Launch est un moyen léger de lancer vos services.

avec des inconvénients très minimes et un énorme potentiel de hausse.

Comment lancer dans le noir ?

Le lancement de vos services dans le noir est l'un des moyens réalistes de tester vos services et modèles sur un système similaire à celui de la production. Mais l'exécution de Dark Launch peut nécessiter beaucoup de configuration et de maturité au sein de l'organisation du point de vue du développement, de la surveillance et de l'infrastructure.

1. Adoptez une architecture de microservices: Il est important d'adopter une architecture de microservices pilotée par API pour pouvoir tester progressivement vos nouveaux services. La méthode d'exécution lors d'un lancement sombre consiste à rejouer une copie du trafic de production vers un nouveau backend, ce qui est préférable si le service de production actuel et le nouveau service sont tous deux disponibles en tant que microservice et que la communication se fait via un appel REST/gRPC.
2. bifurcation du trafic: Le plus souvent, l'interface de l'application est l'endroit où les utilisateurs effectuent le fork de trafic où un pourcentage du trafic de production est acheminé vers le nouveau service.
3. Appels asynchrones: Un principe général des tests est qu'ils ne doivent pas avoir d'impact négatif sur votre expérience de production réelle. Lors du dark launch, vous dupliquez pratiquement le trafic de production, ce qui peut doubler votre latence à moins que vous ne rendiez vos appels backend asynchrones. Si votre service n'est pas critique en termes de latence, la mise en place de délais raisonnables peut également être une solution.
4. Infrastructures: Idéalement, votre organisation a mis en place une infrastructure facile à faire évoluer horizontalement, car à mesure que vous augmentez le pourcentage de trafic vers votre service Dark Launch, vous devez également faire évoluer progressivement votre infrastructure. Dans la plupart des cas, il peut même être judicieux de reproduire l'intégralité du pic de trafic et au-delà pour vous assurer que votre nouveau service sera réellement évolutif.
5. Journalisation: vous devrez enregistrer la demande et la réponse de vos anciens et nouveaux services principaux pour pouvoir comparer la réponse et les performances du service. S'il s'agit d'un modèle d'apprentissage automatique, vous devez vous assurer que les prévisions de votre modèle sont au moins aussi bonnes que celles de votre ancien modèle. Cela nécessite une journalisation approfondie.
6. Surveillance: Dark Launch est assez inutile si vous ne disposez pas de bons tableaux de bord de surveillance et d'instrumentation permettant de comparer la disponibilité, la latence, l'évolutivité et la qualité de réponse de votre nouveau service. Idéalement, cela devrait se faire en temps réel afin que les anomalies puissent être détectées et détectées rapidement.

Dark Launch est-il juste un test hors ligne sophistiqué ?

Les tests hors ligne vous permettent de vérifier comportement de votre système, généralement de manière isolée. Cela vous permettrait rarement de tester le système de bout en bout ainsi que l'état de système environnant avec un trafic réaliste et des paramètres réseau tels que la production? Vous pouvez atteindre 70 % de tout cela grâce à une journalisation méticuleuse et à des tests hors ligne très compliqués, mais Dark Launch s'avère être un système beaucoup plus simple. En effet, vous finissez de toute façon par effectuer la plupart des étapes ci-dessus pour lancer et surveiller un service normalement. Une fois que vous avez effectué un lancement réussi dans le dark, la sortie effective du nouveau service est presque insignifiante, donc le ratio effort-récompense en vaut la peine.

Dans certains cas, cela peut être difficile à justifier dans la pratique. Par exemple, si votre service est dynamique ou s'il modifie réellement la base de données alors faire un lancement dans le noir est beaucoup plus compliqué. D'après mon expérience personnelle, il est si difficile de s'assurer de l'exactitude du système qu'il est Il vaut mieux se contenter de tests hors ligne plutôt que Dark Launch !

Si vous êtes plus curieux de découvrir les lancements dans le noir ou si vous souhaitez partager certaines de vos expériences, contactez-moi à l'adresse nikunj@truefoundry.com !

True Foundry est un PaaS de déploiement de machine learning sur Kubernetes destiné à accélérer les flux de travail des développeurs tout en leur offrant une flexibilité totale dans les tests et le déploiement de modèles, tout en garantissant une sécurité et un contrôle complets à l'équipe Infra. Grâce à notre plateforme, nous permettons aux équipes de machine learning de déployer et surveiller des modèles en 15 minutes avec une fiabilité à 100 %, une évolutivité et la possibilité de revenir en arrière en quelques secondes, ce qui leur permet de réduire les coûts et de mettre les modèles en production plus rapidement, ce qui permet de réaliser une véritable valeur commerciale.