Data Engineering/Kafka

카프카 각 컨포넌트들의 특징

이유즈 2021. 6. 21. 15:41
728x90

브로커 : 프로듀서로부터 데이터를 전달받으면 , 프로듀서가 요청한 토픽의 파티션에 데이터 저장,

             컨슈머가 데이터 요청하면 파티션에 저장된 데이터 전달해줌. 

 

카프카는 파일 시스템에 저장하여 사용 (메모리나 DB에 저장하지 않음) , 이로인해 발생하는 처리 속도 이슈를 

페이지 캐시를 사용해 디스크 입출력 속도를 올려 문제 해결. 

 

페이지 캐시 ? : OS 에서 파일 입출력의 성능 향상을 위해 만들어놓은 메모리 영역. 

한번 읽은 파일의 내용은 메모리의 페이지 캐시 영역에 저장해 추후 동일한 파일의 접근이 일어나면

디스크에서 읽지 않고 메모리에서 직접 읽는 방식!

 

이를 사용하지 않았으면 카프카에서 캐시를 직접 구현해야 했을 것이고, 지속적으로 변하는 

데이터 때문에 가비지 컬렉션이 자주 일어나 속도가 현저히 늘려질 것,,

 

이 때문에 카프카 브로커를 실행하는데 힙 메모리 사이즈를 크게 설정할 필요가 없다. 

 

 

 

데이터 복제, 싱크

클러스터로 묶인 브로커 중 일부에 장애가 발생하더라도 데이터를 유실하지 않고 안전하게 사용하기 위해

토픽을 생성할 때 파티션의 복제 개수를 같이 설정. 

최솟값 : 1 (복제없음), 최댓값 : 브로커 개수만큼. 

 

팔로워들은 리더의 오프셋을 확인해 현재 자신이 가지고있는 오프셋과 차이가 나는 경우 리더로부터 데이터를 가져와 자신의 파티션에 저장하는 방식으로 복제함. 

장애 발생 시 팔로워 파티션 중 하나가 리더가 됨!! 

이로인해 저장 용량이 증가하지만, 데이터를 안전하게 사용할 수 있다. 

 

데이터가 일부 유실되어도 무관하고 데이터 처리 속도가 중요하면 1 , 2 로 설정하고 금융정보와 같이 유실되면 안되는 경우는 복제 개수를 3으로 설정해 최대 2개의 브로커에서 동시에 장애가 발생하더라도 데이터를 안정적으로 유지할 수 있도록 한다. (서버가 1대일 때를 가정)

 

 

컨트롤러

: 다른 브로커들의 상태를 체크하고 브로커가 컨트롤러에서 빠지는 경우 해당 브로커에 존재하는 리터 파티션을 재분배함. 

클러스터의 다수 브로커 중 한대가 컨트롤러의 역할을 함. 

다른 것들 중 하나는 코디네이터.

 

 

코디네이터

: 컨슈머 그룹의 상태를 체크하고 파티션을 컨슈머와 매칭되도록 분배하는 역할. 

컨슈머가 빠지면 매칭되지않은 파티션을 정상 동작하는 컨슈머로 할당하여 끊임없이 데이터가 처리되도록 도와줌. = 리밸런스

 

 

 

 

데이터 삭제 

: 컨슈머가 데이터 가져가도 토픽의 데이터는 삭제되지 않음. 브로커만 삭제 가능! 

삭제가 파일 단위 (로그 세그먼트) 로 이루어짐. 로그 세그먼트엔 다수의 데이터 들어있기 때문에 다른 DB 처럼 선별해 삭제할 수 없음. 

log.segment.bytes 또는 log.segment.ms 옵션에 값이 설정되면 세그먼트 파일이 닫힘. 그리고 그 설정값이 넘으면 삭제됨.

 

(메시지 키를 기준으로 오래된 데이터를 압축하는 정책을 가져갈 수도 있음)

 

 

 

 

주키퍼 : 카프카의 메타데이터를 관리하는데 사용. 

(주키러 쉘 명령어는 zookeeper-shell.sh 로 실행하고, bin 폴더 안에 있다.)