[Kafka] 6. Topics

 

1. What are Kafka Topics?

Kafka의 아키텍처는 세 가지 구성 요소로 구성됩니다: 프로듀서, 컨슈머, 그리고 브로커.

데이터는 메시지 형태로 프로듀서에서 컨슈머로 흐르며, 이 과정에서 브로커에 저장된 Kafka 토픽을 통해 이루어집니다. 

토픽은 데이터 흐름을 조직하고 분배하는 논리적 채널 역할을 합니다.

토픽은 여러 개의 파티션으로 나누어집니다. 파티션은 불변의 순서로 시간에 따라 정렬된 메시지의 하위 집합을 포함합니다. 

Kafka는 여러 브로커—Kafka 클러스터의 노드—에 파티션을 복제하여 장애 허용성을 보장합니다. 

파티션을 호스팅하는 브로커가 실패할 경우 Kafka는 자동으로 다른 브로커에 호스팅된 복제본으로 장애 조치를 수행하여 데이터 가용성과 서비스 연속성을 보장합니다.

토픽 파티션은 소비자 작업 부하를 클러스터의 여러 브로커에 분배하여 수평 확장을 가능하게 합니다. 

파티션은 여러 컨슈머가 동일한 토픽에서 데이터를 처리할 수 있게 합니다. 

이는 데이터 볼륨이나 예상 처리량이 증가할 경우 더 많은 파티션을 추가하고 부하를 추가 브로커에 분산시켜 시스템이 더 높은 부하를 처리할 수 있도록 확장할 수 있음을 의미합니다.

 

 

2. How Kafka Topics Work

Kafka에서 토픽은 커밋 로그의 역할을 합니다. 

토픽을 메시지가 프로듀서에서 컨슈머로 이동하는 동안 임시로 저장되는 로그 파일로 생각할 수 있습니다. 

이는 메시지의 정렬된 시퀀스를 포함합니다. 

프로듀서는 로그의 한쪽 끝에 메시지를 추가하고, 컨슈머는 반대쪽에서 메시지를 읽습니다. 

전체 과정은 Kafka 로그에 관한 가이드에서 자세히 설명되어 있습니다. 아래에 개요를 제공합니다.

 

2.1. Overview

프로듀서는 메시지를 생성하여 토픽에 기록합니다. 

Kafka의 파티션 매퍼는 각 메시지가 어떤 파티션으로 가는지를 결정합니다. 

동일한 키를 가진 모든 메시지는 같은 파티션으로 전송됩니다. 

설정에 따라 프로듀서는 파이어 앤 포겟(fire-and-forget) 방식으로 메시지를 보낼 수 있거나, Kafka 브로커로부터 메시지가 성공적으로 수신되었다는 확인 응답을 기다릴 수 있습니다.

Kafka 프로듀서는 특정 오류가 발생할 경우 메시지를 다시 전송하려고 시도합니다. 

‘retries’라는 매개변수는 프로듀서가 오류가 발생할 경우 메시지를 재전송하려고 시도하는 횟수를 제어합니다. 

‘delivery.timeout.ms’ 속성은 프로듀서가 메시지를 실패로 선언하기 전에 재전송을 시도하는 시간을 제어합니다.

컨슈머는 하나 이상의 토픽을 구독합니다. 

다른 퍼블리시/구독 구현과 달리, Kafka는 메시지를 컨슈머에게 푸시하지 않습니다. 

대신, 컨슈머는 Kafka 토픽 파티션에서 메시지를 끌어와야 합니다.

컨슈머는 브로커의 구독한 토픽 파티션에 연결하여, 메시지가 작성된 순서대로 읽습니다. 

Kafka는 소비자가 서로 다른 토픽에서 메시지를 동시에 읽을 수 있도록 단일 및 다중 토픽 구독을 지원합니다.

Kafka는 소비자를 소비자 그룹으로 묶어 확장을 돕습니다. 

그룹의 모든 소비자는 동일한 토픽을 구독합니다. 

Kafka의 소비자 그룹 조정 메커니즘은 구독된 토픽 파티션이 소비자 간에 고르게 분배되도록 보장합니다. 

이는 소비자가 그룹에 들어가거나 나갈 때 동적 재분배(또는 리밸런싱)를 촉진합니다.

