Cloudová transformace bankovních systémů v Azure

Tento článek shrnuje proces a komponenty týmu komerčního softwarového inženýrství (CSE) Společnosti Microsoft, který se používá k vytvoření řešení pro bankovního zákazníka. V zájmu anonymizace se článek týká zákazníka jako Contoso Bank. Jedná se o významnou mezinárodní organizaci fsI (International Financial Services Industry), která chtěla modernizovat jeden ze svých finančních transakčních systémů.

Architektura

Stáhněte si soubor aplikace Visio s touto architekturou.

Tři hlavní bloky tvoří řešení: back-endové služby, zátěžové testování a monitorování pomocí automatického škálování událostí.

Skutečné kontejnery mikroslužeb Contoso byly ručně vloženy prostřednictvím Dockeru do clusteru Kubernetes. Tento cluster byl:

• Azure Red Hat OpenShift (ARO) v Kubernetes/OpenShift Horizontal Pod Autoscaler (HPA) pro:

  • Držák kanálu.

  • Škálovatelnost a výkon pro zajištění simulace transakcí

• Azure Kubernetes Services (AKS) pro automatické škálování uzlu pro vlastníka kanálu.

Tým CSE vytvořil další mikroslužby jako zástupné procedury, aby konkrétně izoloval skutečné mikroslužby Contoso od jiných externích sálových služeb, které řešení odeslalo prostřednictvím Azure Pipelines.

Workflow

Back-endové služby v jádru poskytují potřebnou logiku, aby se stalo EFT:

1. Nový EFT začíná požadavkem HTTP přijatým službou Channel Holder.

   Služba poskytuje žadatelům synchronní odpovědi pomocí vzoru publikování a odběru prostřednictvím služby Azure Cache for Redis a čeká na odpověď back-endu.

2. Řešení ověří tento počáteční požadavek pomocí služby EFT Pilot Password Service.

   Kromě ověřování služba také rozšiřuje data. Rozšiřování dat pomáhá back-endu rozhodnout, jestli má řešení používat starší systém mikroslužeb nebo nový systém pro zpracování EFT.

3. Služba Channel Holder pak spustí asynchronní tok.

   Služba volá kontroler EFT, což je reaktivní orchestrátor, který koordinuje tok transakce. Dělá to tak, že vytváří příkazy a spotřebovává události z jiných mikroslužeb prostřednictvím služby Azure Event Hubs/Kafka.

4. Jednou z těchto služeb je procesor EFT, kde řešení ovlivňuje skutečnou transakci, provádění kreditních a debetních operací.

   Tým CSE používal automatické škálování řízené událostmi Kubernetes (KEDA). Jedná se o architekturu, která automaticky škáluje aplikace na základě zatížení zpráv zpracovaných řešením. V řešení bylo použito ke škálování procesoru EFT jako řešení zpracovávané nové EFT.

   KeDA se podporuje v AKS a Azure Container Apps.

5. Další je zátěžové testování. Azure Load Testing je plně spravovaná služba zátěžového testování, která umožňuje generovat zatížení ve velkém měřítku. Služba simuluje provoz pro vaše aplikace bez nutnosti nasazení dalších prostředků. Azure Load Testing také nabízí možnost použít existující skript Apache JMeter a použít ho ke spuštění zátěžového testu.

6. Monitorování nakonec odpovídalo za integraci výsledků zátěžového testování, infrastruktury a metrik aplikací.

   Tým koreloval spuštění zátěžového testování s vedlejšími účinky způsobenými mikroslužbami na vrstvě orchestrace úložiště a kontejneru. Povolil rychlý cyklus zpětné vazby pro ladění aplikací. Přehledy prometheus, Grafana a Application Přehledy ve službě Azure Monitor byly základní komponenty, které umožnily tuto funkci monitorování a pozorovatelnosti. Automatické škálování událostí podporovalo ověření scénáře, ve kterém se aplikace škálovat na základě přijaté zprávy. Pro implementaci tohoto chování přizpůsobil tým CSE KEDA tak, aby podporoval škálování aplikací v Javě.

Možnosti řešení

Řešení zahrnuje tři hlavní funkce:

• Horizontální automatické škálování podů pro držák kanálu

• Automatické škálování uzlu pro vlastníka kanálu

• Škálovatelnost a výkon pro dodávky simulace transakcí

Horizontální automatické škálování podů pro držák kanálu

V tomto řešení tým použil mechanismus Kubernetes/OpenShift HPA. HPA automaticky škáluje počet podů na základě vybrané metriky. To poskytuje efektivní mechanismus horizontálního navýšení a snížení kapacity pro kontejnery. Vzhledem k povaze rozhraní REST API pro vlastníka kanálu se tým rozhodl používat HPA s procesorem, aby se repliky služeb mohly s růstem nových efT.

