User segmentation 시스템 개발기

아이디어스가 마케팅 배너를 타겟 그룹에 맞춰 보여주기 위해 유저 세그멘테이션 시스템을 만든 기록이다. MSA로 DB가 분리된 상황에서 여러 서비스의 데이터를 조합해야 하는 문제를 Materialized view와 이벤트 기반 동기화로 풀었다. 결과는 평균 응답 3ms, p99 20ms 미만이다.

핵심 포인트

최근 주문일이나 로그인 시각 같은 기준으로 유저를 나누려면 여러 서비스의 데이터가 필요했다.
전통적인 방식으로 다른 서비스 DB를 직접 조회하면 레거시 메인 DB에 부하가 가고 장애가 전파되기 쉽다.
서로 다른 DB를 오가며 응답하면 적절한 지연 시간을 보장하기 어렵고 캐시 미스인 첫 요청이 특히 느리다.
Materialized view는 다른 서비스의 데이터를 필요한 형태로 비정규화해 복제본으로 갖는 패턴이다.
동기화는 Kafka 이벤트로 처리하며 이벤트 처리의 멱등성이 재처리의 전제가 된다.
초기 적재는 정적 색인, 이후 유지는 동적 색인이라는 검색 색인 방법론과 같은 구조로 봤다.

상세 정리

요구사항의 출발: 마케팅 팀이 전환율을 올리려 특정 기준으로 유저 세그먼트를 나누고 그룹별로 다른 배너를 보여주고자 했다.
세그멘테이션의 정의: 큰 유저 그룹을 기준에 따라 작은 집단으로 나누는 것으로, 행동과 선호를 이해해 경험을 개선하고 비즈니스 목표를 달성하는 것이 목적이다.
단순한 방법: 수십 개의 조건절과 필요한 테이블을 모두 조인한 쿼리 하나로도 구현할 수는 있다.
제약: 백엔드가 MSA로 전환 중이었고 일부 서비스의 DB는 이미 분리돼 있었다.
전통 방식의 단점 1: 마지막 주문일을 알려면 주문 테이블에 질의해야 하는데 레거시 메인 DB에 부하를 주고 장애 전파가 쉬운 구조가 된다.
전통 방식의 단점 2: 분리된 여러 DB를 조회해 응답하면 지연 시간을 보장하기 어렵고, 캐시를 붙여도 첫 요청은 오래 걸린다.
선택한 패턴: 여러 서비스의 데이터를 필요한 쪽이 원하는 형태로 비정규화해 동기화된 복제본으로 갖는 Materialized view를 도입했다. 읽기 모델을 분리해 저장하는 CQRS와 밀접하다.
패턴의 장점 1: 조회 성능이 월등히 빠르다.
패턴의 장점 2: 시스템 간 장애 전파가 막힌다. 주문 시스템에 장애가 나도 세그먼트 기능은 정상 동작한다.
패턴의 단점: 필드를 추가할 때마다 전체를 다시 동기화해야 하고, 동기화 작업이 추가되며 깨질 위험이 있고, 비동기라 완전한 실시간성은 없다.
판단: 단점이 적지 않지만 앞의 두 장점 때문에 채택했다.
동기화 구조: 레거시에 있는 주문 시스템이 결제 완료 이벤트를 Kafka로 발행하면, 관심 있는 마이크로서비스가 받아 각자의 로직을 수행하고 마케팅 서비스는 뷰를 갱신한다.
작업 순서 1: 집계 지점 코드에 동기화용 이벤트 발행 로직을 넣는다. 로그인 시 로그인 이벤트를, 결제 완료 시 체크아웃 이벤트를 발행한다.
작업 순서 2: 먼저 동적 색인용 코드를 개발해 배포한다. 이벤트를 받을 때마다 뷰를 계속 갱신하는 부분이다.
작업 순서 3: 이후 정적 색인 코드를 실행해 기존 데이터 소스의 모든 데이터를 뷰로 옮긴다.
멱등성이 필요한 이유: 같은 이벤트를 여러 번 받아도 저장되는 상태가 같아야 정적 색인과 장애 시 재처리가 안전해진다.
유실 대응: 이벤트가 유실되면 추가로 발행하면 되고, 수신 처리에 문제가 있었다면 Kafka 오프셋을 특정 시점으로 돌려 재생하면 된다.
조회 로직: 세그먼트를 물으면 먼저 캐시를 보고, 비어 있으면 유저 활동 뷰를 조회해 분류 조건에 따라 세그먼트 목록을 만들어 캐시에 넣는다.
캐시 무효화: 유저 활동에 갱신이 생기면 그 유저의 캐시를 지워 다음 요청에 다시 계산되게 한다.
결과: 평균 응답이 3ms, p99가 20ms 미만이었다.
저자의 단서: 이 정도 응답속도가 모든 서비스에 필요하지는 않으니, 성능과 장애 내성이 중요할 때 트레이드오프를 따져보고 도입하라고 권한다.