Skórování podvodů v reálném čase ve velkém měřítku

Skórování podvodů ve velkém měřítku vyžaduje zásadně jinou architekturu než dávkové zpracování. Když se autorizuje platba nebo zakládá účet, máte na doručení rizikového skóre milisekundy — nikoli minuty. V tracio.ai zpracováváme přes 50 000 událostí za sekundu s mediánovou latencí skórování 22 ms. Tento článek vysvětluje architekturu, která to umožňuje.

Pipeline skórování

Každá příchozí událost vstupuje do třístupňové pipeline: obohacení signálů, výpočet vektoru a rizikové skórování. Obohacení signálů připojuje k surové události data z device intelligence — otisk návštěvníka, výsledky detekce botů, IP intelligence a historické chování. Výpočet vektoru transformuje tyto obohacené signály do vektoru příznaků s pevnou délkou, optimalizovaného pro náš skórovací model. Rizikové skórování prožene vektor naším natrénovaným modelem a vrátí skóre mezi 0,0 a 1,0.

Klíčovým návrhovým rozhodnutím je, že obohacení a výpočet vektoru jsou odděleny od skórování. Data obohacení jsou předpočítána a cachována. Když návštěvník načte stránku, spočítáme jeho profil zařízení a uložíme jej do Redisu s TTL 60 minut. Když dorazí požadavek na skórování — obvykle vyvolaný platbou nebo přihlášením — místo opětovného výpočtu profil vyzvedneme z cache. Tím se latence skórování snižuje z více než 200 ms na méně než 30 ms.

Stream processing v Go

Naše vrstva pro příjem dat je napsána v Go a využívá fan-out architekturu. Příchozí události přicházejí přes HTTP POST a jsou okamžitě umístěny do interního kanálu. Pool worker gorutin z tohoto kanálu čte, provádí obohacení a zapisuje obohacené události do ClickHouse pro analytiku a do fronty skórování pro zpracování v reálném čase. Fan-out pool se dynamicky škáluje podle hloubky fronty.

Pro vrstvu příjmu dat jsme zvolili Go kvůli jeho vynikajícím primitivům pro souběžnost a předvídatelné alokaci paměti. Každá worker gorutina spotřebuje přibližně 4 KB prostoru na zásobníku, což nám umožňuje provozovat na jednom uzlu tisíce souběžných workerů. Pauzy garbage collectoru pod jednu milisekundu jsou klíčové pro udržení konzistentní latence při vysoké propustnosti.

Edge caching a signálové vektory

Pro naše zákazníky s nejvyšším objemem nasazujeme skórovací modely na edge pomocí cache předpočítaných signálových vektorů. Když je zařízení viděno poprvé, spočítáme jeho úplný signálový vektor a uložíme jej do naší edge cache (nasazené na Cloudflare Workers KV). Následné požadavky na skórování téhož zařízení cachovaný vektor vyzvednou a skórování provedou lokálně na edge, čímž dosahují latence pod 10 ms.

Edge skórovací model je destilovaná verze našeho plného modelu — menší a rychlejší, ale optimalizovaná na stejné cíle přesnosti. Edge model přetrénováváme týdně a aktualizace nasazujeme pomocí rolling deploymentu, abychom se vyhnuli lavinám invalidace cache. Plný model běží na straně serveru pro případy, kdy je spolehlivost edge modelu pod konfigurovatelným prahem.

ClickHouse pro analytiku

Všechny obohacené události jsou uloženy v ClickHouse, naší sloupcové analytické databázi. Komprese a výkon dotazů ClickHouse nám umožňují ukládat miliardy událostí a přitom podporovat analytické dotazy v reálném čase. Naši zákazníci tuto analytiku využívají k pochopení vzorců podvodů, ladění prahů skórování a vyšetřování jednotlivých událostí.

V ClickHouse používáme materializované pohledy k udržování předagregovaných metrik: míra podvodů podle země, rozložení skórování podle typu zařízení a míra falešně pozitivních výsledků podle prahu. Tyto materializované pohledy se aktualizují v reálném čase, jak události přicházejí, a poskytují metriky připravené pro dashboard bez nákladných agregačních dotazů.

Poučení

Budování systému skórování v reálném čase nás naučilo několik věcí. Za prvé, předpočítání je nejdůležitější optimalizace — jakákoli práce, kterou zvládnete udělat před příchodem požadavku na skórování, je práce, která se nezapočítává do vašeho rozpočtu latence. Za druhé, model souběžnosti Go se dobře hodí pro zpracování událostí s vysokou propustností, ale musíte být disciplinovaní v alokaci paměti, abyste se vyhnuli tlaku na GC. Za třetí, nasazení na edge je pro latenci transformativní, ale vyžaduje pečlivou správu modelů, abyste se vyhnuli zastaralým predikcím.