CDC (Change Data Capture) — 이벤트 기반 동기화

이전 글

조회수 Redis INCR + Write-Behind 배치 flush 전환에서 GET 요청의 DB UPDATE 충돌을 Redis INCR로 해결했습니다. 이 글은 PostService의 dual-write 구조를 이벤트 기반으로 전환하고, 최종적으로 Debezium + Kafka CDC로 모든 DB 변경을 캡처하는 과정입니다.

이전 글 요약

App 스케일아웃에서 CPU 병목이 해소되었다.

인프라는 안정적이다. 하지만 애플리케이션 아키텍처에 구조적 문제가 남아 있다.

1. 정상 상태 인식

현재 아키텍처 — PostService의 dual-write 구조

PostService가 MySQL에 쓰기를 하면서 동시에 여러 Read Model을 직접 갱신하고 있다:

// PostService.createPost() — 현재 구조
@Transactional
public Post createPost(String title, String content, Long authorId, Long categoryId) {
    Post saved = postRepository.save(post);    // 1. MySQL 쓰기
    indexSafely(saved);                        // 2. Lucene 인덱스 직접 호출
    return saved;
}

// PostService.updatePost()
@Transactional
public void updatePost(Long id, String title, String content, Long userId) {
    post.update(title, content);
    indexSafely(post);                                              // 2. Lucene
    tieredCacheService.evict(postDetailL1Cache, "post:" + id);      // 3. 캐시 무효화
}

// PostService.deletePost()
@Transactional
public void deletePost(Long id, Long userId) {
    postRepository.delete(post);
    deleteFromIndexSafely(id);                                      // 2. Lucene
    tieredCacheService.evict(postDetailL1Cache, "post:" + id);      // 3. 캐시 무효화
}

현재 Read Model 동기화 현황

의존 관계 그래프

2. 문제 상황 인식

문제 1: Dual-Write 불일치 — DB 성공 + Lucene 실패 = 영구 불일치

private void indexSafely(Post post) {
    try {
        luceneIndexService.indexPost(post);
    } catch (Exception e) {
        log.error("Lucene 인덱스 실패: {}", post.getId(), e);
        // DB에는 이미 커밋됨 — Lucene에는 없음
        // 재시도 없음, DLQ 없음, 알림 없음
        // → 영구 불일치
    }
}

현재는 try-catch + log.error()로 처리한다. MySQL 트랜잭션이 커밋되면 데이터는 DB에 있지만, Lucene 인덱스에는 없다. 이 불일치를 감지하거나 복구하는 메커니즘이 없다.

실측: 부하 테스트 튜닝(200 VU)에서 Lucene indexing이 IOException으로 실패한 케이스가 관찰되었다. CPU 포화 상태에서 MMapDirectory I/O 타임아웃 발생.

문제 2: PostService 강결합 — 6개 의존성

PostService가 알아야 하는 것:

새로운 Read Model(예: Elasticsearch, 추천 시스템, 알림)을 추가할 때마다 PostService를 수정해야 한다. OCP(Open-Closed Principle) 위반.

문제 3: 불완전한 캐시 무효화

게시글을 삭제해도 검색 결과에 최대 30분간 계속 노출된다(검색 결과 캐시 TTL 만료까지). 삭제된 게시글 링크를 클릭하면 404 — 사용자 경험 저하.

문제 4: Lucene 랭킹 필드 stale

Lucene 인덱스에 FeatureField("features", "viewCount")와 FeatureField("features", "likeCount")가 저장되어 BM25 + 부스팅 랭킹에 사용된다. 하지만:

• 조회수: Redis INCR → 30초 배치 DB flush → Lucene에는 반영 안 됨
• 좋아요: DB UPDATE → Lucene에는 반영 안 됨

검색 결과 랭킹이 stale 데이터 기반. 인기 게시글이 검색 상위에 올라오지 않을 수 있다.

3. 문제 분석 — 왜 dual-write가 구조적으로 위험한가

Dual-Write의 본질적 문제

