Bygga en pipeline för realtidsanalys av bedrägerier

Att bearbeta 50 000 fingerprint-händelser per sekund, berika var och en med smarta signaler och returnera en riskpoäng på under 10 millisekunder kräver en noggrant utformad streaming-arkitektur. Den här artikeln går igenom vår pipeline från mottagning till beslut.

Mottagningslager

Händelser anländer som HTTPS POST-förfrågningar från vår JavaScript-agent som körs i besökarnas webbläsare. Varje händelse innehåller den krypterade signalpayloaden — vanligtvis 8–12 KB komprimerad data som täcker 300+ webbläsarsignaler. Våra edge-servrar terminerar TLS, validerar förfrågans signatur och vidarebefordrar payloaden till bearbetningspipelinen.

Vi använder en driftsättning över flera regioner där edge-servrarna är samlokaliserade med våra kunders CDN-noder. Detta håller nätverkets tur och retur under 20 ms för 95 % av förfrågningarna globalt. Edge-servrarna är tillståndslösa Go-tjänster som körs bakom en lastbalanserare och skalar horisontellt utifrån förfrågningsvolymen.

Signalextraktion

Det första bearbetningssteget dekrypterar och tolkar signalpayloaden. Varje signal extraheras, valideras och typsätts. Canvas-hashar verifieras mot kända omöjliga värden (som indikerar canvas-blockering eller spoofing). WebGL-parametrar korsvalideras för konsekvens. Navigator-egenskaper kontrolleras mot kända giltiga kombinationer.

Det här steget utför även signalnormalisering. User agent-strängar tolkas till strukturerade komponenter (webbläsare, version, OS, enhet). Skärmdimensioner normaliseras för att ta hänsyn till DPI-skalning.

Berikning med Smart Signals

De extraherade signalerna berikas sedan med Smart Signals-analys — vårt intelligenslager på serversidan. Detta inkluderar nätverksklassificering (upplösning av VPN-, proxy-, Tor- och datacenteradresser ur kommersiella IP-intelligensdatabaser), detektering av webbläsarmanipulation (identifiering av inkonsekvenser som tyder på signalspoofing), hastighetsanalys (räkning av händelser, distinkta adresser och platser över de senaste tidsfönstren) och beteendepoängsättning (jämförelse av pekar-, tangentbords- och skrolldynamik mot mänskliga baslinjer).

Enterprise-planer lägger till detektering av virtuella maskiner i samma steg. Den läser WebGL-renderer- och vendorsträngarna efter signaturer från VMware, VirtualBox, Parallels, QEMU och Hyper-V och stämmer sedan av dem mot skärmupplösningar, kärnantal och minnesstorlekar som är typiska för VM:er — ingen enskild markör avgör, det gör kombinationen.

Varje smart signal beräknas självständigt och ger både ett resultat och en konfidenspoäng. Berikningssteget lägger till 35+ fält som beräknas på serversidan till varje händelse, vilket ger en hotbedömning som går utöver vad enbart insamling på klientsidan kan uppnå.

Motor för riskpoängsättning

Den berikade händelsen skickas till vår motor för riskpoängsättning — en modell med gradient-boostat beslutsträd som tränats på miljontals märkta händelser. Modellen tar hänsyn till alla 300+ råsignaler, de 35+ smarta signaler som beräknas på serversidan och flera härledda funktioner: hastighetsmått (hur många händelser från denna enhet under de senaste 5 minuterna, 1 timmen och 24 timmarna), historiska beteendemönster och nätverkets ryktespoäng.

Modellen ger en riskpoäng mellan 0 och 100, tillsammans med de faktorer som bidrar mest. En poäng på 85 kan till exempel åtföljas av faktorer som ”VPN upptäckt”, ”inkognitoläge” och ”hög hastighet — 47 händelser på 5 minuter”. Denna förklarbarhet är avgörande för bedrägerianalytiker som behöver förstå varför en viss händelse flaggades.

Lagrings- och frågelager

Alla händelser sparas i ClickHouse — en kolumnbaserad databas optimerad för analytiska frågor över stora datamängder. ClickHouse hanterar vår skrivvolym (50 000 händelser/sekund) utan problem, och dess kolumnbaserade lagring möjliggör analytiska frågor på under en sekund över miljarder rader.

Vi använder en lagringsstrategi i flera nivåer. Het data (senaste 7 dagarna) lagras på NVMe-SSD:er för frågesvar under 100 ms. Varm data (7–90 dagar) ligger på vanliga SSD:er. Kall data (90+ dagar) komprimeras och flyttas till objektlagring, sökbar men med högre latens.

Kafka som ryggrad

Apache Kafka binder samman pipelinen. Varje steg läser från och skriver till Kafka-topics. Mottagningslagret skriver råa händelser. Signalextraktionssteget läser råa händelser och skriver extraherade händelser. Smart Signals-berikningssteget läser extraherade händelser och skriver berikade händelser. Motorn för riskpoängsättning läser berikade händelser och skriver poängsatta händelser.

Denna arkitektur ger flera fördelar: steg kan skalas självständigt, fel i ett steg påverkar inte andra, och vi kan spela upp händelser igen genom vilket steg som helst för felsökning eller ombearbetning. Kafkas konsumentgrupper möjliggör parallell bearbetning inom varje steg, och dess exactly-once-semantik säkerställer att ingen händelse bearbetas två gånger eller går förlorad.

Latensbudget

Vårt mål för latens från början till slut är 10 ms från det ögonblick den berikade signalpayloaden anländer till bearbetningspipelinen till det ögonblick riskpoängen returneras. Så här fördelas budgeten: signalextraktion tar 1–2 ms, Smart Signals-berikning tar 3–4 ms, riskpoängsättning tar 2–3 ms, och serialisering och svar tar 1–2 ms. Kafka-hoppet mellan stegen lägger till mindre än 1 ms i vår samlokaliserade driftsättning.

Att konsekvent hålla denna budget vid 50 000 händelser/sekund kräver noggrann optimering i varje steg. Vi använder förallokerade minnespooler, zero-copy-serialisering och batchade ClickHouse-skrivningar. Modellen för riskpoängsättning kompileras till maskinkod med ONNX Runtime, vilket eliminerar overhead från Python-tolken.

Mark ägnade två veckor åt att profilera pipelinen innan han hittade flaskhalsen i vårt distribuerade uppslagslager — en enda mutex serialiserade uppslag över alla goroutiner. Efter bytet till en shardad låsdesign sjönk p99 från 48 ms till 9 ms. Ibland är lösningen pinsamt enkel när man väl hittar den.