Cloudtransformatie voor banksysteem op Azure

In dit artikel vindt u een overzicht van het proces en de onderdelen die het CSE-team (Commercial Software Engineering) van Microsoft heeft gebruikt voor het bouwen van een oplossing voor een bankklant. Omwille van de anonimiteit verwijst het artikel naar de klant als Contoso Bank. Het is een grote internationale organisatie voor financiële dienstverlening (FSI) die een van zijn financiële transactiesystemen wilde moderniseren.

Architectuur

Een Visio-bestand van deze architectuur downloaden.

Drie hoofdblokken vormen de oplossing: back-endservices, belastingstests en bewaking met automatische schaalaanpassing van gebeurtenissen.

De werkelijke Contoso-microservicescontainers werden handmatig gepusht via Docker naar het Kubernetes-cluster. Dit cluster was:

• Azure Red Hat OpenShift (ARO) in de Kubernetes/OpenShift Horizontal Pod Autoscaler (HPA) voor:

  • Kanaalhouder.

  • Schaalbaarheid en prestaties voor producten voor transactiesimulatie.

• Azure Kubernetes Services (AKS) voor de automatische schaalaanpassing van knooppunten voor Kanaalhouder.

Het CSE-team heeft de andere microservices gemaakt als stubs om de werkelijke Contoso-microservices specifiek te isoleren van andere externe mainframeservices die de oplossing heeft gepusht via Azure Pipelines.

Workflow

In de kern bieden de back-endservices de benodigde logica voor een EFT:

1. Een nieuwe EFT begint met een HTTP-aanvraag die is ontvangen door de kanaalhouderservice.

   De service biedt synchrone antwoorden voor aanvragers met behulp van een patroon voor publiceren/abonneren via een Azure Cache voor Redis en wacht op een back-endantwoord.

2. De oplossing valideert deze eerste aanvraag met behulp van de EFT Pilot Password-service.

   Naast het uitvoeren van validaties verrijkt de service ook de gegevens. De gegevensverrijking helpt de back-end te bepalen of de oplossing een verouderd microservicesysteem of een nieuwe moet gebruiken om de EFT te verwerken.

3. De Channel Holder-service start vervolgens de asynchrone stroom.

   De service roept de EFT-controller aan, een reactieve orchestrator die een transactiestroom coördineert. Dit doet u door opdrachten te produceren en gebeurtenissen van andere microservices te gebruiken via Azure Event Hubs/Kafka.

4. Een van deze services is de EFT-processor, waarbij de oplossing de werkelijke transactie beïnvloedt, waarbij krediet- en debitbewerkingen worden uitgevoerd.

   Het CSE-team gebruikte KEDA. Het is een framework waarmee toepassingen automatisch worden geschaald op basis van de belasting van berichten die door de oplossing zijn verwerkt. In de oplossing werd deze gebruikt om de EFT-processor te schalen terwijl de oplossing nieuwe EFT's verwerkt.

   KEDA wordt ondersteund in AKS en Azure Container Apps

5. Vervolgens wordt het testen van belasting uitgevoerd. Azure Load Testing is een volledig beheerde service voor belastingstests waarmee u grootschalige belasting kunt genereren. De service simuleert verkeer voor uw toepassingen zonder dat u extra resources hoeft te implementeren. Azure Load Testing wordt ook geleverd met de mogelijkheid om een bestaand Apache JMeter-script te nemen en te gebruiken om een belastingstest uit te voeren.

6. Ten slotte was bewaking verantwoordelijk voor het integreren van resultaten van belastingtests, infrastructuur en metrische toepassingsgegevens.

   Het team correleerde een belastingtestuitvoering met de bijwerkingen die worden veroorzaakt door microservices op de opslag- en containerindelingslaag. Er is een snelle feedbackcyclus toegestaan voor het afstemmen van toepassingen. Prometheus, Grafana en Application Insights in Azure Monitor waren de belangrijkste onderdelen waarmee deze bewakings- en waarneembaarheidsmogelijkheid werd toegestaan. De gebeurtenis automatisch schalen ondersteunt de validatie van een scenario waarbij toepassingen worden geschaald op basis van het ontvangen bericht. Om dit gedrag te implementeren, heeft het CSE-team KEDA aangepast om het schalen van Java-toepassingen te ondersteunen.