소비자는 자신에게 할당된 파티션에서만 메시지를 가져옵니다. 

각 토픽 파티션은 그룹 내에서 오직 하나의 소비자만 소비할 수 있습니다. 이는 파티션 내에서 순차적인 메시지 처리 및 메시지 순서 보장을 보장합니다.

 

 

2.2. Topic Partition Offsets

토픽 파티션은 Kafka의 기본 저장 요소입니다. 

파티션 내에서 Kafka는 오프셋을 사용하여 메시지를 추적합니다. 

오프셋은 파티션의 시작 지점부터 메시지의 순서를 나타냅니다. 

오프셋은 Kafka가 메시지 순서를 보장하고 배달 보증을 설정하는 데 도움을 줍니다.

파티션 내부에서 Kafka는 데이터를 세그먼트로 나눕니다. 

세그먼트는 Kafka의 디렉토리 구조 내에서 파일을 나타냅니다. 

한 번에 활성화된 세그먼트는 하나뿐이며, Kafka는 최신 데이터를 이 세그먼트에 기록합니다.

Kafka가 세그먼트를 커밋하고 새로운 세그먼트를 시작하는 지점을 제어할 수 있는 두 가지 구성 매개변수는 다음과 같습니다:

- **log.segment.bytes**: 세그먼트가 커밋되는 최대 크기를 제어합니다.
- **log.segment.ms**: Kafka가 세그먼트를 열어 두는 최대 시간을 제어합니다.

 

2.3. Replication

Kafka 파티션은 메시지 내구성을 높이기 위해 여러 서버에 복제됩니다. 

복제 계수는 토픽 수준에서 구성할 수 있습니다. 

각 토픽 파티션은 리더 파티션과 복제본 집합을 가집니다. 

모든 쓰기는 리더 파티션을 통해 이루어집니다. 

Kafka는 복제본 파티션을 동기화하여 리더가 실패할 경우 그 중 아무 것이나 인수받을 수 있도록 합니다.

‘acks’ 매개변수가 0으로 설정되면 Kafka는 파이어 앤 포겟(fire-and-forget) 방식으로 작동합니다. 

1로 설정되면 프로듀서는 파티션 리더의 확인 응답을 기다립니다. 

 

이 매개변수의 기본 값은 ‘all’입니다.
이 경우 프로듀서는 모든 싱크된 파티션 복제본이 수신을 확인할 때까지 기다립니다.

이는 내구성을 증가시키지만 성능의 일부 비용을 수반합니다.

따라서 Kafka 복제는 개발자가 내구성과 처리량 사이의 균형을 맞출 수 있도록 허용합니다.

 

 

2.4. Schema Management

Kafka의 스키마 관리란 프로듀서에서 컨슈머로의 데이터 흐름에서 표준을 설정하는 것을 포함합니다. 

Kafka에서는 프로듀서와 컨슈머 간의 조정이 없기 때문에 데이터 내 데이터 형식에 대한 표준을 설정하는 것이 어렵습니다. 

여기서 스키마 관리가 도움이 됩니다.

Kafka는 스키마 레지스트리 컴포넌트를 통해 스키마를 관리합니다. 

특정 형식을 준수하는 것이 중요한 사용 사례에서는 스키마 레지스트리를 사용하여 공통 형식을 적용할 수 있습니다.

데이터는 토픽 내에서 바이트 형태로 남아 있습니다. 

Kafka 프로듀서는 직렬화를 통해 복잡한 비즈니스 객체를 바이트로 변환합니다. 

마찬가지로, Kafka 컨슈머는 바이트를 가져와 원래의 비즈니스 객체로 변환하기 위해 역직렬화를 사용합니다. 

스키마 레지스트리는 이러한 비즈니스 객체의 스키마를 저장하고 새로운 메시지가 올 때마다 자동으로 검증하는 데 도움이 됩니다.

 

2.5. Compression

Kafka는 토픽에 저장된 데이터를 압축하여 저장 공간을 최적화하는 것을 지원합니다. 

토픽 수준에서 데이터를 자동으로 압축하거나 압축된 프로듀서 데이터를 수용하는 기능을 제공합니다. 

압축 동작은 ‘compression.type’ 매개변수를 사용하여 제어할 수 있습니다.

