Побудова конвеєра аналітики шахрайства в реальному часі
Огляд архітектури: приймання 50K подій/секунду, збагачення smart-сигналами та оцінювання ризику менш ніж за 10 мс за допомогою нашого потокового рушія.
Обробка 50 000 подій відбитків на секунду, збагачення кожної з них smart-сигналами та повернення оцінки ризику менш ніж за 10 мілісекунд вимагають ретельно спроєктованої потокової архітектури. Ця стаття проведе вас нашим конвеєром від приймання до ухвалення рішення.
Рівень приймання
Події надходять як HTTPS POST-запити від нашого JavaScript-агента, що працює у браузерах відвідувачів. Кожна подія містить зашифрований корисний вантаж сигналів — зазвичай 8–12 КБ стиснених даних, що охоплюють 130+ сигналів браузера. Наші edge-сервери завершують TLS, перевіряють підпис запиту та пересилають корисний вантаж до конвеєра обробки.
Ми використовуємо мультирегіональне розгортання, де edge-сервери розміщені разом із вузлами CDN наших клієнтів. Це утримує мережевий цикл туди-назад під 20 мс для 95% запитів у всьому світі. Edge-сервери — це stateless-сервіси на Go, що працюють за балансувальником навантаження й масштабуються горизонтально залежно від обсягу запитів.
Вилучення сигналів
Перший етап обробки розшифровує та розбирає корисний вантаж сигналів. Кожен сигнал вилучається, перевіряється й типізується. Хеші Canvas звіряються з відомими неможливими значеннями (які вказують на блокування чи підробку Canvas). Параметри WebGL перехресно перевіряються на узгодженість. Властивості Navigator звіряються з відомими коректними комбінаціями.
Цей етап також виконує нормалізацію сигналів. Рядки User Agent розбираються на структуровані компоненти (браузер, версія, ОС, пристрій). Розміри екрана нормалізуються з урахуванням масштабування DPI. Зсуви часового поясу перевіряються за даними геолокації IP.
Збагачення Smart Signals
Вилучені сигнали потім збагачуються аналізом Smart Signals — нашим серверним рівнем інтелекту. Це охоплює виявлення режиму інкогніто (порівняння шаблонів сигналів із відомими сигнатурами приватного перегляду), виявлення VPN (перехресне зіставлення даних IP із сигналами часового поясу та локалі), виявлення підробки браузера (визначення невідповідностей, що вказують на фальсифікацію сигналів) та виявлення віртуальних машин (розпізнавання апаратних профілів, пов'язаних із VMware, VirtualBox та хмарними ВМ).
Кожен smart-сигнал обчислюється незалежно й видає як булевий результат, так і оцінку впевненості. Етап збагачення додає до кожної події 24 додаткові сигнали, забезпечуючи всебічну оцінку загроз, що виходить за межі можливого лише за рахунок збору на боці клієнта.
Рушій оцінювання ризику
Збагачена подія передається до нашого рушія оцінювання ризику — моделі дерева рішень із градієнтним бустингом, навченої на мільйонах розмічених подій. Модель враховує всі 130+ сирих сигналів, 24 smart-сигнали та кілька похідних ознак: метрики швидкості (скільки подій від цього пристрою за останні 5 хвилин, 1 годину та 24 години), історичні шаблони поведінки й оцінки репутації мережі.
Модель видає оцінку ризику від 0 до 100 разом із головними чинниками, що на неї вплинули. Оцінка 85, наприклад, може супроводжуватися такими чинниками, як «виявлено VPN», «режим інкогніто» та «висока швидкість — 47 подій за 5 хвилин». Ця пояснюваність критично важлива для аналітиків шахрайства, яким потрібно розуміти, чому конкретну подію було позначено.
Рівень зберігання та запитів
Усі події зберігаються у ClickHouse — стовпцевій базі даних, оптимізованій для аналітичних запитів над великими наборами даних. ClickHouse без зусиль справляється з нашим обсягом запису (50K подій/секунду), а його стовпцеве зберігання уможливлює субсекундні аналітичні запити над мільярдами рядків.
Ми використовуємо багаторівневу стратегію зберігання. Гарячі дані (останні 7 днів) зберігаються на NVMe SSD для відповіді на запити менш ніж за 100 мс. Теплі дані (7–90 днів) — на стандартних SSD. Холодні дані (90+ днів) стискаються й переносяться до об'єктного сховища, доступні для запитів, але з вищою затримкою.
Kafka як хребет
Apache Kafka зв'язує конвеєр докупи. Кожен етап читає з топіків Kafka та пише до них. Рівень приймання пише сирі події. Етап вилучення сигналів читає сирі події й пише вилучені події. Етап збагачення Smart Signals читає вилучені події й пише збагачені події. Рушій оцінювання ризику читає збагачені події й пише оцінені події.
Ця архітектура дає кілька переваг: етапи можна масштабувати незалежно, збої на одному етапі не впливають на інші, і ми можемо відтворити події через будь-який етап для налагодження чи повторної обробки. Групи споживачів Kafka уможливлюють паралельну обробку в межах кожного етапу, а її семантика exactly-once гарантує, що жодна подія не буде оброблена двічі чи втрачена.
Бюджет затримки
Наша наскрізна ціль за затримкою — 10 мс від моменту, коли збагачений корисний вантаж сигналів надходить до конвеєра обробки, до моменту повернення оцінки ризику. Ось як розкладається цей бюджет: вилучення сигналів займає 1–2 мс, збагачення Smart Signals — 3–4 мс, оцінювання ризику — 2–3 мс, а серіалізація й відповідь — 1–2 мс. Перехід через Kafka між етапами додає менш ніж 1 мс у нашому спільно розміщеному розгортанні.
Стабільне дотримання цього бюджету за 50K подій/секунду вимагає ретельної оптимізації на кожному етапі. Ми використовуємо попередньо виділені пули пам'яті, серіалізацію zero-copy та пакетні записи в ClickHouse. Модель оцінювання ризику компілюється в нативний код за допомогою ONNX Runtime, усуваючи накладні витрати інтерпретатора Python.
Марк витратив два тижні на профілювання конвеєра, перш ніж знайшов вузьке місце в нашому розподіленому рівні пошуку — один м'ютекс серіалізував пошуки по всіх горутинах. Після переходу на шардовану схему блокувань p99 впав із 48 мс до 9 мс. Іноді виправлення виявляється до смішного простим, щойно ви його знаходите.