두 개 이상의 데이터 저장소에 애플리케이션이 직접 쓰기를 하면, 분산 트랜잭션 없이는 원자성을 보장할 수 없다. Martin Kleppmann(“Designing Data-Intensive Applications” 저자)은 이를 “dual-write problem”으로 명명하고, race condition과 partial failure 두 가지 근본 문제를 제시한다.

“Two clients may write to System A and System B in different orders. Without a single source of ordering, the systems end up permanently inconsistent with no indication that anything is wrong.”

해결책으로 “Write to a single authoritative system (the database), then use CDC (log extraction) to propagate changes”를 권장한다. Confluent도 “Issues caused by this problem are extremely difficult to spot, and you don’t get any red flags indicating that something has become inconsistent”라고 경고한다.

이 문제를 해결하는 업계 표준 패턴:

이 프로젝트에 적합한 접근: 점진적 진화

로드맵에서 설계한 3-step 진화:

단, Kafka + Debezium은 최소 5~8G RAM이 필요하여 현재 Free Tier에서는 불가. Spring Event부터 시작하여 구조적 개선을 먼저 달성한다.

4. 대안 검토

방안 1: Spring ApplicationEvent + @TransactionalEventListener

// PostService — 직접 호출 제거, 이벤트 발행으로 전환
@Transactional
public Post createPost(...) {
    Post saved = postRepository.save(post);
    // indexSafely(saved);  ← 제거
    eventPublisher.publishEvent(new PostEvent.Created(saved.getId(), saved));
    return saved;
}

// 별도 EventHandler — Lucene 인덱스 갱신
@Component
public class LuceneIndexEventHandler {
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void onPostCreated(PostEvent.Created event) {
        luceneIndexService.indexPost(event.post());
    }
}

// 별도 EventHandler — 캐시 무효화
// [주의] AFTER_COMMIT 리스너에서 DB 작업이 필요하면 반드시 REQUIRES_NEW 사용
@Component
public class CacheInvalidationEventHandler {
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void onPostUpdated(PostEvent.Updated event) {
        tieredCacheService.evict(postDetailL1Cache, "post:" + event.postId());
    }
}

멀티 인스턴스 제약: 스케일아웃에서 이미 App을 2대로 확장했다. Spring ApplicationEvent는 JVM 내부 이벤트이므로, App 1에서 게시글을 생성하면 App 1의 Lucene만 갱신되고 App 2의 Lucene은 갱신되지 않는다. 이 부분은 기존 5분 주기 rsync가 커버한다.

Spring Modulith 활용: 이 프로젝트는 Spring Modulith 2.0.2를 사용 중이다. @ApplicationModuleListener는 @TransactionalEventListener(AFTER_COMMIT) + 이벤트 발행 로그(Event Publication Log)를 제공하여, 리스너 실패 시 자동 재시도가 가능하다.

AFTER_COMMIT 리스너의 알려진 함정: 리스너에서 예외가 발생해도 트랜잭션은 이미 커밋되었으므로 롤백되지 않는다. Spring 6.x에서 @TransactionalEventListener의 기본 동작이 동기(같은 스레드)이므로, 리스너가 느리면 HTTP 응답도 지연된다.

방안 2: Transactional Outbox Pattern

// PostService — 이벤트를 outbox 테이블에 함께 저장
@Transactional
public Post createPost(...) {
    Post saved = postRepository.save(post);
    outboxRepository.save(new OutboxEvent("POST_CREATED", saved.getId(), toJson(saved)));
    return saved;
}

// OutboxPoller — 별도 스케줄러가 outbox 테이블 폴링 → 이벤트 발행
// SKIP LOCKED: 멀티 인스턴스에서 같은 이벤트 중복 처리 방지
@Scheduled(fixedRate = 1000)
@Transactional
public void pollAndPublish() {
    List<OutboxEvent> events = outboxRepository.findUnpublishedForUpdate(BATCH_SIZE);
    for (OutboxEvent event : events) {
        try {
            applicationEventPublisher.publishEvent(toDomainEvent(event));
            event.markPublished();
        } catch (Exception e) {
            event.incrementRetryCount();
            log.error("Outbox event 처리 실패 (retry {}): {}",
                event.getRetryCount(), event.getId(), e);
        }
    }
}

