카프카(Kafka)를 안정적이게 사용할 수 있도록 가용성 측면에서 활용되는 리플리케이션(Replication)과 리플리케이션(Replication)들중 리더(Leader)와 팔로워(Follower)에 대해서, ISR(InSyncReplica), 동작 방식에 대해서 알아보도록 하겠습니다.
리플리케이션(Replication)
데이터 파이프라인에 메인 허브 역할을 하는 카프카 클러스터가 정상적으로 동작하지 못한다거나 연결된 데이터 파이프라인에 영향을 미친다면 심각한 문제가 생길 수 있기 때문에 안정적인 서비스를 제공하기 위해 리플리케이션이라는 동작을 하도록 구상됐습니다.
리플리케이션이란 메시지들을 여러 개로 복제해서 카프카 클러스터 내 브로커들에 분산시키는 동작입니다.
카프카의 replication 동작을 위해 topic 생성 시 필수값으로 replication factor라는 옵션을 설정해야 합니다.
Kafka Container에서 replication 생성 예시를 진행해 보겠습니다.
Topic 생성 명령어 예시
docker-compose exec kafka bash
/opt/kafka/bin $ kafka-topics.sh --bootstrap-server kafka1:9092 --create --topic topic01 --partitions 1 --replication-factor 2
/opt/kafka/bin $ kafka-topics.sh --bootstrap-server kafka1:9092 --create --topic topic02 --partitions 1 --replication-factor 3
replication-factor라는 옵션값은 카프카 내 몇 개의 리플리케이션을 유지하겠다는 의미입니다.
topic01의 경우 —replication-factor 값이 2
- 원본을 포함한 리플리케이션이 총 2개 있다는 의미입니다.
topic02의 경우 —replication-factor 값이 3
- 원본을 포함한 리플리케이션이 총 3개가 있다는 의미입니다.
정확히는 kafka의 topic이 replication 되는 것이 아니라 partition 이 replication 되는 것입니다.
Replication factor 수가 커질수록 당연히 안정성은 높으나 broker의 resource를 많이 사용하게 됩니다.
복제에 대한 오버헤드를 줄여 최대한 broker를 효율적으로 사용하는 것을 권장합니다. Repliaction factor 수를 4 5 이상으로 설정할 수는 있지만 상황에 맞춰서 아래와 같이 권장합니다.
- 테스트나 개발 환경 : replication-factor 1 설정 권장
- 운영 환경(로그성 메시지로서 약간의 유실 허용) - replication-factor 2 설정 권장
- 운영 환경(유실 호용 하지 않음) - replication-factor 3 설정 권장
유의 사항은 당연하지만 각각의 replication-factor 숫자만큼 broker가 필요하다는 점입니다
ex)replication-factor 3인 경우 broker는 3개가 필요합니다.
Topic01 describe
Topic02 describe
ReplicationFactor : 위의 예시와 일치하는 숫자가 표시되어 있습니다.
Leader : Partition 0의 Leader는 각각 broker1과 broker3 임을 보여줍니다.
Replicas : Replication들은 topic01은 broker1,2에 topic02는 broker3,2,1라는 의미입니다.
Isr(In Sync Replica) : 현재 동기화되고 있는 리플리케이션들은 topic01은 broker1,2에 topic02는 broker3,2,1라는 의미입니다. 자세한 내용은 아래에 자세하게 설명하겠습니다.
카프카는 N - 1까지의 브로커 장애가 발생해도 메시지 손실 없이 안정적으로 메시지를 주고받을 수 있습니다.
topic2를 기준으로 3개의 브로커가 있으므로 그중 2대의 브로커가 장애가 발생하더라도 남은 1대의 브로커가 클라이언트들의 요청을 안전하게 처리할 수 있게 됩니다.
Leader(리더) & Follower(팔로워)
topic describe 명령어를 통해서 보면 leader라는 부분이 존재합니다.
과연 leader는 무엇이고 어떤 역할을 할까요?
Leader만의 역할이 존재하기 때문에 카프카에서는 Leader를 특별히 따로 강조해서 표시합니다.
카프카는 내부적으로 동일한 리플리케이션들을 Leader와 Follower로 구분하고 각자의 역할을 분담시킵니다.
Leader는 리플리케이션중에서 하나가 선정되며 모든 읽기와 쓰기는 그 리더를 통해서만 가능합니다.
각각의 파티션의 Leader만 읽기가 쓰고 가능하기에 리더들에게 메시지가 보내지며 Consumer들도 리더들로부터 메시지를 가져옵니다.
Follower들은 Leader가 이슈가 있을 경우를 대비해 언제든지 새로운 Leader가 될 준비를 합니다.
지속적으로 새로운 메시지를 확인하고 새로운 메시지가 있으면 Leader로부터 메시지를 복제합니다.
ISR(InSyncReplica)
ISR은 도대체 무엇일까요?
ISR이라는 논리적인 그룹에 Leader와 Follower는 묶여있으며 ISR 그룹에 속하지 못한 Follower는 새로운 Leader가 될 수 있는 자격이 없습니다.
🤔 ISR로 따로 그룹화 한 이유가 무엇일까요?
Follower 역시도 불완전한 상태로 존재할 수 있고 불완전한 Follower가 새로운 Leader가 된다면 데이터의 정합성이나 메시지의 손실과 같은 치명적인 문제가 발생할 수 있기 때문입니다.
Leader는 만약 특정 Follower가 특정 주기의 시간만큼 복제요청을 진행하지 않는다면 Replication 동작에 문제가 발생했다고 판단 ISR 그룹에서 추방하며 해당 Follower는 Leader가 될 자격을 박탈당합니다.
역으로 다시 보면 Topic의 상태가 의심될 때 Topic ISR 상태를 점검해 봄으로써 Topic의 상태가 양호한 지 불량한 지에 대해서 확인할 수 있습니다.
ISR 그룹 내에 모든 Follower에게 복제가 완료되면, Replication Factor 수만큼 전부 메시지를 저장했다면, 커밋되었다는 표시를 하며 마지막 커밋 Offset 위치는 high water mark라고 부릅니다.
log-end-offset은 해당 토픽 파티션에 저장된 데이터의 끝을 나타내며(브로커가 관리함), 파티션에 쓰고 클러스터에 커밋된 마지막 메시지의 오프셋입니다.
이전 글에서 LAG라는 개념을 잠깐 다루었습니다.
https://colevelup.tistory.com/18
[Kafka] Topic, Partition, Offset, Segement(segement, Segement 관리)
토픽(Topic) Topic Event는 무엇인가 발생한 사실에 대한 record이며 record 또는 message라고 공식 document에서는 말합니다. Events are organized and durably stored in topics. Very simplified, a topic is similar to a folder in a fil
colevelup.tistory.com
바로 그 LAG가 컨슈머 Current-Offset과 브로커의 Log-End-Offset 간의 차이로 만들어집니다.
메시지의 일관성을 유지하기 위해서 커밋된 메시지만 Consumer가 읽어갈 수 있습니다.
🤔 만약 커밋되기 전 메시지를 Consumer가 읽을 수 있다고 가정한다면?
Consumer A와 B는 동일한 Topic Partition을 읽었지만 Consumer A는 Message A와 Message B를 읽어왔고 Consumer B는 Message A만 가져왔습니다.
커밋되지 않은 메시지를 Consumer가 읽어 갈 수 있는 경우 동일한 Topic에 Partition에서 Consume 했었음에도 메시지가 일치하지 않는 현상이 발생할 수 있습니다
그렇다면 커밋된 위치를 어떻게 알 수 있을까요?
모든 broker는 재시작 시 커밋된 메시지를 유지하기 위해 로컬디스크에 replication-offset-checkpoint라는 파일에 마지막 커밋 offset 위치를 저장합니다.
kafka1 container에서 replication-offset-checkpoint를 확인해 보도록 하겠습니다.
bash로 붙는 명령어는 생략하도록 하겠습니다.
kafka/kafka-logs-{$hash}/ cat replication-offset-checkpointcat 명령어로 replication-offset-checkpoint를 출력해 보면
log-message-test는 topic 명이고 각각 1, 0은 Partition number, 뒤에 각각 붙어있는 1은 커밋된 Offset 번호를 의미합니다.
producer명령어를 통해서 message를 추가적으로 전송한다면.
커밋된 Offset 번호가 증가한 것을 확인할 수 있습니다
replication 된 다른 broker들에서도 동일한 명령어를 이용해 확인 가능하며 모두 동일한 offset 번호를 나타냄을 알 수 있습니다.
특정 topic에 partition에 복제가 되지 않거나 문제가 있다고 판단되는 경우 replication-offset-checkpoint라는 파일의 내용을 확인하고 replication 되고 있는 다른 broker들과 비교해 보면 어떤 broker, topic, partition에 문제가 있는지 파악할 수 있습니다.
Leader와 Follower 간의 Replication 동작
kafka는 Leader와 Follower간 통신 최적화를 어떻게 구현해 두었을까요?
1. Leader는 1번 Offset 위치에 두 번째 새로운 메시지인 message2를 Producer로부터 받은 뒤 저장합니다.
2. 0번 메시지에 대해 replication을 마친 Follower들은 Leader에게 1번 Offset에 대한 Replication을 요청합니다.
3. 요청을 받은 Leader는 0번 Offset에 대한 Repliaction 동작이 성공했음을 인지하고 high water mark를 증가시킵니다.
만약 follower가 Replication을 성공하지 못했다면 이후 1번 Offset에 대한 요청이 아닌 0번 Offset에 대한 Replication요청을 보내게 됩니다.
Leader는 Replication요청의 Offset을 보고 follower들이 어느 위치까지 Replication을 성공했는지 인지할 수 있습니다.
1. Follower들로부터 1번 Offset 메시지에 대한 Replication 요청을 받은 Leader는 응답에 0번 Offset 메시지가 커밋되었다는 내용도 함께 전달합니다.
2. Leader에 응답을 받은 모든 Follower는 0번 Offset 메시지가 커밋되었다는 사실을 알고 Leader와 동일하게 커밋을 표시합니다 그리고 1번 Offset에 있던 메시지를 Replication 합니다.
이과정을 반복하면서 Leader와 Follower 간 메시지의 최신상태를 유지합니다.
ack통신의 제거와 Follower의 pull
메시지 하나를 Replication 할 때 ack가 보내지고 그에 따른 ack를 다시 보내는 2회의 통신을 주고받는다고 해도 메시지가 1만 개가 들어온다면 2만 회의 통신비용이 생깁니다.
카프카는 Leader와 Follower 간 Follower가 메시지를 잘 받았는지 ack 통신을 하는 단계를 제거했습니다.
카프카는 Leader가 메시지를 직접 전달하는 push방식이 아닌 Follower들이 pull 하는 방식으로 동작함으로써 Leader의 부하를 줄여줄 수 있게 되었습니다.
하지만 high water mark를 활용하여도 특정 복구 동작시에는 메시지가 유실될 수 있기 때문에 Leader-Epoch를 활용하여 복구동작을 진행하기도 합니다 Leader-Epoch에 대해서는 추후 포스팅을 통해서 진행하겠습니다!
참조
Kafka 운영자가 말하는 Topic Replication | Popit
Kafka Replication Factor: A Comprehensive Guide
Kafka - difference between Log end offset(LEO) vs High Watermark(HW)
RabbitMQ vs Kafka Part 6 - Fault Tolerance and High Availability with Kafka - Jack Vanlightly
'MessageQueue > Apache Kafka' 카테고리의 다른 글
| [Kafka] Kafka와 zero-copy (0) | 2023.01.30 |
|---|---|
| [Kafka] Leader Epoch(리더 에포크)을 활용한 카프카 브로커(kafka broker) 복구 (1) | 2023.01.28 |
| [Kafka] Topic, Partition, Segment, Segment 관리, Offset (0) | 2023.01.21 |
| [Kafka] kafka cluster 실습 환경 구축 (0) | 2023.01.21 |
| [Kafka] Kafka 도입 사례로 보는 Kafka 사용의 당위성과 이점 (1) | 2023.01.15 |
댓글