컨트롤러

💡 이번 포스팅에서는 컨트롤에 대해 정리해 보도록 하겠습니다.

 

카프카 클러스터 중 하나의 브로커가 컨트롤러 역할을 하게 되며, 파티션의 ISR 리스트 중에서 리더를 선출합니다.

리더를 선축하기 위한 ISR 리스트 정보는 안전한 저장소에 보관되어 있어야 하는데, 가용성 보장을 위해 주키퍼에 저장되어 있습니다.

컨트롤러는 브로커가 실패하는 것을 예의주시하고 있으며, 만약 브로커의 실패가 감지되면 즉시 ISR 리스트 중 하나를 새로운 파티션 리더로 선출합니다.

그러고 나서 새로운 리더의 정보를 주키퍼에 기록하고, 변경된 정보를 모든 브로커에게 전달합니다.

파티션의 리더가 다운됐다는 것은 해당 파티션의 리더가 없는 상태를 의미하며, 카프카 클라이언트인 프로듀서나 컨슈머가 해당 파티션으로 읽거나 쓰기가 불가능합니다. 이렇게 카프카 클라이언트가 읽기/쓰기를 하지 못하면 모든 읽기/쓰기 동작은 실패하게 되고, 클라이언트에 설정되어 있는 재시도 숫자만큼 재시도를 하게 됩니다.

따라서 클라이언트들이 재시도하는 시간 내에 리더 선출 작업이 빠르게 이뤄져야 합니다.

 

리더 선출 과정은 컨트롤러에 의해 이루어집니다. 파티션이 하나인 경우, 컨트롤러가 새로운 리더를 선출하고 리더 정보를 주키퍼에 기록하며 다른 브로커들에게 업데이트 정보를 전파하는 데는 그리 오랜 시간이 걸리지 않습니다.

하나의 파티션에 대해 리더 선출 작업이 약 0.2초가 걸린다고 가정하면, 하나의 파티션은 0.2초 만에 완료되는 반면 1만 개의 파티션에 대해 리더 선출이 이뤄져야 한다면, 전체 작업 소요시간은 약 2,000초가 걸리게 됩니다.

1대의 브로커 장애가 발생하고, 새로운 리더 선출 작업으로 카프카와 클라이언트 간에 30여 분간 통신이 끊어지는 사태가 발생한다면, 실시간 데이터 처리를 수행하는 부서들은 모두 장애 상황을 겪게 될 것입니다.

 

2018년 11월 릴리스 된 1.1.0 버전부터는 리더 선출 작업 속도가 빨라졌습니다.

카프카 버전 1.0.0에서 6분 30초가 걸리던 작업이 불필요한 로깅을 없애고 주키퍼 비동기 API가 반영된 1.1.0에서는 약 3초 만에 완료됐습니다.

출처 : https://www.confluent.io/blog/apache-kafka-supports-200k-partitions-per-cluster/

 

제어된 브로커 종료

 

제어된 브로커 종료란, 예기치 않은 브로커의 실패나 장애가 아니라 관리자에 의해 이뤄지는 자연스러운 종료 또는 안전한 종료라고 생각하면 됩니다.

 

제어된 종료와 장애로 인한 급작스러운 종료의 차이는 바로 다운타임입니다.

제어된 종료를 사용하면 카프카 내부적으로 파티션들의 다운타임을 최소화할 수 있습니다.

📢 브로커가 종료되기 전, 컨트롤러는 해당 브로커가 리더로 할당된 전체 파티션에 대해 리더 선출 작업을 진행하기 때문입니다.

 

제어된 종료를 사용하려면 controlled.shutdown.enable 옵션을 true로 설정해야 합니다.

 

 

리더 분포의 불균형

리더 분포의 불균형이란 리더 파티션이 각 브로커마다 골고루 분포되지 않았다는 뜻입니다.

 

Preferred Leader Election

1번처럼 m-brk-topic-dd 토픽의 파티션에 대한 정보를 보면 Replicas의 가장 첫 브로커로 설정되어 있는 것을 확인할 수 있습니다.

Replicas의 첫 브로커는 다른 말로 Preferred Leader라고도 하며, 파티션의 리더가 Preferred Leader와 동일한 경우 Preferred Leader의 균형이 맞다고 말합니다.

 

토픽의 정보를 먼저 조회 후 브로커 3을 종료했습니다. 그리고 다시 토픽의 정보를 조회하면 파티션 1번에 대한 리더는 브로커 1이 선출된 것을 확인할 수 있습니다.

 

그러고 나서 다시 브로커 3을 실행하게 되면, 일정 시간(기본 300초) 이후 리더를 재선출하게 되는데 이때 초기에 할당된 Preferred Leader로 선출하여 앞서 설명한 Preferred Leader의 균형을 맞춥니다.

그래서 마지막 3번처럼 일정 시간 이후 다시 토픽의 정보를 조회하면 리더가 Preferred Leader에 맞춰 변경되어 있는 것을 확인할 수 있습니다.

 

 

Unclean Leader Election

기존의 리더 브로커가 오랜 기간 살아나지 않을 경우 복제가 완료되지 않은, 즉 ISR이 아닌 OSR(Out of Sync Replica)인 팔로워 브로커가 리더가 될지 결정해야 합니다.

이때 기존의 리더 브로커가 가진 메시지 손실 여부를 감수하고 복제가 완료되지 않은 팔로워 브로커가 리더가 되게 하려면 unclean.leader.election.enable 옵션을 true로 설정하면 됩니다.

 

이 옵션이 있는 이유는 카프카는 데이터의 유실이 발생하더라도 카프카 서버가 중지되는 상황을 막아서 서비스 가용성을 보장하려는 목적이 있기 때문입니다.

 

만약 unclean.leader.election.enable 옵션을 활성화하지 않은 상태에서 ISR에서 더 이상 리더로 선출될 브로커가 없을 경우 아래와 같이 리더는 none으로 설정됩니다.

 

컨슈머는 리더 파티션에서 메시지를 읽기 때문에 리더가 none일 경우 컨슈머는 더 이상 메시지를 읽을 수 없게 됩니다.

 

출처: https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=freepsw&logNo=221028179182

 

 

 

 

참고 자료

• <실전 카프카 개발부터 운영까지> - 고승범 지음
• <인프런 카프카 완벽 가이드 - 코어편> - 권철민