Xây dựng pipeline phân tích gian lận theo thời gian thực
Phân tích kiến trúc: nạp 50K sự kiện/giây, làm giàu bằng smart signals và chấm điểm rủi ro trong dưới 10ms nhờ streaming engine của chúng tôi.
Xử lý 50.000 sự kiện fingerprint mỗi giây, làm giàu mỗi sự kiện bằng smart signals và trả về điểm rủi ro trong dưới 10 mili-giây đòi hỏi một kiến trúc streaming được thiết kế cẩn thận. Bài viết này đi qua toàn bộ pipeline của chúng tôi, từ khâu nạp dữ liệu đến quyết định.
Lớp nạp dữ liệu
Các sự kiện đến dưới dạng request HTTPS POST từ JavaScript agent của chúng tôi chạy trong trình duyệt của khách truy cập. Mỗi sự kiện chứa payload tín hiệu đã mã hóa — thường là 8-12KB dữ liệu nén bao phủ hơn 130 tín hiệu trình duyệt. Các edge server của chúng tôi kết thúc TLS, xác thực chữ ký của request và chuyển tiếp payload tới pipeline xử lý.
Chúng tôi dùng triển khai đa vùng, trong đó các edge server được đặt cùng vị trí với các node CDN của khách hàng. Điều này giữ vòng khứ hồi mạng dưới 20ms cho 95% request trên toàn cầu. Các edge server là dịch vụ Go không trạng thái chạy sau một load balancer, mở rộng theo chiều ngang dựa trên khối lượng request.
Trích xuất tín hiệu
Giai đoạn xử lý đầu tiên giải mã và phân tích payload tín hiệu. Mỗi tín hiệu được trích xuất, xác thực và định kiểu. Các hash canvas được kiểm chứng với những giá trị bất khả thi đã biết (dấu hiệu của việc chặn hoặc giả mạo canvas). Các tham số WebGL được kiểm chứng chéo để đảm bảo nhất quán. Các thuộc tính navigator được đối chiếu với những tổ hợp hợp lệ đã biết.
Giai đoạn này cũng thực hiện chuẩn hóa tín hiệu. Chuỗi user agent được phân tích thành các thành phần có cấu trúc (trình duyệt, phiên bản, hệ điều hành, thiết bị). Kích thước màn hình được chuẩn hóa để tính đến việc co giãn theo DPI. Độ lệch múi giờ được xác thực với dữ liệu định vị địa lý theo IP.
Làm giàu bằng Smart Signals
Các tín hiệu đã trích xuất sau đó được làm giàu bằng phân tích Smart Signals — lớp tình báo phía máy chủ của chúng tôi. Bao gồm phát hiện incognito (so sánh các mẫu tín hiệu với những chữ ký duyệt web riêng tư đã biết), phát hiện VPN (đối chiếu dữ liệu IP với tín hiệu múi giờ và locale), phát hiện giả mạo trình duyệt (nhận diện những mâu thuẫn cho thấy tín hiệu bị làm giả) và phát hiện máy ảo (nhận diện các cấu hình phần cứng gắn với VMware, VirtualBox và VM đám mây).
Mỗi smart signal được tính toán độc lập và cho ra cả một kết quả boolean lẫn một điểm tin cậy. Giai đoạn làm giàu bổ sung 24 tín hiệu vào mỗi sự kiện, mang lại một đánh giá mối đe dọa toàn diện vượt ra ngoài những gì chỉ riêng thu thập phía client có thể đạt được.
Engine chấm điểm rủi ro
Sự kiện đã làm giàu được chuyển tới engine chấm điểm rủi ro của chúng tôi — một mô hình cây quyết định gradient-boosted được huấn luyện trên hàng triệu sự kiện đã gán nhãn. Mô hình xét toàn bộ hơn 130 tín hiệu thô, 24 smart signals và một số đặc trưng phái sinh: các chỉ số vận tốc (bao nhiêu sự kiện từ thiết bị này trong 5 phút, 1 giờ và 24 giờ qua), các mẫu hành vi lịch sử và điểm uy tín mạng.
Mô hình xuất ra một điểm rủi ro từ 0 đến 100, kèm theo các yếu tố đóng góp hàng đầu. Ví dụ, điểm 85 có thể đi kèm các yếu tố như "phát hiện VPN", "chế độ incognito" và "vận tốc cao — 47 sự kiện trong 5 phút". Khả năng diễn giải này là then chốt với các chuyên viên phân tích gian lận cần hiểu vì sao một sự kiện cụ thể bị gắn cờ.
Lớp lưu trữ và truy vấn
Toàn bộ sự kiện được lưu bền vào ClickHouse — một cơ sở dữ liệu dạng cột được tối ưu cho các truy vấn phân tích trên tập dữ liệu lớn. ClickHouse xử lý khối lượng ghi của chúng tôi (50K sự kiện/giây) một cách nhẹ nhàng, và lưu trữ dạng cột của nó cho phép các truy vấn phân tích dưới một giây trên hàng tỷ dòng.
Chúng tôi dùng chiến lược lưu giữ nhiều tầng. Dữ liệu nóng (7 ngày gần nhất) được lưu trên SSD NVMe để phản hồi truy vấn dưới 100ms. Dữ liệu ấm (7-90 ngày) nằm trên SSD tiêu chuẩn. Dữ liệu lạnh (từ 90 ngày trở lên) được nén và chuyển sang object storage, vẫn truy vấn được nhưng độ trễ cao hơn.
Kafka làm xương sống
Apache Kafka gắn kết cả pipeline lại với nhau. Mỗi giai đoạn đều đọc từ và ghi vào các topic Kafka. Lớp nạp dữ liệu ghi các sự kiện thô. Giai đoạn trích xuất tín hiệu đọc các sự kiện thô và ghi các sự kiện đã trích xuất. Giai đoạn làm giàu Smart Signals đọc các sự kiện đã trích xuất và ghi các sự kiện đã làm giàu. Engine chấm điểm rủi ro đọc các sự kiện đã làm giàu và ghi các sự kiện đã chấm điểm.
Kiến trúc này mang lại nhiều lợi thế: các giai đoạn có thể mở rộng độc lập, lỗi ở một giai đoạn không ảnh hưởng tới giai đoạn khác, và chúng tôi có thể phát lại các sự kiện qua bất kỳ giai đoạn nào để gỡ lỗi hoặc xử lý lại. Các consumer group của Kafka cho phép xử lý song song trong mỗi giai đoạn, và ngữ nghĩa exactly-once của nó đảm bảo không sự kiện nào bị xử lý hai lần hoặc bị mất.
Ngân sách độ trễ
Mục tiêu độ trễ toàn tuyến của chúng tôi là 10ms, tính từ thời điểm payload tín hiệu đã làm giàu tới pipeline xử lý đến thời điểm điểm rủi ro được trả về. Ngân sách được chia như sau: trích xuất tín hiệu tốn 1-2ms, làm giàu Smart Signals tốn 3-4ms, chấm điểm rủi ro tốn 2-3ms, còn serialization và phản hồi tốn 1-2ms. Bước nhảy Kafka giữa các giai đoạn thêm dưới 1ms trong triển khai đặt cùng vị trí của chúng tôi.
Đáp ứng ngân sách này một cách ổn định ở mức 50K sự kiện/giây đòi hỏi tối ưu cẩn thận ở từng giai đoạn. Chúng tôi dùng các pool bộ nhớ cấp phát trước, serialization zero-copy và ghi ClickHouse theo lô. Mô hình chấm điểm rủi ro được biên dịch sang mã native bằng ONNX Runtime, loại bỏ chi phí của trình thông dịch Python.
Mark đã dành hai tuần profiling pipeline trước khi tìm ra nút thắt cổ chai trong lớp tra cứu phân tán của chúng tôi — một mutex duy nhất đang serialize các lượt tra cứu trên toàn bộ goroutine. Sau khi chuyển sang thiết kế khóa phân mảnh, p99 giảm từ 48ms xuống 9ms. Đôi khi cách sửa lại đơn giản đến mức ngượng ngùng một khi bạn tìm ra nó.