방안 3: Debezium + Kafka CDC

Debezium 프로덕션 알려진 한계: Connector가 단일 태스크(단일 스레드)로 binlog를 순차 처리하므로, 대량 DML 시 lag이 누적될 수 있다. 극단적인 경우 15~20분까지 보고됨. 내장 관찰성(Observability)이 없어 별도 Prometheus + Grafana 필요. DDL 발생 시 Connector 재시작이 필요한 경우가 있다.

선택: Spring Event → Outbox → CDC 순서

현업 사례

Outbox + CDC 조합: 업계 best practice는 Outbox 테이블에 이벤트를 저장한 뒤, 폴링이 아닌 CDC(Debezium)로 outbox 테이블의 변경을 감지하여 Kafka에 전달하는 것이다. 이 프로젝트에서는 폴링 Outbox → CDC Outbox로 자연스럽게 진화할 수 있다.

비용 분석

운영 복잡도 정당화 — “일 200건에 Kafka가 필요한가?”

이 질문에 대한 답은 “Kafka를 운영하는 비용”과 “dual-write 불일치를 수동으로 복구하는 비용”의 비교다.

Kafka 운영의 핵심 비용은 인프라 자체보다 운영 진입 비용과 장애 대응 복잡도에 가깝습니다. 이 프로젝트에서는 KRaft 단일 브로커 + @ConditionalOnProperty fallback 구조로 운영 부담을 최소화했습니다. Kafka가 죽어도 서비스는 @ApplicationModuleListener 수준으로 자동 전환되어 서비스 중단 없이 동작합니다. Kafka는 “평시의 정확성 보장”이고, fallback은 “장애 시 서비스 연속성 보장”입니다.

”Elasticsearch를 쓰면 CDC 자체가 불필요하지 않나?”

Elasticsearch를 도입해도 MySQL → ES 동기화 문제는 동일하다. ES 공식 문서에서도 Logstash JDBC Input이나 Debezium을 사용한 CDC를 권장한다. 즉 ES를 써도 CDC 파이프라인은 필요하고, 인프라 비용은 오히려 더 높다. Embedded Lucene + CDC는 같은 정확성을 훨씬 적은 비용으로 달성하는 선택이다.

5. Spring Event 전환 구현

도메인 이벤트 설계

// sealed interface로 타입 안전성 보장
public sealed interface PostEvent {
    Long postId();

    record Created(Long postId, Post post) implements PostEvent {}
    record Updated(Long postId, Post post) implements PostEvent {}
    record Deleted(Long postId) implements PostEvent {}
    record LikeChanged(Long postId) implements PostEvent {}
}

EventHandler 분리

Consumer 멱등성 (Idempotency)

설계 원칙: 이벤트 핸들러는 가능하면 SET(절대값 덮어쓰기) 방식으로 구현하고, INCREMENT(상대값 증가) 방식은 피한다.

Trade-off: 동기 → 비동기 전환의 일시적 불일치 window

이 window는 수 ms 수준이며, 커뮤니티 게시판에서 허용 가능하다.

코드 변경 Before/After

PostService 의존성 변화

캐시 무효화 개선

테스트

기존 109개에서 Lucene 직접 호출 테스트 3개 제거 + EventHandler 테스트 11개 추가 = 117개 전체 통과.

새로 추가된 파일

6. k6 부하 테스트 — @TransactionalEventListener (100 VU, 20분)

Overview

읽기 vs 쓰기 분리 분석

읽기 경로는 스케일아웃 대비 동등하거나 개선:

에러율 12.6%의 원인은 쓰기 타임아웃. 읽기 경로는 이벤트 전환의 영향 없음.

쓰기 병목 분석 — HikariCP Primary Pool 고갈

Spring의 AbstractPlatformTransactionManager.processCommit() 소스코드 기준으로, afterCommit() 콜백은 커넥션이 풀에 반환되기 전에 실행된다:

processCommit() {
    doCommit()                    // 1. DB 커밋
    triggerAfterCommit()          // 2. AFTER_COMMIT 리스너 실행 ← 커넥션 아직 점유!
    cleanupAfterCompletion()     // 3. 커넥션 반환 ← 여기서야 반환
}

Lucene 인덱싱(~100ms)과 캐시 무효화가 끝날 때까지 DB 커넥션이 반환되지 않아, Primary pool(5개)이 고갈되고 후속 쓰기 요청이 4~5초간 커넥션 대기.

Grafana 대시보드

L1+L2 합산 77% 히트. 스케일아웃(81%)과 유사.

총 요청 수: 30,553
에러율: 12.70%

읽기:  검색 28ms / 자동완성 8ms / 목록 14ms / 상세 19ms
쓰기:  평균 5,315ms / P95 13,909ms (HikariCP primary pool 고갈)

7. @ApplicationModuleListener 전환 — 비동기 이벤트 + Event Publication Log

@TransactionalEventListener(AFTER_COMMIT) → @ApplicationModuleListener로 전환. Spring Modulith가 내부적으로 @Async + @TransactionalEventListener(AFTER_COMMIT) + @Transactional(REQUIRES_NEW)를 결합하여 제공한다.

k6 결과 — @ApplicationModuleListener 전환 후 (100 VU, 20분)

쓰기 병목 완전 해소. 읽기 성능은 동등 유지.

HikariCP — 커넥션 대기 해소

• 커넥션 획득 시간: 4~5초 → ~1ms (즉시 획득)
• DB 커밋 즉시 커넥션 반환 → Lucene 인덱싱은 별도 스레드에서 독립 실행

Grafana 대시보드

L1+L2 합산 79% 히트. 동등.

총 요청 수: 42,007
에러율: 0.00%

읽기:  검색 27ms / 자동완성 9ms / 목록 17ms / 상세 23ms
쓰기:  평균 33ms / P95 98ms

Spring Event 전환 최종 종합

Event Publication Log 재시도 검증

Spring Modulith의 Event Publication Log가 실제로 재시도에 성공하는지 검증했다.

알려진 한계: (1) 이벤트 클래스의 FQCN이 DB에 저장되므로, 클래스를 리네임/이동하면 기존 미완료 이벤트의 재시도가 ClassNotFoundException으로 실패한다. 이벤트 클래스 변경 전 미완료 이벤트를 반드시 소진해야 한다. (2) GitHub Issue #835에서 런타임 중 리스너가 호출되지 않는 케이스가 보고되었다. 이 프로젝트에서는 재현되지 않았지만, Kafka CDC로 진화하는 추가적인 동기가 된다. (3) 멀티 인스턴스에서 재시작 시 미완료 이벤트 재처리가 인스턴스별로 독립적이므로 중복 처리 가능 — Consumer 멱등성이 전제조건이다.

8. Debezium + Kafka CDC

Outbox를 별도로 구현하지 않은 이유

로드맵에서는 Spring Event → Outbox → CDC를 계획했지만, Outbox를 건너뛰고 @ApplicationModuleListener에서 바로 Kafka CDC로 진화했다. Spring Modulith의 @ApplicationModuleListener가 Outbox의 핵심 기능을 프레임워크 수준에서 이미 제공하기 때문이다.

왜 이렇게 진화했는가

Kafka + CDC가 해결하는 구조적 한계

”직접 SQL 미감지”가 현실에서 발생하는 시나리오

핵심은 “PostService를 통하지 않는 모든 변경 경로를 원천 차단할 수 있는가?”이다. CDC(binlog 기반)는 이 문제를 데이터베이스 레벨에서 해결한다.

Redis Streams를 쓰지 않는 이유

인프라 구성

