Configuration d'un déploiement de la version canary API Gateway

La version Canary est une stratégie de développement logiciel qui consiste à déployer une nouvelle version d'API (ou de tout autre logiciel) à des fins de test, tandis que la version de base reste déployée en tant que version de production pour l'exploitation normale dans la même étape. Dans le cadre de cette documentation, la version de base est désignée sous le nom de version de production. Même si cela est raisonnable, vous êtes libre d'appliquer une version Canary à une version hors production à des fins de test.

Dans le cadre du déploiement d'une version Canary, l'ensemble du trafic d'API est séparé de façon aléatoire entre la version de publication et la version Canary selon un rapport préconfiguré. En règle générale, la version Canary reçoit un petit pourcentage du trafic d'API et la version de production utilise le reste. Les fonctions d'API mises à jour ne sont visibles au niveau du trafic d'API qu'à travers la version Canary. Vous pouvez ajuster le pourcentage de trafic Canary pour optimiser la couverture ou les performances de test.

En maintenant le trafic Canary à un niveau limité et en conservant la sélection aléatoire, les utilisateurs ne sont pour la plupart jamais perturbés par les bogues éventuels de la nouvelle version, et aucun utilisateur n'est perturbé de façon permanente sur le plan individuel.

Dès lors que les métriques de test ont satisfait à vos exigences, vous pouvez promouvoir la version Canary en version de production et désactiver la Canary dans le déploiement. Les nouvelles fonctions deviennent alors disponibles dans l'étape de production.

Rubriques

• Déploiement des versions Canary dans API Gateway
• Création d'un déploiement de version Canary
• Mise à jour d'une version Canary
• Promotion d'une version Canary
• Désactivation d'une version canary

Déploiement des versions Canary dans API Gateway

Dans API Gateway, le déploiement d'une version Canary s'appuie sur l'étape de déploiement de la version de production de la version de base d'une API, et attache à l'étape une version Canary pour les nouvelles versions, par rapport à la version de base, de l'API. L'étape est associée au déploiement initial et Canary aux déploiements suivants. Au début, l'étape et Canary pointent toutes les deux vers la même version d'API. Tout au long de cette section, nous parlons indifféremment d'étape et de version de production, mais aussi de Canary et de version Canary.

Pour déployer une API avec une version Canary, vous devez créer un déploiement de version Canary en ajoutant des paramètres Canary à l'étape d'un déploiement standard. Les paramètres Canary décrivent la version Canary sous-jacente, tandis que l'étape représente la version de production de l'API dans le cadre de ce déploiement. Pour ajouter des paramètres Canary, définissez canarySettings pour l'étape de déploiement et spécifiez les éléments suivants :

• Un ID de déploiement, au départ identique à l'ID du déploiement de la version de base défini au niveau de l'étape.

• Un pourcentage du trafic d'API, entre 0,0 et 100,0 (inclus), pour la version Canary.

• Variables d'étape de la version Canary qui peuvent remplacer les variables d'étape de version de production.

• L'utilisation du cache d'étape pour les demandes Canary, si useStageCache est défini et si la mise en cache d'API est activée au niveau de l'étape.

Du moment qu'une version Canary est activée, l'étape de déploiement ne peut pas être associée à un autre déploiement de version non Canary tant que la version Canary n'est pas désactivée et que les paramètres Canary ne sont pas supprimés de l'étape.

Lorsque vous activez la journalisation d'exécution d'API, les journaux et les métriques propres à la version Canary sont générés pour toutes les demandes Canary. Ils sont signalés à un groupe de journaux CloudWatch Logs de l'étape de production ainsi qu'à un groupe de journaux CloudWatch Logs spécifique à la version Canary. Il en va de même pour la journalisation d'accès. Les journaux propres à Canary s'avèrent utiles pour valider les nouvelles modifications apportées à l'API et pour décider s'il convient de les accepter et de promouvoir la version Canary en étape de production, ou s'il est préférable d'abandonner les modifications et de supprimer la version Canary de l'étape de production.

Le groupe de journaux d'exécution s'intitule API-Gateway-Execution-Logs/{rest-api-id}/{stage-name} dans le cas de l'étape de production et API-Gateway-Execution-Logs/{rest-api-id}/{stage-name}/Canary dans le cas de la version Canary. Pour la journalisation d'accès, vous devez créer un groupe de journaux ou en choisir un existant. Le nom du groupe de journaux d'accès de la version Canary est assorti du suffixe /Canary, qui est ajouté au nom du groupe de journaux sélectionné.

Une version Canary peut exploiter le cache d'étape, s'il est activé, pour stocker les réponses et utiliser les entrées mises en cache pour renvoyer des résultats aux prochaines demandes Canary, au cours d'une période time-to-live (TTL) préconfigurée.

Dans le cadre du déploiement d'une version Canary, la version de production et la version Canary de l'API peuvent être associées à une même version ou à des versions différentes. Lorsqu'elles sont associés à des versions différentes, les réponses concernant les demandes de production et Canary sont mises en cache séparément et le cache d'étape renvoie les résultats correspondant aux demandes de production et Canary. Lorsque la version de production et la version Canary sont associées à un même déploiement, le cache d'étape utilise une seule clé de cache pour les deux types de demande et renvoie la même réponse aux mêmes demandes de la version de production et de la version Canary.