[Kafka 101] 카프카 메시지와 토픽과 파티션 (Kafka Message, Topic and Partition)

들어가며

메시지 큐의 구조 (출처 : https://aws.amazon.com/ko/message-queue/)

 카프카 브로커는 프로듀서로부터 메시지를 전달받고, 다시 이를 컨슈머로 전달하는 역할을 담당합니다. 이번 글은 카프카를 통해 흘러가는 메시지에 대해 알아보고, 나아가 카프카의 요소인 토픽과 파티션에 대해 개념적으로 살펴봅니다.

카프카의 메시지

 카프카의 메시지는 Key(키)와 Value(값)로 구성됩니다. 먼저, 메시지의 키는 해당 메시지가 카프카 브로커 내부에 저장될 때, 저장되는 위치와 관련된 요소입니다. 프로듀서가 메시지를 브로커로 전달할 때, 프로듀서 내부의 파티셔너(Partitioner)가 저장 위치를 결정하는데, 이때 키의 값을 이용하여 연산하고 그 결과에 따라 저장되는 위치를 결정합니다.

 메시지의 값은 메시지가 전달하고자 하는 내용물을 의미합니다. 값은 단순한 문자열이 될 수도 있고, JSON이나 특정 객체가 될 수 있습니다. 참고로 이렇게 다양한 타입의 값을 보낼 수 있는 것은 브로커를 통해 메시지가 발행되거나 소비될 때, 메시지 전체가 직렬화/역직렬화되기 때문입니다.

카프카 메시지의 구조 (출처 : https://www.slideshare.net/PaoloCastagna1/introduction-to-apache-kafka-confluent-and-why-they-matter)

 메시지의 키와 값은 다양한 타입이 될 수 있지만, 특정한 구조인 스키마(schema)를 가집니다. 카프카 메시지의 스키마는 데이터베이스의 테이블 스키마와 유사한 개념입니다. 이는 프로듀서가 발행하고 컨슈머가 소비할 때 메시지를 적절하게 처리하기 위해 필요합니다. 예를 들어, 프로듀서가 내용(값)이 JSON 형태인 메시지를 발행할 때, 해당 메시지를 소비하는 컨슈머는 프로듀서가 생산한 JSON의 구조를 예상하고, 그에 맞게 메시지를 처리하려고 합니다. 이때 만약 프로듀서와 컨슈머가 메시지에 대한 서로 다른 스키마를 가지고 있다면, 정상적인 처리를 할 수 없습니다. 이처럼 스키마는 카프카 개발, 운영에서 굉장히 중요한 역할을 담당합니다. 스키마 관리에 관한 더욱 자세한 이야기는 이후 스키마 레지스트리 부분에서 정리하겠습니다.

카프카의 토픽

 카프카의 토픽(Topic)은 메시지를 구분하는 논리적인 단위로, 동일한 토픽의 메시지들은 논리적으로 같은 문맥(context)을 가집니다. 예를 들어, 주문에 관한 내용을 담고 있는 메시지를 발행하고, 소비하기 위해서 우리는 order라는 토픽을 생성하고 이 토픽을 기준으로 메시지를 발행, 소비할 수 있습니다.

 이처럼 토픽은 논리적인 단위이자 메시지 흐름의 단위이기도 합니다. 그렇기 때문에 토픽을 설계할 때는 메시지의 논리적인 구분을 명확하게 해야 합니다.

카프카의 파티션

 논리적인 단위인 카프카 토픽을 기준으로 발행되는 메시지들은 브로커 내부의 물리적인 단위인 카프카 파티션(Partition)으로 나뉩니다. 즉, 모든 토픽은 각각 대응하는 하나 이상의 파티션이 브로커에 구성되고, 발행되는 토픽 메시지들은 파티션들에 나뉘어 저장됩니다. 

T0 토픽은 4개의 파티션으로, T1 토픽은 2개의 파티션으로 구성된 모습 (출처 : https://www.slideshare.net/PaoloCastagna1/introduction-to-apache-kafka-confluent-and-why-they-matter)

 이렇게 하나의 토픽에 대하여 여러 파티션을 구성하는 가장 큰 이유는 분산 처리를 통한 성능 향상에 있습니다. 카프카는 하나의 토픽에 대해 여러 프로듀서가 발행할 수 있고, 여러 컨슈머가 구독할 수 있습니다. 그렇기 때문에 토픽을 하나의 파티션으로 구성하면, 무수한 발행-구독 요청을 하나의 파티션이 처리해야 합니다. 물론 카프카는 하나의 파티션만으로도 충분한 성능을 발휘할 수 있지만, 일반적으로 2개 이상의 파티션을 서로 다른 브로커에 병렬 구성하여 요청의 부하를 분산시켜 줍니다. 이에 따라 자연스럽게 해당 토픽에 관한 성능도 향상시킬 수 있습니다. 

 이외에도 파티션의 가장 큰 특징은 하나의 파티션 내에서는 메시지 순서가 보장되는 것입니다. 즉, 파티션은 메시지 순서 보장의 단위로써, 각 파티션의 메시지는 발행되는 순서대로 구독할 수 있습니다. 따라서 하나의 토픽이 여러 파티션으로 구성되는 경우, 토픽 단위의 메시지 순서는 보장할 수 없습니다. 이는 파티션 내부에서의 순서는 보장되지만 파티션 간의 순서는 보장되지 않기 때문입니다.

파티션 복제

 하나의 토픽은 하나 이상의 파티션으로 구성됩니다. 여기에서 나아가 카프카는 서비스 안정성과 장애 수용(Fault-Tolerance)에 관한 요소로 파티션의 복제(Replica) 기능을 제공합니다.

 하나의 파티션은 1개의 리더 레플리카와 그 외 0개 이상의 팔로어 레플리카로 구성됩니다. 리더 레플리카는 파티션의 모든 쓰기, 읽기 작업을 담당합니다. 반대로 팔로어 레플리카는 리더 레플리카로 쓰인 메시지들을 그대로 복제하고, 만약 리더 레플리카에 장애가 발생하는 경우, 리더 자리를 승계받을 준비를 합니다. 참고로 승계받을 준비가 된 즉, 리더 레플리카의 메시지를 적절하게 복제하여 리더 레플리카와 동기화된 레플리카들의 그룹을 ISR(In-Sync Replica)라고 합니다.

토픽 : topic1 / 파티션 : 4개 / 복제 계수 3 인 경우 (출처 : https://www.confluent.io/blog/hands-free-kafka-replication-a-lesson-in-operational-simplicity/)

 파티션의 레플리카 수는 복제 계수(Replication factor)를 통해 결정되는데, 만약 복제 계수가 1이라면 파티션은 리더 레플리카로만 구성됩니다. 이때, 파티션과 리더 레플리카는 별개인 것이 아니라 동일한 것으로 볼 수 있습니다. 즉, 일반적으로 말하는 '물리적인 파티션'은 리더 레플리카를 이야기한다고 할 수 있습니다. 나아가 복제 계수가 2개 이상이라면 해당 파티션은 1개의 리더 레플리카와 1개 이상의 팔로어 레플리카로 구성됩니다. 이 경우 모든 레플리카들은 서로 다른 브로커에 구성됩니다. 만약 같은 파티션의 레플리카가 동일한 브로커에 구성되는 경우에는 에러가 발생합니다. 

 이처럼 파티션의 레플리카들은 언제 발생할지 모르는 장애에 대비하여 데이터 유실을 방지하고, 지속적인 서비스를 제공하기 위해 구성됩니다. 

마무리

 이번 글을 통해 카프카의 기본 요소인 메시지와 토픽과 파티션에 대해 알아봤습니다. 특히, 토픽은 논리적인 단위이고 파티션은 물리적인 단위, 나아가 파티션은 하나 이상의 레플리카로 구성되는 것은 매우 중요한 내용입니다. 이것들은 카프카 운영의 기본 지식이므로 꼭 운영에 앞서 잘 이해하시기를 빕니다. 

ps 1. 혹시 잘못되거나 부족한 부분은 댓글로 남겨주시길 바랍니다. 
ps 2. 내용이 마음에 드셨다면 공감 버튼을 눌러주세요!