Cet article résume les processus et les composants que l’équipe CSE de Microsoft a utilisés afin de créer une solution pour un client du secteur bancaire. Pour des raisons d’anonymat, l’article fait référence au client en tant que Contoso Bank. Il s’agit d’une organisation internationale de services financiers de premier plan souhaitant moderniser l’un de ses systèmes de transactions financières.
Architecture
Téléchargez un fichier Visio de cette architecture.
Trois blocs principaux constituent la solution : services back-end, tests de charge, et supervision avec le processus de mise à l’échelle automatique des événements.
Les conteneurs réels des microservices Contoso ont été envoyés manuellement par le biais de Docker au cluster Kubernetes. Ce cluster était :
Azure Red Hat OpenShift (ARO) dans HPA (processus d’autoscaling de pod horizontal) Kubernetes/OpenShift :
Service Channel Holder.
Scalabilité et performances des livrables de simulation de transaction.
Azure Kubernetes Services (AKS) pour le processus d’autoscaling du nœud pour le service Channel Holder.
L’équipe CSE a créé les autres microservices en tant que stubs pour isoler spécifiquement les microservices Contoso réels des autres services de mainframe externes que la solution a envoyés par le biais des pipelines Azure.
Workflow
À la base, les services back-end fournissent la logique nécessaire pour qu’un transfert TEF se produise :
Un nouveau transfert EFT commence par une requête HTTP reçue par le service Channel Holder.
Le service fournit des réponses synchrones aux demandeurs à l’aide d’un modèle de publication-abonnement via un Azure Cache pour Redis et attend une réponse du back-end.
La solution valide cette demande initiale à l’aide du service EFT Pilot Password.
Outre l’exécution de validations, le service enrichit également les données. L’enrichissement des données permet au back-end de décider si la solution doit utiliser un système de microservices hérité ou un nouveau système pour traiter le transfert EFT.
Le service Channel Holder démarre ensuite le flux asynchrone.
Le service appelle le contrôleur EFT, un orchestrateur réactif qui coordonne un workflow de transactions. Pour ce faire, il génère des commandes et consomme des événements à partir d’autres microservices via Azure Event Hubs/Kafka.
L’un de ces services est le processeur EFT, où la solution effectue la transaction réelle, par le biais d’opérations de crédit et de débit.
L'équipe du CST a eu recours à la mise à l'échelle automatique pilotée par les événements de Kubernetes (KEDA). Il s’agit d’un framework qui met automatiquement à l’échelle les applications en fonction de la charge des messages traités par la solution. Dans la solution, il a été utilisé pour mettre à l’échelle le processeur EFT lorsque la solution traitait de nouveaux transferts EFT.
KEDA est pris en charge sur AKS et Azure Container Apps
Ensuite, vient le test de charge. Test de charge Azure est un service complètement managé qui permet de générer une charge à grande échelle. Le service simule le trafic pour vos applications sans qu'il soit nécessaire de déployer des ressources supplémentaires. Azure Load Testing permet également de prendre un script Apache JMeter existant et de l'utiliser pour exécuter un test de charge.
Enfin, l’analyse était responsable de l’intégration des résultats du test de charge, de l’infrastructure et des métriques d’application.
L’équipe a corrélé une exécution du test de charge avec les effets secondaires causés par les microservices sur la couche d’orchestration du conteneur et du stockage. Cela a permis d’obtenir un cycle de commentaires rapide pour le paramétrage des applications. Prometheus, Grafana et Application Insights dans Azure Monitor étaient les principaux composants permettant cette fonctionnalité de surveillance et d’observation. Le processus de mise à l’échelle automatique des événements prenait en charge la validation d’un scénario dans lequel les applications étaient mises à l’échelle en fonction de la charge des messages reçue. Pour implémenter ce comportement, l’équipe CSE a adapté KEDA pour prendre en charge la mise à l’échelle des applications Java.
Fonctionnalités de la solution
La solution implique trois fonctionnalités majeures :
HPA (processus d’autoscaling de pod horizontal) pour Channel Holder
Autoscaling des nœuds pour Channel Holder
Scalabilité et performances des livrables de simulation de transaction
HPA (processus d’autoscaling de pod horizontal) pour Channel Holder
Dans cette solution, l’équipe a utilisé un mécanisme HPA Kubernetes/OpenShift. HPA met automatiquement à l’échelle le nombre de pods en fonction d’une métrique sélectionnée. Cela offre un mécanisme efficace de scale-in et scale-out pour les conteneurs. Étant donné la nature liée à l’UC de l’API REST Channel Holder, l’équipe a opté pour l’utilisation de HPA avec l’UC afin que les réplicas de service puissent croître à mesure que de nouveaux transferts EFT se produisent.
Ce composant exécute un service appelé Channel Holder sur Azure Red Hat OpenShift. Il effectue des tests d’autoscaling du pod sur ce service. Le composant devait atteindre les fonctionnalités suivantes :
Fournir un pipeline DevOps à partir de l’environnement local sur Azure pour le service Channel Holder.
Assurer la surveillance du cluster OpenShift via un tableau de bord Grafana.
Exécuter des tests d’autoscaling de pod horizontal pour le service Channel Holder.
Fournir une capacité d’observation sur le service Channel Holder en activant la capture des métriques (par exemple, l’utilisation) avec Prometheus et Grafana.
Fournir un rapport détaillé sur les tests exécutés, le comportement des applications et les stratégies de partitionnement Kafka, le cas échéant.
Autoscaling des nœuds pour Channel Holder
Premièrement, HPA effectue un scale-up des réplicas jusqu’à saturer l’infrastructure du cluster. Ensuite, un mécanisme de scale-in et scale-out pour les nœuds permet aux applications de continuer à recevoir et à traiter de nouvelles demandes. Pour ce mécanisme, l’équipe a utilisé l’autoscaling de nœud Kubernetes, ce qui a permis au cluster de croître même lorsque tous les nœuds étaient proches de leur capacité maximale.
Ce composant se concentre sur l’exécution du service Channel Holder sur AKS pour permettre les tests d’autoscaling. Il devait atteindre les fonctionnalités suivantes :
Assurer la surveillance du cluster AKS via un tableau de bord Grafana.
Exécuter des tests d’autoscaling de nœud pour le service Channel Holder.
Fournir une capacité d’observation sur le service Channel Holder en activant la capture des métriques avec Prometheus et Grafana.
Fournir un rapport détaillé sur les tests exécutés, le comportement des applications et les stratégies de partitionnement Kafka, le cas échéant.
Scalabilité et performances des livrables de simulation de transaction
À l’aide du framework de test de charge, l’équipe CSE a généré suffisamment de charge pour déclencher les mécanismes d’autoscaling de HPA et du nœud. Lorsque la solution déclenchait les composants, cela générait des métriques d’infrastructure et d’application permettant à l’équipe de valider les temps de réponse de la mise à l’échelle de Channel Holder et le comportement de l’application en cas de charge élevée.
Ce composant se concentre sur l’exécution des services Channel Holder, Contrôleur EFT et Processeur EFT sur ARO et AKS. En outre, il exécute l’autoscaling du pod et du nœud, ainsi que des tests de performances sur tous les services. Il devait atteindre les fonctionnalités suivantes :
Exécuter des tests de performances sur les microservices jusqu’à atteindre ou dépasser 2 000 transactions par seconde.
Exécuter des tests d’autoscaling du pod/nœud horizontal sur les microservices.
Fournir une capacité d’observation sur le service Channel Holder en activant la capture des métriques avec Prometheus et Grafana.
Fournir un rapport détaillé sur les tests exécutés, le comportement des applications et les stratégies de partitionnement Kafka adoptées.
Components
La liste ci-dessous résume les technologies utilisées par l’équipe CSE pour créer cette solution :
Azure
Tiers
Services back-end Contoso Bank
Open source
Détails du scénario
Contoso Bank est une organisation internationale de services financiers de premier plan souhaitant moderniser l’un de ses systèmes de transactions financières.
Contoso Bank souhaitait utiliser des applications simulées et réelles, ainsi que des charges de travail existantes, pour surveiller la réaction de l’infrastructure de la solution en termes de scalabilité et de performances. La solution devait être compatible avec les exigences du système de paiement existant.
Cas d’usage potentiels
Contoso Bank souhaitait utiliser un ensemble de simulations pour :
Déterminer l’impact de la scalabilité de l’infrastructure.
Déterminer la réaction aux défaillances dans la conception architecturale existante du logiciel mainframe spécifique.
La solution proposée utilise une application virtuelle pour simuler des scénarios fonctionnels. Son but est de surveiller les performances et la scalabilité de l’infrastructure. L’objectif était de déterminer l’impact des défaillances dans les charges de travail du système EFT (Electronic Funds Transfer) mainframe via cet ensemble de simulations.
Il était également nécessaire de proposer une transition DevOps fluide de l’environnement local vers le cloud. La transition devait inclure le processus et la méthodologie de la banque et devait utiliser les outils existants de Contoso Bank. L’utilisation des technologies existantes ayant pour but de réduire l’impact de l’apprentissage de nouvelles compétences pour les développeurs. La transition aiderait Contoso Bank à passer en revue les décisions de conception actuelles et futures. La transition offrirait également la certitude qu’Azure est un environnement suffisamment robuste pour héberger les nouveaux systèmes distribués.
Considérations
Critères de réussite
L’équipe Contoso et l’équipe CSE ont défini les critères de réussite suivants pour cet engagement :
Critères d’ordre général
Contoso Bank considérait les points généraux suivants comme des critères de réussite sur tous les composants :
Fournir à l’équipe technique Contoso la possibilité d’appliquer la transformation numérique et l’adoption du cloud. L’équipe CSE :
A fourni les outils et processus nécessaires dans Azure.
A démontré comment l’équipe technique Contoso peut continuer à utiliser ses outils existants.
Chaque composant est accompagné d’un document couvrant :
Les résultats des tests de scalabilité et de performances.
Les paramètres et les métriques pris en compte pour chaque test.
Toute modification du code ou de l’infrastructure, si nécessaire, au cours de chaque test.
Les leçons tirées des ajustements des performances, du réglage des performances et les paramètres pris en compte pour chaque test.
Les leçons apprises et les conseils sur les stratégies de partitionnement Kafka.
Des recommandations/conseils relatifs à l’architecture générale basés sur les leçons apprises via les livrables.
Critères des livrables
| Métrique | Valeur (plage) |
|---|---|
| Capacité à exécuter des tests d’autoscaling du pod sur Channel Holder | Cible : Le système crée automatiquement un nouveau réplica de pod Channel Holder après une utilisation de 50 % l’UC. |
| Capacité à exécuter l’autoscaling du nœud sur Channel Holder | Cible : Le système crée de nouveaux nœuds Kubernetes en raison des contraintes de ressources sur les pods (par exemple, utilisation de l’UC). Kubernetes restreint le nombre de nœuds que le système peut créer. La limite est de trois nœuds. |
| Capacité à exécuter des tests de performances et d’autoscaling du pod/nœud sur la simulation EFT | Cible : Le système crée automatiquement de nouveaux réplicas de pod pour tous les services. La réplication a lieu après avoir atteint 50 % de l’utilisation de l’UC et la création d’un nouveau nœud Kubernetes lié aux contraintes de ressources de l’UC. La solution doit prendre en charge 2 000 transactions par seconde. |
Solution technique
La solution fournie par l’équipe comprenait des problèmes transversaux et des implémentations spécifiques pour atteindre les objectifs en matière de livrables cibles. Elle devait également adhérer à certaines contraintes de conception basées sur les stratégies de Contoso Bank.
Il est à noter qu’en raison d’une contrainte de fonctionnalité sur Azure Red Hat OpenShift 3.11, Contoso a demandé l’utilisation d’Azure Kubernetes Service pour tester les scénarios d’autoscaling du nœud.
L’équipe CSE devait prendre en compte un certain nombre de contraintes de conception :
En raison des exigences internes, Contoso Bank a demandé l’utilisation des technologies suivantes :
OpenShift 3.11 en tant que plateforme d’orchestration de conteneur.
Java et Spring Boot pour le développement de microservices.
Kafka en tant que plateforme de streaming d’événements avec la fonctionnalité Confluent Schema Registry.
La solution ne devait pas avoir de dépendance au cloud.
Les outils de DevOps et de surveillance devaient être identiques à ceux que Contoso utilisait déjà dans son environnement de développement local.
La solution ne pouvait pas partager sur des environnements externes le code source que Contoso héberge dans l’environnement local. La stratégie Contoso permet uniquement de déplacer des images de conteneur d’un emplacement local vers Azure.
La stratégie Contoso limite la capacité d’un pipeline d’intégration constante (CI) à fonctionner entre des environnements locaux et un cloud. Contoso a déployé manuellement tout le code source hébergé dans l’environnement local, en tant qu’images de conteneur, sur Azure Container Registry. Le déploiement local était la responsabilité de Contoso.
Le scénario simulé pour les tests devait utiliser un sous-ensemble des charges de travail EFT mainframe comme référence de flux.
Contoso Bank devait effectuer tous les tests HPA et des performances sur ARO.
Problèmes transversaux de la solution
Streaming de messages
L’équipe CSE a décidé d’utiliser Apache Kafka comme plateforme de streaming de messages distribués pour les microservices. Pour une meilleure scalabilité, l’équipe a pensé à utiliser un groupe de consommateurs par microservice. Dans cette configuration, chaque instance de microservice correspond à une unité d’échelle pour fractionner et paralléliser le traitement des événements.
L’équipe a utilisé une formule pour calculer le nombre idéal estimé de partitions par rubrique afin de prendre en charge le débit estimé. Pour plus d’informations sur la formule, consultez Comment choisir le nombre de rubriques ou de partitions dans un cluster Kafka.
Rapidité de CI/CD
Pour DevOps, Contoso Bank utilisait déjà une instance locale de GitLab pour son référentiel de code. Ils ont créés des pipelines d’intégration continue/de livraison continue (CI/CD) pour les environnements de développement à l’aide d’une solution Jenkins personnalisée développée en interne. Cela n’offrait pas une expérience DevOps optimale.
Pour offrir une expérience DevOps améliorée pour Contoso, l’équipe CSE a utilisé Azure Pipelines sur Azure DevOps pour gérer le cycle de vie de l’application. Le pipeline CI s’exécute à chaque demande de tirage (pull request), tandis que le pipeline CD s’exécute à chaque fusion réussie dans la branche primaire. Chaque membre de l’équipe de développement était responsable de la gestion des référentiels et des pipelines pour chaque service. Ils devaient également appliquer des révisions du code, des tests unitaires et du linting (analyse du code source statique).
L’équipe CSE a déployé simultanément les services sans interdépendance et a utilisé des agents Jenkins comme demandé par Contoso Bank.
Elle a incorporé Prometheus dans le cadre de la solution pour surveiller les services et le cluster. Outre la génération de données significatives pour la solution, Contoso Bank peut utiliser Prometheus à l’avenir pour améliorer les produits en fonction de l’utilisation quotidienne. Un tableau de bord Grafana affiche ces métriques.
Stratégie de déploiement
L’équipe a déployé la solution dans l’environnement de développement via Azure Pipelines. Chaque service avait ses propres pipeline de build et de déploiement. L’équipe a utilisé un pipeline de déploiement pouvant être déclenché manuellement. Cela doit forcer un déploiement complet de l’environnement et des conteneurs dans une version de branche spécifique.
L’équipe CSE a créé des branches de mise en production qui ont généré des versions stables pour le déploiement. La fusion de branches dans la branche primaire se produit uniquement quand l’équipe est sûre d’être prête à déployer la solution. Une stratégie de restauration, au-delà du déploiement de la version stable précédente, n’était pas incluse dans cet engagement. Des portes d’approbation existent pour chaque étape. Chaque porte demande l’approbation du déploiement.
Récupération d'urgence
La solution utilise des scripts Terraform et Azure Pipelines pour tous les services. En cas d’incident, Contoso Bank peut recréer l’environnement entier à l’aide de scripts Terraform ou en exécutant à nouveau le pipeline de mise en production. Terraform comprend que l’environnement a changé et le recrée. La solution provisionne et détruit de manière dynamique l’infrastructure sur Azure en fonction des besoins. Les comptes de stockage sont du stockage redondant interzone (ZRS). Une stratégie de sauvegarde n’était pas incluse dans cet engagement.
Sécurité et confidentialité
Un registre privé (Azure Container Registry) stockait toutes les images de conteneur.
La solution utilise des secrets ARO et AKS pour injecter des données sensibles dans des pods, comme des chaînes de connexion et des clés.
L’accès au serveur d’API Kubernetes nécessite une authentification via Microsoft Entra ID pour ARO et AKS.
L’accès à Jenkins nécessite une authentification via Microsoft Entra ID.
Conclusions
À la fin du projet, l’équipe CSE a partagé les insights suivants :
Résultat de la solution et de l’engagement
L’équipe a observé un haut niveau de compatibilité entre AKS et ARO pour le déploiement des services.
Application Insights sans code facilite la création d’une capacité d’observation, la collaboration à l’adoption du cloud sur les migrations « lift-and-shift ».
Le test de charge est une partie importante des solutions prévues à grande échelle et requiert une analyse et une planification antérieures pour prendre en compte les spécificités des microservices.
Le potentiel de test de charge pour rechercher les effets secondaires des microservices est souvent sous-estimé par les clients.
La création d’un environnement de test peut nécessiter une stratégie d’élimination d’infrastructure pour éviter le coût lié à une infrastructure inutile.
Apprentissages clés
Il existe une migration d’application fluide depuis ARO vers AKS.
La fonctionnalité d’autoscaling du nœud n’était pas disponible sur Red Hat OpenShift version 3.11, qui était la version utilisée pendant l’engagement. Par conséquent, l’équipe CSE a exécuté les scénarios de test d’autoscaling de nœud via AKS.
La fin de vie d’un produit peut nécessiter des personnalisations créatives. Une phase de préparation joue un rôle important lorsque l’équipe fournit une solution réussie.
Au moment de la création de cet article, l'équipe CSE a créé une solution de test de charge intégrant ACI et JMeter dans un pipeline Azure DevOps. Azure Load Testing a depuis été mis à disposition en tant que service de test de charge entièrement géré sans qu'il soit nécessaire de déployer des ressources de calcul supplémentaires.
L’équipe a recommandé l’utilisation d’Azure Event Hubs pour Kafka, mais pour Contoso Bank, le registre de schéma était une fonctionnalité importante. Pour aider Contoso Bank dans le laps de temps demandé, l’équipe a dû prendre en compte l’utilisation du registre de schéma dans une autre instance d’AKS.
Le protocole Kafka avec le registre de schéma n’était pas pris en charge par le processus d’autoscaling Event Hub dans KEDA.
Étapes suivantes
Autoscaling d’applications Java avec KEDA à l’aide d’Azure Event Hubs : Exemple KEDA pour Java
Modèle : Saga : Informations sur le modèle Saga sur Microservices.io
Ressources associées
Pour plus d’informations sur les processus et les technologies utilisés pour créer cette solution, consultez les articles suivants :