포스트

무신사 「Kafka와 Strimzi를 이용하여 6개의 도메인을 하나의 도메인으로 합쳐보았습니다」 리뷰 — 배치 없이 CDC와 Kafka Streams로 옮긴 결정, 그리고 통합 모델이 원본과 같다는 것을 누가 확인하는가

Tech Blog Review
게시
By August
좋아요 조회 11 분 읽는 시간

엔지니어링 요약

Problem

무신사 커뮤니티팀은 6개 콘텐츠 도메인을 하나의 통합 모델로 옮겨야 했다. 옮기는 동안 기존 화면이 전부 동작해야 하고(Strangler Fig), Polyglot MSA라 도메인 이벤트 발행 코드를 모든 서비스에 심는 것은 불가능에 가까웠다.

Decision

원문의 결정(Lambda 대신 Kappa에 가까운 구조: Debezium CDC → Kafka Streams KTable 조인·역정규화 → Sink)과 Strimzi로 Kafka Connect를 GitOps로 관리한 이유, 그리고 데이터 재생(replay) 세 방법을 옮기고, MCP의 Shadow Release와 네이버페이 전환 글의 이중 발행 검증기에 대조했다.

Result

옮기는 방법은 상세한데 옮긴 결과가 맞는지 확인하는 방법이 없다는 것이 이 글의 빈칸이다. 네이버 글은 기존·신규 메시지를 두 벌로 발행해 대조하는 검증기를 뒀고, MCP에서는 신구 조회를 나란히 비교했다. 무신사 글에는 통합 모델이 6개 원본과 일치하는지를 세는 장치가 적혀 있지 않다. 반대로 원문이 잘 적은 것은 재생의 대가다. 실시간 트래픽을 받으면서 전체를 다시 옮기려면 Consumer Lag이 안 생기는 속도로 조절해야 했다는 문장이 그것이다.

원문: Kafka와 Strimzi를 이용하여 6개의 도메인을 하나의 도메인으로 합쳐보았습니다 — MUSINSA techblog, 조유신(커뮤니티개발팀), 2024-06-27

같은 날 리뷰한 네이버페이 전환 글과 나란히 읽으면 좋은 글이다. 둘 다 오래된 시스템을 멈추지 않고 새 구조로 옮기는 이야기이고, 둘 다 CDC를 쓴다. 다른 것은 네이버 글이 “옮긴 것이 맞는지 어떻게 확인했는가”에 절반을 쓴 반면 무신사 글은 “어떻게 옮겼는가”에 전부를 쓴다는 점이다. 그 차이가 이 리뷰의 축이다.

원문이 말하는 것

스냅·좋아요·인플루언서 마케팅 등 6개 콘텐츠 도메인이 각기 다른 형태로 저장돼 있어 필터·추천 같은 기능을 통합 모델 없이 만들기 어려웠다. API에서 추상화하는 것도 가능하지만 데이터가 흩어진 채로는 한계가 있어 데이터 통합을 택했다.

한 번에(cut-over) 옮길지 점진적으로 옮길지에서 Strangler Fig를 골랐다. 옮기는 중에도 이전 도메인 화면이 전부 동작해야 하므로, DML이나 배치가 아니라 준실시간 마이그레이션 파이프라인을 만들어 통합 모델을 등장시키고 제공 영역을 넓혀 간다.

파이프라인 구조는 Batch, Lambda(배치 + 스트림), Kappa(스트림만) 중에서 골랐다. 처음엔 경험이 많은 Lambda를 하려 했지만, 6개 도메인의 루트·파생 테이블이 매우 많고 Polyglot MSA라 모든 변경에 도메인 이벤트 발행 코드를 심는 것이 불가능에 가까워 CDC로 갔다. Kafka Connect 클러스터를 세우고 루트·파생 테이블을 전부 토픽에 넣고 나니 배치 레이어가 RDBMS를 다시 읽는 것이 낭비로 느껴져, Kafka Streams로 CDC 토픽을 역정규화하는 쪽으로 갔고 결과적으로 Kappa에 가까워졌다.

Kafka Connect는 AWS DMS(토픽 설정·SMT 제약), MSK Connect(Terraform 관리, 설정 변경 시 태스크 수동 제거)를 제치고 Strimzi Operator로 갔다. Kubernetes YAML로 커넥터를 선언하고 재배포로 재생성할 수 있어서다. Debezium MySQL 커넥터 설정에서 눈에 띄는 것은 tasksMax: 1(WAL 처리), snapshot.locking.mode: none, ExtractNewRecordState SMT, 그리고 CDC 토픽을 SSOT로 쓰기 위해 cleanup.policy: compact로 만든 것이다.