프로듀서가 압축을 담당하는 경우 이 매개변수는 ‘producer’ 값을 가집니다. 

이는 프로듀서에서 오는 압축 데이터가 토픽에서 동일한 상태로 유지됨을 의미합니다.

개발자는 이를 토픽 수준에서 지원되는 알고리즘 중 하나(gzip, snappy, lz4, 또는 zstd)로 설정할 수 있습니다. 

토픽 수준에서 다른 알고리즘을 구성하면 Kafka는 설정된 압축 알고리즘을 사용하여 데이터를 다시 압축합니다.

 

2.6. Metadata Management

Kafka 메타데이터는 토픽, 해당 파티션, 동기화된 복제본 및 기타 구성에 대한 정보를 포함합니다. 

Kafka는 메타데이터 관리를 위해 두 가지 방법을 지원합니다: 

Apache ZooKeeper™라는 외부 서비스 또는 KRaft 구성 모드에서의 내부 메타데이터 토픽. 

최신 클러스터에는 KRaft 모드를 사용하는 것이 권장되며, 이는 보다 현대적이고 Kafka 성능과 관련된 많은 병목 현상을 제거합니다.

KRaft 모드에서는 Kafka가 컨트롤러의 과반수와 함께 메타데이터 로그를 유지합니다. 

리더 컨트롤러가 모든 브로커 요청을 처리합니다. 메타데이터 토픽은 다른 토픽처럼 파티션, 복제본, 오프셋을 사용하여 관리됩니다.

 

 

 

3. Setting Up And Configuring Kafka Topics

Kafka는 토픽을 설정하고 관리하기 위한 여러 유틸리티 스크립트를 제공합니다. 

이 섹션에서는 Kafka 토픽을 관리하기 위해 'kafka-topics.sh'와 'kafka-configs.sh' 두 가지 스크립트를 사용합니다.

새로운 Kafka 토픽을 생성하려면, CLI에서 아래 명령어를 실행합니다.

bin/kafka-topics.sh --bootstrap-server <server_url> --create --topic test-topic --partitions 1 --replication-factor 3

위 명령은 'test-topic'이라는 이름의 새로운 토픽을 생성하며, 복제 계수는 3이고 파티션 수는 1입니다. 

'kafka-topics.sh'를 사용하여 기존 Kafka 토픽과 관련된 설정을 변경할 수 있습니다.

bin/kafka-configs.sh --bootstrap-server <server_url> --entity-type topics --entity-name test-topic --alter --add-config log.segment.bytes=32000

위 명령은 'test-topic'이라는 기존 토픽에 대해 'log.segment.bytes' 매개변수를 변경합니다.

 

 

4. Best Practices In Kafka Topics

Kafka는 사용 사례에 따라 성능을 최적화하기 위한 여러 구성 매개변수를 제공합니다. 

다음 섹션에서는 일부 토픽 수준 구성 매개변수에 대한 모범 사례를 자세히 설명합니다.

 

4.1. Optimize The Number Of Partitions

토픽의 파티션 수는 클러스터 성능에 영향을 주는 중요한 요소입니다. 

하나의 파티션은 동시에 하나의 컨슈머에게만 할당되기 때문에, 컨슈머가 유휴 상태가 되는 것을 방지하기 위해 파티션 수는 항상 필요한 수 이상으로 유지해야 합니다. 

파티션은 Kafka에서 병렬 처리의 기본 요소이므로, 들어오는 메시지를 적절한 시간 내에 처리하기 위해 파티션 수를 결정해야 합니다.

모범 사례로는, 필요한 수에 소량의 버퍼 비율을 추가하여 발생할 수 있는 급증을 대비하는 것이 좋습니다. 

또한 사용 중인 커스텀 키 기반 파티셔닝 전략을 고려해야 합니다.

예를 들어, 일부 파티션에서 높은 데이터 볼륨을 초래할 수 있는 파티션 키를 사용하는 경우, 전체 토픽은 불균형이 생기며, 컨슈머들이 따라잡기 힘들어집니다. 

수 천 개의 파티션을 가지는 것도 좋지 않은 선택이며, 이는 클러스터의 오버헤드를 증가시키고 성능을 저하시킬 수 있습니다.

 

