Budování pipeline pro fraud analytiku v reálném čase

Zpracování 50 000 fingerprint událostí za sekundu, obohacení každé o smart signály a vrácení rizikového skóre za méně než 10 milisekund vyžaduje pečlivě navrženou streamingovou architekturu. Tento článek provází naší pipeline od příjmu až po rozhodnutí.

Vrstva příjmu (ingestion)

Události přicházejí jako HTTPS POST požadavky z našeho JavaScriptového agenta běžícího v prohlížečích návštěvníků. Každá událost obsahuje zašifrovaný payload signálů — typicky 8–12 KB komprimovaných dat pokrývajících 130+ signálů prohlížeče. Naše edge servery ukončují TLS, validují podpis požadavku a přeposílají payload do zpracovávající pipeline.

Používáme multiregionální nasazení, kde jsou edge servery kolokovány s CDN uzly našich zákazníků. To udržuje síťový round-trip pod 20 ms pro 95 % požadavků globálně. Edge servery jsou bezstavové Go služby běžící za load balancerem, škálující se horizontálně podle objemu požadavků.

Extrakce signálů

První fáze zpracování dešifruje a parsuje payload signálů. Každý signál je extrahován, validován a otypován. Canvas hashe se ověřují proti známým nemožným hodnotám (které indikují blokování nebo spoofing canvasu). WebGL parametry se křížově validují na konzistenci. Vlastnosti navigatoru se kontrolují proti známým platným kombinacím.

Tato fáze rovněž provádí normalizaci signálů. Řetězce user agenta se parsují do strukturovaných komponent (prohlížeč, verze, OS, zařízení). Rozměry obrazovky se normalizují s ohledem na DPI škálování. Časové posuny (timezone offsets) se validují proti datům z geolokace IP.

Obohacení Smart Signals

Extrahované signály jsou poté obohaceny analýzou Smart Signals — naší server-side inteligenční vrstvou. Ta zahrnuje detekci anonymního režimu (porovnávání vzorců signálů proti známým signaturám soukromého prohlížení), detekci VPN (křížové porovnávání dat IP se signály časového pásma a locale), detekci tamperingu prohlížeče (identifikace nekonzistencí indikujících spoofing signálů) a detekci virtuálních strojů (rozpoznávání hardwarových profilů spojených s VMware, VirtualBox a cloudovými VM).

Každý smart signál je počítán nezávisle a produkuje jak boolean výsledek, tak skóre spolehlivosti. Fáze obohacení přidává ke každé události 24 dalších signálů a poskytuje komplexní posouzení hrozeb, které jde nad rámec toho, čeho lze dosáhnout samotným sběrem na straně klienta.

Engine pro skórování rizika

Obohacená událost je předána našemu enginu pro skórování rizika — modelu typu gradient-boosted rozhodovací strom trénovanému na milionech označkovaných událostí. Model zohledňuje všech 130+ syrových signálů, 24 smart signálů a několik odvozených příznaků: metriky velocity (kolik událostí z tohoto zařízení za posledních 5 minut, 1 hodinu a 24 hodin), historické vzorce chování a skóre reputace sítě.

Model generuje rizikové skóre mezi 0 a 100 spolu s hlavními přispívajícími faktory. Skóre 85 může být například doprovázeno faktory jako „detekována VPN“, „anonymní režim“ a „vysoká velocity — 47 událostí za 5 minut“. Tato vysvětlitelnost je klíčová pro fraud analytiky, kteří potřebují pochopit, proč byla konkrétní událost označena.

Vrstva úložiště a dotazů

Všechny události se persistují do ClickHouse — sloupcové databáze optimalizované pro analytické dotazy nad velkými datovými sadami. ClickHouse zvládá náš objem zápisů (50 tis. událostí/s) bez problémů a jeho sloupcové úložiště umožňuje subsekundové analytické dotazy nad miliardami řádků.

Používáme víceúrovňovou strategii retence. Hot data (posledních 7 dní) jsou uložena na NVMe SSD pro odezvu dotazů pod 100 ms. Warm data (7–90 dní) jsou na standardních SSD. Cold data (90+ dní) jsou komprimována a přesunuta do objektového úložiště, dotazovatelná, ale s vyšší latencí.

Kafka jako páteř

Apache Kafka svazuje pipeline dohromady. Každá fáze čte z Kafka topiců a zapisuje do nich. Vrstva příjmu zapisuje syrové události. Fáze extrakce signálů čte syrové události a zapisuje extrahované události. Fáze obohacení Smart Signals čte extrahované události a zapisuje obohacené události. Engine pro skórování rizika čte obohacené události a zapisuje oskórované události.

Tato architektura poskytuje několik výhod: fáze lze škálovat nezávisle, selhání v jedné fázi neovlivní ostatní a události můžeme přehrávat kteroukoli fází pro ladění nebo přepracování. Consumer groups Kafky umožňují paralelní zpracování v rámci každé fáze a její exactly-once sémantika zajišťuje, že žádná událost není zpracována dvakrát ani ztracena.

Rozpočet latence

Náš end-to-end cíl latence je 10 ms od okamžiku, kdy obohacený payload signálů dorazí do zpracovávající pipeline, po okamžik, kdy je vráceno rizikové skóre. Zde je rozpad rozpočtu: extrakce signálů zabere 1–2 ms, obohacení Smart Signals 3–4 ms, skórování rizika 2–3 ms a serializace a odpověď 1–2 ms. Kafka hop mezi fázemi přidává v našem kolokovaném nasazení méně než 1 ms.

Konzistentní plnění tohoto rozpočtu při 50 tis. událostech za sekundu vyžaduje pečlivou optimalizaci v každé fázi. Používáme předalokované paměťové pooly, zero-copy serializaci a dávkované zápisy do ClickHouse. Model pro skórování rizika je zkompilován do nativního kódu pomocí ONNX Runtime, čímž se eliminuje režie interpretu Pythonu.

Mark strávil dva týdny profilováním pipeline, než našel úzké hrdlo v naší distribuované vyhledávací vrstvě — jediný mutex serializoval vyhledávání napříč všemi gorutinami. Po přechodu na shardovaný návrh zámků klesla p99 z 48 ms na 9 ms. Někdy je oprava trapně jednoduchá, jakmile ji najdete.