Oplossingsmogelijkheden

De oplossing omvat drie belangrijke mogelijkheden:

• Horizontale automatische schaalaanpassing van pods voor kanaalhouder

• Automatisch schalen van knooppunten voor kanaalhouder

• Schaalbaarheid en prestaties voor producten voor transactiesimulatie

Horizontale automatische schaalaanpassing van pods voor kanaalhouder

In deze oplossing heeft het team een Kubernetes/OpenShift HPA-mechanisme gebruikt. HPA schaalt automatisch het aantal pods op basis van een geselecteerde metrische waarde. Dit biedt een efficiënt in- en uitschaalmechanisme voor containers. Gezien de CPU-gebonden aard van de Channel Holder REST API heeft het team gekozen voor het gebruik van HPA met CPU, zodat de servicereplica's kunnen groeien naarmate er nieuwe EFT's optreden.

Met dit onderdeel wordt een service met de naam Channel Holder uitgevoerd in Azure Red Hat OpenShift. Het voert automatische schaalaanpassing van pods uit op deze service. Het onderdeel moest de volgende mogelijkheden bereiken:

• Geef een DevOps-pijplijn op van on-premises naar Azure voor de service Kanaalhouder.

• Bied OpenShift-clusterbewaking via een Grafana-dashboard.

• Voer horizontale automatische schaalaanpassingstests voor pods uit voor de Channel Holder-service.

• Geef waarneembaarheid op de kanaalhouder door het activeren van metrische gegevensopname (bijvoorbeeld gebruik) met Prometheus en Grafana.

• Geef een gedetailleerd rapport op over de tests die zijn uitgevoerd, het gedrag van de toepassingen en de strategieën voor partitionering van Kafka, indien van toepassing.

Automatisch schalen van knooppunten voor kanaalhouder

De eerste HPA schaalt de replica's omhoog tot een punt waar de clusterinfrastructuur wordt overbelast. Vervolgens zorgt een in- en uitschaalmechanisme voor de knooppunten ervoor dat de toepassingen nieuwe aanvragen ontvangen en verwerken. Voor dat mechanisme heeft het team automatische schaalaanpassing van Kubernetes-knooppunten gebruikt, waardoor het cluster zelfs kon groeien wanneer alle knooppunten dicht bij hun volledige capaciteit lagen.

Dit onderdeel is gericht op het uitvoeren van de Channel Holder-service op AKS om automatische schaalaanpassing van knooppunten toe te staan. Het moest de volgende mogelijkheden bereiken:

• AKS-clusterbewaking bieden via een Grafana-dashboard.

• Voer automatisch schalen van knooppunttests uit voor de Channel Holder-service.

• Geef waarneembaarheid op de kanaalhouder door het activeren van metrische gegevensopname met Prometheus en Grafana.

• Geef een gedetailleerd rapport op over de tests die zijn uitgevoerd, het gedrag van de toepassingen en de strategieën voor partitionering van Kafka, indien van toepassing.

Schaalbaarheid en prestaties voor producten voor transactiesimulatie

Met behulp van het framework voor belastingtests heeft het CSE-team voldoende belasting gegenereerd om zowel HPA- als automatische schaalaanpassingsmechanismen voor knooppunten te activeren. Toen de oplossing de onderdelen heeft geactiveerd, heeft het metrische infrastructuur- en toepassingsgegevens gegenereerd voor het team om reactietijden van kanaalhouders te valideren en het gedrag van de toepassing onder hoge belasting.

Dit onderdeel richt zich op het uitvoeren van kanaalhouder-, EFT-controller- en EFT-processorservices op ARO en AKS. Daarnaast worden pod- en knooppunt automatisch schalen en prestatietests uitgevoerd voor alle services. Het moest de volgende mogelijkheden bereiken:

• Voer prestatietests uit via de microservices totdat deze 2000 transacties per seconde bereikt of overschrijdt.

• Voer automatische schaalaanpassingstests voor horizontale pods/knooppunten uit via de microservices.

• Geef waarneembaarheid op de kanaalhouder door het activeren van metrische gegevensopname met Prometheus en Grafana.