Streams 쪽은 소스 토픽들을 KTable로 만들고, 변경 로그를 Deduplication Processor로 같은 키의 중복을 제거한 뒤 KTable들과 조인해 통합 모델을 만들어 Sink한다. 코파티셔닝을 위해 CDC 토픽을 한 번 더 다른 토픽으로 Sink해 파티션 수를 유동적으로 가져갔다.

데이터 재생이 마지막 절이다. 요구사항이 바뀌면 처음부터 다시 옮겨야 하는데, 방법 셋(Debezium Signal의 incremental snapshot, Streams 앱 오프셋 초기화 또는 application ID 변경, dedup 이후 토픽에 루트 스트림 재발행)을 전부 구현했다. 실시간 트래픽을 받는 서비스라 Streams 앱과 Sink의 Consumer Lag이 안 생기는 속도로 조절해 전체를 다시 옮겼다. 파이프라인을 두 버전으로 유지하는 방법은 Sink RDBMS의 한계와 코드 이원화 때문에 보류했다.

같은 곳: 이벤트 발행 코드를 심을 수 없을 때 CDC

parity-pay는 CDC 대신 Outbox를 골랐는데(5편), 그 선택이 가능했던 조건이 원문에서 드러난다. Outbox는 업무 트랜잭션을 우리가 쓰고 있을 때 가능하다. 같은 트랜잭션에 이벤트를 적어야 하기 때문이다. 원문의 조건은 6개 도메인이 여러 언어·서비스로 흩어져 있고 그 코드에 발행을 심을 수 없다는 것이다. 그 조건에서 Outbox는 선택지가 아니고 CDC가 유일하다. 카카오 CDC 글도 10년 된 레거시라 같은 조건이었다. Outbox와 CDC의 선택은 지연이나 운영 비용보다 먼저 원본 트랜잭션을 우리가 통제하는가로 갈린다는 것을 세 글을 읽고 정리하게 됐다.

원문이 답하지 않는 것: 통합 모델이 맞는가

옮기는 방법은 커넥터 YAML까지 상세하다. 그런데 옮긴 결과가 6개 원본과 같은지를 누가 어떻게 확인하는지가 없다.

이것이 네이버페이 글과의 차이다. 네이버는 기존·신규 메시지를 두 벌로 발행해 스펙 검증기(내용 비교)와 발행 검증기(집합 비교)로 실시간 대조했고, 검증기가 잡은 불일치 유형까지 적었다. MCP의 Shadow Release도 신구 조회를 나란히 비교했다. 무신사의 통합 모델은 6개 원본의 KTable 조인이므로 어긋날 곳이 많다. 조인 키가 없는 행, 파생 테이블이 먼저 바뀌고 루트가 나중에 바뀌는 순서, Deduplication이 같은 키의 서로 다른 변경을 하나로 합치는 경우. 이것들이 실제로 몇 건이었고 어떻게 잡았는지가 있어야 “옮겼다”가 “맞게 옮겼다”가 된다.

원문의 데이터 재생 절이 그 답의 일부일 수 있다. 어긋남이 발견되면 재생으로 다시 만든다. parity-pay 6편에서 잔액 스냅샷이 원장과 어긋나면 원장에서 재구축하되 어긋남을 먼저 세고, 원인을 조사한 뒤에 재구축한다고 적었다. 재생은 고치는 장치이고 세는 장치는 따로 있어야 한다. 원문에는 고치는 장치만 있다.

원문이 잘 적은 것: 재생의 대가

“실시간 트래픽을 받으면서 전체를 재마이그레이션하려면 Consumer Lag이 안 생기는 속도로 조절해야 했다”는 문장이 이 글에서 가장 실질적인 운영 지식이다. 재생은 곧 부하이고, 그 부하가 실시간 처리를 밀어내면 재생하는 동안 서비스가 틀린다. parity-pay 5편에서 적체가 한 곳에 몰리면 처리량이 110배 떨어지는 것을 쟀는데, 재생은 적체를 일부러 만드는 일이다. 속도 조절이 필요하다는 것을 원문이 명시했고, 어떤 속도였는지(초당 몇 건, 전체 재생에 몇 시간)는 없다.

