Kafka 동작 원리

1. Pub - Sub 모델

실제 메세지의 송신과 수신이 분리되어 있으며 카프카 큐에 데이터를 저장하는 Kafka Producer , 이를 읽어오는 Kafka Consumer로 분리 되어 Client API를 제공

 

2. Zookeeper

- 분산 코디네이터 서비스

- Kafka는 Zookeeper를 활용하여 데이터 분산 처리

- 각 서버의 상태와 연결, 환경 ,구성 ,위치 , 정보 등 관리데이터를 저장하기 위해 설계

- 디렉토리와 파일처럼 노드내에  데이터를 가지고 있으며 주키퍼 네임스페이스 노드를 가지고 있음

- 클러스터를 구성하는 서버들끼리 공유되는 데이터를 유지하거나 어떤 연산을 조율하기 위해 사용

- 서버 모니터링 가능

- 각 디렉터리 노드를 Znode라고 하며 , 영구노드와 임시노드,시퀀스 노드로 구성

- Persistent 노드 : 세션종료시 삭제되지 않고 데이터 유지

- Ephermeral 노드 : 세션이 유지되는 동안에 활성 , Persistent노드의 미결상태를 저장

- Seqeunce 노드 : 경로의 끝에 일정하게 증가하는 카운터가 추가됨

- 클러스터는 리더와 팔로워로 구성되며 리더는 내부 알고리즘에 의해 자동 선정됨

- 모든 데이터의 업데이트 이벤트는 리더에게 전달되며 팔로워 과반수의 승인이 있어야 읽기가 가능하다. (서버간 데이터가 불일치 할 수 있으며 이를 판단하기 위해 과반수이상의 승인이 필요하다. , 따라서 서버를 홀수개로 구성하는 것이 좋음

 

- 동작 방식

 

1) 연결 유지를 위해 클라이언트는 연결 서버에 주기적으로 핑 전송

2) 핑전송 실패시 클라이언트는 다른 서버에 연결 (서버는 일정시간 동안 핑이 안온다면 세션 종료)

3) 연결된 서버에서 읽기 실행

4) 연결된 서버에 변경 요청

5) 변경을 요청 받으면 리더에게 전달후 전 노드에 해당 트랜잭션을 전파함

 

3. Topic과 Partition

- 메세지는 토픽으로 분류되고 토픽은 여러 파티션으로 구성된다.

- 파티션의 한칸은 로그라고 불리며 각 로그의 위치를 오프셋이라고 부름

- 각 메세지가 저장되어야 할 파티션이 라운드 로빈 방식으로 동작하기 때문에 각 브로커의 처리 성능에 따라 순서가 바뀔 수 있음

- 각 서버가 분산하여 처리하기 때문에 각 서버의 부담을 줄임

 

4. Partition의 개수

- 파티션을 늘려서 데이터를 저장하는 속도를 올릴 수 잇지만 파티션은 한번 늘어나면 줄어들 수 없음

- 파티션을 늘릴수록 관리 포인트가 늘어남

- Producer와 Consumer의 요청에 따라서 각 파티션을 정리해서 메세지를 전달하는 시간이 늘어남

- 많은 레플리카중 파티션 리더를 뽑느데 시간이 늘어남

- 하나의 브로커에 파티션을 너무 많이 두게 되면 브로커안에 파티션 리더가 많이 존재 할 경우 브로커가 장애를 일으킬 경우 해당 파티션 그룹들은 전부 stop되게 된다.

 

5. Producer ACKS

1) ACK 0 : 프로듀서가 자신이 보낸 메세지에 대해 카프카로 부터 확인을 기다리지 않음

2) ACK 1 : 프로듀서가 자신이 보낸 메세지에 대해 파티션 리더로 부터만 확인을 받음

3) ACK all : 프로듀서가 자신이 보낸 메세지에 대해 카프카 리더와 팔로워까지 전부 확인

4) min.insync.replicas : Ack all 일시 write의 성공여부를 확인하기 위해 응답이 날라온 서버의 개수