KRaft 단일 브로커의 한계와 방어 전략: Confluent 공식 문서에서 KRaft combined mode(브로커 + 컨트롤러 단일 프로세스)는 개발/테스트 전용이라고 명시하며, 프로덕션에서는 최소 3개 컨트롤러를 권장한다. 현재 단일 브로커 구성에서 Kafka가 죽으면 CDC 파이프라인이 멈추지만, 서비스 자체는 중단되지 않는다. @ConditionalOnProperty fallback으로 @ApplicationModuleListener가 자동 전환되어 비동기 이벤트 처리 수준으로 동작한다. 이 구조에서 Kafka의 역할은 “평시의 정확성 극대화”이고, fallback은 “장애 시 서비스 연속성 보장”이다. Kafka가 복구되면 Debezium이 마지막 binlog position부터 이어서 캡처하므로 장애 동안의 변경도 소급 반영된다. 프로덕션 확장 시에는 KRaft 3노드 컨트롤러 + 전용 브로커로 HA를 확보해야 한다.

Debezium Connector 상태

Kafka 토픽

코드 구조 — Kafka 유무에 따른 자동 전환

CDC 파이프라인 동작 확인

CDC Consumer 아키텍처 버그 발견 및 수정

Kafka CDC 배포 후 게시글 생성 → 검색 노출이 안 되는 문제를 발견했다.

근본 원인: docker-compose.yml.j2(App 1)에서 SPRING_KAFKA_BOOTSTRAP_SERVERS 환경변수 매핑이 빠져 있었다.

수정 후 구조:

현업과의 비교: 프로덕션에서는 Elasticsearch/OpenSearch 같은 별도 검색 클러스터가 자체적으로 Primary/Replica 복제를 관리하므로, “CDC Consumer가 어느 App에서 돌아야 하느냐” 문제가 발생하지 않는다. embedded Lucene은 인프라 비용을 아끼는 대신, 이런 관리 복잡성을 애플리케이션이 부담한다.

Consumer Group 분리 이유: App 1과 App 2가 CDC로 하는 일이 다르므로(인덱싱 vs 캐시 무효화), 브로드캐스트 패턴(별도 Consumer Group)을 적용했다.

CDC 정확성 검증 — 직접 SQL DELETE 테스트

CDC End-to-End 지연 측정

커뮤니티 게시판에서 “게시글 작성 후 2초 뒤 검색 가능”은 허용 가능한 수준이며, CDC의 이점(직접 SQL 감지, 이벤트 리플레이, 양쪽 L1 캐시 무효화)이 이 지연을 상회한다.

9. k6 부하 테스트 — Kafka CDC (100 VU, 20분)

성능 비교

@ApplicationModuleListener와 Kafka CDC의 읽기/쓰기 성능이 동등하다. 성능 차이가 아니라 아키텍처 정확성(correctness)의 차이가 CDC 도입의 핵심 이유다.

k6 터미널 결과

프로필: LOAD (100 VU, 20분)
총 요청 수: 42,084
에러율: 0.00%

전체:        평균 35.61ms   P95 137.63ms
검색 (전체):  평균 25.74ms   P95 99.60ms
  희귀 토큰 (10%):    평균 20.41ms   P95 90.56ms
  중빈도 토큰 (60%):   평균 17.48ms   P95 87.26ms
  고빈도 토큰 (30%):   평균 44.44ms   P95 167.63ms
자동완성:     평균 10.37ms   P95 65.03ms
최신 게시글:  평균 17.95ms   P95 81.02ms
상세 조회:    평균 25.11ms   P95 91.06ms
쓰기 (생성+좋아요): 평균 23.94ms   P95 87.92ms

Overview

시나리오별 응답시간

네트워크 상세

Debezium CDC 모니터링

• CDC Lag: 초기 ~10초 스파이크 후 0ms 근처로 수렴
• Events Per Second: 부하에 따라 0 → ~60 ops/s까지 선형 증가

Kafka 모니터링

• Lag by Consumer Group: wiki-cdc-consumer — lag 0. Consumer가 메시지를 즉시 소비

Spring Boot / JVM

• Heap used: 8.45% (92.5 MiB / 1 GiB)
• HTTP Errors (5xx): 0 ops/s

• GC Pressure: 0.1%
• Threads: live 38, daemon 31, peak 41

• Mapped buffer: ~30 GB — Lucene 인덱스 파일의 memory-mapped I/O. 1,215만 건 인덱스

