Chapter 01.
더보기
Apache Kafka 개요
Apache Kafka는 고성능, 분산형 실시간 이벤트 스트리밍 플랫폼으로, 주로 대규모 데이터 흐름을 실시간으로 처리하고 전송하는 데 최적화된 시스템입니다. Kafka는 특히 비즈니스 환경에서 발생하는 이벤트를 수집하고 분석하는 데 많이 사용됩니다.
Kafka의 주요 기능
- 이벤트 스트림 안전하게 전송 (Publish & Subscribe): 메시지를 다양한 소비자들에게 안전하게 전송.
- 디스크에 데이터 저장 (Write to Disk): 메시지 데이터를 디스크에 지속적으로 저장하여 신뢰성 제공.
- 이벤트 스트림 분석 및 처리 (Processing & Analysis): 실시간 데이터 흐름을 처리하고 분석.
Kafka 특징
- 실시간 이벤트 스트리밍: 비즈니스 이벤트를 실시간으로 처리하고, 각종 실시간 애플리케이션에 적합.
- 빅 데이터 처리: 대규모 데이터 세트를 실시간으로 처리하는 데 강력한 성능을 발휘.
- 높은 성능: 초당 수백만 건의 메시지를 처리할 수 있는 성능을 제공, 특히 큰 규모의 데이터를 다룰 때 유리.
Kafka 사용 사례
- 산업 분야: 교통, 금융, 모바일 애플리케이션, 온라인 마켓 등 다양한 분야에서 사용됨.
- 핵심 용도: 이벤트 스트리밍, 데이터 수집, 로그 분석, 실시간 ETL(Extract, Transform, Load) 처리 등.
Kafka의 주요 요소
- Topic: 메시지가 저장되는 논리적 장소.
- Producer: 메시지를 생성하여 Kafka의 Topic에 전송하는 애플리케이션.
- Consumer: Topic에서 메시지를 읽고 처리하는 애플리케이션.
- Consumer Group: 여러 Consumer들이 협력하여 Topic의 메시지를 병렬로 처리하는 집합.
Kafka의 데이터 구조
- Topic: 메시지가 저장되는 논리적 공간.
- Partition: 하나의 Topic을 여러 Partition으로 나누어 병렬 처리 성능을 향상.
- Segment: Partition 안에 실제 메시지가 저장되는 물리적 파일.
- Commit Log: 메시지가 변경되지 않고 시간순으로 쌓임.
Producer와 Consumer의 동작
- Producer는 메시지를 지속적으로 Kafka에 전송하고, Consumer는 이를 읽고 처리합니다.
- Consumer Lag: Producer의 메시지 전송 속도와 Consumer의 처리 속도 차이로 발생하는 지연 상태.
Kafka Cluster 및 Partition 관리
- Kafka Cluster: 여러 Broker로 구성되며, 각 Broker는 Partition을 관리.
- Broker: 메시지 읽기 및 쓰기를 담당하는 서버.
- Bootstrap Servers: 여러 Broker의 목록을 제공하여 장애 발생 시 대응할 수 있도록 함.
Zookeeper와 Kafka의 관계
- Zookeeper는 Kafka 클러스터의 구성 정보 관리와 동기화를 담당합니다.
- Leader-Follower 모델: Zookeeper는 Kafka 클러스터 내 Broker 간의 동기화를 담당하며, 장애 처리 및 구성 변경을 관리합니다.
Kafka의 Producer 개념 및 작동 원리
1. Producer 역할
- Producer는 메시지를 생성하여 Kafka의 Topic으로 전송하는 애플리케이션입니다. 이를 통해 메시지가 여러 Consumer들에 의해 읽히고 처리됩니다.
2. Producer와 Consumer의 관계
- Consumer는 Topic에서 메시지를 읽고 처리하는 애플리케이션입니다. Consumer Group을 통해 여러 Consumer들이 협력하여 메시지를 병렬로 처리합니다.
3. 메시지 구조
- Kafka의 메시지는 Header, Key, Value로 구성됩니다. 메시지는 Byte Array로 저장되며, Serializer와 Deserializer를 통해 데이터를 바이트 배열로 변환하고 역직렬화합니다.
4. 메시지 전송 과정
- Producer는 메시지가 어떤 Partition으로 가야 하는지 결정해야 하며, Partitioner가 이를 도와줍니다. Key를 사용하여 Partition을 선택하거나, Kafka 2.4 이상에서는 Sticky Partitioner가 사용됩니다.
5. Serializer/Deserializer
- Producer는 데이터를 Serializer를 통해 Byte Array로 변환하고, Consumer는 이를 Deserializer를 통해 원래 데이터 형식으로 복원합니다.
6. Partitioner 종류
- Round Robin 방식과 Sticky 방식이 있으며, Kafka 2.4 이상에서는 Sticky Partitioner가 기본적으로 사용됩니다.
Kafka의 Replication(복제) 기술 개념
1. Replication(복제)
- Kafka는 Partition을 복제하여 장애가 발생하더라도 데이터를 손실 없이 복구하고, 가용성을 보장합니다. 각 Partition은 하나의 Leader와 여러 Follower를 가질 수 있습니다.
2. 장애 발생 시 복구
- Broker 장애 시, Partition의 복제본이 다른 Broker에 존재하면 데이터를 손실 없이 복구할 수 있습니다.
- Leader가 장애를 겪으면, Follower 중 하나가 Leader로 승격되어 자동 복구가 이루어집니다.
3. 복제 관련 주요 동작
- Consumer Lag와 Leader 장애 처리 등이 자동으로 관리됩니다.
- Rack Awareness 기능을 통해 Partition의 복제본을 여러 Rack에 분산시켜 장애 발생 시 복구를 빠르게 할 수 있습니다.
In-Sync Replicas (ISR) 개념 및 동작
1. ISR의 정의
- **ISR(In-Sync Replicas)**는 Leader와 Follower가 동일한 High Water Mark까지 복제된 상태를 유지하는 복제본 목록입니다.
2. High Water Mark (HWM)
- HWM은 Leader와 Follower가 동일하게 복제한 마지막 Offset을 의미합니다. 이 시점 이후의 메시지만 Consumer가 읽을 수 있습니다.
3. 복제 지연 및 문제점
- replica.lag.max.messages와 replica.lag.time.max.ms 옵션을 통해 Follower가 Leader로부터 데이터를 복제하는 속도를 관리하고, 지연되는 Follower를 Out-of-Sync Replica로 간주하여 ISR에서 제거할 수 있습니다.
4. Controller의 역할
- Controller는 Leader Election과 클러스터 구성 관리를 담당합니다. Controller가 장애를 겪으면 다른 Broker가 새 Controller로 선출됩니다.
Summary
- Producer는 Kafka Topic에 메시지를 전송하며, Serializer와 Partitioner가 메시지 전송에서 중요한 역할을 합니다.
- Kafka의 Replication과 In-Sync Replicas(ISR) 메커니즘은 장애 발생 시 데이터의 가용성과 일관성을 보장합니다. Leader가 장애를 겪으면, Follower 중에서 새로운 Leader가 자동으로 선출됩니다.
- Consumer는 High Water Mark를 기준으로 Committed 메시지만 읽을 수 있으며, Consumer Lag를 모니터링하여 메시지 처리의 일관성을 유지합니다.
Chapter 02.
더보기
Apache Kafka 심화 개념 및 이해
이번에는 Apache Kafka의 더 심화적인 부분들을 살펴보겠습니다. 이 내용은 주로 Producer의 설정 및 동작에 관한 상세한 설명입니다.
1. Producer Acks, Batch, Page Cache, Flush
Producer Acks
- **acks**는 메시지가 성공적으로 전송되었음을 보장하는 설정입니다. 이 값은 Kafka의 안정성과 성능을 조절하는 중요한 파라미터입니다.
- acks=0: 메시지를 전송한 후 ACK를 기다리지 않음. 빠른 메시지 전송을 원할 때 사용하지만 메시지 손실 가능성 있음.
- acks=1: (기본값) Leader가 메시지를 수신한 후 ACK를 보냄. Leader 장애 발생 시 메시지가 손실될 수 있음.
- acks=all (또는 acks=-1): 메시지가 모든 Replica에 복제되었을 때만 ACK를 보냄. 데이터 손실을 방지하지만 대기 시간이 길어질 수 있음.
Producer Retry (재전송)
- 재시도는 네트워크 오류나 시스템 오류를 보완하기 위해 메시지를 다시 전송하는 동작입니다.
- retries: 메시지를 전송하기 위한 최대 재시도 횟수.
- retry.backoff.ms: 재시도 사이의 대기 시간.
- request.timeout.ms: 응답을 기다리는 최대 시간.
- delivery.timeout.ms: send() 후 성공 또는 실패를 보고하는 시간의 상한.
2. Producer Batch 처리
Batch 처리
- Batch 처리는 여러 메시지를 모아서 한 번에 전송하는 방식으로, RPC 호출 횟수를 줄여 성능을 향상시킵니다.
- linger.ms: 메시지를 배치 처리할 때까지 대기하는 시간. 기본값은 0이며, 100ms로 설정하면 배치 처리 전에 메시지를 조금 더 대기할 수 있습니다.
- batch.size: 배치의 최대 크기입니다. 기본값은 16 KB이며, 성능을 위해 이를 100 KB 이상으로 설정할 수 있습니다.
Batch 처리 시의 동작
- Batching은 성능 최적화를 위한 중요한 기법입니다. 여러 개의 메시지를 하나의 네트워크 요청으로 묶어 보내면 Broker의 처리 부하를 줄일 수 있습니다.
- 예를 들어, **linger.ms**를 100ms로 설정하고 **batch.size**를 1MB로 설정하면, 최대 1MB까지 메시지를 모은 후 한 번에 전송됩니다.
3. 메시지 순서 보장 (enable.idempotence)
Idempotence 설정
- 메시지의 순서를 보장하려면 **enable.idempotence=true**로 설정해야 합니다.
- Idempotence는 메시지가 중복으로 전송되더라도 같은 결과를 보장하는 기능입니다.
- 예를 들어, 네트워크 오류로 인해 한 메시지가 재전송되더라도 원본 메시지의 순서를 보장할 수 있습니다. 이 설정은 **max.in.flight.requests.per.connection**을 통해 동시에 처리할 수 있는 요청 수를 제한할 수 있습니다.
순서 변경 문제
- 여러 개의 in-flight 요청을 보내면 메시지 순서가 변경될 수 있습니다. **enable.idempotence**가 켜져 있으면, 순서가 바뀌지 않도록 보장합니다.
4. Page Cache와 Flush
Page Cache
- Kafka는 Page Cache를 사용하여 디스크에서 직접 데이터를 읽고 씁니다. 이 방식은 Zero-copy 전송을 가능하게 하여 CPU 개입 없이 데이터를 네트워크 버퍼로 바로 전송할 수 있습니다.
- Kafka의 Log Segment는 기본적으로 OS Page Cache에 기록되며, 이는 성능을 크게 향상시킵니다.
Flush
- Flush는 Page Cache의 데이터를 디스크에 기록하는 동작입니다. Kafka는 Flush를 적절하게 관리하여 성능을 최적화합니다.
- Flush 조건:
- log.flush.interval.messages: 메시지가 일정 개수만큼 쌓이면 Flush.
- log.flush.interval.ms: 일정 시간 간격으로 Flush.
- Kafka는 OS의 background Flusher Thread를 활용하여 Flush 작업을 효율적으로 수행합니다.
- Flush 조건:
Flush 발생 시점
- Kafka의 장애 대응: 메시지가 Page Cache에만 있을 때 Broker 장애가 발생하면 메시지가 손실될 수 있습니다. 이를 방지하기 위해 Replication(복제)을 활용하여 데이터의 가용성을 높입니다.
- 복제된 Partition은 장애가 발생해도 데이터를 복구할 수 있습니다.
5. Kafka 클러스터 및 Producer, Consumer, Consumer Group 구조
Kafka의 Producer, Consumer, 그리고 Consumer Group은 메시지를 효율적으로 전송하고 처리하는 데 중요한 역할을 합니다.
- Producer는 메시지를 생성하고 Topic에 전송합니다.
- Consumer는 특정 Topic에서 메시지를 읽고 처리합니다.
- Consumer Group은 여러 Consumer들이 함께 협력하여 메시지를 병렬로 처리합니다. 하나의 Topic에 여러 개의 Consumer Group이 있을 수 있습니다.
6. Kafka의 데이터 흐름
- Producer는 Topic에 메시지를 보냅니다.
- Kafka Broker는 이 메시지를 여러 Partition에 저장하고, 복제를 통해 장애 대응을 합니다.
- Consumer는 해당 Topic의 Partition에서 메시지를 읽어 처리합니다.
- 여러 Consumer가 하나의 Consumer Group으로 묶여 병렬 처리할 수 있습니다.
7. 요약
- Producer Acks 설정을 통해 메시지의 안정성 및 성능을 제어할 수 있습니다.
- Batch 처리는 네트워크 호출을 줄여 성능을 향상시키는 데 중요한 역할을 합니다.
- Idempotence 설정을 통해 메시지 순서를 보장할 수 있으며, 동시에 여러 요청이 처리될 때 발생할 수 있는 순서 변경을 방지합니다.
- Page Cache와 Flush는 Kafka의 성능 최적화 및 데이터 손실 방지에 중요한 요소입니다.
이렇게 Apache Kafka의 심화 개념들을 이해하고 설정하는 것은 대규모 데이터 스트리밍 시스템을 운영할 때 매우 중요합니다. 이 지식을 활용해 Kafka를 더욱 효율적이고 안정적으로 사용할 수 있습니다.
Apache Kafka: Replica Failure 개념 및 처리 방법
Apache Kafka는 높은 가용성 및 데이터 복구를 위해 Replica(복제본) 개념을 사용합니다. 이 과정에서 Replica Failure가 발생할 수 있으며, 이를 처리하기 위한 Kafka의 내부 동작과 프로세스를 살펴보겠습니다.
1. In-Sync Replicas (ISR) 리스트 관리
- Leader는 각 파티션에 대해 In-Sync Replicas (ISR) 리스트를 관리합니다. ISR은 메시지가 커밋되기 전에 모든 복제본이 동기화되어야 할 Replica들을 나타냅니다.
- 메시지가 ISR에 포함된 모든 Replica에서 수신되면, 해당 메시지는 Commit된 것으로 간주됩니다.
2. Replica Failure 처리
Follower가 실패하는 경우
- Follower가 실패하면, 해당 Follower는 Leader에 의해 ISR 리스트에서 제거됩니다.
- Leader는 새로운 ISR 리스트를 사용하여 메시지를 Commit합니다.
- ISR 관리는 Leader가 유지하며, ZooKeeper는 이를 모니터링하여 ISR 리스트의 변화를 기록합니다.
Leader가 실패하는 경우
- Leader가 실패하면, Controller는 Follower들 중에서 새로운 Leader를 선출합니다.
- 새로운 Leader가 선출되면, Controller는 ISR 정보를 ZooKeeper에 기록하고, 이를 모든 Broker에 전파하여 Metadata를 업데이트합니다.
3. ISR 리스트와 장애 처리
Follower가 너무 느리면
- Follower가 replica.lag.time.max.ms 내에 fetch하지 않으면, Leader는 해당 Follower를 ISR에서 제거합니다.
- Leader는 ZooKeeper에 ISR 리스트를 업데이트하고, Controller는 이를 모니터링합니다.
Broker 장애 처리
- Broker의 장애가 발생하면, Controller는 해당 장애가 발생한 Partition에 대해 새로운 Leader를 선출하고, ISR 리스트를 갱신합니다.
4. 실제 장애 예시 (Broker 실패 시 처리)
Broker 4대, Partition 4, Replication Factor 3
- 예를 들어, Replication Factor가 3인 Topic이 있을 때, 여러 Broker가 각 Partition을 관리합니다.
- 각 Partition은 3개의 Replica를 갖고 있으며, 이를 통해 Broker 간에 데이터를 복제하여 고가용성을 보장합니다.
- 만약 하나의 Broker가 장애가 나면, 그 Broker가 담당하던 Replica는 다른 Replica로 대체됩니다.
Broker 장애 발생 시
- 예를 들어, Broker 104가 장애가 발생하면, 해당 Broker가 담당했던 Replica는 다른 Broker로 대체되며, Partition은 장애를 복구하기 위해 새로운 Leader를 선출할 수 있습니다.
Leader가 없으면?
- Partition에 Leader가 없으면, 해당 Partition을 사용할 수 없습니다. Producer는 메시지를 보내지 못하고, Consumer도 데이터를 읽을 수 없습니다.
- 만약 Producer가 retries 파라미터를 설정한 경우, Leader가 복구될 때까지 재시도합니다. 그러나 **retries=0**으로 설정되면, NetworkException이 발생하고 메시지 전송이 실패합니다.
5. 장애 복구 흐름 요약
- Follower가 실패하면, Leader는 해당 Follower를 ISR 리스트에서 삭제하고, 메시지를 새로운 ISR 리스트를 통해 Commit합니다.
- Leader가 실패하면, Controller가 Follower 중에서 새로운 Leader를 선출하고, 이를 ZooKeeper에 기록 후 모든 Broker에 전파합니다.
- Leader가 없으면, 해당 Partition은 사용 불가 상태가 되며, Producer는 재시도를 시도하거나 NetworkException이 발생합니다.
6. Replica Failure에 대한 결론
- Replica Failure는 Kafka 클러스터의 가용성을 보장하기 위해 중요한 역할을 합니다. Leader와 Follower 간의 복제 및 장애 처리 방식은 Kafka의 내구성과 고가용성을 확보하는 핵심 메커니즘입니다.
- Replica가 실패할 경우, Leader와 Controller가 협력하여 빠르게 장애를 복구하고, 메시지의 일관성을 유지합니다.
이와 같은 방식으로 Replica Failure는 Kafka의 복제와 장애 복구 메커니즘의 중요한 부분으로, 안정적이고 고가용성 있는 메시징 시스템을 구축할 수 있게 도와줍니다.
Apache Kafka: Replica Recovery 개념 및 이해
Apache Kafka는 **고가용성(Availability)**과 **내구성(Durability)**을 제공하기 위해 Replica(복제본) 개념을 사용하며, Replica Recovery는 장애가 발생한 후 데이터를 복구하는 중요한 프로세스입니다. 이 과정에서 acks, retries, idempotence 등 다양한 Kafka 파라미터가 중요한 역할을 합니다.
1. acks=all 의 중요성
- acks=all(또는 acks=-1)은 Producer가 메시지를 모든 Replica에 성공적으로 전송한 후에 ack를 받도록 설정하는 옵션입니다. 이를 통해 Kafka는 데이터 손실을 방지하고, 내구성을 보장합니다.
2. Replica Recovery 과정 (acks=all 설정 시)
시나리오:
- 3개의 Replica로 구성된 하나의 Partition에 메시지 4개(M1, M2, M3, M4)가 Producer에 의해 전송됩니다.
- acks=all, retries=MAX_INT, enable.idempotence=false로 설정되어 있습니다.
- ISR 리스트에는 **Leader (X)**와 두 **Follower (Y, Z)**가 있습니다.
메시지 전송 및 장애 상황:
- 메시지 M1, M2는 ISR 리스트의 모든 Replica에 복제되고 Commit됩니다.
- M3는 Follower Y에서 복제되었으나 Commit되지 않았고, M4는 아직 복제되지 않았습니다.
- 이때, **Broker X (Leader)**가 장애가 발생합니다. 새로운 Leader Y가 선출되고, Follower Z는 M3를 fetch합니다.
문제점:
- M3는 아직 Commit되지 않았는데, Leader Y는 M3를 가지고 있습니다. 이는 Leader Epoch의 증가로 인해 발생한 문제입니다. 장애가 발생하기 전에 M3는 ack를 받지 않았기 때문에, Producer는 M3에 대해 ack를 받지 못하고 재시도합니다.
3. acks=all에서의 메시지 재전송 및 중복 문제
중복 메시지 발생:
- idempotence=false일 경우, 재시도되는 메시지는 중복될 수 있습니다. Producer는 M3, M4를 다시 보내며, M3가 중복되는 상황이 발생합니다.
- Follower Z는 **M3 (중복)**과 M4를 fetch합니다.
- Z는 M3를 재조정하고 High Water Mark를 수신하여 Commit을 진행합니다. 그러나 M4는 복제되지 않아서 Producer는 이를 잃어버릴 수 있습니다.
결과:
- M4는 Producer가 재시도하지 않으면 영원히 손실되므로, 이 문제는 ack=all이 중요한 이유 중 하나입니다.
4. acks=1일 경우 (Leader 장애 후)
시나리오:
- acks=1로 설정된 경우, Producer는 M4에 대한 ack를 받지 않으므로, M4는 Leader Y가 장애 발생 후에도 Commit되지 않은 상태로 남습니다.
- 이때, Producer가 M4를 재전송하지 않으면, M4는 영원히 손실될 수 있습니다.
결과:
- acks=1 설정에서는 M4를 복구할 방법이 없으므로, 데이터 유실이 발생합니다. 이 점에서 acks=all 설정이 중요한 이유를 다시 한 번 알 수 있습니다.
5. 장애 발생 후 X 복구
시나리오:
- 장애가 발생했던 Broker X가 복구되면, X는 Follower로서 Leader Y로부터 복제를 시작합니다.
- Leader Epoch는 Y에서 1로 증가하고, X는 Y로부터 M3, M4를 복제합니다.
- X는 Leader로 복귀하지 않고 Follower로 남아, Zookeeper와 Controller에서 Metadata를 업데이트한 후 복제를 시작합니다.
결과:
- 복구된 X는 Leader Y로부터 M3, M4를 복제하고, ISR 리스트에 복귀합니다. 이로 인해 X는 장애 이전 상태로 복구됩니다.
6. Topic 파라미터: Availability와 Durability 선택
Kafka에서는 **가용성(Availability)**과 내구성(Durability) 사이의 균형을 선택할 수 있도록 여러 파라미터를 제공합니다.
Key 파라미터:
- unclean.leader.election.enable: ISR 리스트에 없는 Replica를 Leader로 선출할 것인지에 대한 옵션입니다.
- **false**일 경우: ISR 리스트에 있는 Replica만을 Leader로 선출하여 데이터 손실 방지.
- **true**일 경우: 데이터 유실을 감수하고 ISR에 없는 Replica를 Leader로 선출하여 고가용성 보장.
- min.insync.replicas: 최소 요구되는 ISR의 수입니다. 이 값을 증가시키면 Producer는 충분히 동기화된 Replica가 있을 때만 메시지를 전송합니다.
- 예를 들어, **min.insync.replicas=2**이면, 2개의 Replica가 동기화되어야만 메시지를 전송할 수 있습니다.
- acks: **acks=all**로 설정하면, 모든 Replica가 메시지를 성공적으로 받았을 때만 ack를 보냅니다. 이 설정은 내구성을 보장하지만 지연이 발생할 수 있습니다.
7. Summary
- Replication.factor: 복제본의 수. 내구성을 보장하려면 3 이상이 필요합니다.
- acks: **acks=all**을 설정하여 내구성과 데이터 손실 방지를 보장할 수 있습니다.
- min.insync.replicas: 최소 동기화된 복제본 수를 설정하여 가용성과 내구성을 균형 있게 설정합니다.
- unclean.leader.election.enable: 데이터 유실을 감수하고 가용성을 높이려면 **true**로 설정할 수 있습니다.
이러한 파라미터들을 적절히 설정하면, Kafka 클러스터에서의 가용성과 내구성을 조절할 수 있습니다.
Apache Kafka: Consumer Rebalance 개념 및 이해
Apache Kafka에서 Consumer Rebalance는 메시지를 처리하는 Consumer Group 내의 소비자들 간에 Partition을 재할당하는 과정입니다. 이 과정은 Consumer가 그룹에 새로 합류하거나 탈퇴할 때, 또는 그룹 내에서 설정 변경이 발생할 때 자동으로 발생합니다. 이 과정은 메시지 소비를 효율적으로 분배하고, 데이터 처리의 부하를 균등하게 하여 시스템의 안정성을 보장합니다.
1. Consumer의 동작 방식
- Kafka의 Consumer는 Partition에서 메시지를 가져오기 위해 poll 메서드를 사용하여 데이터를 주기적으로 가져옵니다.
- 가져온 offset 정보는 **__consumer_offsets**라는 Kafka 내의 특별한 Topic에 저장되어 관리됩니다.
Consumer의 기본 흐름:
- Consumer는 메시지를 **poll()**로 받아옵니다.
- 해당 메시지의 offset을 __consumer_offsets Topic에 기록합니다.
- Consumer Group 내에서 Consumer들은 메시지 소비를 분배받습니다.
2. Consumer Group 및 Partition 할당
- Consumer Group은 동일한 group.id를 가진 여러 Consumer들이 메시지를 분배하여 처리하는 단위입니다.
- 각 Partition은 하나의 Consumer에게만 할당되며, Partition을 여러 Consumer가 동시에 소비하지 않도록 합니다.
- Partition Assignment는 group.id를 기준으로 Partition을 분배하는 방식이며, 이 분배 방식을 partition.assignment.strategy 파라미터로 조정할 수 있습니다.
3. Group Coordinator 및 Rebalance 프로세스
Group Coordinator와 Leader:
- Consumer Group의 모든 Consumer들은 Group Coordinator라는 Broker에 등록됩니다.
- Group Coordinator는 Consumer Group의 상태를 관리하고, Partition 할당 및 Rebalance를 담당하는 역할을 합니다.
- Group Leader는 Consumer 중 하나가 될 수 있으며, Partition을 다른 Consumer들에게 할당합니다.
Rebalance 과정:
- Consumer들이 Group Coordinator에 등록되면, 각 Consumer는 자신에게 할당된 Partition에서 데이터를 소비하기 시작합니다.
- 새로운 Consumer가 Consumer Group에 합류하거나, 기존 Consumer가 탈퇴할 때 Rebalance가 발생하여 Partition이 재할당됩니다.
- Group Coordinator는 Consumer들의 요청에 따라 Partition을 할당하고, 그 정보를 ZooKeeper에 저장합니다.
4. Rebalance Trigger 조건
Consumer Rebalancing은 특정 조건에 의해 트리거됩니다. 주요 트리거 조건은 다음과 같습니다:
- Consumer가 Group에서 탈퇴: 만약 Consumer가 종료되거나 네트워크 문제로 탈퇴할 경우, Partition을 다시 다른 Consumer에게 할당해야 합니다.
- 새로운 Consumer가 Group에 합류: 새로운 Consumer가 Consumer Group에 합류하면, 기존 Partition을 새 Consumer에게 할당하기 위해 Rebalance가 필요합니다.
- Consumer가 Topic 구독을 변경: Topic이나 Partition이 변경되면, 기존의 할당을 다시 조정해야 합니다.
- Partition 증가: Topic의 Partition 수가 변경되면, 추가된 Partition을 Consumer들 간에 재배분해야 합니다.
5. Rebalancing 과정
- Group Coordinator는 Consumer에 Rebalance 신호를 보냅니다.
- Consumer는 **poll()**을 중지하고, 이전에 소비한 메시지의 offset을 commit합니다.
- Consumer는 새로운 Generation에 다시 합류하여 Partition을 재할당받고, 새로 할당된 Partition에서 다시 Consume을 시작합니다.
6. Consumer Heartbeats
- Consumer는 주기적으로 heartbeat를 보내 Group Coordinator와의 연결을 유지합니다.
- heartbeat.interval.ms(기본값: 3초) 동안 heartbeats가 수신되지 않으면 Consumer는 Consumer Group에서 삭제됩니다.
- session.timeout.ms(기본값: 10초) 내에 heartbeat가 수신되지 않으면 Consumer가 죽은 것으로 간주하고, Partition을 재할당합니다.
Heartbeats의 중요성:
- Consumer가 정상적으로 작동하고 있는지 확인하기 위해 heartbeat가 필수적입니다.
- 이 과정을 통해 Consumer 장애를 빠르게 감지하고, Rebalancing을 트리거할 수 있습니다.
7. Rebalancing을 최적화하는 방법
Rebalancing을 피해야 하는 이유:
- Rebalance 중에는 Consumer가 메시지를 처리할 수 없기 때문에, 불필요한 Rebalancing은 피해야 합니다.
- 불필요한 Rebalancing을 피하려면 다음과 같은 방법들을 사용할 수 있습니다:
- Consumer Group 멤버 고정:
- group.instance.id를 설정하여 Consumer가 항상 동일한 인스턴스로만 동작하도록 하여 Rebalancing을 최소화할 수 있습니다.
- session.timeout.ms 튜닝:
- heartbeat.interval.ms를 session.timeout.ms의 1/3로 설정하여, Consumer의 재가입 시간을 조정합니다.
- max.poll.interval.ms 튜닝:
- poll() 후 처리 시간을 충분히 제공하여, 과도한 Rebalancing을 방지할 수 있습니다.
8. Summary:
- Partition Assignment는 Consumer Group의 Consumer들이 Partition을 어떻게 소비할지를 결정하는 중요한 부분입니다.
- Consumer Rebalancing은 새로운 Consumer가 추가되거나 기존 Consumer가 탈퇴할 때 Partition을 재할당하는 과정입니다.
- Rebalancing은 Consumer가 **poll()**을 중단하게 만들므로, 불필요한 Rebalancing을 피하기 위해 최적화가 필요합니다.
- Heartbeats와 session.timeout.ms 등을 통해 Consumer 장애를 빠르게 감지하고, Rebalance가 발생하도록 합니다.
Kafka의 Consumer Group과 Partition 할당 및 Rebalancing을 적절히 관리하면, 시스템의 확장성과 안정성을 높일 수 있습니다.
'기타 (Other)' 카테고리의 다른 글
| [python] PDF 텍스트 추출해서 TXT 파일로 만들기 (0) | 2025.02.11 |
|---|---|
| [python] Flask 커스텀 헤더를 이용한 인증 예제 (1) | 2025.02.11 |
| [python] pandas (4) | 2025.01.09 |
| [python] decorator 예제 (0) | 2024.12.07 |
| [python] logging (0) | 2024.12.07 |