Cloudera CDH/CDP 및 Hadoop EcoSystem, Semantic IoT등의 개발/운영 기술을 정리합니다. gooper@gooper.com로 문의 주세요.
*출처 : http://jays1204.github.io/kafka/2017/07/12/kafka-caution.html
카프카 사용시 주의 사항
현재 개발에서 여러가지 데이터 전송을 위해 카프카를 사용하고 있다.
카프카를 사용하면서 겪은(주의하지 못해) 문제를 이야기 하려 한다.
메세지 중복 consume, At-least-once
카프카에 메세지를 보내고(publish), 받아오는(consume) 과정을 진행할 때 주의해야 할 사항이 있다.
우선 기본적으로 한 파티션에는 그룹의 하나의 컨슈머만 메세지를 가져올 수 있다.
이제 카프카의 토픽에 메세지 A가 담겨있다고 가정해보자.
이때 특정 그룹의 컨슈머는 토픽에 대해 메세지를 컨슘하고 이에 대해 특정 일을 처리하고 commit을 할 것 이다.
이러한 일련의 작업을 하다보면 이미 처리했다고 생각한 메세지 A가 다시 한번 컨슘되는 현상이 발생한다.
이것은 카프카가 기본적으로 메세지 전송에 대해 at-least-once 정책이기 때문이다.
‘적어도 한번’은 메세지를 보낸다는 것으로 동일 메세지에 대해 전송이 1번 혹은 그 이상이 될 수 있음을 말한다.
메세지 중복 consume이 발생할 수 있는 상황
1. 클라이언트가 메세지를 보내길 시도했는데 네트워크 에러가 발생하였다. 이에 대한 재시도가 잠재적으로 중복 메세지를 쌓을 수 있다. 만일 메세지가 전송되기 전에 네트워크 장애가 일어났다면 중복은 발생하지 않을 것이다. 그러나 메세지가 카프카의 로그에 쌓인 이후지만 로그에 쌓였음의 응답이 publisher에 돌아오기 전의 상황에 네트워크 장애가 발생하였다면 메세지 중복이 발생할 수 있다.
2. 컨슈머가 토픽으로부터 메세지를 읽었는데 크래시가 발생하였다. 컨슈머가 재시작하거나 또는 다른 인스턴스가 consume을 하려할때 이미 읽은 메세지부터 다시 읽게 된다.
- 카프카에서 메세지를 컨슘해서 이에 대한 task A을 처리하였다.
- 일을 완료후 해당 메세지의 offset까지 처리하였음을 의미하는 commit을 하길 원했다.
- commit 도중에 어떠한 이유로 장애가 발생하였다.
- 이미 해당 메세지에 대해 task A를 처리하였는데 동일 메세지가 다시금 consume되었다.
- 혹은 리밸런싱(rebalancing)시에 발생할 수도 있다. 컨슈머 그룹내에 변동이 생기면 파티션과 짝을 맞출 컨슈머를 다시 재분배하는 것을 의미한다.
이와 같은 이유로 메세지를 받아 이를 처리할 땐 해당 메세지가 이전에 받아온 메세지인지 여부를 알 수 있어야 한다.
예를 들면 DB table의 pk를 메세지에 포함시켜서 해당 메세지에 대한 일이 처리되면 DB에 업데이트를 하여 컨슈머에서 중복 여부를 알 수 있게 할 수 있다.
consume 메세지의 순서
보통 카프카의 토픽을 구성할 땐 여러개의 파티션을 이용하기 마련이다.
timestamp를 순서대로 보내는 publisher가 있다고 가정하고 이를 10개의 파티션으로 구성된 토픽에 전송하고 이를 동일 컨슈머 그룹의 10개의 컨슈머가 컨슘하고 있다고 가정을 해보자.
순서대로 보낸 timestamp메세지는 각 파티션에 차례대로 쌓일 것이다.
하지만 막상 10개의 컨슈머에서 consume해온 기록을 종합해서 보다 보면 consume해온 timestamp의 순서가 보낸 순서와 완벽하게 일치 하지 않을 수 있다.
이는 카프카가 단일 파티션내에선 쌓인 순서대로 메세지를 consume하도록 보장을 해주는 반면 서로 다른 파티션에 대해서는 순서를 보장해주지 않기 때문이다.
모든 메세지를 정말로 순서대로 가져가길 원한다면 파티션을 하나로 구성할 수 있다.
혹은 publish할때마다 파티션을 지정해서 메세지를 전송하여 일부 순서를 보장할 수 있다.