Nginx

인프라 (Host)

컨테이너별 리소스

• wiki-app-prod CPU: 피크 ~70% — @ApplicationModuleListener(~100%)보다 낮음. CDC가 Lucene 인덱싱을 분리

MySQL

MySQL Replication

• Replication Lag: 0~1초 사이 진동 (정상)
• CDC(Debezium)는 Primary의 binlog를 직접 읽으므로, Replication Lag과 무관하게 동작

Redis

Application HTTP

• 두 인스턴스 모두 안정 구간에서 ~50ms 이하
• HTTP 에러율: 초기 시점 후 0%

HikariCP

• 커넥션 획득 시간: ~1ms 이하
• 프로세스 CPU: 피크 ~50% (@ApplicationModuleListener ~100% 대비 감소)

Tiered Cache

L1+L2 합산: 79% → 73%. CDC Consumer가 캐시를 더 적극적으로 무효화하기 때문.

10. CDC 전환 최종 종합

CDC E2E 지연 SLA와 대응 전략

주간 운영 체크리스트

운영 비용 총평: Kafka + Debezium의 주간 운영 시간은 약 30분~1시간이다. 대부분 Grafana 알림이 자동으로 커버하고, 수동 점검은 주 1회 5분 수준이다. 이 비용은 dual-write 불일치 발생 시 디버깅 + 전체 재인덱싱(28분) + 사용자 불만 대응에 소모되는 시간보다 확실히 작다.

부록: 검색엔진 자동완성 시스템 설계 — 대규모 아키텍처 관점

이 부록은 시스템 디자인 인터뷰 대비 정리이며, wikiEngine의 현재 구현과는 규모가 다르다.

요구사항

읽기와 쓰기의 요구사항 분리

자동완성 시스템을 설계할 때 먼저 본 것은 “같은 검색 기능처럼 보여도 실제 요구사항은 다르다”는 점이었습니다. 자동완성 제안은 사용자가 입력할 때마다 즉시 반응해야 하므로 매우 빠른 읽기 경로가 중요하지만, 검색어 빈도를 누적하는 경로는 약간의 지연을 허용하더라도 안정적으로 기록되는 편이 더 중요합니다.

이 둘을 하나의 데이터 구조로 함께 처리하면, 빠르게 보여주는 일과 정확하게 누적하는 일이 서로를 방해할 수 있습니다. 그래서 조회 경로와 집계 경로를 분리해, 자동완성은 이미 준비된 결과를 즉시 반환하고, 검색어 집계는 뒤에서 안정적으로 누적·정리하는 구조가 더 적합하다고 판단했습니다.

Trie 자료구조 — naive 구현의 한계와 프로덕션 최적화

자동완성을 생각하면 가장 먼저 떠오르는 건 Trie입니다. 소규모에서는 접두사 탐색에 자연스러운 선택이지만, 규모가 커질수록 모든 후보를 메모리에 유지하는 비용이 커지고, 특히 1~2글자 접두사에서는 분기 수가 급격히 늘어나 원하는 순서로 다시 정렬하는 과정까지 포함하면 응답 시간을 안정적으로 맞추기 어려워집니다.

그래서 이 프로젝트에서는 입력 시마다 후보를 다시 탐색하는 방식보다, 접두사마다 상위 추천 결과를 미리 정리해두고 요청이 오면 바로 반환하는 구조가 더 적합하다고 판단했습니다. 즉, 접두사마다 정렬된 추천 결과를 미리 대응시켜 두는 단순한 조회 구조로 바꾼 것입니다. 이 방식은 조회 경로를 예측 가능하게 만들고, 분산 환경에서도 같은 기준의 추천 결과를 일관되게 제공하기 쉽다는 장점이 있습니다.

물론 Trie 계열 자체가 항상 부적합한 것은 아닙니다. 규모가 큰 서비스는 Trie 변형이나 FST처럼 메모리와 탐색 비용을 줄인 자료구조를 사용하기도 합니다. 다만 이 글에서 강조하고 싶은 건 “어떤 자료구조가 더 멋진가”보다, 요구사항과 운영 제약 안에서 어떤 조회 방식이 더 단순하고 안정적인가를 먼저 판단했다는 점입니다.

