Kafka Broker & Zookeeper란?
Kafka Broker & Zookeeper란?
브로커(broker)는 실행된 Kafka application 서버를 뜻한다.
주키퍼(zookeeper)는 이러한 분산 메세지 큐의 정보를 관리해 주는 역할을 한다.
kafka를 띄우기 위해서는 주키퍼가 반드시 실행되어야 한다.
3대 이상의 브로커로 클러스터를 구성한다.
주키퍼와 연동(~2.5.0버전)
- 주키퍼의 역활 : 메타데이터(브로커id, 컨트롤러id 등) 저장
- 추후에는 주키퍼와 연동하지 않도록 구성할 예정 → 메타데이터를 브로커 안에 저장
n개 브로커 중 1대는 Controller기능을 수행한다.
- Controller : 각 브로커에게 담당파티션 할당 수행, 브로커 정상 동작 모니터링 관리
- 누가 Controller인지는 zookeeper에 저장
Broker partition replication
Kafka에서는 파티션(partition) 단위로 분산처리를 수행한다.
이 분산 처리를 할 때 핵심적인 기능이 바로 복제(Replication)이라 볼 수 있다.
분산 처리를 할 때에는 모든 브로커에 데이터를 동일하게 보내는 것이 아니라 Master -> Slave 방향으로 데이터를 복제하는 것처럼 Kafka는 리더(leader) 파티션이 팔로워(follower) 파티션에 복제를 수행하게 된다.
파티션들은 어떤 브로커에서 리더가 될지는 모르며 리더의 선출을 주키퍼(zookeeper)가 진행하게 된다.
왜 복제하는가?
장애 대응과 데이터의 유실을 막기 위해(고가용성) 복제를 한다.
하나의 브로커에 파티션(partition)을 몰아주지 않는 것은 데이터를 나눠서 저장을 해야 효율적이기 때문이다.
만약 replication이 2개 라면, 브로커(broker) 한개가 죽더라도 복제본이 존재하므로 복구가 가능하다.
그럼 많이 복제할수록 좋은게 아닌가?
Kafka에 들어오는 데이터 양과 retention date(저장시간)을 고려해서 replication 개수를 정해야 한다.
3개 이상의 브로커를 사용할땐 replication3을 권장한다.
ack
ack란 프로듀서(producer)의 상세옵션이라고 생각하면 된다.
0, 1, all 중 하나를 골라서 사용 가능하고 replication과 관계를 맺을 수 있다.
ack가 0일 경우
리더(leader) 파티션(partition)에 데이터를 전달하고, 응답값을 받지 않는다.
그래서 리더 파티션에 데이터가 정상적으로 전송되었는지, 팔로워(follower) 파티션에 정상적으로 복제 되었는지 알 수 없다.
즉, 리더 파티션을 전달되는 속도는 빠르지만 브로커(broker)에 장애가 났을 경우 제대로 전송되었는지 확인하지 못해서 데이터 유실 가능성이 있다.
ack가 1일 경우
리더(leader) 파티션(partition)에 데이터를 전달하고, 응답값을 받는다.
다만 팔로워(follower) 파티션에 정삭적으로 복제되었는지 알 수 없다.
즉, 리더 파티션이 데이터를 받은 즉시 브로커가 장애가 났을 경우엔 팔로워 파티션에 데이터가 미처 전송되지 못할 수 있어 데이터 유실 가능성이 있다.
ack가 all일 경우
리더(leader) 파티션(partition)에 데이터를 전달하고, 정상적으로 전달 되었는지 응답값을 받는다.
리더 파티션이 데이터를 보낸 후 나머지 팔로워(follower) 파티션에도 데이터가 저장 되는것을 확인하는 절차를 거친다.
즉, 데이터의 유실은 적지만 ack1과 ack0에 비해 확인하는 과정이 많아 데이터 전달 속도가 현저히 느려진다.
