minkukjo
commented
2 years ago 느낀 점
- 요즘 나오는 대부분의 HA를 지원하는 서비스들은 레플리케이션이 기본인 듯 하다. ( ES, MySQL, Kafka 등등.. )
- 레플리케이션의 대상은 토픽이 아닌, 하나의 토픽 내에 존재하는 파티션 단위로 복제를 한다.
- 결국은 브로커들이 모든 레플리케이션의 복제본을 가지게 된다. 이론적으로는 N-1까지의 브로커가 장애가 발생해도 메시지 손실없이 안정적으로 메시지를 주고 받는 것이 가능하다.
- 지난 주에 희찬님이 질문하시고 모두가 궁금해했던
Broker가 죽는다면 새로운 Replication이 다른 브로커로 복제되는건가?의 대답이 바로 나왔다.
- 지난 주에 희찬님이 질문하시고 모두가 궁금해했던
카프카의 복제 방식
-
하나의 토픽의 파티션들은 레플리케이션에서 리더와 팔로워로 존재하게 된다.
- 일반적으로 하나의 토픽은 병렬 처리를 위해 여러 개의 파티션으로 분리된다.
- 이 여러 개로 나누어진 파티션 중 하나의 레플리케이션에서 리더가 존재하게 된다.
- 리더는 레플리케이션 중 하나로 선정되며, 나머지 레플리케이션의 파티션들은 팔로워가 된다.
- 결국 프로듀서는 모든 레플리케이션에 메시지를 쓰는게 아니라, 리더에게만 쏘고 컨슈밍하는 구조인 것이다.
- 그럼 리더가 Read/Write를 다하는데 나머지 팔로워들은 노는건가? 라고 생각하지만, 그렇지는 않고 리더가 문제가 생기면 언제든 새로운 리더가 될 준비를 하고 있다.
- 따라서 컨슈머가 토픽의 메시지를 꺼내가듯이, 지속적으로 리더가 새로운 메시지를 받았는지 확인하고 새로운 메시지가 있으면 해당 메시지를 리더로부터 복제한다. ( Polling 방식을 사용하는 것으로 추측됨 )
-
리더와 팔로워는 ISR(In Sync Replica)라는 것으로 묶이게 되고, 이 그룹에 속한 팔로워만이 리더가 될 수 있다.
-
리더는 그룹 내에 존재하는 팔로워들의 데이터를 일치시키고 유지하기 위해 지속적으로 리더의 데이터를 따라가게 된다.
-
즉, 리더에 뒤쳐지지 않고 잘 따라잡고 있는 팔로워만이 ISR 그룹에 속하게 된다.
-
리더는 특정 주기의 시간만큼 복제 요청을 하지 않는 팔로워를 ISR 그룹에서 추방한다.
-
ISR 그룹 내에서는 모든 팔로워의 복제가 완료되었을 때 리더는 내부적으로 커밋되었다는 표시를 하게 된다.
-
마지막 커밋 오프셋 위치는 하이워터마크 라고 부른다. (High Water Mark)
-
복제가 되기 전 커밋이 되어버리면 리더가 바뀌고난 뒤에 컨슈머가 컨슈밍한 메시지가 다른 이슈가 생길 수 있다.
-
그래서 복제에서는 복제가 완료된 뒤에야 비로소 커밋이 되게 된다.
리더와 팔로워간의 동작
- 리더는 모든 메시지의 Read/Write를 담당해야해서 매우 바쁨.
- 근데 이런 리더가 팔로워들이랑 통신하면서 레플리케이션에 관여하기 시작하면 성능이 급격하게 떨어지게 될 것임.
- 카프카에서 리더는 팔로워들의 복제가 성공적으로 완수되었는지에 대한 ACK 통신을 하지 않는다.
- 원리는 간단하다. 팔로워들이 리더에게 N번째 오프셋을 요청하게 되면, 리더는 N-1 메시지가 성공적으로 복제되었다고 간주하고 N-1 오프셋에 대해 커밋 표시와 하이워터마크를 증가시킨다.
- 만약 팔로워가 N-1번째 오프셋에 대한 레플리케이션에 실패한다면, 다시 N-1 번째로 요청하게 될터이니, 리더는 팔로워들이 보내는 레플리케이션 요청의 오프셋을 보고, 어느 위치의 오프셋까지 성공했는지 알 수 있게 된다.
- N번째 레플리케이션 요청에 리더가 응답할 때 N-1번째 오프셋이 커밋되었다는 사실도 함께 응답으로 보낸다.
- 리더의 응답을 받은 모든 팔로워들은 N-1번의 오프셋을 커밋표시한다.
- 그리고 N번째 오프셋 메시지를 레플리케이션한다.
- 카프카는 이러한 ACK 응답을 제거하여 빠른 성능을 얻었을 뿐만 아니라, 신뢰성을 확보했다는 점이 놀랍다.
- 결국 팔로워들이 리더에 pull하는 방식으로 동작해서 리더의 부하를 최소화 시킨 모델을 사용했다.
리더에포크와 복구
- Leader Epoch는 카프카의 파티션들이 복구 동작을 할 때 메시지의 일관성을 유지하기 위한 용도로 사용된다.
- 하이워터마크를 사용해서 오프셋의 마지막 커밋 위치를 리더와 팔로워가 동기화하게 되는데, 만약 이 과정 중 리더는 하이워터마크를 올렸는데, 팔로워가 올리기 전에 장애가 나서 다운된다면?
- 팔로워는 리부트된 직후 복구 모드로 들어가게 된다.
- 팔로워는 자신이 가진 메시지 중 자신의 워터마크보다 높은 메시지들은 신뢰할 수 없다 판단하고 지워버린다.
- 그리고 나서 다시 해당 워터마크 이후부터 새로운 메시지를 리더에게 요청한다.
- 근데 갑자기 리더가 죽어버려서, 방금 잠에서 깨어난 팔로워가 리더로 승격된다.
- 이렇게되면 결국 복구 직후 지웠던 메시지는 영영 유실되게 되어버린다.
- 이 때 리더에포크를 사용하는데, 앞서 팔로워가 자신의 워터마크보다 높은 메시지를 지우기 전, 리더에게 리더에포크 요청을 보낸다.
- 요청을 받은 리더는 리더에포크 응답으로 리더가 어디까지 메시지를 받았는지 알려준다.
- 팔로워는 자신의 워터마크보다 높은 메시지와 리더의 메시지가 동일하다면 ( 비록 팔로워의 워터마크 값은 리더보다 낮지만 ) 메시지를 지우지 않고 자신의 워터마크를 리더가 갖고 있는 값 만큼 상향 조정한다.
컨트롤러
- 카프카 클러스터 중 하나의 브로커가 컨트롤러 역할을 담당.
- ISR 리스트 정보는 일반적으로 주키퍼에 저장.
- 파티션 리더가 다운될 수도 있는데, 이는 파티션의에 리더가 없는 것을 뜻하며 프로듀서나 컨슈머가 읽기/쓰기 동작을 할 수 없다는 것을 의미한다.
- 클라이언트는 정해진 재시도 횟수와 시간에 따라 재시도를 수행하는데, 이 때 리더 선출 작업이 빠르게 이루어져야 클라이언트의 요청을 처리할 수 있다.
- 컨트롤러는 리더를 선출해서 리더 정보를 주키퍼에 기록하고, 바뀐 리더에 대한 정보를 모든 브로커에게 전파한다.
로그
- 카프카의 메시지는 각 브로커에 세그먼트라는 파일에 저장된다.
- 로그 세그먼트의 최대 크기는 1GB가 기본값이다.
- 커지면 기본적으로 롤링한다.
- 그러니까 1GB가 꽉차면 새로운 파일에 쓰기 시작한다는 뜻.
- 로그 세그먼트는 브로커에서 설정으로 주기적으로 지워줄 수 있다.
- 세그먼트 컴팩션도 존재하는데, 로그를 삭제하지 않고 압축해서 보관하는 것이다.
- 컨슈머 그룹은 항상 마지막으로 커밋된 오프셋 정보를 필요로 하기 때문에, 과거에 커밋된 정보는 삭제되어도 문제가 없다.
- 그래서 로그 컴팩션은 메시지의 키 값을 기준으로 가장 마지막 값이 필요한 경우에 사용된다.
- 로그 컴팩션의 장점은 역시 빠른 장애 복구이다. 장애 복구 시 전체 로그를 복구하지 않고 가장 최신의 상태로 복구할 수 있기 때문이다.
MinJunKweon
메모
replication-factorcontrolled.shutdown.enablelog.cleanup.policy가delete(default)여야 함retention.ms: 메시지(log)를 얼만큼의 기간동안 보관할지 설정 (default 7 days)retention.bytes: 메시지(log)를 얼만큼의 용량만큼 보관할지 설정 (default -1; 제한 없음)log.retention.check.interval.ms: 일정 주기를 가지고 체크하여 로그 삭제 (deafult 5 min)log.cleanup.policy가compact여야 함__consumer_offset토픽(consumer group이 특정 topic을 어디까지 읽었는지 저장)이 compaction 사용느낀점
궁금한 점
팔로워가 특정 주기의 시간만큼 복제 요청을 하지 않는다면, 리더는 해당 팔로워가 리플리케이션 동작에 문제가 발생했다고 판단해 ISR그룹에서 추방합니다.특정 주기-> 옵션?ISR 그룹에서 추방하면 무슨 일이 벌어질까? 새로운 팔로워를 찾을까?ISR 리스트 정보는 가용성 보장을 위해 Zookeeper에 저장Kafka 3.0부터는 어떻게 저장할까? KRAFT?