4.2. Keep in-sync replication Below The Replication Factor

카프카는 파티션을 다양한 서버에 복제하여 장애에 대비합니다. 

설정에 따라 프로듀서는 다음 항목으로 이동하기 전에 모든 복제본이 메시지 수신을 확인할 때까지 대기할 수 있습니다. 

이는 내구성을 향상시키지만, 처리량이 저하될 수 있습니다.

카프카는 토픽 수준에서 ‘min.insync.replicas’라는 설정 매개변수를 통해 동기화된 복제본 수를 구성할 수 있습니다. 

이는 내구성과 성능의 균형을 맞추기 위해 복제 계수보다 약간 낮은 값으로 설정하는 것이 종종 선호됩니다.

 

The min.insync.replicas setting in Kafka controls the minimum number of replicas that must acknowledge a write for it to be considered successful.

For example, if you set min.insync.replicas to 2 and the replication factor for the topic is 3, at least 2 replicas must acknowledge the message before it is considered successfully written.

 

The default value for min.insync.replicas can vary but is typically set to 1. 

This means that at least one replica must acknowledge the write.

 

4.3. Use the Same Compression Algorithm for Producers And their Topic

카프카에서 압축을 사용하는 이상적인 시나리오는 프로듀서와 토픽 모두에서 동일한 압축 알고리즘을 사용하는 것입니다. 

카프카는 토픽에 대해 서로 다른 압축 알고리즘을 설정할 수 있지만, 이 경우 메시지를 다시 압축해야 하므로 추가 오버헤드가 발생합니다. 

토픽의 ‘compression.type’ 매개변수를 ‘producer’ 값으로 설정하면 카프카는 프로듀서가 사용하는 동일한 압축 알고리즘을 자동으로 사용합니다.

일반적으로 ‘lz4’ 압축이 최고의 성능을 제공하고, ‘gzip’은 더 나은 압축 비율을 제공합니다. 

그렇지만 각 사용 사례는 독특하므로 최상의 방법을 찾기 위해 독립적인 평가가 필요할 수 있습니다.

 

 

4.4. Turn off Automatic Validation If not Strictly necessary

스키마 레지스트리가 활성화되어 있는 경우, 카프카는 메시지의 스키마를 자동으로 검증하고 오류를 발생시킬 수 있습니다. 

이는 거버넌스 기준을 확립하는 데 도움이 되지만, 모든 사용 사례에 필요한 것은 아닙니다. 

이 옵션을 활성화하면 일부 오버헤드가 발생하고 처리량에 영향을 줄 수 있습니다. 

압축이 활성화된 경우에는 메시지를 스키마를 검증하기 위해 압축을 해제해야 하므로 이 영향이 더 클 수 있습니다.

하지만 사용 사례에서 스키마 진화가 필요하다면 이와 같은 주장은 스키마 검증을 피하기에 충분하지 않습니다. 

이 경우, 자동 검증 기능을 활성화 상태로 유지하는 것이 좋습니다.

 

schema registry를 쓸 경우에만 Turn on할 수 있다.

 

 

5. Conclustion

카프카 토픽은 비즈니스 목표에 따라 메시지를 논리적으로 그룹화하는 데 도움을 줍니다. 

이는 메시지를 논리적 채널로 그룹화하며, 처리되는 메시지 종류에 따라 운영 매개변수를 구성할 수 있습니다. 

카프카는 병렬 처리를 지원하기 위해 토픽을 파티션으로 나누어 저장합니다.

디스크에 카프카는 파티션을 여러 세그먼트로 나누어 저장하며, 그 중 하나만이 활성 세그먼트로 작동합니다. 

카프카의 이점을 최대한 활용하려면 토픽 수준의 매개변수를 신중하게 조정하여 처리량과 내구성을 균형 있게 맞춰야 합니다.

카프카는 오픈 소스의 성숙한 기술이지만 현대 사용 사례에 맞게 신중한 구성과 조정이 요구됩니다. 

팀은 사용 사례에 따라 카프카 토픽 및 파티션 구성을 자주 모니터링하고 재구성해야 할 수도 있습니다. 

이는 시스템이 확장하면서 많은 도전과 병목 현상을 초래할 수 있습니다.