[Kafka 원리] Kafka Broker 메세지 저장 방식Cluster(broker), partition, segment 기본 개념 및 옵션

목차

• Broker, kafka cluster란?
  • Broker란?
  • Kafka Cluster란?
• Partition이란?
  • Partition이 메시지 보관하는 법
  • Partition이 필요한 이유는?
  • 병목현상이 왜 일어 날까?
  • Partition 수 늘리기
  • Partition 수 늘리는 것이 무조건 좋은 방법일까?
  • Partition replica 기준
• Segment란?
  • rolling 및 retention
  • segment 주요 옵션

Broker

Message Queue시스템에서는 message Produce와 Consume 하기 위해 message를 관리하거나 보관해주는 서버가 필요한데 그것이 Kafka에서는 Broker라고 부른다.

Kafka Cluster

Kafka에서는 메시지 분산처리 플랫폼 이기 때문에 분산처리가 가능한 Cluster를 구성할 수 있습니다. 이로써 Broker 서버가 다운되었을 때 통신 장애, message 유실 등에 대한 처리가 유연하게 가능합니다.

Topic

Kafka에서는 messgae를 보내는 목적지를 정할 수 있는데 이것이 Topic이다. Producer(메시지 보내는 사람)이 Kafka에 생성된 Topic들 중에 어떤 Topic에 보낼지를 지정해 message를 보낼 수 있습니다.

Partition이란?

• 토픽에 전송되는 메시지를 보관하는 물리적인 메세지 그룹입니다.
• 여러 개의 Broker에 나눠서 Partition을 구별할 수 있음
• Partition마다 message를 관리하기 때문에 message 병렬 처리도 가능함
• 보관도 분산해서 하기 때문에 고가용성을 유지하는데 좋습니다.

Partition에 메시지 보관하는 법

• Order라는 토픽에 3개의 파티션을 구성했다고 하면 partition은 0부터 시작해서 3개가 구성됩니다. 아래와 같이 Partition0, 1, 2가 됨
• order토픽에 메시지가 들어오게 되면, 각 Broker에 상태에 맞게 Partition별로 offset 0부터 차례로 쌓이게 됩니다.
• Partition별 offset 단위로 메시지를 보관하기 때문에 메세지를 consume할 때 Partition별로 처음부터 끝까지 읽기, 특정 파티션 만 설정해서( ex Partition 0,1 만) 메세지 가져오기 등이 가능하게 되어 메세지 관리하기와 고도화가 편리하게 가능함

https://kafka.apache.org/20/documentation.html

 

Partition이 필요한 이유는?

order라는 Topic에 Partition 1개가 있다고 가정해 보겠습니다. 예를 들어 4개의 프로듀서가 1초에 10개의 메시지를 받는다고 하면, 1초에 broker가 받는 메세지는 총 40개입니다. 4 * 10 = 40. 극단적으로 Broker1에 1개의 partition이 존재하고 이것을 1초에 10개의 메세지만 받을 수 있다고 하면 broker가 1초에 메세지 보관 처리하는 메세지 총 갯수는 10개입니다. 1 * 10 = 10 이 때 producer가 보내는 메세지와 broker가 처리하는 메세지 수가 30개의 간극이 벌어지게 됩니다.

병목현상이 왜 일어나까?

병목현상이 일어나는 이유는 message가 순서가 보장이 되어야 하기 때문입니다. Broker가 처리할 수 있는 양보다 Message가 들어오는 양이 많다고 하면 순서를 보장하는 데까지의 waiting이 생기게 됩니다. 즉, Broker가 처리할 수 있는 처리량을 잘 파악하여 message 처리를 잘 생각하여 partition처리를 해야 합니다.

Partition 수 늘리기

위와 같은 현상이 발생하면 30개의 메시지가 병목현상이 발생하는데 이를 해결하려면 어떻게 해야 할까? 이럴 때 partition 수를 늘리는 방법이 있습니다. Partition을 늘리게 되면 Producer가 보내주는 message를 병렬로 처리하기 때문에 위와 같은 병목 현상을 없앨 수 있습니다.

 

Partition 수 늘리는 것이 무조건 좋은 방법일까?

Kafka에서는 고가용성을 제공하기 위해서 Broker에 대한 message replication factor을 제공합니다. 즉 Cluster를 구성하고 Partition을 Topic별로 구성했다면 복제 옵션을 줘서 partition에 들어온 message를 복제할 수 있습니다. 하지만 Partition의 메시지를 복제하는 것도 Task이기 때문에 처리하는데 시간이 걸리게 됩니다.

만약 Cluster에 Broker한대가 장애가 발생했다고 하면 복제가 하나가 없어지거나 복제의 기준이 되는 리더가 없어졌으므로, 장애 복구가 들어가게 됩니다. 하지만 단순히 아래와 같이 몇 개의 partition이 없다면 문제가 되지 않겠지만, 한 중개인에 엄청나게 많은 Partition이 존재한다면 다른 곳으로 복제하는 방식이 적용되는데 시간이 많이 걸리게 됩니다.

또한 partition은 늘리는 것을 자유롭지만, 감소할 수 없는 제약 조건이 있습니다. 즉, partition을 효율적으로 사용하기 위해서는 꼭 적당한 partition을 유지하는 것이 중요하다고 합니다.

Partition replica 기준

용도	replica 갯수
개발	1
운영(장애 대응 필수 x)	2
운영(장애 대응 필수)	3

 

Segment

• kafka 메시지는 topic안에 partition별로 로그를 쓰게 되는데, 로그를 직접적으로 써지고 보관하는 단위가 segment이다.
• topic 아래에 파티션들이 존재하고 파티션 아래에 segment들이 존재한다.
• 활성 segment는 하나이다.
• Topic 별로 관리되는 디렉터리 아래에 파티션 폴더가 존재하고 그 안에. log,. index 파일들이 존재하게 됩니다.

Segment Rolling

• 세그먼트는 기본적으로 롤링(덧붙이기) 전략을 적용
• 특정 오프셋까지나, 설정된 byte가 넘어가면 새로운 segment가 생성되어 메시지가 관리된다.
• . index파일이 존재하며 특정 오프셋의 위치가 존재한다.

log Segment 주요 옵션

옵션	설명
log.segment.bytes	바이트 단위로 최대 세그먼트 크기를 정의 (default 1GB)
log.roll.hours	kafka가 새 세그먼트 파일을 롤링할 때까지 대기하는 최대 시간(default 7일)
log.cleanup.policy	delete 또는 compact로 설정하며 delete로 설정 된 경우 로그 세그먼트는 시간이나 크기 제한에 도달할 때 주기적으로 삭제됨.(default delete)
log.retention.{ms, minutes, hours}	로그 세그먼트를 보유할 시간을 정의
log.retention.bytes	삭제하기 전에 보관할 파티션당 로그 수. 로그의 시간이나 크기제한에 도달하면 삭제됨.
log.retention.check.interval.ms	로그의 보유 정책을 만족하기 위해 삭제할 대상을 확인하는 시간 주기
log.segment.delete.delay.ms	삭제되는데 걸리는 delay시간 정의 (default 1분)

https://strimzi.io/blog/2021/12/17/kafka-segment-retention/

 

 

 

 

 

참고문헌

https://ooeunz.tistory.com/115

https://strimzi.io/blog/2021/12/17/kafka-segment-retention/

https://medium.com/walmartglobaltech/rendezvous-with-kafka-a-simple-guide-to-get-started-48db3b921cc

https://bigdatalab.tistory.com/10