Tato komponenta spouští službu s názvem Channel Holder v Azure Red Hat OpenShiftu. Provádí testy automatického škálování podů pro tuto službu. Komponenta musela dosáhnout následujících možností:

• Poskytněte kanál DevOps z místního prostředí do Azure pro službu Channel Holder.

• Zajištění monitorování clusteru OpenShift prostřednictvím řídicího panelu Grafana

• Proveďte horizontální testy automatického škálování podů pro službu Channel Holder.

• Zajištění pozorovatelnosti pro vlastníka kanálu aktivací zachytávání metrik (například využití) pomocí nástroje Prometheus a Grafana.

• Zadejte podrobnou sestavu o spuštěných testech, chování aplikací a strategiích dělení Kafka( pokud existuje).

Automatické škálování uzlu pro vlastníka kanálu

První HPA škáluje repliky až do bodu, kdy saturuje infrastrukturu clusteru. Pak mechanismus horizontálního navýšení a snížení kapacity pro uzly udržuje aplikace, které přijímají a zpracovávají nové požadavky. Pro tento mechanismus tým použil automatické škálování uzlů Kubernetes, které umožnilo růst clusteru i v případě, že se všechny uzly blížily své plné kapacitě.

Tato komponenta se zaměřuje na spuštění služby Channel Holder v AKS, která umožňuje testy automatického škálování uzlů. Muselo dosáhnout následujících možností:

• Zajištění monitorování clusteru AKS prostřednictvím řídicího panelu Grafana

• Proveďte testy automatického škálování uzlu pro službu Channel Holder.

• Zajištění pozorovatelnosti na držiteli kanálu aktivací zachycení metrik pomocí nástroje Prometheus a Grafana.

• Zadejte podrobnou sestavu o spuštěných testech, chování aplikací a strategiích dělení Kafka( pokud existuje).

Škálovatelnost a výkon pro dodávky simulace transakcí

Pomocí architektury zátěžového testování tým CSE vygeneroval dostatečnou zátěž pro aktivaci mechanismů automatického škálování HPA i uzlů. Když řešení aktivovalo komponenty, vygeneroval pro tým metriky infrastruktury a aplikací, aby ověřil dobu odezvy škálování držitelů kanálu a chování aplikace při vysokém zatížení.

Tato komponenta se zaměřuje na provozování služeb Channel Holder, EFT Controller a EFT Processor v ARO a AKS. Provádí také automatické škálování podů a uzlů a testy výkonnosti na všech službách. Muselo dosáhnout následujících možností:

• Proveďte testy výkonnosti v mikroslužbách, dokud nedosáhne nebo překročí 2 000 transakcí za sekundu.

• Proveďte testy automatického škálování horizontálního podu nebo uzlu v mikroslužbách.

• Zajištění pozorovatelnosti na držiteli kanálu aktivací zachycení metrik pomocí nástroje Prometheus a Grafana.

• Zadejte podrobnou sestavu o spuštěných testech, chování aplikací a strategiích dělení Kafka.

Komponenty

Následující seznam shrnuje technologie, které tým CSE použil k vytvoření tohoto řešení:

• 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 for Redis

• Třetí strana

  • Back-endové služby Contoso Bank

  • Docker

  • Grafana

  • Prometheus

• Open source

  • Jenkins

  • KEDA

  • Apache JMeter

  • Redis

Podrobnosti scénáře

Contoso Bank je velká mezinárodní organizace fsI (International Financial Services Industry), která chtěla modernizovat jeden z jejích finančních transakčních systémů.

Společnost Contoso Bank chtěla použít simulované a skutečné aplikace a existující úlohy k monitorování reakce infrastruktury řešení na škálovatelnost a výkon. Řešení muselo být kompatibilní s požadavky stávajícího platebního systému.

Potenciální případy použití

Společnost Contoso Bank chtěla použít sadu simulací k:

• Určete dopad škálovatelnosti infrastruktury.

• Určete reakci na selhání ve stávajícím návrhu architektury konkrétního sálového softwaru.

Navrhované řešení by k simulaci funkčních scénářů použilo virtuální aplikaci. Jejím účelem by bylo monitorovat výkon a škálovatelnost infrastruktury. Cílem bylo určit dopad selhání v systémových úlohách EFT (Mainframe Electronic Funds Transfer) prostřednictvím této sady simulací.

Bylo také nutné navrhnout hladký přechod DevOps z místního prostředí do cloudu. Přechod musel zahrnovat proces a metodologii banky a musel používat stávající nástroje společnosti Contoso Bank. Používání stávajících technologií by snížilo dopad na dovednosti pro vývojáře. Přechod by pomohl společnosti Contoso Bank při kontrole aktuálních a budoucích rozhodnutí o návrhu. Přechod by také poskytoval jistotu, že Azure je prostředí dostatečně robustní pro hostování nových distribuovaných systémů.

