Signal, 실시간 텔레메트리 플랫폼

문제

100개가 넘는 국가에서 수백만 명이 신원 인증을 진행했고, 그중 일부는 아무도 모르게 이탈했습니다. 벤더 연동이 깨져도 누구도 알아차리지 못했습니다. 흩어진 서버 로그를 사람이 직접 읽었고, 진단 한 번에 하루에서 사흘이 걸렸습니다. 그 하루하루가 온보딩을 끝내지 못한 실제 사용자였습니다.

접근 방식

• 작고 타입이 지정된 SDK. TypeScript 트래커 하나가 웹, 모바일, Mini Program의 모든 화면에서 같은 사용자 행동 데이터를 수집해, 어디서나 이벤트의 의미가 같도록 했습니다.
• 안전 밸브가 있는 스로틀링. SDK는 이벤트를 큐에 쌓아 3초마다 또는 10개가 모이면, 먼저 오는 쪽에 맞춰 전송합니다. 클릭마다 요청을 보내면 브라우저의 네트워크 스레드가 고갈되고, 너무 오래 쌓아 두면 탭을 닫을 때 이벤트를 잃습니다. 페이지를 떠날 때는 navigator.sendBeacon을 사용합니다.
• 검증하는 BFF. 배치는 Backend for Frontend로 들어가 TypeScript 정의에 맞춰 스키마를 검증하고, 타임스탬프가 타당한지 확인하고, 예상하지 못한 필드와 개인정보(PII)를 제거한 뒤, 세션 메타데이터와 백엔드의 판정(통과, 거절, 검토 대기)을 덧붙입니다. 이 판정을 UI에 표시된 내용과 비교하자 UI와 백엔드의 상태 불일치가 드러났습니다.
• Kafka, Flink, ClickHouse, Grafana. Kafka가 전 세계 트래픽 급증을 흡수하고, Flink가 이벤트를 실시간으로 처리하며, ClickHouse가 저장하고(컬럼형 저장소는 수십억 건의 고카디널리티 이벤트 집계에도 밀리초 단위로 응답하지만, 행 기반 저장소는 매우 느립니다), Grafana가 퍼널을 보여 줍니다.
• 조용한 장애 처리. 파이프라인이 내려가면 SDK는 localStorage에 이벤트를 최대 100개까지 보관하고, 수동형 서킷 브레이커가 전송을 멈춥니다. 상태 확인을 위해 서버를 호출하지 않고, 다음 성공 응답을 기다립니다.

결과

장애를 감지하는 시간이 24–72시간에서 5분 미만으로 줄었습니다. 벤더 단계 하나가 깨지면 수천 건의 온보딩이 실패하는 퍼널에서, 이는 포스트모템의 한 줄로 끝나느냐, 그날 아침에 고치느냐의 차이입니다.