रियल-टाइम फ्रॉड एनालिटिक्स पाइपलाइन बनाना

प्रति सेकंड 50,000 फ़िंगरप्रिंट इवेंट प्रोसेस करना, हर एक को स्मार्ट सिग्नल से समृद्ध करना और 10 मिलीसेकंड के भीतर रिस्क स्कोर लौटाना — इसके लिए एक सावधानी से डिज़ाइन की गई स्ट्रीमिंग आर्किटेक्चर चाहिए। यह लेख हमारी पाइपलाइन को इंजेशन से लेकर निर्णय तक समझाता है।

इंजेशन लेयर

इवेंट, विज़िटर के ब्राउज़र में चल रहे हमारे JavaScript एजेंट से HTTPS POST अनुरोध के रूप में आते हैं। हर इवेंट में एन्क्रिप्टेड सिग्नल पेलोड होता है — आम तौर पर 300+ ब्राउज़र सिग्नल को कवर करने वाला 8-12KB कंप्रेस्ड डेटा। हमारे edge सर्वर TLS टर्मिनेट करते हैं, अनुरोध के सिग्नेचर को वैलिडेट करते हैं और पेलोड को प्रोसेसिंग पाइपलाइन को फ़ॉरवर्ड कर देते हैं।

हम मल्टी-रीजन डिप्लॉयमेंट का उपयोग करते हैं, जहाँ edge सर्वर हमारे ग्राहकों के CDN नोड्स के साथ कोलोकेटेड होते हैं। इससे विश्व भर में 95% अनुरोधों के लिए नेटवर्क राउंड-ट्रिप 20ms के नीचे रहती है। edge सर्वर स्टेटलेस Go सर्विसें हैं जो एक लोड बैलेंसर के पीछे चलती हैं और अनुरोध की मात्रा के आधार पर हॉरिज़ॉन्टली स्केल होती हैं।

सिग्नल एक्सट्रैक्शन

पहला प्रोसेसिंग चरण सिग्नल पेलोड को डिक्रिप्ट और पार्स करता है। हर सिग्नल को एक्सट्रैक्ट, वैलिडेट और टाइप किया जाता है। Canvas हैश को ज्ञात असंभव मानों के विरुद्ध सत्यापित किया जाता है (जो canvas ब्लॉकिंग या स्पूफ़िंग का संकेत देते हैं)। WebGL पैरामीटर को संगति के लिए क्रॉस-वैलिडेट किया जाता है। Navigator प्रॉपर्टीज़ को ज्ञात वैध संयोजनों के विरुद्ध जाँचा जाता है।

यह चरण सिग्नल नॉर्मलाइज़ेशन भी करता है। User agent स्ट्रिंग को संरचित घटकों (ब्राउज़र, वर्शन, OS, डिवाइस) में पार्स किया जाता है। स्क्रीन के आयामों को DPI स्केलिंग के हिसाब से नॉर्मलाइज़ किया जाता है।

Smart Signals एनरिचमेंट

एक्सट्रैक्ट किए गए सिग्नल को फिर Smart Signals विश्लेषण से समृद्ध किया जाता है — यह हमारी सर्वर-साइड इंटेलिजेंस लेयर है। इसमें नेटवर्क वर्गीकरण (व्यावसायिक IP इंटेलिजेंस डेटाबेस से VPN, proxy, Tor और डेटासेंटर पतों की पहचान करना), ब्राउज़र टैम्परिंग डिटेक्शन (उन असंगतियों की पहचान करना जो सिग्नल स्पूफ़िंग का संकेत देती हैं), वेलोसिटी विश्लेषण (हाल की समय-खिड़कियों में इवेंट, अलग-अलग पतों और स्थानों की गिनती करना) और व्यवहार स्कोरिंग (पॉइंटर, कीबोर्ड और स्क्रॉल की गतिकी की तुलना मानवीय बेसलाइन से करना) शामिल है।

Enterprise प्लान इसी चरण में वर्चुअल मशीन डिटेक्शन जोड़ते हैं। यह WebGL renderer और vendor strings में VMware, VirtualBox, Parallels, QEMU और Hyper-V के हस्ताक्षर पढ़ता है, और फिर उन्हें VM में आम तौर पर मिलने वाले screen resolutions, कोर संख्या और मेमोरी आकार से क्रॉस-चेक करता है — कोई एक अकेला marker निर्णय नहीं करता, संयोजन करता है।

हर स्मार्ट सिग्नल स्वतंत्र रूप से कंप्यूट होता है और एक परिणाम तथा एक confidence स्कोर दोनों देता है। एनरिचमेंट चरण हर इवेंट में 35+ सर्वर-कंप्यूटेड फ़ील्ड जोड़ता है, जो एक थ्रेट असेसमेंट प्रदान करता है — ऐसा जो अकेले क्लाइंट-साइड कलेक्शन से हासिल नहीं किया जा सकता।

रिस्क स्कोरिंग इंजन

समृद्ध किया गया इवेंट हमारे रिस्क स्कोरिंग इंजन को भेजा जाता है — यह एक gradient-boosted decision tree मॉडल है जिसे लाखों लेबल्ड इवेंट पर ट्रेन किया गया है। यह मॉडल सभी 300+ रॉ सिग्नल, 35+ सर्वर-कंप्यूटेड स्मार्ट सिग्नल और कई व्युत्पन्न फ़ीचर्स पर विचार करता है: वेलोसिटी मेट्रिक्स (पिछले 5 मिनट, 1 घंटे और 24 घंटे में इस डिवाइस से कितने इवेंट आए), ऐतिहासिक व्यवहार पैटर्न और नेटवर्क रेप्युटेशन स्कोर।

