Kafka Transaction을 적용했는데 중복 데이터가 발생한 사례

카프카 트랜잭션과 중복 데이터 발생의 미스터리

데이터 처리 시스템에서 카프카(Apache Kafka)는 높은 처리량과 안정성으로 인해 사실상 표준으로 자리 잡았습니다. 특히 데이터의 일관성이 중요한 금융 시스템이나 주문 처리 시스템에서는 카프카의 트랜잭션(Transactions) 기능을 활용합니다. 트랜잭션은 여러 파티션에 걸친 메시지 쓰기 작업을 원자적으로 처리하여, ‘전부 성공하거나 아니면 아무것도 처리되지 않게’ 만드는 강력한 도구입니다. 하지만 많은 개발자가 트랜잭션을 적용했음에도 불구하고 중복 데이터가 발생하는 당혹스러운 상황을 마주하곤 합니다. 왜 이런 일이 발생하는지, 그리고 이를 어떻게 해결해야 하는지 깊이 있게 살펴보겠습니다.

트랜잭션이 무엇을 보장하는가

카프카 트랜잭션은 정확히 ‘원자적 쓰기(Atomic Writes)’를 보장합니다. 생산자가 여러 파티션으로 메시지를 보낼 때, 이 메시지들이 모두 성공적으로 기록되거나 하나도 기록되지 않게 하는 것이죠. 이를 통해 소비자는 트랜잭션이 커밋된 메시지만 읽을 수 있게 설정하여, 중간 단계의 데이터를 보지 않도록 제어할 수 있습니다. 하지만 여기서 중요한 점은 트랜잭션이 ‘메시지 처리의 중복’까지 완전히 막아주는 마법의 도구는 아니라는 사실입니다.

트랜잭션을 적용했는데 중복이 발생하는 이유

트랜잭션을 사용함에도 불구하고 중복 데이터가 발생하는 가장 흔한 원인은 시스템의 복합적인 구성 요소들 사이의 불일치 때문입니다. 대표적인 원인들은 다음과 같습니다.

• 외부 시스템과의 결합: 카프카 트랜잭션은 카프카 내부의 상태만을 관리합니다. 만약 카프카에서 메시지를 읽어 데이터베이스에 저장하고 다시 카프카로 결과를 보내는 과정이라면, 데이터베이스의 커밋과 카프카의 커밋은 서로 다른 트랜잭션입니다. 이 두 지점이 완벽하게 동기화되지 않으면 중복이 발생합니다.

• 재시도 정책의 함정: 네트워크 일시적 오류로 인해 생산자가 메시지를 보낸 후 승인(ACK)을 받지 못하면, 생산자는 동일한 메시지를 다시 보냅니다. 이때 카프카의 멱등성(Idempotence) 설정이 제대로 되어 있지 않거나, 트랜잭션 범위 밖에서 재시도가 일어나면 중복이 발생할 수 있습니다.
• 소비자 오프셋 관리의 불일치: 소비자가 메시지를 처리하고 오프셋을 커밋하는 시점과 비즈니스 로직이 실행되는 시점이 다를 때 발생합니다. 처리는 완료되었으나 오프셋 커밋 전에 애플리케이션이 재시작되면, 재기동된 소비자는 동일한 메시지를 다시 읽게 됩니다.

멱등성 생산자와 트랜잭션의 관계 이해하기

카프카에서 중복을 방지하기 위한 핵심 기능은 ‘멱등성 생산자(Idempotent Producer)’입니다. 멱등성이란 동일한 작업을 여러 번 수행해도 결과가 한 번만 수행한 것과 같음을 의미합니다. 카프카 0.11 버전부터 도입된 이 기능은 PID(Producer ID)와 시퀀스 번호를 사용하여 중복 메시지를 식별합니다.

트랜잭션을 사용하려면 반드시 멱등성 생산자를 활성화해야 합니다. 하지만 멱등성 생산자는 ‘단일 파티션’ 내에서의 중복 방지에 최적화되어 있습니다. 여러 파티션에 걸쳐 트랜잭션을 구성할 때는 트랜잭션 ID(Transactional ID)를 설정하여, 좀 더 넓은 범위에서 중복을 제어하게 됩니다. 많은 이들이 멱등성 생산자만 켜면 모든 문제가 해결될 것이라 착각하지만, 실제로는 분산 환경에서의 상태 불일치를 고려해야 합니다.

중복 데이터 발생을 방지하는 실용적인 전략

중복을 완벽하게 제거하는 것은 분산 시스템에서 매우 어려운 과제입니다. 하지만 다음의 전략들을 조합하면 발생 빈도를 현저히 낮출 수 있습니다.

데이터베이스와 카프카의 동기화

카프카에서 읽은 메시지를 DB에 저장하고, 그 결과를 다시 카프카로 보낼 때 ‘아웃박스 패턴(Transactional Outbox Pattern)’을 사용하세요. 이 패턴은 DB의 테이블에 메시지를 저장하는 작업과 비즈니스 데이터를 저장하는 작업을 하나의 DB 트랜잭션으로 묶습니다. 그 후 별도의 프로세스가 DB의 아웃박스 테이블을 읽어 카프카로 전송합니다. 이렇게 하면 DB와 카프카 간의 상태 불일치를 방지할 수 있습니다.

