without haste but without rest

카프카 메시지 Key의 역할 본문

Data Engineering & DataOps/Kafka

카프카 메시지 Key의 역할

JinungKim 2022. 1. 13. 16:52

Message Key

카프카 브로커에 메세지를 전송할 때 Topic, Key, Value 값을 보내게 된다. 이때 토픽과 밸류는 직관적이지만 키가 굳이 필요한 이유에 관해서 궁금했다.


왜 쓰는 걸까?

Key는 메시지의 종류를 나타날 때 사용하고, 데이터의 처리 순서와 밀접한 관련이 있다. 동일한 키를 동일한 파티션으로 보내는 것이 주요한 목적이다. 간단한 예시로, 토픽의 파티션 개수가 2개 이상이 되는 순간 오프셋의 순서를 보장할 수가 없다. 따라서 트랜잭션 데이터의 순서가 뒤바뀔 수 있는 위험이 존재한다. 이때 레코드의 Primary와 같은 고유값을 키로 이용한다면 동일한 파티션으로만 전송하게 되므로 특정 파티션의 바틀넥 현상에 의해서 순서가 역전되는 문제를 회피할 수 있다. 

 

예를 들어서 uuid가 0인 시계열 데이터 10건을, user_data 라는 2개의 파티션으로 구성된 토픽에 전송 한다고 가정하자. (0번 파티션과 1번 파티션이다.) Key를 정하지 않고 데이터 10건을 전송했다. (각각 5건씩 0번 과 1번 파티션에 보내게 되었다고 가정하자.) 이때 갑자기 1번 파티션에 네트워크 지연 문제가 생기게 되었다. 이런 경우 user_data 토픽을 컨슘 할 때 0번 파티션의 데이터만 먼저 컨슘하게 될 것이고 이후에 1번 파티션의 데이터를 컨슘하므로 시계열 데이터의 순서가 보장되지 않는 치명적인 문제가 발생한다. (사실 순서가 보장되어야 하는 데이터가 파티션에 나뉘어서 들어간 순간부터 순서를 보장하기 어려워진다.)

 

하지만, uuid를 Key로 주어서 user_data 토픽에 전송하는 경우 동일한 Key를 가진 데이터는 지정된 하나의 파티션에만 전송이 되므로 데이터의 순서를 보장할 수 있게 된다.  

 

카프카는 exactly once가 아닌 at least once 방식을 기본 옵션으로 제공한다. 프로듀서 단에서는 데이터의 순서를 최대한 보장하고, 컨슈머 단에서는 데이터 플로우 프레임워크 등을 사용해서 중복 데이터를 제거하는 방식으로 exactly once와 같은 효과를 낼 수 있다. 

처음부터 extactly once로 구현하기에는 메시지큐에 소요되는 리소스가 너무 크기 때문이다.

 

카프카 메시지 키를 사용할 때 주의할 점은 잘못 사용하는 하는 경우 파티션 하나에 트래픽이 과도하게 몰리게 된다. 경우에 따라서 프로듀서가 제공하는 오토 로드 밸런싱을 사용하는 것이 더 나은 선택지가 될 수 있다. 오토 로드 밸런싱을 사용하고자 하는 경우 키 값을 "null" 로 사용하면 된다.


 

Comments