मॉडल 0 से 100 के बीच एक रिस्क स्कोर देता है, साथ ही शीर्ष योगदान करने वाले कारक भी। उदाहरण के लिए, 85 के स्कोर के साथ "VPN detected", "incognito mode" और "high velocity — 5 मिनट में 47 इवेंट" जैसे कारक हो सकते हैं। यह स्पष्टता उन फ़्रॉड एनालिस्ट के लिए महत्वपूर्ण है जिन्हें यह समझने की ज़रूरत होती है कि किसी विशेष इवेंट को फ़्लैग क्यों किया गया।

स्टोरेज और क्वेरी लेयर

सभी इवेंट ClickHouse में पर्सिस्ट किए जाते हैं — यह एक कॉलमनार डेटाबेस है जो बड़े डेटासेट पर एनालिटिकल क्वेरी के लिए ऑप्टिमाइज़ है। ClickHouse हमारी राइट वॉल्यूम (50K इवेंट/सेकंड) को बिना किसी परेशानी के संभाल लेता है, और इसका कॉलमनार स्टोरेज अरबों पंक्तियों पर सब-सेकंड एनालिटिकल क्वेरी सक्षम करता है।

हम एक मल्टी-टियर रिटेंशन रणनीति का उपयोग करते हैं। हॉट डेटा (पिछले 7 दिन) को सब-100ms क्वेरी रिस्पॉन्स हेतु NVMe SSD पर रखा जाता है। वॉर्म डेटा (7-90 दिन) स्टैंडर्ड SSD पर रहता है। कोल्ड डेटा (90+ दिन) को कंप्रेस करके ऑब्जेक्ट स्टोरेज में ले जाया जाता है, जो क्वेरी योग्य तो रहता है पर अधिक लेटेंसी के साथ।

रीढ़ के रूप में Kafka

Apache Kafka पूरी पाइपलाइन को आपस में जोड़ता है। हर चरण Kafka टॉपिक्स से पढ़ता और उनमें लिखता है। इंजेशन लेयर रॉ इवेंट लिखती है। सिग्नल एक्सट्रैक्शन चरण रॉ इवेंट पढ़ता है और एक्सट्रैक्टेड इवेंट लिखता है। Smart Signals एनरिचमेंट चरण एक्सट्रैक्टेड इवेंट पढ़ता है और एनरिच्ड इवेंट लिखता है। रिस्क स्कोरिंग इंजन एनरिच्ड इवेंट पढ़ता है और स्कोर्ड इवेंट लिखता है।

यह आर्किटेक्चर कई लाभ देती है: चरणों को स्वतंत्र रूप से स्केल किया जा सकता है, एक चरण में विफलता दूसरों को प्रभावित नहीं करती, और हम डिबगिंग या रीप्रोसेसिंग के लिए किसी भी चरण से इवेंट रीप्ले कर सकते हैं। Kafka के consumer group हर चरण के भीतर समानांतर प्रोसेसिंग सक्षम करते हैं, और इसके exactly-once सिमैंटिक्स सुनिश्चित करते हैं कि कोई इवेंट दो बार प्रोसेस न हो या खो न जाए।

लेटेंसी बजट

हमारा एंड-टू-एंड लेटेंसी लक्ष्य उस क्षण से 10ms है जब समृद्ध सिग्नल पेलोड प्रोसेसिंग पाइपलाइन पर आता है, उस क्षण तक जब रिस्क स्कोर लौटाया जाता है। बजट इस प्रकार बँटता है: सिग्नल एक्सट्रैक्शन 1-2ms लेता है, Smart Signals एनरिचमेंट 3-4ms लेता है, रिस्क स्कोरिंग 2-3ms लेती है, और सीरियलाइज़ेशन तथा रिस्पॉन्स 1-2ms लेता है। हमारे को-लोकेटेड डिप्लॉयमेंट में चरणों के बीच Kafka हॉप 1ms से कम जोड़ता है।

50K इवेंट/सेकंड पर इस बजट को लगातार पूरा करने के लिए हर चरण पर सावधानीपूर्वक ऑप्टिमाइज़ेशन ज़रूरी है। हम प्री-अलोकेटेड मेमोरी पूल, ज़ीरो-कॉपी सीरियलाइज़ेशन और बैच्ड ClickHouse राइट का उपयोग करते हैं। रिस्क स्कोरिंग मॉडल को ONNX Runtime का उपयोग करके नेटिव कोड में कंपाइल किया जाता है, जिससे Python इंटरप्रेटर का ओवरहेड ख़त्म हो जाता है।

Mark ने बॉटलनेक ढूँढने से पहले दो हफ़्ते पाइपलाइन की प्रोफ़ाइलिंग में लगाए — हमारी डिस्ट्रीब्यूटेड लुकअप लेयर में एक अकेला mutex सभी goroutine में लुकअप को सीरियलाइज़ कर रहा था। sharded lock डिज़ाइन पर स्विच करने के बाद, p99 48ms से घटकर 9ms रह गई। कभी-कभी फ़िक्स शर्मनाक हद तक सरल होता है, बस उसे ढूँढ लेने भर की देर होती है।