🔎 아파치 카프카 Exactly-once 처리의 진실과 거짓

'아파치 카프카 애플리케이션 프로그래밍 with 자바' 책의 저자이자 개발 유튜버이신 데브원영님께서 개인 블로그에 아파치 카프카의 Exactly-once 처리에 대해 정리해주셔서 공유드립니다. 아파치 카프카와 같은 분산 이벤트 스트리밍 플랫폼을 사용하거나 메시지 브로커를 활용하다 보면 항상 마주치는 문제로 메시지 전달 시멘틱(message delivery semantic)이 있는데요, 메시지 전달 시멘틱은 A지점에서 B지점으로 데이터를 전송할 때 어느 만큼의 신뢰도로 데이터를 전송하는지에 대한 정의입니다. 메시지 전달 시멘틱은 다음과 같이 크게 세가지로 나뉩니다. 📌 적어도 한번(at least once) : 데이터가 전달될 때 유실이 발생하지는 않지만 중복이 발생할 가능성이 있음을 뜻하며 아파치 카프카는 기본 옵션으로 사용할 경우 '적어도 한번'을 보장합니다. 📌 많아도 한번(at most once) : 최대 한번의 메시지를 보내고 일부 데이터는 유실될 수 있음을 뜻합니다. 📌 정확히 한번(exactly once) : A에서 B로 데이터를 보낼 때 어떠한 경우에서도 유실이나 중복이 발생하지 않는 것을 뜻합니다. 데이터 처리의 중복/유실을 방지 위해 아파치 카프카는 많은 노력을 기울여 왔는데요, 그 결과로 멱등성 프로듀서(idempotence producer)와 트랜잭션 프로듀서/컨슈머(transaction producer/consumer)를 얘기할 수 있습니다. 멱등성 프로듀서는 네트워크 장애가 발생하더라도 브로커에 단 하나의 레코드만 보낼 수 있도록 보장하여 "프로듀서 -> 토픽" 구간을 '정확히 한번' 처리가 되도록 하였습니다. 트랜잭션 프로듀서/컨슈머는 여러 레코드를 원자(atomic) 단위로 데이터를 처리할 수 있도록 설계되었는데, 여기에 추가적으로 컨슈머의 커밋을 트랜잭션에 포함시키는 기능(sendOffsetsToTransaction)을 가지고 있습니다. 이를 통해 "A토픽 -> 컨슈머 -> 데이터 처리 -> 프로듀서 -> B토픽" 으로 이어지는 파이프라인에서 '정확히 한번' 처리가 되도록 하였습니다. 여기서 주의해야할 점은, Kafka 에서 자주 사용하는 "토픽 -> 컨슈머" 형태에 대해서는 '정확히 한번' 처리에 대한 이야기가 없다는 점입니다. 즉, Kafka 에서 지원하는 Exactly-once 처리는 "프로듀서 -> 토픽" 과 "A토픽 -> 컨슈머 -> 데이터 처리 -> 프로듀서 -> B토픽" 형태만 보장을 하고 있습니다. 그렇다면 "토픽 -> 컨슈머" 형태는 Exactly-once 처리가 불가능할까요? 사실 이건 컨슈머 구현에 따라 달라질 수 있습니다. "토픽 -> 컨슈머" 처리에서 Exactly-once 처리를 하기 위해서는 멱등성(idempotence) 처리를 하도록 컨슈머 구현이 되야합니다. 예를 들어 Kafka 메세지를 통해 데이터베이스에 데이터를 저장하는 컨슈머를 구현한다면, 동일한 레코드가 중복 적재될 때는 결과가 하나만 나올 수 있도록 유니크 키 같은 것을 사용하여 멱등성 처리를 할 수 있습니다. 이를 통해 "토픽->컨슈머" 까지 Exactly-once 처리를 할 수 있게 됩니다. 제가 요약한 내용에 대한 상세한 설명들이 데브원영님의 블로그에 정리되어있으니 관심있으신 분들께서는 한번 읽어보시면 좋겠습니다. 📚 원문: https://voidmainvoid.tistory.com/504?fbclid=IwAR3z7zNNRPsQIEBy1Qu7BGz1fXeJn_GBpMQxJQwSeskFWnfOvLBhky0cJKs