Réinventez votre stratégie de publication avec une passerelle API

L’un des avantages du passage à une architecture basée sur des API est que vous pouvez itérer rapidement et déployer de nouvelles modifications sur nos services. Il y a aussi la notion de trafic et de routage établie avec une passerelle API pour la partie modernisée de l’architecture. La passerelle API fournit des étapes pour vous permettre d’avoir plusieurs API déployées derrière la même passerelle et est capable de mises à jour sur place sans temps d’arrêt. L’utilisation d’une passerelle API vous permet de tirer parti des nombreuses fonctionnalités de gestion des API du service, telles que authentification, taux limitation, observabilité, gestion des versions d’API multiples et gestion du déploiement par étapes (déploiement d’une API en plusieurs étapes telles que développement, test, étape et production).

Passerelle API open source (Apache APISIX et Traefik) et service mesh (Istio et Linkerd) sont capables de diviser le trafic et de mettre en œuvre des fonctionnalités telles que la version canari et déploiement bleu vert. Avec les tests Canary, vous pouvez effectuer un examen critique d’une nouvelle version d’une API en ne sélectionnant qu’une petite partie de votre base d’utilisateurs.

Qu’est-ce qu’une version canari?

Une version Canary introduit une nouvelle version de l’API et achemine un petit pourcentage du trafic vers Canary. Dans les passerelles API, la répartition du trafic permet de déplacer ou de migrer progressivement le trafic d’une version d’un service cible vers une autre. Par exemple, une nouvelle version, v1.1d’un service peut être déployé parallèlement à l’original, v1.0. Le transfert de trafic vous permet de tester ou de publier votre nouveau service en n’acheminant d’abord qu’un petit pourcentage du trafic utilisateur, par exemple 1%pour v1.1puis en transférant l’intégralité de votre trafic au fil du temps vers le nouveau service.

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é. Cela inclut la vérification d’une augmentation des indicateurs de performance clés tels que le taux de conversion des clients ou la valeur moyenne des achats. La répartition du 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 à travers votre v1.0 et v1.1 du service cible et voir lequel fonctionne le mieux sur une période de temps spécifique. En savoir plus sur la fonctionnalité de répartition du trafic dans Apache APISIX Ingress Controller.

Le cas échéant, les canaris sont une excellente option, car le pourcentage de trafic exposé au canari est hautement contrôlé. Le compromis est que le système doit avoir une bonne surveillance en place pour pouvoir identifier rapidement un problème et revenir en arrière si nécessaire (ce qui peut être automatisé). Ce guide vous explique comment utiliser Apache APISIX et Flagger pour mettre en place rapidement une solution de libération canari.

Mise en miroir du trafic

En plus d’utiliser la répartition du trafic pour exécuter des tests, vous pouvez également utiliser la mise en miroir du trafic pour copier ou dupliquer le trafic. Vous pouvez l’envoyer à un emplacement supplémentaire ou à une série d’emplacements. Souvent, avec la mise en miroir du trafic, les résultats des demandes 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 s’assurer qu’elles sont correctes. Par exemple, il compare les résultats générés par un service refactorisé et existant.

L’utilisation de la mise en miroir du trafic vous permet de “dark release” des services, où un utilisateur est tenu dans l’ignorance de la nouvelle version, mais vous pouvez observer en interne l’effet requis.

La mise en œuvre de la mise en miroir du trafic à la périphérie des systèmes est devenue de plus en plus populaire au fil des ans. APISIX offre la proxy-miroir plugin pour refléter les demandes des clients. Il duplique le trafic en ligne réel vers le service de mise en miroir et permet une analyse spécifique du trafic en ligne ou des demandes de contenu sans interrompre le service en ligne.

Qu’est-ce qu’un déploiement bleu vert ?

Le déploiement bleu-vert 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 cela se trouve un environnement bleu complet et un environnement vert. L’environnement bleu actuel représente l’environnement en direct actuel et l’environnement vert représente la prochaine version de la pile. L’environnement vert est vérifié avant de passer au trafic en direct. Lorsqu’il est mis en ligne, le trafic passe du bleu au vert. L’environnement bleu est maintenant désactivé, mais si un problème est détecté, la restauration est rapide. Le prochain changement consiste à passer du vert au bleu, en oscillant à partir de la première version.

Le bleu vert fonctionne bien en raison de sa simplicité, et c’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, même si vous devez toujours être prudent en cas de restauration. Il nécessite également le double du nombre de ressources pour pouvoir fonctionner à froid en parallèle de l’environnement actuellement actif.

Gestion du trafic avec Argo Rollouts

Les stratégies décrites ajoutent 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 tel que Déploiements Argo est utile pour démontrer certaines des préoccupations discutées.

Avec Argo, il est possible de définir un Déploiement CRD qui représente la stratégie que vous pouvez adopter pour déployer un nouveau canari de votre API. Une définition de ressource personnalisée (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. Ils permettent à l’utilisateur d’interagir avec une API avec l’extension pour prendre en charge différentes fonctionnalités.

Vous pouvez utiliser Apache APISIX et Apache APISIX Ingress Controller pour la gestion du trafic avec Argo Rollouts. Ce guide vous montre comment intégrer ApisixRoute Argo Rollouts l’utilisant comme équilibreur de charge à tour de rôle pondéré.

Résumé

La possibilité de séparer le déploiement et la libération du service (et de l’API correspondante) est une technique puissante, en particulier avec la montée en puissance de l’approche de livraison progressive. Un service de publication Canary peut utiliser les fonctionnalités de répartition et de mise en miroir du trafic de la passerelle API et offre un avantage concurrentiel. Cela aide votre entreprise à atténuer le risque d’une mauvaise version et à comprendre les exigences de votre client.

Cet article a été initialement publié sur le Blog API7.ai et a été republié avec autorisation.