Lekcie o zmierení v mierke s architektúrou bez servera

Zmierenie v rozsahu je rozdiel medzi dôverou vo svoje finančné záznamy a strávením nocí prenasledovaním nezhody medzi viacerými stranami.V Lead Bank budujeme infraštruktúru, ktorá zhromažďuje, spracováva a zosúladí údaje pre programy kariet a vkladov na podporu správnosti, auditovateľnosti a povinností súladu. Zmierovanie overuje konzistenciu v bankovom jadre, sieťových súboroch kariet, vydávaných správach o procesoroch a dátových programoch fintech.Pretože sa vzťahuje na viacero strán, pracovný postup je svojou povahou viacnásobný a jediné nezhody môžu spôsobiť nákladné vyšetrovanie a zvýšiť riziko dodržiavania predpisov. Tento príspevok prechádza architektúrou AWS bez servera, ktorú sme vybudovali pre zmierenie viacerých strán, dvoma výrobnými prekážkami, s ktorými sme sa prvýkrát stretli (limity spracovania súborov a hot spots Amazon DynamoDB), a vzormi, ktoré sme použili na ich zmiernenie. I. Kontext a technické obmedzenia zmierenia vo veľkom meradle V Banking-as-a-Service (BaaS) kartové programy, fintechy zvyčajne fungujú prostredníctvom bankového identifikačného čísla (BIN) sponzor, FDIC-zabezpečená vydávajúca banka, ktorá drží licenciu na sieť kariet a je zodpovedná za vyrovnanie a dohľad nad programom. programy zvyčajne zahŕňajú štyri úlohy: sieť kariet (pre smerovanie a pravidlá), vydávajúca banka (legálny emitent a vyrovnávací protistrana), fintech program manažér (skúsenosti a operácie koncového používateľa), a vydávajúci procesor (autorizácia v reálnom čase a operácie účtu karty). Nákup karty začína žiadosťou o autorizáciu, zvyčajne v správe ISO 8583, spoločný štandard pre správy o transakciách s kartami v reálnom čase vymieňané medzi nadobúdateľmi a emitentmi prostredníctvom sietí kariet. sieť používa BIN karty na nasmerovanie žiadosti k jej emitentovi na schválenie alebo odmietnutie rozhodnutia. Skutočné vyrovnanie finančných prostriedkov nastáva nasledujúci deň, keď sieť distribuuje súbory vyrovnania siete všetkým účastníkom. Toto oddelenie medzi autorizáciou v reálnom čase a vyrovnaním dávok je hlavným dôvodom, prečo je zosúladenie založené na súboroch a prevádzkovo kritické. Zmierovanie je kontrola, ktorá overuje konzistenciu medzi vnútornými záznamami a vonkajšími zdrojmi pravdy, vrátane bankového jadra, siete kariet alebo procesorových súborov a dát programov fintech.Vzhľadom na to, že tieto systémy sa líšia v identifikátoroch, načasovaní a sémantike úprav, zosúladenie je svojou povahou viacstranné a viacstupňové.Jedno nesúladenie môže spôsobiť nákladné vyšetrovanie a zvýšiť riziko súladu. V tomto príspevku je Entita konečným spotrebiteľom programu fintech. Účet je objekt, ktorý obsahuje veľa metadát o vzťahoch entít s programom fintech. Zostatok je objekt, ktorý má hodnotu denominovanú v rôznych menách. Transakcia je objekt, ktorý opisuje finančnú udalosť, ako je nákup, platba alebo vrátenie peňazí, ktoré mení hodnotu danej zostatku. Karta je jedným z nástrojov, ktoré možno použiť na vykonanie transakcie a zmenu zostatku. Bankové jadro je knižnica, ktorá drží peniaze programu. V praxi sa zmierovanie rozdeľuje na štyri opakujúce sa pracovné postupy, z ktorých každý má odlišné technické obmedzenia: Overte transakcie, ktoré tvoria súvahu. Preukázať, že súčet zostatkov na úrovni zákazníka sa rovná zostatku omnibus For-Benefit-Of (FBO) jadra banky. Zodpovedajúca aktivita umiestnenej karty k sieťovým alebo procesorovým súborom napriek objemu, variabilite formátu a nesúladným identifikátorom alebo načasovaniu medzi stranami. Overte totožnosť, stav karty a údaje o autorizácii účtu, ktoré môžu zrušiť finančné zhody, ak sú zastarané alebo nekonzistentné. Hoci mnohé pracovné postupy prebiehajú cez rozhranie programovania aplikácií (API), zosúladenie je stále dominované súbormi na konci dňa, pretože poskytujú auditovateľný snímok a podporujú deterministické opätovné spracovanie. Nedokonalé doručenie a opakovanie súborov: súbory prichádzajú neskoro, nesprávne, duplikované alebo opravené, takže potrubie musí byť idempotentné a bezpečné pre opätovné spustenie. Identifikátory nie sú čisté: rovnaká transakcia môže mať rôzne identifikátory medzi stranami, takže zhodovanie často vyžaduje zložené kľúče a korelačnú logiku. Nastaviteľná sémantika vyrovnania: vrátenie peňazí, spory, poplatky a opravy menia pravidlá zhody v priebehu času a zvyšujú zosilnenie písania. Dve výrobné prekážky sa objavujú skoro: dlhé spustenie spracovania súborov môže prekročiť krátkodobé výpočtové limity a vysoký objem písania môže vytvoriť nerovnomerné prístupové vzory a horúce oddiely v databáze zosúladenia. V tomto príspevku sa zameriavame na technické výzvy finančného zmierenia, konkrétne na kontroly bilancie a zhodovanie sieťového vyrovnania a na to, ako sme navrhli potrubie bez servera AWS okolo týchto obmedzení. Architektúra bez servera: odpojenie a orchestrácia Vzhľadom na tieto obmedzenia sme sa zaviazali k bezserverovej architektúre s cieľom minimalizovať prevádzkové nadmerné zaťaženie, maximalizovať dostupnosť a podporovať automatické škálovanie.Tento prístup umožnil nášmu malému tímu rýchlo iterovať a sústrediť naše inžinierske úsilie na komplexnú finančnú obchodnú logiku namiesto údržby a opravy infraštruktúry, čo výrazne znížilo náš vývojársky a infraštruktúrny nákladový profil. a Aby bol článok jednoduchý a zameraný, budeme sa zameriavať iba na finančné súbory. Amazon Simple Storage Service (Amazon S3), Amazon EventBridge, Amazon Simple Queue Service (Amazon SQS), Amazon DynamoDB, AWS Lambda, Amazon Elastic Container Service (Amazon ECS), AWS Step Functions A. Príjem a usmerňovanie udalostí (Amazon S3 a Amazon EventBridge) Proces začína, keď jeden z súborov (transakcia, bilancia alebo vyrovnanie siete) klesne do priečinka Secure File Transfer Protocol (SFTP), ktorý je synchronizovaný so zásobníkmi S3. V našom dizajne sme smerovali udalosti vytvorené objektom S3 cez EventBridge namiesto priamych oznámení S3. To uľahčilo cestu požitia, pretože výrobcovia a spotrebitelia zostali voľne spájaní. Trvalo udržateľné spracovanie (Amazon SQS) V našom dizajne sa pravidlo EventBridge zameriava na štandardný rad SQS, ktorý poskytuje trvanlivé vyrovnávanie a odpojenie príjmu z spracovania. Throttling/Load Leveling: Vyhladzuje špičky požitia.Ak naraz dorazia tri masívne súbory, čela absorbuje zaťaženie, čo pomáha zabezpečiť, aby naše downstreamové výpočtové služby ťahali správy stabilnou a udržateľnou rýchlosťou namiesto toho, aby boli preťažené. Trvanlivosť: Správy pretrvávajú v SQS, kým nie sú úspešne spracované, čo zaručuje aspoň jedno doručenie. Dead Letter Queue (DLQ): Každý rad SQS je nakonfigurovaný s DLQ. Ak spracovanie Lambda zlyhá opakovane (napr. prekračuje maximálny počet retry 5), správa sa presunie do DLQ na manuálnu kontrolu, takže žiadna transakcia nie je ticho stratená. C. Počítačová vrstva (AWS Lambda a Amazon ECS) Naša výpočtová infraštruktúra je strategicky rozdelená tak, aby optimalizovala náklady aj trvanie: AWS Lambda: Rieši ľahké, náročné a orchesterné práce, ako je napríklad analýza správ a spúšťanie paralelnej mapy funkcie Step. Lambda ponúka extrémne rýchle studené štarty a nízke náklady na efemérne úlohy, ktoré sú zaručené do 15 minút. AWS ECS Fargate: Vyhradené pre zosúladenie úloh, ktoré vyžadujú vysokú pamäť alebo presahujú 15-minútový časový limit Lambda (bežná fľaša, ako je podrobne uvedené v oddiele III). D. Orchestrácia pracovného postupu (AWS Step Functions) Zmierovanie je dlhodobý, často viacdňový pracovný postup, takže AWS Step Functions je vhodná pre orchestráciu bez servera na koordináciu jednotlivých výpočtových krokov. Vybrali sme Step Functions špeciálne preto, že poskytuje trvanlivosť a toleranciu chýb, ktoré nie sú vyjednávané pre finančné dodržiavanie, bez toho, aby sme museli písať komplexný retry a kód správy stavu. Dôvody tohto výberu sú zakorenené v architektonickej nevyhnutnosti: Spravovaný stav a trvanlivosť: Zmierovanie zahŕňa desiatky sekvenčných a paralelných krokov (rozdelenie, normalizácia, zosúladenie, agregácia). Funkcie krokov prirodzene spravujú stav medzi krokami, keď zlyhá následná služba (napr. chyba Lambda). State Machine prestane, sleduje presný bod zlyhania a umožňuje, aby sa pracovný postup obnovil alebo reštartoval z tohto bodu, čo je dôležité pre auditovateľnosť a obnovu. Massive Parallelism via Map State: V závislosti od nášho prípadu použitia sme vykonávali určité úlohy paralelne pomocou paralelného stavu a podobne, keď sme chceli iterovať cez tú istú úlohu s iným vstupom, použili sme stav mapy Visual Debugging and Auditability: Pre súlad a operácie je schopnosť vizualizovať celý pracovný postup neoceniteľná. Step Functions poskytuje grafický pohľad na každý krok vrátane jeho vstupov, výstupov a dôvodov zlyhania. E. Pretrvávajúca vrstva (Amazon DynamoDB) Vybrali sme DynamoDB ako našu základnú databázu pre ukladanie nezmeniteľných záznamov o transakciách a súvahách kvôli jeho charakteristikám, ktoré sú nevyhnutné pre masívny program kariet: Vysoký objem, nízka latencia: DynamoDB je navrhnutý pre predvídateľnú, jednocifernú milisekundovú latenciu pri vysokom objeme, ktorá je potrebná pre finančné pracovné postupy. Bezserverové a spravované: Využitím jeho plne spravovanej povahy sme odstránili zbytočnosť poskytovania, opravy a rozdelenia tradičnej relačnej databázy (MySQL / Postgres), čo nám umožnilo plne sa sústrediť na výzvy na úrovni aplikácií, ako je navrhovanie kľúčov oddielov. Integrácia tokov: DynamoDB toky sú nevyhnutné, poskytujú takmer v reálnom čase tok zmien, ktoré spúšťajú systémy dodržiavania predpisov, analýzy a ukladania údajov (Snowflake). Naša zjednodušená verzia našich tokov debetných kariet vyzerala takto. V prvej polovici vysielajúci procesor spúšťa sieťové súbory, ktoré sú synchronizované so systémom S3. Pravidlo EventBridge načúva novým udalostiam systému S3 a odosiela ich do vysielajúceho reťazca SQS. Iniciátor Lambda priebežne vysiela tento reťazec a spúšťa funkciu Network Settlement Step, ktorá analyzuje sieťový súbor a ukladá analyzované údaje do tabuľky Network Settlement DynamoDB. Na spodnej polovici začína tok fintech, keď partner fintech spustí súbory transakcie a súvahy.Toto spúšťa udalosť smerovanú cez SQS reťazec do iniciátora Lambda, ktorý potom spustí samostatnú funkciu kroku, ktorá validuje a zosúladí súbory s dátami vyrovnania siete.Tento proces sa nazýva sieťové zosúladenie. Na pravej strane máme zosúladenie FBO, ktoré zosúladí súbor bilancie fintech s vyrovnanou sumou na účte FBO, aby podporilo presnosť od konca k koncu v sieti, fintech a bankových záznamoch. Scaling Battle: Prekonanie limitov bez servera Táto architektúra spočiatku fungovala dobre, ale ako náš objem rástol, narazili sme na dve kritické prekážky: trvanie výpočtu a rozdelenie databázy, čo nás donútilo vyvinúť náš prístup. A. Optimalizácia výpočtu: migrácia Lambda na ECS Zatiaľ čo rozdelenie súborov pomohlo, komplexná logika zosúladenia vo veľkých kúskoch (napr. 20 000 záznamov v súbore širokého stĺpca s pevnou šírkou) stále príležitostne prekročila toto okno. Naše riešenie nebolo prestavbou, ale jednoduchým architektonickým prepínaním: Unified Codebase: Udržiavali sme jeden jadrový pracovník na zosúladenie, kontajnerizovanú aplikáciu napísanú v Go, ktorá sa zaoberala analýzou a spracovaním súborov. Dynamické vykonávanie: Tento kontajnerový obrázok sme nasadili na Lambda (pre rýchle, efemérne vykonanie) a ECS Fargate (pre dlhodobé, pamäťovo náročné úlohy). Výber funkcie kroku: Funkcia kroku používa stav voľby na začiatku procesu. Ak je veľkosť súboru pod určitým prahom (napr. 1 GB), zameriava sa na funkciu Amazon Lambda. Ak je súbor veľký, stav voľby povolá integráciu funkcií kroku pre ECS (RunTask) na spustenie špeciálnej úlohy Fargate. Tento prístup nám dal praktickú rovnováhu: nákladovú efektívnosť a rýchlosť Lambdy pre 90% menších súborov a výpočtový priestor Fargate pre 10% masívnych, pomalých transakcií a súborov súvah. B. Zvládnutie DynamoDB pre písanie s vysokým výkonom DynamoDB je skvelou voľbou pre databázu, ktorá má vysoký objem, nízku latenciu požiadavky na ukladanie transakcií. Avšak, jeho škálovateľnosť je predurčená na distribúciu I/O rovnomerne cez oddiely. Throttling sa vyskytuje, keď jeden oddielový kľúč prekročí svoj limit (zvyčajne 1 000 jednotiek kapacity písania (WCU) alebo 3 000 jednotiek kapacity čítania (RCU) za sekundu). Mali sme partičný kľúč ProgramID#FileDate (napr. PROGX#20250101) Tento dizajn zlyhal, pretože všetky transakcie pre masívny program v jeden deň zasiahli , prekročenie limitu WCU a požitie hnačky. Nájsť všetky transakcie pre konkrétny program na konkrétny dátum Rovnaké rozdelenie Lekcia globálneho sekundárneho indexu (GSI) Backpressure: Spočiatku sme sa to pokúsili vyriešiť presunutím primárneho kľúča s vysokou kardinálnosťou na GSI a namiesto toho dotazovaním GSI. Avšak to neposkytlo žiadnu úľavu. Pretože GSI dostáva svoj dátový tok z hlavnej tabuľky, ak je oddiel primárnej tabuľky už poškriabaný, čela požitia GSI zažije GSI backpressure, čo v konečnom dôsledku obmedzuje priepustnosť písania celej tabuľky. Uvedomili sme si, že problém s kľúčom jadra oddelenia sa musí vyriešiť na úrovni koreňovej tabuľky. Optimalizovaný návrh kľúča: Rozdelenie kľúča: Naším riešením bolo zaviesť skartovanie písania pre našich zákazníkov s najvyšším objemom: PK Sharding: K oddielovému kľúču sme pripojili vypočítané číslo shard: ProgramID#FileDate#ShardN. Sharding Logic: Použili sme ľahký hashingový algoritmus (napr. modulo) na TransactionID, aby sme ho priradili k fragmentu (napr. TransactionID % 10 má za následok počet fragmentov medzi 0 a 9). Výsledok: To rozložilo zaťaženie písania na desať fyzických oddielov namiesto jedného, čo okamžite zmiernilo problém s horúcimi oddielmi a umožnilo nám vstrebávať dáta 10x vyššou rýchlosťou. IV. Akčné lekcie, ktoré sa naučili V tejto časti sú zhrnuté vzory, ktoré môžete aplikovať na svoje vlastné zmierovacie potrubia, s príkladmi z našej implementácie. A. Výučba systémového dizajnu Tu sú tri lekcie systémového dizajnu, ktoré môžete použiť pri budovaní zmierovacieho potrubia, ktoré sa musí zaoberať retries, nedokonalými vstupmi a viacerými externými systémami: Make retries safe by default (idempotency is the baseline): In an event-driven pipeline, retries are expected, so you should design each step to be safely repeatable. For our use case, we had to pass an idempotency key (for example, a TransactionID or MessageID) through the workflow and use it to guard every side-effecting operation. In practice, that means: Workflow steps: each state transition is protected with conditional writes (for example, in DynamoDB) so the same message cannot advance or mutate state twice. Core banking transactions: postings, transfers, and ledger-affecting actions are executed with explicit dedupe semantics (same idempotency key → same outcome), so a retry results in a no-op or a deterministic “already processed” response rather than a duplicate movement of funds. Webhooks and outbound notifications: These are delivered at least once, so each message includes a stable, recipient-facing idempotency key (event ID) and we maintain an internal delivery ledger (attempts, acknowledgements, and final state). Recipients can safely dedupe replays, and our retries won’t trigger duplicate downstream actions. Always Use a Dead Letter Queue (DLQ): and a redrive policy so that malformed messages are quarantined instead of endlessly retrying and clogging the queue. Configure a SQS DLQ Do not let a service be the only source of truth for its own correctness.: Reconciliation is cross-system by definition, so build checks that validate invariants from the outside. For example, comparing transactions sent by the program against the network and their FBO was very important. Nastavenie SQS DLQ B. Lekcie operačnej excelentnosti Tieto prevádzkové lekcie sú o skrátení času na detekciu a času na vyriešenie tým, že zlyhania sú viditeľné, uskutočniteľné a ľahko preskúmané pre váš tím aj pre vašich partnerov. Zameranie sa na vnútornú pozorovateľnosť: Zistili sme, že kultúra pozorovateľnosti je lepšia ako konštantné riešenie problémov. Náš dôraz sa posunul z reakcie na chyby na ich predchádzanie, čo si vyžadovalo prevádzkovú disciplínu na celej doske. Kľúčom k tomu bolo identifikovať naše hotspoty v ranom štádiu (nastavenie prísnych upozornení a prahových hodnôt pre metriky, ako je hĺbka rezu SQS a strečing DynamoDB) nastavením požadovaných cieľov úrovne služieb (SLO). Zamerať sa na vonkajšiu pozorovateľnosť: mali by ste urobiť zlyhania zosúladenia pre klientov uskutočniteľnými vrátením jasných, samoobslužných chybových správ a usmernení.V našej implementácii sme štandardizovali kódy chýb a vytvorili dostatočný kontext pre partnerov na riešenie spoločných problémov bez eskalácie podpory. Investujte do nástrojov: Vytvorte vyšetrovacie nástroje v ranom štádiu, aby ste mohli sledovať nezhody so zdrojovým súborom, spustením spracovania a výsledným písaním bez vykopávania denníkov. Zamerajte sa na rýchlosť, aby ste získali spätnú väzbu: Mali by ste optimalizovať pre rýchle spätné väzby. Serverless umožnil rýchle spustenie a nízke náklady na vývojárov. Po našom prvom mesiaci spustenia tohto systému zosúladenia založeného na udalostiach bol náš celkový účet za cloudové výpočty nižší ako faktúry za obed nášho tímu. Táto architektúra umožnila nášmu malému tímu rýchlo iterovať a úplne sa zamerať na komplexnú finančnú logiku, a nie na infraštruktúru. Návrh rozhrania: súbor vs. API Bežnou chybou bolo predvolené používanie rozhraní založených na súboroch, keď bolo API vhodnejšie pre obchodný proces. Použite správne rozhranie pre problém: Tu nie je žiadna správna odpoveď; musíte premýšľať o tom, čo je správna abstrakcia na vyriešenie problému. Použili sme súbory len pre skutočné operácie dávok, kde je požadovaný snapshot na konci dňa (napr. Vyrovnanie siete). Potom sme použili API pre všetko ostatné, najmä tam, kde je potrebná spätná väzba v reálnom čase alebo malé, diskrétne prenosy dát. Museli sme prepísať niekoľko vnútorných rozhraní z nahrávania založených na súboroch na HTTP API, pretože prevádzková nadváha sledovania, spracovania a vyrovnávania mnohých malých súborov sa ukázala byť oveľa zložitejšia ako jednoduchá API výzva. Zaobchádzajte so schémami súborov ako so zmluvami o verziách: Mali by ste zaobchádzať so schémami súborov ako so zmluvami o verziách, pretože malé zmeny môžu prerušiť analýzu a ticho skresliť výsledky zosúladenia. záver Budovanie zmierovacieho systému, ktorý sa rozširuje na AWS, je menej o výbere bezserverových komponentov a viac o návrhu na zlyhanie, prehrávanie a vyšetrovanie.V našej implementácii poskytli služby bezserverových služieb AWS silný základ pre orchestráciu a trvanlivý stav.Výsledky výroby v konečnom dôsledku záviseli od detailov, najmä od idempotencie, návrhu kľúča oddielov a prevádzkových signálov, ktoré spôsobili, že nesúlady sa rýchlo zistili a vyriešili.