• Geef een gedetailleerd rapport op over de tests die zijn uitgevoerd, het gedrag van de toepassingen en de strategieën voor partitionering van Kafka.

Onderdelen

De onderstaande lijst bevat een overzicht van de technologieën die het CSE-team heeft gebruikt om deze oplossing te maken:

• Azure

  • Azure Pipelines

  • Azure Kubernetes Services (AKS)

  • Azure Red Hat OpenShift

  • Azure SQL-database

  • Azure Event Hubs - (Kafka)

  • Azure Monitor

  • Azure Container Registry

  • Azure Container Instances (ACI)

  • Azure Cache voor Redis

• Derden

  • Back-endservices van Contoso Bank

  • Docker

  • Grafana

  • Prometheus

• Opensource

  • Jenkins

  • KEDA

  • Apache JMeter

  • Redis

Scenariodetails

Contoso Bank is een grote internationale organisatie voor financiële dienstverlening (FSI) die een van de financiële transactiesystemen wilde moderniseren.

Contoso Bank wilde gesimuleerde en werkelijke toepassingen en bestaande workloads gebruiken om de reactie van de oplossingsinfrastructuur voor schaalbaarheid en prestaties te bewaken. De oplossing moest compatibel zijn met de vereisten van het bestaande betalingssysteem.

Potentiële gebruikscases

Contoso Bank wilde een reeks simulaties gebruiken om:

• Bepaal de impact van de schaalbaarheid van de infrastructuur.

• Bepaal de reactie op fouten in het bestaande architectuurontwerp van specifieke mainframesoftware.

De voorgestelde oplossing zou een virtuele toepassing gebruiken om functionele scenario's te simuleren. Het doel hiervan is om de prestaties en schaalbaarheid van de infrastructuur te bewaken. Het doel was om de impact van storingen in de EFT-systeemworkloads (Mainframe Electronic Funds Transfer) te bepalen via deze reeks simulaties.

Er was ook een vereiste om een soepele DevOps-overgang van on-premises naar de cloud voor te stellen. De overgang moest het proces en de methodologie van de bank bevatten en moest de bestaande hulpprogramma's van Contoso Bank gebruiken. Het gebruik van bestaande technologieën vermindert de impact op vaardigheden voor de ontwikkelaars. De overgang helpt Contoso Bank bij het beoordelen van huidige en toekomstige ontwerpbeslissingen. De overgang biedt ook het vertrouwen dat Azure een omgeving is die robuust genoeg is om de nieuwe gedistribueerde systemen te hosten.

Overwegingen

Slagingscriteria

Het Contoso-team en het CSE-team hebben de volgende succescriteria gedefinieerd voor deze afspraak:

Algemene criteria

Contoso Bank beschouwde de volgende algemene punten als geslaagde criteria voor alle onderdelen:

• Geef het technische team van Contoso de mogelijkheid om digitale transformatie en cloudimplementatie toe te passen. Het CSE-team:

  • De benodigde hulpprogramma's en processen in Azure zijn geleverd.

  • Gedemonstreerd hoe het technische team van Contoso hun bestaande hulpprogramma's kan blijven gebruiken.

• Elk onderdeel wordt geleverd met een document met de volgende informatie:

  • Resultaten van schaalbaarheids- en prestatietests.

  • Parameters en metrische gegevens die bij elke test worden overwogen.

  • Elke code of infrastructuurwijziging indien nodig tijdens elke test.

  • Lessen die zijn geleerd over het aanpassen van prestaties, het afstemmen van prestaties en parameters die voor elke test worden overwogen.

  • Lessen die zijn geleerd en richtlijnen over kafka-partitioneringsstrategieën.

  • Algemene aanbevelingen/richtlijnen voor architectuur op basis van de lessen over de producten.

Criteria voor producten

Technische oplossing

De oplossing van het team bevatte kruislingse zorgen en specifieke implementaties om de beoogde producten te bereiken. Het moest ook voldoen aan enkele ontwerpbeperkingen op basis van het beleid van Contoso Bank.

Het is de moeite waard om te vermelden dat Contoso vanwege een functiebeperking in Azure Red Hat OpenShift 3.11 het gebruik van Azure Kubernetes Service heeft aangevraagd voor het testen van scenario's voor automatisch schalen van knooppunten.

