Stratégies de publication d'API avec API Gateway
December 22, 2022
Une fois que vous avez correctement séparé le déploiement et la mise en production, l'étape suivante consiste à choisir des mécanismes pour contrôler la mise en production progressive des fonctionnalités. Il est essentiel de sélectionner une stratégie de mise en production qui vous permette de réduire les risques en production. En effet, peu importe à quel point vous testez une nouvelle version de votre API avant sa mise en production, le véritable test a lieu lorsque vous la mettez enfin devant les clients.
Nous pouvons réduire ce risque en effectuant un test ou une expérience avec une petite fraction du trafic et en vérifiant le résultat. Lorsque le résultat est concluant, la mise en production pour tout le trafic est déclenchée. Certaines stratégies conviennent mieux à des scénarios spécifiques que d'autres et nécessitent des degrés variables de services et d'infrastructures supplémentaires. Dans cet article, nous explorerons 3 stratégies populaires de mise en production d'API qui utilisent une API Gateway aujourd'hui.
Pourquoi utiliser une API Gateway dans le déploiement d'API
L'un des avantages de passer à une architecture basée sur les API est que nous pouvons itérer rapidement et déployer de nouveaux changements à nos services. Nous avons également le concept de trafic et routage établi avec une API Gateway pour la partie modernisée de l'architecture. L'API Gateway fournit des étapes qui vous permettent d'avoir plusieurs API déployées derrière la même passerelle, et elle est capable de mettre à jour en place sans temps d'arrêt. L'utilisation d'une API Gateway vous permet de tirer parti des nombreuses fonctionnalités de gestion d'API du service, telles que l'authentification, la limitation de débit, l'observabilité (métriques importantes pour les API), la gestion de plusieurs versions d'API et la gestion des déploiements par étapes (déployer une API en plusieurs étapes telles que dev, test, stage et prod).
Les solutions open source d'API Gateway (Apache APISIX et Traefik), ainsi que les solutions de Service Mesh (Istio et Linkerd) sont capables de faire du fractionnement de trafic et de mettre en œuvre des fonctionnalités comme le déploiement Canary et Blue-Green. Avec le test canary, vous pouvez examiner de manière critique une nouvelle version d'une API en ne sélectionnant qu'une petite partie de votre base d'utilisateurs. Nous aborderons la mise en production canary dans la section suivante.
Mise en production Canary
Une mise en production canary introduit une nouvelle version de l'API et dirige un petit pourcentage du trafic vers la version canary. Dans les API gateways, le fractionnement de trafic permet de déplacer ou de migrer progressivement le trafic d'une version d'un service cible à une autre. Par exemple, une nouvelle version, v1.1, d'un service peut être déployée aux côtés de la version originale, v1.0. Le déplacement de trafic vous permet de tester ou de mettre en production votre nouveau service en ne dirigeant d'abord qu'un petit pourcentage du trafic utilisateur, disons 1%, vers v1.1, puis en déplaçant tout votre trafic vers le nouveau service au fil du temps.
Cela vous permet de surveiller le nouveau service, de rechercher des problèmes techniques, tels qu'une latence accrue ou des taux d'erreur, et de rechercher l'impact commercial souhaité, comme une augmentation des indicateurs de performance clés tels que le taux de conversion des clients ou la valeur moyenne du panier d'achat. Le fractionnement de trafic vous permet d'exécuter des tests A/B ou multivariés en divisant le trafic destiné à un service cible entre plusieurs versions du service. Par exemple, vous pouvez diviser le trafic 50/50 entre vos versions v1.0 et v1.1 du service cible et voir laquelle performe le mieux sur une période donnée. Apprenez-en plus sur la fonctionnalité de fractionnement de trafic dans le contrôleur d'entrée Apache APISIX.
Lorsque cela est approprié, les mises en production canary sont une excellente option, car le pourcentage de trafic exposé à la version canary est hautement contrôlé. Le compromis est que le système doit disposer d'une bonne surveillance pour pouvoir identifier rapidement un problème et revenir en arrière si nécessaire (ce qui peut être automatisé). Ce guide vous montre comment utiliser Apache APISIX et Flagger pour mettre en œuvre rapidement une solution de mise en production canary.
Miroir de trafic
En plus d'utiliser le fractionnement de trafic pour exécuter des expériences, vous pouvez également utiliser le miroir de trafic pour copier ou dupliquer le trafic et l'envoyer à un emplacement supplémentaire ou à une série d'emplacements. Souvent, avec le miroir de trafic, les résultats des requêtes dupliquées ne sont pas renvoyés au service appelant ou à l'utilisateur final. Au lieu de cela, les réponses sont évaluées hors bande pour vérifier leur exactitude, comme comparer les résultats générés par un service refactorisé et un service existant, ou une sélection de propriétés opérationnelles est observée lorsqu'une nouvelle version du service traite la requête, comme la latence de réponse ou l'utilisation du CPU.
L'utilisation du miroir de trafic vous permet de "mettre en production sombre" des services, où un utilisateur est tenu dans l'ignorance de la nouvelle version, mais vous pouvez observer en interne l'effet souhaité.
La mise en œuvre du miroir de trafic à la périphérie des systèmes est devenue de plus en plus populaire au fil des ans. APISIX propose le plugin proxy-mirror pour refléter les requêtes des clients. Il duplique le trafic en ligne réel vers le service de miroir et permet une analyse spécifique du trafic en ligne ou du contenu des requêtes sans interrompre le service en ligne.
Blue-Green
Le déploiement Blue-Green est généralement mis en œuvre à un point de l'architecture qui utilise un routeur, une passerelle ou un équilibreur de charge, derrière lequel se trouvent un environnement bleu complet et un environnement vert. L'environnement bleu actuel représente l'environnement en production actuel, et l'environnement vert représente la prochaine version de la pile. L'environnement vert est vérifié avant de basculer vers le trafic en production, et au moment de la mise en production, le trafic est basculé du bleu au vert. L'environnement bleu est maintenant "éteint", mais si un problème est détecté, il est possible de revenir rapidement en arrière. Le prochain changement passerait du vert au bleu, oscillant ainsi à partir de la première mise en production.
Le déploiement Blue-Green fonctionne bien en raison de sa simplicité et est l'une des meilleures options de déploiement pour les services couplés. Il est également plus facile de gérer les services persistants, bien que vous deviez toujours être prudent en cas de retour en arrière. Il nécessite également le double des ressources pour pouvoir fonctionner en parallèle avec l'environnement actuellement actif.
Gestion du trafic avec Argo Rollouts
Les stratégies discutées apportent beaucoup de valeur, mais le déploiement lui-même est une tâche que vous ne voudriez pas avoir à gérer manuellement. C'est là qu'un outil comme Argo Rollouts est précieux pour démontrer pratiquement certaines des préoccupations discutées.
En utilisant Argo, il est possible de définir un Rollout CRD (Custom Resource Definition) qui représente la stratégie que vous pouvez adopter pour déployer une nouvelle version canary de votre API. Un CRD permet à Argo d'étendre l'API Kubernetes pour prendre en charge le comportement de déploiement. Les CRD sont un modèle populaire avec Kubernetes, et ils permettent à l'utilisateur d'interagir avec une seule API avec l'extension pour prendre en charge différentes fonctionnalités.
Vous pouvez utiliser Apache APISIX et le contrôleur d'entrée Apache APISIX pour la gestion du trafic avec Argo Rollouts. Ce guide vous montre comment intégrer ApisixRoute avec Argo Rollouts en l'utilisant comme un équilibreur de charge à répartition pondérée.
Résumé
Avec l'essor de l'approche de livraison progressive, et également des exigences avancées dans le cadre de la livraison continue avant cela, la capacité à séparer le déploiement et la mise en production d'un service (et de l'API correspondante) est une technique puissante. La capacité à mettre en production des services en mode canary et à utiliser les fonctionnalités de fractionnement et de miroir de trafic d'une API Gateway peut offrir un avantage concurrentiel à votre entreprise en atténuant les risques d'une mauvaise mise en production et en comprenant plus efficacement les besoins de vos clients.