Оцінка шахрайства в реальному часі на масштабі
Як tracio.ai обробляє 50K подій/секунду з оцінкою за менш ніж 50 мс завдяки потоковій обробці, попередньо обчисленим векторам сигналів та edge-кешуванню.
Оцінка шахрайства на масштабі вимагає принципово іншої архітектури, ніж пакетна обробка. Коли авторизується платіж або створюється обліковий запис, у вас є мілісекунди — а не хвилини — щоб видати оцінку ризику. У tracio.ai ми обробляємо понад 50 000 подій за секунду з медіанною затримкою оцінки 22 мс. Ця стаття пояснює архітектуру, яка робить це можливим.
Конвеєр оцінки
Кожна вхідна подія проходить триетапний конвеєр: збагачення сигналів, обчислення вектора та оцінка ризику. Збагачення сигналів долучає дані device intelligence — відбиток відвідувача, результати bot detection, IP-аналітику та історичну поведінку — до необробленої події. Обчислення вектора перетворює ці збагачені сигнали на вектор ознак фіксованої довжини, оптимізований для нашої моделі оцінки. Оцінка ризику пропускає вектор через нашу навчену модель і повертає оцінку в діапазоні від 0.0 до 1.0.
Ключове проєктне рішення полягає в тому, що збагачення та обчислення вектора відокремлені від оцінки. Дані збагачення обчислюються попередньо й кешуються. Коли відвідувач завантажує сторінку, ми обчислюємо профіль його пристрою та зберігаємо його в Redis з TTL 60 хвилин. Коли надходить запит на оцінку — зазвичай ініційований платежем або входом, — ми отримуємо попередньо обчислений профіль замість того, щоб обчислювати його заново. Це скорочує затримку оцінки з понад 200 мс до менш ніж 30 мс.
Потокова обробка з Go
Наш шар прийому даних написаний на Go й використовує архітектуру fan-out. Вхідні події надходять через HTTP POST і одразу поміщаються у внутрішній канал. Пул робочих goroutine читає з цього каналу, виконує збагачення й записує збагачені події в ClickHouse для аналітики та в чергу оцінки для обробки в реальному часі. Пул fan-out масштабується динамічно залежно від глибини черги.
Ми обрали Go для шару прийому даних завдяки його чудовим примітивам конкурентності та передбачуваному виділенню пам'яті. Кожна робоча goroutine споживає приблизно 4 КБ стекового простору, що дозволяє нам запускати тисячі одночасних воркерів на одному вузлі. Паузи збирача сміття менш ніж мілісекунда є критичними для підтримки стабільної затримки за високої пропускної здатності.
Edge-кешування та вектори сигналів
Для наших клієнтів із найбільшими обсягами ми розгортаємо моделі оцінки на edge, використовуючи попередньо обчислений кеш векторів сигналів. Коли пристрій бачимо вперше, ми обчислюємо його повний вектор сигналів і зберігаємо його в нашому edge-кеші (розгорнутому на Cloudflare Workers KV). Наступні запити на оцінку для того самого пристрою отримують кешований вектор і виконують оцінку локально на edge, досягаючи затримки менш ніж 10 мс.
Edge-модель оцінки — це дистильована версія нашої повної моделі: менша й швидша, але оптимізована під ті самі цільові показники точності. Ми перенавчаємо edge-модель щотижня й розгортаємо оновлення через поетапне (rolling) розгортання, щоб уникнути лавин інвалідації кешу. Повна модель працює на стороні сервера для випадків, коли впевненість edge-моделі нижча за налаштовуваний поріг.
ClickHouse для аналітики
Усі збагачені події зберігаються в ClickHouse — нашій колонковій аналітичній базі даних. Стиснення та продуктивність запитів ClickHouse дозволяють нам зберігати мільярди подій, водночас підтримуючи аналітичні запити в реальному часі. Наші клієнти використовують цю аналітику, щоб розуміти патерни шахрайства, налаштовувати пороги оцінки та розслідувати окремі події.
Ми використовуємо матеріалізовані подання (materialized views) у ClickHouse для підтримки попередньо агрегованих метрик: рівень шахрайства за країною, розподіл оцінок за типом пристрою та частка хибних спрацювань за порогом. Ці матеріалізовані подання оновлюються в реальному часі в міру надходження подій, надаючи готові для дашборда метрики без затратних агрегаційних запитів.
Здобуті уроки
Побудова системи оцінки в реальному часі навчила нас кількох речей. По-перше, попереднє обчислення — найважливіша оптимізація: будь-яка робота, яку ви можете виконати до надходження запиту на оцінку, — це робота, що не зараховується до вашого бюджету затримки. По-друге, модель конкурентності Go добре підходить для обробки подій з високою пропускною здатністю, але потрібно бути дисциплінованим щодо виділення пам'яті, щоб уникнути тиску на GC. По-третє, розгортання на edge є трансформаційним для затримки, але вимагає ретельного керування моделями, щоб уникнути застарілих прогнозів.