카프카 데이터 플랫폼의 최강자 3장을 읽고 정리한 내용입니다.
- 참고: 2장은 카프카 설치와 관련된 내용임
카프카 디자인의 특징
기존 엑티브엠큐 사용의 문제
많은 데이터 처리의 한계
운영 관리의 어려움
분산 시스템
여러 대 서버로 이루어진 서버 그룹
더 높은 성능
장애 극복
시스템 확장 용이
페이지 캐시
남은 잔여 메모리 일부를 페이지 캐시로 사용해 성능향상을 높인다
카프카는 5GB 힙 메모리면 충분하니, 거기서 남은걸 페이지 캐시로 사용하길 권장
하나의 시스템에서 카프카와 다른 어플리케이션을 같이 실행하면 페이지 캐시를 공유하게 됨.
참고: https://brunch.co.kr/@alden/25
페이지 캐시는 리눅스(VFS 계층) 에서는 디스크 접근을 최소화 하여 파일 I/O성능을 향상시키기 위해 사용되는 메모리 영역입니다. 한 번 읽은 파일의 내용을 이 페이지 캐시 영역에 저장하고, 같은 파일의 접근이 일어나면 디스크에서 읽어오는 것이 아니라 페이지 캐시에서 읽어오게 됩니다.
리눅스에서 파일을 여는 과정 중 find_get_page() 메소드를 통해 해당 영역이 페이지 캐시에 있는지 확인하고 만약 있다면 디스크까지 접근하지 않게 됩니다. 만약 해당 영역이 페이지 캐시 내에 없다면_page_cache_alloc() 메소드를 통해 해당 파일의 내용을 저장할 페이지 캐시 영역을 할당하고, bio 구조체를 통해 할당받은 페이지 캐시를 추가 합니다.
출처: https://boxfoxs.tistory.com/288 [박스여우 - BoxFox]
배치 전송 처리
빈번한 IO를 방지하기 위해 작은 IO들을 묶어서 처리할 수 있도록 배치 작업으로 처리
카프카의 이해
토픽
데이터를 구분하기 위한 단위로 사용
토픽명 => 접두어로 서비스 명을 사용
파티션
- 토픽마다 1개이상의 파티션 존재
- 빠른 전송을 위해서는 병렬로 처리되어야 하며 이를 위해서는 토픽 내에 여러 파티션이 필요하다
- 파티션 수를 증가시킬 수 있지만 줄일 수 없음. 줄일려면 토픽을 삭제해야 함(참고: https://blog.voidmainvoid.net/183)
- 파티션을 수를 늘리는게 무조건 좋을까?
- 파티션이 많아질 수록 파일 핸들 수가 많아져서 리소스 낭비
- 리터 파티션의 브로커 다운시 리더 선출하는 시간이 걸림. 컨트롤러 역할의 브로커가 다운됬을 때 장애 복구 지연. 리더 선출하는 시간이 더 오래 걸리게 된다.
- 그럼, 적절한 파티션 수는?
- 파티션 수를 무작정 늘리기보다는 적절한 값으로 설정.
- 처음에는 적은 수의 파티션으로 운영하다가 프로듀서 또는 컨슈머에서 병목현상이 발생할 때 조금씩 늘려가는 방식을 권장
오프셋
- 메시지가 저장되는 위치
- 파티션 내에서 순차적으로 증가하는 숫자 형태
- 파티션마다 유일한 값
- 메시지 순서 보장에 이용. 메시지는 반드시 오프셋 순서로 가져가게 되어
- 컨슈머는 자신이 어디까지 데이터를 가져갔는지 offset을 이용해서 관리
리플리케이션
- 카프카 토픽은 단위로 브로커에 복제한 파티션을 분산되는데 이를 리플리케이션라 한다
- 브로커에서 토픽별로 리플리케이션 팩터 값을 설정할 수 있음
// 카프카 설정 파일
vi /usr/local/kafka/conflg/server.properties
// 팩터 값 설정
default.replication.factor- replication: 2
- replication : 3
- 클러스터 내 모든 브로커에게 동일하게 설정해야 하며, 변경시에는 브로커 모두 재시작을 해야함
리더 파티션
원본
읽기/쓰기가 여기서 발생
팔로워 파티션
복제본
리더 파티션이 실패하면 팔로워가 리더 역할을 승계. 고장난 리더는 팔로워가 되어 복제되지 못한 데이터를 새 리더에게서 읽어와서 동기화
장단점
- 장점
- 장애극복: 브로커가 다운이 되도 다른 브로커가 있기에 장애가 안남
- 단점
- 리소스 사용량 증가
ISR
- 리더와 팔로워간에 데이터가 불일치하면 리더로 승격하는데 문제가 생김
- 리필리케이션이 되고 있는 것들간의 그룹
- ISR에 속해 있는 구성원만이 리더의 자격을 가짐
- 리플리케이션의 신뢰성을 높인다
- 팔로워는 일정 주기로 리더에게 새로운 메시지에 대한 확인 요청을 함. 리더는 이걸 받아서 팔로워 상태를 확인. 만약 해당 요청이 오지 않으면 ISR에서 추방
모든 브로커가 다운
- 마지막 리더가 살아나기를 기다린다
=> 클러스터 장애가 길어질 수 있음 - ISR에서 추방되었지만 먼저 살아나면 자동으로 리더가 된다
=> 리더가 바뀌기 때문에 메시지 손실이 있을 수 있음
unclean.leadeer.election.enable = true or false// 1번 방식 : false, 2번 방식 : true
카프카에서 주키퍼 지노드
서버 네임/controller
브로커 레벨에서의 실패를 감지
모든 파티션의 리더 변경을 책임
토픽과 파티션 메타 데이터를 관리하고 파티션 리더를 결정
서버네임/broker
브로커 관리
brocker/topics에서 클러스터내 토픽 정보 확인 가능
서버네임/consumer
컨슈머가 읽은 오프셋 정보
0.9 이후로는 오프셋 저장 장소가 카프카의 토픽(__consumer_offsets)
서버네임/config
토픽의 상셍 설정 정보 확인
