컨트롤러
컨트롤러 역시 카프카 브로커 중 하나이며 일반 브로커의 기능에 더하여 파티션 리더를 선출하는 책임을 갖는다.
컨트롤러 선출 과정
카프카 클러스터가 실행되면 모든 브로커들은 최상위 노드에 /controller 임시 노드를 생성하려고 한다. 이 때 가장 먼저 실행된 브로커가 임시 노드를 생성하고 컨트롤러가 되며 나머지 브로커들은 ‘노드가 이미 존재한다’는 예외를 받고 이미 /controller 임시 노드가 있다는 것과 클러스터에 컨트롤러가 있다는 것을 알게 된다. 이후에 모든 브로커들은 /controller 노드에 주키퍼의 watch를 생성하여 controller 노드에 변화가 생기면 바로 알 수 있도록 한다.
컨트롤러 재선출
컨트롤러 브로커가 중단되거나 연결이 끊기면 임시 노드였던 /controller가 삭제된다. 다른 브로커들은 주키퍼의 watch를 통해 controller를 바라보고 있었기 때문에 삭제되었다는 것을 바로 알게되고 controller 임시 노드를 생성하는 시도를 한다. 이후엔 마찬가지로 컨트롤러 선출과 마찬가지로 제일 먼저 controller 임시 노드를 생성한 브로커가 컨트롤러 브로커가 되고, 나머지 브로커들은 새로 생성한 controller 임시 노드에 주키퍼 watch를 생성하고 변화가 생길 경우 알 수 있도록 한다.
컨트롤러는 생성될 때 마다 컨트롤러 세대 번호를 부여받는다. 브로커들은 이 컨트롤러 세대 번호를 통해 지금 받은 컨트롤러 메시지가 새로 만들어진 컨트롤러의 메시지인지(가장 최근의 컨트롤러의 메시지) 예전의 컨트롤러인지 파악한다. 예전의 컨트롤러 세대 번호로 받은 메시지는 무시한다.
리더 재선출
한 브로커가 클러스터를 떠난 것을 컨트롤러가 인식하면 그 브로커에 어떠한 리더 파티션들이 있었는지 확인하고 새로운 리더가 될 브로커를 결정한다. 새롭게 선출된 리더와 팔로워들의 정보를 브로커들에게 전송한다.
새로 선출된 각 파티션의 리더는 프로듀서와 컨슈머의 요청을 자신이 처리해야함을 인식하고 팔로워들은 새로운 리더에게서 메시지를 복제해야 함을 인식한다.
'Data Engineering > Kafka' 카테고리의 다른 글
Producer의 send() method 수행 과정 (feat. flush()) (2) | 2022.03.15 |
---|---|
카프카 내부 메커니즘 - 4. 요청 처리 (0) | 2022.02.17 |
카프카 내부 메커니즘 - 1.클러스터 멤버십 (0) | 2022.02.15 |
Kafka의 Zero copy (0) | 2022.02.12 |
Kafka의 구조와 원리 (0) | 2021.07.04 |