Kafka의 핵심 아키텍처 이해하기: 토픽부터 ISR까지
Apache Kafka는 대용량의 실시간 데이터 스트리밍을 처리하기 위한 분산 메시징 시스템입니다. 브로커중 하나가 도중에 다운 되어 버리면 어떻게 할까요?? 중간에 쌓였던 메시지들하고 새롭게 유입되는 메세지들의 손실이 있을 것입니다. 이로인해 서비스 운영에 차질이 생길 수도 있습니다. 이를 방지하기위한 기술인 Replication과 ISR에 대해서 다뤄볼까합니다.
1. Topic, Partition, Segment: Kafka의 데이터 구조
우선 Replication과 ISR에 대해서 설명하기 전에 Topic과 Partition, Segment에 대해서 이해를 하고 있어야 합니다. 우선 논리 적인 측면에서 바라본다면 다음과 같습니다.
우선 Topic은 메시지를 분류하는 논리적인 단위입니다. Topic은 여러개의 Partition으로 나뉘며, 각 Partition은 메시지의 순서를 보장하고 병렬 처리를 가능하게 합니니다. 각 Partition은 Segment라는 파일 단위로 물리적으로 저장이 되며, Segment는 디스크에 저장되는 실제 파일로, 메시지의 저장 및 삭제를 효율적으로 관리합니다. Segment파일은 특정기간이 지나거나 파일의 크기가 특정값을 넘어가게되면 새롭게 생성되어 저장이됩니다.
물리적 관점으로 보면 다음과 같습니다.
Topic별 Partition들은 여러 Broker들에 분산되어 위치해 있고 Partition별로 독립적으로 유지가 되며 Partition들 안에 Segment file들은 위에 그림과 같이 저장이 됩니다.
2. Commit Log와 Consumer Lag: 메시지 처리 상태 추적
Kafka는 메시지를 로그 형태로 저장하며, Consumer는 오프셋을 기반으로 메시지를 읽습니다. Current Offset는 Consumer가 마지막으로 커밋한 메시지의 위치이고, Log End Offset는 Broker에 저장된 가장 최신 메시지의 위치입니다. Consumer Lag는 Log End Offset과 Current Offset의 차이로, Consumer가 얼마나 뒤처져 있는지를 나타냅니다. Consumer Lag은 시스템의 처리 지연을 모니터링하는 데 중요한 지표입니다.
3. Broker 장애가난다면??
만약 위에 그림처럼 Broker-103이 다운이 되어버린다면 어떻게 될까요?? 그 전에 쌓여있던 메시지와 새롭게 들어오는 메시지에 대한 손실이 생길 것입니다.
그렇다면 위에 그림과 같이 기존 Broker-103에 있던 Partition들을 Broker-102과 Broker-104에 새롭게 생성하면 되지 않을까 싶습니다. 이렇게 해버려도 처음에 말했던 것처럼 그 전에 쌓여있던 메시지와 새롭게 생성되기 전까지 들어오는 메시지에 대한 손실이 생길것입니다. 그렇다면 어떻게 해결을 해야할까요??
4. Replication과 리더 재선출: 고가용성 보장
위에 문제를 해결할 수 있는 방법이 Replication을 설정하면 됩니다. Leader Partition과 Follower Partition들이 있습니다. Leader Partition에서 Producer가 메시지를 write를 하게 되면 각각의 Follower들은 해당 메시지를 Leader쪽에서 가져오게 됩니다.
그러면 3번에서 문제로 삼았던 Broker가 다운되었을때 어떨까요??
일을 수행하고 있던 Leader쪽의 Broker가 다운이 되면 위에 그림과 같이 Follower들중 하나를 Leader로 선출하게 되고 Producer와 Consumer는 새로운 Leader쪽으로 붙게됩니다. 그러면 Follower들이 어떻게 Leader에서 읽어오고, 리더 재선출을 할때 어떤 기준으로 Follower들중 한개를 선출하는지는 글 마지막 부분에서 다루겠습니다.
5. 리더의 불균형 분산 방지: Hotspot 문제 해결
모든 파티션의 리더가 특정 브로커에 집중되면 해당 브로커에 부하가 집중되어 성능 저하가 발생할 수 있습니다. 이를 방지하기 위해 Kafka는 auto.leader.rebalance.enable 설정을 제공합니다. 이 설정이 활성화되면, Kafka는 주기적으로 파티션 리더의 분포를 확인하고, 불균형이 감지되면 리더를 재분배하여 부하를 균등하게 분산시킵니다. 이러한 자동 리더 리밸런싱은 클러스터의 안정성과 성능을 유지하는 데 중요한 역할을 합니다.
6. Leader / Follower 작동 방식: Fetcher Thread
이제 Leader와 Follower의 작동 방식에 대해서 살펴보자! 우선 Leader쪽으로 Producerrk write을 수행하고 하게된다.
우선 Leader쪽으로 Producerrk write을 수행하고 하게된다.
각각 Follower들이 있는 Broker에서 Fetcher Thread가 동작을 하게 되어 Leader로 부터 새로운 메시지를 Fetch해 오고 자신의 Commit Log에 기록을 하게 된다.
Leader에서는 High Water Mark를 이동하게 되고 두번째로 Fetcher Thread가 동작을 할때는 Null를 전달해준다.(새로운 메시지가 없다면!)
세번째로 Fetcher Thread가 동작을 하게될때 각각 Follower들의 High Water Mark도 이동하게 됩니다.
마지막으로 한꺼번에 정리하자면, Kafka에서 Leader와 Follower 간의 데이터 동기화는 Fetcher Thread를 통해 이루어집니다. Leader는 프로듀서로부터 메시지를 수신하고, 각 Follower는 Fetcher Thread를 통해 Leader로부터 새로운 메시지를 가져와 자신의 커밋 로그에 기록합니다. 이 과정에서 Leader는 High Water Mark(HWM)를 관리하여, 모든 ISR 구성원이 해당 메시지를 복제한 시점을 기준으로 커밋된 메시지를 결정합니다. Follower는 Fetcher Thread를 통해 주기적으로 Leader로부터 데이터를 가져오며, 새로운 메시지가 없을 경우에는 Null을 전달받습니다. 또한, Leader 브로커 내에도 다른 파티션의 Follower 역할을 수행할 수 있으므로, 해당 브로커에도 Fetcher Thread가 존재합니다.
7. ISR (In-Sync Replica): 동기화된 복제본 관리
ISR(In-Sync Replica) 목록은 리더와 동기화된 팔로워들의 집합으로, 리더는 이 목록을 기반으로 데이터의 복제 상태를 관리합니다. ISR에 포함되기 위해서는 팔로워가 리더로부터 데이터를 정상적으로 복제하고, High Water Mark(HWM)를 따라잡아야 합니다. 만약 ISR 목록에 있는 리더 브로커가 다운되면, ISR 내의 다른 팔로워 중 하나가 새로운 리더로 선출됩니다.
추가로, Kafka는 KIP-966을 통해 ELR(Eligible Leader Replicas) 개념을 도입하여, ISR이 최소 요구 수(min.insync.replicas)보다 작아지는 상황에서도 데이터 손실 없이 리더 선출이 가능하도록 개선하였습니다. ELR은 ISR에서 제외되었지만, 여전히 커밋된 데이터를 보유하고 있는 복제본들을 포함하며, 이러한 복제본은 리더 후보로 고려됩니다. 이를 통해, “마지막 복제본이 다운되는” 상황에서도 데이터의 무결성을 유지할 수 있습니다.
마무리
Kafka의 아키텍처는 고가용성과 데이터 무결성을 보장하기 위해 정교하게 설계되어 있습니다. Topic, Partition, Segment의 구조부터 Replication, ISR, 리더 선출 메커니즘까지, 각 요소들이 유기적으로 작동하여 안정적인 데이터 스트리밍을 가능하게 합니다. 이러한 구조와 메커니즘을 이해하면, Kafka를 더욱 효과적으로 활용하고, 발생할 수 있는 문제에 대한 대응 능력을 향상시킬 수 있습니다.