Er waren een aantal ontwerpbeperkingen waarmee het CSE-team rekening moest houden:

• Vanwege interne vereisten heeft Contoso Bank het gebruik van de volgende technologieën aangevraagd:

  • OpenShift 3.11 als containerindelingsplatform.

  • Java en Spring Boot voor microserviceontwikkeling.

  • Kafka als gebeurtenisstreamingplatform met de functie Confluent Schema Registry.

• De oplossing moest cloudneutraal zijn.

• DevOps en bewakingsprogramma's moesten dezelfde zijn die Contoso al in hun on-premises ontwikkelomgeving heeft gebruikt.

• De oplossing kan de broncode die Contoso host in de on-premises omgeving niet delen met externe omgevingen. Contoso-beleid staat alleen het verplaatsen van containerinstallatiekopieën van on-premises naar Azure toe.

• Contoso-beleid beperkt de mogelijkheid voor een pijplijn voor constante integratie (CI) om te werken tussen zowel on-premises omgevingen als elke cloud. Contoso heeft alle broncode die wordt gehost in de on-premises omgeving, als containerinstallatiekopieën, handmatig geïmplementeerd in Azure Container Registry. De implementatie aan de on-premises zijde was de verantwoordelijkheid van Contoso.

• Het gesimuleerde scenario voor tests moest een subset van mainframe EFT-workloads gebruiken als een stroomreferentie.

• Contoso Bank moest alle HPA- en prestatietests uitvoeren op ARO.

Kruislingse zorgen over de oplossing

Berichtstreaming

Het CSE-team heeft besloten Apache Kafka te gebruiken als het gedistribueerde platform voor berichtstreaming voor microservices. Voor een betere schaalbaarheid heeft het team nagedacht over het gebruik van één consumentengroep per microservice. In die configuratie is elk microservice-exemplaar een schaaleenheid voor het splitsen en parallelliseren van de verwerking van gebeurtenissen.

Ze hebben een formule gebruikt om het geschatte ideale aantal partities per onderwerp te berekenen ter ondersteuning van de geschatte doorvoer. Zie Het aantal onderwerpen of partities in een Kafka-cluster kiezen voor meer informatie over de formule.

CI/CD-snelheid

Voor DevOps heeft Contoso Bank al een on-premises exemplaar van GitLab gebruikt voor hun codeopslagplaats. Ze hebben pijplijnen voor continue integratie/continue levering (CI/CD) gemaakt voor ontwikkelomgevingen met behulp van een aangepaste Jenkins-oplossing die ze intern hebben ontwikkeld. Het biedt geen optimale DevOps-ervaring.

Om een verbeterde DevOps-ervaring voor Contoso te bieden, heeft het CSE-team Azure Pipelines in Azure DevOps gebruikt om de levenscyclus van de toepassing te beheren. De CI-pijplijn wordt uitgevoerd op elke pull-aanvraag, terwijl de CD-pijplijn wordt uitgevoerd bij elke geslaagde samenvoeging naar de hoofdbranch. Elk lid van het ontwikkelteam was verantwoordelijk voor het beheren van de opslagplaatsen en pijplijnen voor elke service. Ze moesten ook codebeoordelingen, eenheidstests en linting afdwingen (statische broncodeanalyse).

Het CSE-team heeft services gelijktijdig geïmplementeerd zonder onderlinge afhankelijkheden en heeft Jenkins-agents gebruikt zoals aangevraagd door Contoso Bank.

Ze hebben Prometheus opgenomen als onderdeel van de oplossing om de services en het cluster te bewaken. Naast het genereren van zinvolle gegevens voor de oplossing, kan Contoso Bank Prometheus in de toekomst gebruiken om de producten te verbeteren op basis van dagelijks gebruik. In een Grafana-dashboard worden deze metrische gegevens weergegeven.

Implementatiestrategie

Het team heeft de oplossing geïmplementeerd in de ontwikkelomgeving via Azure Pipelines. Elke service heeft een eigen build- en implementatiepijplijn. Ze hebben een implementatiepijplijn gebruikt die handmatig kan worden geactiveerd. Er moet een volledige implementatie van de omgeving en de containers in een specifieke vertakkingsversie worden afgedwongen.