소비자 측면에서의 멱등성 보장

소비자가 메시지를 처리할 때, 이미 처리된 메시지인지 확인하는 로직을 비즈니스 로직에 포함해야 합니다. 예를 들어 메시지에 고유한 트랜잭션 ID나 요청 ID를 포함하고, 이를 DB의 특정 테이블에 기록하여 중복 처리를 방지하는 ‘유니크 제약 조건’을 활용하는 방식입니다.

정확한 설정값 확인

카프카 설정에서 다음 항목들이 올바르게 구성되어 있는지 확인하세요.

• enable.idempotence: true로 설정되어 있어야 합니다.

• transactional.id: 고유한 ID를 부여하여 생산자의 재시작 시에도 상태를 유지할 수 있게 합니다.
• acks: all로 설정하여 모든 복제본에 메시지가 기록되도록 보장합니다.

자주 묻는 질문과 답변

Q: 트랜잭션만 사용하면 데이터 중복이 아예 안 생기나요?

A: 아니요. 트랜잭션은 카프카 내에서의 원자성만 보장합니다. 외부 시스템과 연동되거나 소비자가 오프셋을 잘못 관리할 경우 중복은 언제든 발생할 수 있습니다.

Q: 멱등성 생산자만 쓰면 트랜잭션은 안 써도 되나요?

A: 단일 파티션에만 데이터를 보낸다면 멱등성 생산자만으로 충분합니다. 하지만 여러 파티션에 걸쳐 데이터를 원자적으로 쓰고 싶다면 반드시 트랜잭션을 사용해야 합니다.

Q: 중복 데이터를 제거하는 가장 비용 효율적인 방법은 무엇인가요?

A: 가장 효율적인 방법은 소비자 단계에서 비즈니스 로직에 멱등성을 부여하는 것입니다. 데이터베이스의 유니크 키(Unique Key)를 활용하여 중복 삽입을 원천 차단하는 것이 시스템 복잡도를 낮추면서 가장 확실한 방법입니다.

전문가가 말하는 중복 데이터 대응의 핵심

데이터 엔지니어링 전문가들은 “중복은 발생할 수 있다”는 전제하에 시스템을 설계할 것을 권장합니다. 즉, 중복을 0%로 만드는 데 과도한 리소스를 투입하기보다는, 중복이 발생했을 때 이를 감지하고 안전하게 처리할 수 있는 ‘멱등한 처리 로직’을 구축하는 것이 훨씬 경제적입니다.

예를 들어, 결제 시스템이라면 ‘결제 요청 ID’를 기준으로 데이터베이스에 고유 제약 조건을 걸어두는 것만으로도 수많은 중복 문제를 해결할 수 있습니다. 카프카는 데이터를 전달하는 파이프라인일 뿐, 최종 데이터의 무결성은 애플리케이션의 비즈니스 로직이 책임져야 한다는 점을 잊지 말아야 합니다.

비용 효율적인 활용을 위한 조언

카프카 트랜잭션은 성능 비용을 동반합니다. 트랜잭션 커밋을 위해 추가적인 네트워크 통신과 오버헤드가 발생하기 때문입니다. 따라서 모든 메시지를 트랜잭션으로 묶으려 하지 마세요. 반드시 원자성이 필요한 데이터(예: 송금, 주문 확정 등)에만 트랜잭션을 적용하고, 로그성 데이터나 분석용 데이터는 일반적인 생산자 설정을 사용하여 시스템의 전체적인 처리량을 확보하는 것이 좋습니다.

또한, 트랜잭션이 길어지면 소비자가 데이터를 읽지 못하는 지연(Latency)이 발생할 수 있습니다. 트랜잭션 범위를 작고 짧게 유지하여 카프카 클러스터의 부하를 줄이면서도 데이터 일관성을 확보하는 전략이 필요합니다.

마지막으로 고려해야 할 점

카프카 트랜잭션을 적용한 후 중복이 발생하는 것은 시스템이 잘못된 것이 아니라, 분산 시스템의 자연스러운 특성 중 하나입니다. 중요한 것은 중복이 발생했을 때 시스템이 어떻게 반응하느냐입니다. 카프카의 설정과 외부 시스템과의 연동 방식을 다시 점검하고, 소비자 측에서 멱등성을 보장하는 로직을 추가하는 것만으로도 훨씬 견고한 데이터 파이프라인을 구축할 수 있습니다.

성공적인 분산 시스템을 구축하기 위해서는 도구의 기능을 맹신하기보다, 그 도구가 가진 한계점을 이해하고 이를 비즈니스 로직 레벨에서 보완하는 것이 가장 중요합니다. 오늘 언급한 멱등성 생산자 설정, 아웃박스 패턴, 그리고 소비자 측의 중복 확인 로직을 순차적으로 적용해보며 시스템의 안정성을 높여보시기 바랍니다.