Důležité informace

Kritéria úspěchu

Tým Společnosti Contoso a tým CSE definovaly následující kritéria úspěchu pro tuto rezervaci:

Obecná kritéria

Společnost Contoso Bank považovala za úspěšná kritéria pro všechny komponenty následující obecné body:

• Poskytněte technickému týmu Společnosti Contoso možnost použít digitální transformaci a přechod na cloud. Tým CSE:

  • Poskytli jsme potřebné nástroje a procesy v Azure.

  • Ukázali jsme, jak technický tým Společnosti Contoso může pokračovat v používání stávajících nástrojů.

• Každá komponenta by byla součástí dokumentu, který zahrnuje:

  • Výsledky škálovatelnosti a testů výkonnosti

  • Parametry a metriky považované za každý test

  • Jakýkoli kód nebo změna infrastruktury v případě potřeby během každého testu.

  • Zkušenosti s úpravami výkonu, laděním výkonu a parametry, které se pro každý test považují.

  • Poznatky a pokyny ke strategiím dělení Kafka

  • Obecná doporučení k architektuře /pokyny založené na učení nad dodávkami

Kritéria dodávky

Technické řešení

Řešení, které poskytuje tým, zahrnovalo průřezové otázky a konkrétní implementace pro dosažení cílové dodávky. Musel také dodržovat určitá omezení návrhu na základě zásad společnosti Contoso Bank.

Je dobré poznamenat, že kvůli omezení funkcí v Azure Red Hat OpenShiftu 3.11 společnost Contoso požádala o použití služby Azure Kubernetes Service k testování scénářů automatického škálování uzlů.

Tým CSE musel zvážit několik omezení návrhu:

• Kvůli interním požadavkům společnost Contoso Bank požádala o použití následujících technologií:

  • OpenShift 3.11 jako platforma orchestrace kontejnerů

  • Java a Spring Boot pro vývoj mikroslužeb

  • Kafka jako platforma streamování událostí s funkcí Registru schémat Confluent.

• Řešení muselo být nezávislé na cloudu.

• DevOps a monitorovací nástroje musely být stejné jako nástroje pro monitorování, které už společnost Contoso používala ve svém místním vývojovém prostředí.

• Řešení nemohlo sdílet zdrojový kód, který contoso hostuje v místním prostředí, do externích prostředí. Zásady Společnosti Contoso umožňují přesun imagí kontejnerů jenom z místního prostředí do Azure.

• Zásady společnosti Contoso omezují schopnost kanálu kontinuální integrace (CI) fungovat mezi místními prostředími a jakýmkoli cloudem. Společnost Contoso ručně nasadila veškerý zdrojový kód hostovaný v místním prostředí jako image kontejneru do služby Azure Container Registry. Nasazení na místní straně bylo zodpovědností společnosti Contoso.

• Simulovaný scénář pro testy musel jako referenci na tok použít podmnožinu úloh EFT sálového počítače.

• Společnost Contoso Bank musela provést všechny testy HPA a výkonnosti na ARO.

Průřezové aspekty řešení

Streamování zpráv

Tým CSE se rozhodl používat Apache Kafka jako platformu pro streamování distribuovaných zpráv pro mikroslužby. Kvůli lepší škálovatelnosti tým přemýšlel o použití jedné skupiny příjemců na mikroslužbu. V této konfiguraci je každá instance mikroslužby jednotkou škálování pro rozdělení a paralelizaci zpracování událostí.

Použili vzorec k výpočtu odhadovaného ideálního počtu oddílů na téma pro podporu odhadované propustnosti. Další informace o vzorci najdete v tématu Jak zvolit počet témat nebo oddílů v clusteru Kafka.

Rychlost CI/CD

Pro DevOps už společnost Contoso Bank pro své úložiště kódu použila místní instanci GitLabu. Vytvořili kanály kontinuální integrace a průběžného doručování (CI/CD) pro vývojová prostředí pomocí vlastního řešení založeného na Jenkinsi, které vyvinuli interně. Neposkytovalo optimální prostředí DevOps.

K zajištění vylepšeného prostředí DevOps pro Společnost Contoso tým CSE použil Azure Pipelines v Azure DevOps ke správě životního cyklu aplikace. Kanál CI běží na všech žádostech o přijetí změn, zatímco kanál CD běží při každém úspěšném sloučení do hlavní větve. Každý člen vývojového týmu zodpovídá za správu úložišť a kanálů pro každou službu. Také museli vynucovat kontroly kódu, testy jednotek a lintování (analýza statického zdrojového kódu).