Het CSE-team heeft releasebranches gemaakt die stabiele versies voor implementatie hebben gegenereerd. Het samenvoegen van vertakkingen in de hoofdvertakking vindt alleen plaats wanneer het team zeker weet dat ze klaar zijn om de oplossing te implementeren. Een terugdraaistrategie, buiten de implementatie van de vorige stabiele versie, was buiten het bereik van deze afspraak. Er bestaan goedkeuringspoorten voor elke fase. Elke poort vraagt goedkeuring van de implementatie aan.

Herstel na noodgeval

De oplossing maakt gebruik van Terraform-scripts en Azure Pipelines voor alle services. Als zich een noodgeval voordoet, kan Contoso Bank de hele omgeving opnieuw maken met behulp van Terraform-scripts of door de release-pijplijn opnieuw uit te voeren. Terraform begrijpt dat de omgeving is gewijzigd en opnieuw wordt gemaakt. De oplossing richt de infrastructuur in Azure dynamisch in en vernietigt deze indien nodig. Opslagaccounts zijn zone-redundante opslag (ZRS). Een back-upstrategie valt buiten het bereik van deze afspraak.

Beveiliging en privacy

• Een privéregister (Azure Container Registry) heeft alle containerinstallatiekopieën opgeslagen.

• De oplossing maakt gebruik van ARO- en AKS-geheimen om gevoelige gegevens in pods te injecteren, zoals verbindingsreeks s en sleutels.

• Toegang tot de Kubernetes API-server vereist verificatie via Microsoft Entra ID voor ARO en AKS.

• Toegang tot Jenkins vereist verificatie via Microsoft Entra-id.

Conclusies

Aan het einde van het project heeft het CSE-team de volgende inzichten gedeeld:

• Resultaat van oplossing en betrokkenheid

  • Het team heeft een hoog compatibiliteitsniveau tussen AKS en ARO waargenomen voor de implementatie van services.

  • Application Insights Codeless maakt het eenvoudiger om waarneembaarheid te creëren, samen te werken aan de cloudimplementatie bij lift-and-shift-migraties.

  • Belastingstests zijn een belangrijk onderdeel van grootschalige beoogde oplossingen en vereisen eerdere analyses en planning om rekening te houden met de specifieke microservice.

  • Het belastingstestpotentieel voor het vinden van bijwerkingen van microservices wordt vaak onderschat door klanten.

  • Het maken van een testomgeving vereist mogelijk een strategie voor het verwijderen van infrastructuur om onnodige infrastructuurkosten te voorkomen.

• Belangrijke leertrajecten

  • Er is een soepele toepassingsmigratie van ARO naar AKS.

  • De functie voor automatisch schalen van knooppunten was niet beschikbaar op Red Hat OpenShift versie 3.11. Dit was de versie die tijdens de afspraak werd gebruikt. Als zodanig heeft het CSE-team automatisch schalen van knooppunten uitgevoerd via AKS.

  • Het einde van de levensduur van een product kan creatieve aanpassingen vereisen. Een voorbereidingsfase speelt een belangrijke rol wanneer het team een succesvolle oplossing levert.

  • Bij het maken van dit artikel heeft het CSE-team een oplossing voor belastingstests gemaakt die ACI en JMeter integreert in een Azure DevOps Pipeline. Azure Load Testing is sindsdien beschikbaar gesteld als een volledig beheerde service voor belastingstests zonder dat er extra rekenresources hoeven te worden geïmplementeerd.

  • Het team raadde het gebruik van Azure Event Hubs voor Kafka aan, maar voor Contoso Bank was het schemaregister een belangrijke functie. Om in het aangevraagde tijdsbestek deel te nemen aan Contoso Bank, moest het team het gebruik van het schemaregister in een ander exemplaar van AKS overwegen.

  • Het Kafka-protocol met schemaregister wordt niet ondersteund door Event Hubs Scaler in KEDA.

Volgende stappen

• Automatisch schalen van Java-toepassingen met KEDA met behulp van Azure Event Hubs: KEDA voor Java-voorbeeld

• Patroon: Saga: Informatie over het Saga-patroon op Microservices.io

Verwante resources

Zie de volgende artikelen voor meer informatie over de processen en technologieën die worden gebruikt om deze oplossing te maken:

• Patronen en implementaties