“Source의 실제 데이터 크기보다 파이프라인에서 쓰는 데이터 크기가 더 크다”는 부수 관찰도 좋다. KTable의 changelog, 코파티셔닝을 위한 재발행 토픽, compact 토픽이 각각 원본의 복사본이다. Kappa는 배치 레이어를 없애는 대신 Kafka 안에 원본의 복사본을 여럿 둔다.

가져갈 것

  • Outbox와 CDC의 선택은 원본 트랜잭션을 우리가 통제하는가로 먼저 갈린다. 통제하지 못하면 CDC가 유일하다.
  • 옮기는 방법과 맞는지 확인하는 방법은 다른 일이다. 확인하는 장치가 없으면 “옮겼다”까지다.
  • 재생은 고치는 장치다. 세는 장치가 따로 있어야 하고, 재생 자체가 부하라 속도 조절이 설계에 들어간다.
  • Kappa는 배치를 없애는 대신 원본의 복사본을 여럿 만든다. 그 크기가 원본보다 크다.
시리즈

빅테크 기술 블로그 리뷰

31편 중 26편

이전 시리즈 글 네이버 D2 「@RequestCache: HTTP 요청 범위 캐싱을 위한 커스텀 애너테이션 개발기」 리뷰 — 캐시의 수명을 '요청 하나'로 맞추면 TTL 고민이 사라진다, 그리고 @RequestScope가 안 되는 이유 다음 시리즈 글 쿠팡 「대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략」 리뷰 — 캐시 두 겹과 '분 단위 99.99% 동일'이라는 문장, 그리고 그 0.01%를 누가 어떻게 세는가
  1. 1 카카오 「실시간 메시징 시스템 개발기」(3편) 리뷰 — Redis에 몰린 부하를 서버로 옮기고, 그 서버를 pprof로 세 번 깎은 이야기
  2. 2 카카오 「추가배포 없이 API의 case 통일시키기」 리뷰 — 받는 쪽이 자기 케이스에 맞춰 알아서 읽게 하면 배포 순서가 사라진다
  3. 3 카카오 「MySQL DATETIME, TIMESTAMP 데이터 타입에 대한 분석」 리뷰 — 바이트 단위 저장 구조부터 아직 안 고쳐진 Y2K38까지
  4. 4 네이버 D2 「6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기」 리뷰 — 복제·검증·복구를 셋으로 나누고, 옛 도구와 새 도구를 서로 모르게 같이 돌린 전환
  5. 5 카카오 「MySQL ALTER DDL 수행 방식에 대한 이해」 리뷰 — Copy·In-Place·Instant는 '무엇을 복사하느냐'보다 '언제 Exclusive 메타 락을 잡느냐'로 구분된다
  6. 6 카카오 「MySQL Orchestrator 기반의 새로운 HA 표준 개발기」 리뷰 — 10년 멈춘 Perl 도구를 떠나 Raft 클러스터로, 그리고 slave_net_timeout 한 줄
  7. 7 카카오 「MySQL Ver. 8.0 New Feature: Instant DDL Algorithm에 대한 이해」 리뷰 — 컬럼을 0.01초에 추가하는 대가는 '읽을 때마다 버전을 대조하는 것'이다
  8. 8 네이버 D2 「CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제」 리뷰 — 같은 SQL인데 바인딩 타입이 다르면 Oracle은 다른 쿼리로 본다
  9. 9 카카오 「MySQL InnoDB Log에 대한 이해 - (1)」 리뷰 — 트랜잭션 하나가 어떻게 MTR 여러 개로 쪼개져 Redo Log Buffer에 들어가는가
  10. 10 카카오 「PostgreSQL to ES: Kafka Connect CDC 파이프라인」 1·2편 리뷰 — 변경이 없어서 디스크가 차고, LSN이 사라져서 스냅샷을 다시 짜야 했던 CDC의 실제 운영 비용
  11. 11 LINE 「기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다」 리뷰 — 블랙박스는 입력과 출력만 정의하면 통계로 같음을 증명할 수 있다
  12. 12 뱅크샐러드 「게임을 만들 때 데이터 정합성을 유지하는 법 (feat. 낙관적 락)」 리뷰 — 같은 WHERE version 조건인데, 충돌한 요청을 어떻게 하는가에서 갈리는 두 설계
  13. 13 우아한형제들 「Spring Batch와 Querydsl」 리뷰 — offset을 버린 Reader가 21분을 4분으로 만든 이유, 그리고 그 Reader가 답하지 않는 두 가지
  14. 14 네이버 D2 「테스트는 어떻게 좋은 코드를 만드는가(feat. 험블 객체 패턴)」 리뷰 — 목이 많아지는 것은 테스트의 문제가 아니라 설계의 신호
  15. 15 당근 「QR을 찍으면 무슨 일이 벌어질까? 당근페이 현장 결제의 모든 것」 리뷰 — 카드망을 빌려 7주 만에 낸 결제와, 그 글이 다루지 않은 승인 응답이 사라지는 순간
  16. 16 네이버 D2 「스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기」 리뷰 — 두 DB에 동시에 쓰되 한쪽 실패는 무시하고, 읽기 트래픽을 복제해 성능을 재고, 6개월간 불일치를 0으로 만든 과정
  17. 17 야놀자 「RESTful API validation 자동화 하기」 리뷰 — 인터페이스 하나에서 검증·문서·타입을 뽑는 이유, 그리고 자동화가 없으면 누락이 필연이라는 문장
  18. 18 카카오 「MySQL Json 데이터 타입의 저장 구조와 성능 비교」 리뷰 — 통째로 넣고 통째로 꺼내면 TEXT, 키로 파고들면 JSON
  19. 19 LINE 「도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까?」 리뷰 — 사용자를 모르는 채팅 플랫폼, 웹으로 만든 클라이언트, SOFT STOP으로 갈아 끼우는 챗봇 시나리오
  20. 20 카카오페이 「MSA 환경에서 네트워크 예외를 잘 다루는 방법」 리뷰 — Unknown을 타입으로 만든 글과, Unknown을 상태로 저장한 프로젝트가 갈리는 지점
  21. 21 카카오 「메시징 서버의 스트레스 테스트 노하우와 AI가 덜어 준 부분」 리뷰 — 지표를 네 층으로 내려가 읽는 법, 그리고 LLM에게 맡긴 것과 맡기지 못한 것
  22. 22 네이버 D2 「일 3,000만 건의 네이버페이 주문 메시지를 처리하는 Kafka 시스템의 무중단 전환 사례」 리뷰 — 두 벌로 발행해 대조한 검증기와, 발행 제어 키를 파티션 키와 같게 둔 이유
  23. 23 카카오 「잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정」 리뷰 — 벤더가 8ms 만에 리포트를 보냈고, 우리는 101ms짜리 트랜잭션 안에 있었다
  24. 24 컬리 「컬리의 입고 시스템이 외부 인입 데이터를 안전하게 동기화하는 방법」 리뷰 — 145회 재시도가 맞는 도메인과 재시도를 금지한 도메인, 그리고 발행부와 수신부가 각자 책임지는 구조
  25. 25 네이버 D2 「@RequestCache: HTTP 요청 범위 캐싱을 위한 커스텀 애너테이션 개발기」 리뷰 — 캐시의 수명을 '요청 하나'로 맞추면 TTL 고민이 사라진다, 그리고 @RequestScope가 안 되는 이유
  26. 26 무신사 「Kafka와 Strimzi를 이용하여 6개의 도메인을 하나의 도메인으로 합쳐보았습니다」 리뷰 — 배치 없이 CDC와 Kafka Streams로 옮긴 결정, 그리고 통합 모델이 원본과 같다는 것을 누가 확인하는가
  27. 27 쿠팡 「대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략」 리뷰 — 캐시 두 겹과 '분 단위 99.99% 동일'이라는 문장, 그리고 그 0.01%를 누가 어떻게 세는가
  28. 28 LINE 「LINE에서 Kafka를 사용하는 방법 - 1편」 리뷰 — 초당 4GB 클러스터가 바이트가 아니라 요청 수를 제한하는 이유, 그리고 2,000틱짜리 파이프라인에서 같은 것을 본 기록
  29. 29 카카오 「MySQL 인증 플러그인 caching_sha2_password에 대한 이해」 리뷰 — 비밀번호 해시가 바뀌는 것보다 '평문이 서버까지 가야 한다'는 점이 전환의 진짜 비용
  30. 30 LINE 「초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기」 리뷰 — 인터셉터와 시리얼라이저만으로 브로커에 평문을 남기지 않는 법
  31. 31 카카오뱅크 「하루 N억 건의 알림 시스템 구축기 (1)」 리뷰 — P99의 80%가 대기였다는 진단, Age 기반 Work-Stealing, 그리고 큐를 나누는 순간 순서를 잃는 문제
TechBlog, Musinsa
Tech Blog Review Musinsa CDC Kafka Streams Debezium Strimzi Strangler Fig Data Migration
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.

댓글

아직 댓글이 없습니다