Tým CSE nasadil služby souběžně bez vzájemné závislosti a použil agenty Jenkinse, jak požaduje Contoso Bank.

Začlenili prometheus jako součást řešení pro monitorování služeb a clusteru. Kromě generování smysluplných dat pro řešení může Společnost Contoso Bank v budoucnu využívat Prometheus k vylepšení produktů na základě denního využití. Na řídicím panelu Grafana se zobrazují tyto metriky.

Strategie zavedení

Tým nasadil řešení do vývojového prostředí prostřednictvím Azure Pipelines. Každá služba měla vlastní kanál sestavení a nasazení. Použili kanál nasazení, který je možné aktivovat ručně. Mělo by vynutit úplné nasazení prostředí a kontejnerů v konkrétní verzi větve.

Tým csE vytvořil větve vydaných verzí, které pro nasazení vygenerovaly stabilní verze. Slučování větví do hlavní větve nastane jenom v případě, že si tým je jistý, že je připravený k nasazení řešení. Strategie vrácení zpět, nad rámec nasazení předchozí stabilní verze, byla pro tuto rezervaci mimo rozsah. Pro každou fázi existují schvalovací brány. Každá brána vyžaduje schválení nasazení.

Zotavení po havárii

Řešení používá skripty Terraformu a Azure Pipelines pro všechny služby. Pokud dojde k havárii, společnost Contoso Bank může znovu vytvořit celé prostředí pomocí skriptů Terraformu nebo opětovným spuštěním kanálu verze. Terraform chápe, že se prostředí změnilo a znovu ho vytvořilo. Řešení podle potřeby dynamicky zřídí a zničí infrastrukturu v Azure. Účty úložiště jsou zónově redundantní úložiště (ZRS). Pro tuto rezervaci byla mimo rozsah strategie zálohování.

Ochrana osobních údajů a zabezpečení

• Privátní registr (Azure Container Registry) uložil všechny image kontejneru.

• Řešení používá tajné kódy ARO a AKS k vložení citlivých dat do podů, jako jsou připojovací řetězec a klíče.

• Přístup k serveru rozhraní API Kubernetes vyžaduje ověřování prostřednictvím ID Microsoft Entra pro ARO a AKS.

• Přístup k Jenkinsi vyžaduje ověření prostřednictvím ID Microsoft Entra.

Závěry

Na konci projektu sdílel tým CSE následující přehledy:

• Výsledek řešení a zapojení

  • Tým zaznamenal vysokou úroveň kompatibility mezi AKS a ARO pro nasazení služeb.

  • Application Přehledy Codeless usnadňuje vytváření pozorovatelnosti a spolupráci na přechodu na cloud při migraci metodou "lift and shift".

  • Zátěžové testování je důležitou součástí zamýšlených řešení ve velkém měřítku a vyžaduje předchozí analýzu a plánování zvážení specifik mikroslužeb.

  • Zákazníci často podceňují zátěžové testování, které může najít vedlejší účinky mikroslužeb.

  • Vytvoření testovacího prostředí může vyžadovat strategii vyřazení infrastruktury, aby se zabránilo zbytečným nákladům na infrastrukturu.

• Klíčové poznatky

  • Existuje bezproblémová migrace aplikací z ARO do AKS.

  • Funkce automatického škálování uzlu nebyla k dispozici v Red Hat OpenShiftu verze 3.11, což byla verze použitá během rezervace. Tým CSE například provedl scénáře automatického škálování uzlů prostřednictvím AKS.

  • Konec životnosti produktu může vyžadovat kreativní přizpůsobení. Fáze přípravy hraje důležitou roli, když tým poskytuje úspěšné řešení.

  • Při vytváření tohoto článku vytvořil tým CSE řešení zátěžového testování, které integruje ACI a JMeter do kanálu Azure DevOps. Služba Azure Load Testing je od té doby dostupná jako plně spravovaná služba pro zátěžové testování, aniž by bylo nutné nasazovat další výpočetní prostředky.

  • Tým doporučil použití služby Azure Event Hubs pro Kafka, ale registr schématu Contoso Bank byl důležitou funkcí. Aby se tým v požadovaném časovém rámci zúčastnil společnosti Contoso Bank, musel zvážit použití registru schématu v jiné instanci AKS.

  • Služba Event Hubs Scaler ve službě KEDA nepodporuje protokol Kafka s registrem schématu.

Další kroky

• Automatické škálování aplikací v Javě pomocí KEDA pomocí služby Azure Event Hubs: Ukázka KEDA pro Javu

• Model: Saga: Informace o vzoru Saga na Microservices.io

Související prostředky

Další podrobnosti o procesech a technologiích používaných k vytvoření tohoto řešení najdete v následujících článcích:

• Vzory a implementace