데이터 처리 파이프라인 — MapReduce 패턴과 현대 구현

자동완성 결과는 검색처럼 매 요청마다 즉시 다시 계산해야 하는 기능은 아니라고 봤습니다. 최신 결과가 약간 늦게 반영되어도 괜찮다는 전제가 있었기 때문에, 모든 입력을 실시간으로 처리하는 복잡한 구조보다 일정 주기로 모아 집계하는 방식이 더 적합했습니다.

그래서 사용자가 입력한 검색어는 먼저 모아두고, 일정 주기마다 최근 데이터를 기준으로 접두사별 상위 추천 결과를 다시 계산하는 흐름으로 설계했습니다. 어떤 검색어가 많이 입력되면 그 검색어는 자신의 모든 접두사 후보에 반영되고, 각 접두사마다 상위 추천 결과만 남기는 식입니다. 이렇게 하면 조회 시점에는 이미 정렬이 끝난 결과를 바로 반환할 수 있고, 무거운 계산은 뒤에서 주기적으로 처리할 수 있습니다.

여기서 말하는 MapReduce는 특정 프레임워크 이름이 아니라, “데이터를 나누고, 같은 키끼리 모으고, 다시 집계한다”는 사고 패턴에 가깝습니다. 핵심은 대규모 처리 기술을 과시하는 것이 아니라, 요구사항이 허용하는 지연 범위 안에서 가장 단순하고 운영 가능한 흐름을 선택했다는 점입니다.

데이터 동기화 — 변경 전파 구조

자동완성 데이터의 원천은 사용자의 검색 행동이고, 게시글 데이터의 원천은 서비스의 저장소입니다. 이 둘은 성격이 다르기 때문에 같은 방식으로 다루지 않았습니다. 검색어 순위는 집계 흐름으로 만들고, 게시글 제목 변경처럼 자동완성 결과 자체에 영향을 주는 데이터는 변경 사항이 뒤에서 자동으로 전파되도록 설계했습니다.

즉, “사용자 행동은 모아서 다시 계산하고, 데이터 상태 변경은 필요한 곳에 자동 반영한다”는 식으로 경로를 나눈 것입니다. 이렇게 해야 전체를 실시간으로 처리하지 않아도 필요한 최신성은 유지하면서 복잡도를 통제할 수 있습니다.

설계 하이라이트

후속 개선 — CDC 에러 핸들링 강화

DLQ(Dead Letter Topic) + 재시도 로직

왜 예외를 throw해야 하는가: Spring Kafka의 DefaultErrorHandler는 리스너가 예외를 throw할 때만 동작합니다. catch에서 예외를 삼키면 Kafka 입장에서 “정상 처리”로 간주되어 offset이 커밋되고, 재시도도 DLQ 격리도 일어나지 않습니다. Confluent 공식 문서에서도 DLQ는 “운영 관찰성 시그널”로 — DLT에 메시지가 쌓이면 알림을 보내 원인을 분석하는 패턴을 권장합니다.

AckMode.RECORD를 명시한 이유: enable-auto-commit=true(기본값)면 poll() 주기마다 자동 커밋되어, 처리 실패한 메시지도 커밋될 수 있습니다. enable-auto-commit=false + ack-mode=RECORD로 설정하면 각 레코드 처리 완료 후에만 offset이 커밋되어, 실패 시 해당 레코드부터 재처리됩니다.

관련 파일:

• CdcErrorHandlerConfig.java — DefaultErrorHandler + DeadLetterPublishingRecoverer
• DebeziumCdcConsumer.java — catch에서 throw 추가
• application.yml — enable-auto-commit: false, ack-mode: RECORD

Previous Post

This post follows View Count Redis INCR + Write-Behind Batch Flush, where DB UPDATE conflicts in GET requests were resolved with Redis INCR. This post covers the evolution from PostService’s dual-write architecture to event-driven synchronization and ultimately Debezium + Kafka CDC for capturing all database changes.