카프카 디자인의 특징
- 높은 처리량과 빠른 메시지 전송 등을 중점으로 설계되었다.
- 분산 시스템, 페이지 캐시, 배치 전송 처리 등의 기능이 구현되어있다.
1. 분산 시스템
- 같은 역할을 하는 여러 대의 서버로 이루어진 서버 그룹을 말한다.
- 분산 시스템 중 하나의 서버에 장애가 발생하면 다른 서버가 대신 처리한다.
- 부하를 분산시킬 수 있다.
2. 페이지 캐시
- OS는 메모리 일부를 페이지 캐시로 유지해 OS의 성능 향상을 높인다.
- 메모리에 존재하는 데이터는 디스크를 읽지 않기 때문에 성능을 높일 수 있다.
3. 배치 전송 처리
- 네트워크 I/O를 줄이기 위해 데이터를 모아 보낸다.
- 메시지를 보내는 시간이 1초라고 하면 (1)의 경우 4초, (2)의 경우 1초가 걸린다.
카프카 데이터 모델
- 고성능, 고가용성으로 발전한 데는 토픽과 파티션의 역할이 컸다.
- 토픽은 메일 시스템의 메일 주소라고 생각하면 쉽다.
- 파티션은 토픽을 분할한 것이며 수평 확장이 가능하다.
파티션의 이해
프로듀서 : 1, 파티션 : 1, 메세지 : 4
- 하나의 메시지 전송 시간이 1초라고 하면 모든 메시지를 전송하는데 4초가 걸린다.
프로듀서 : 4, 파티션 : 4, 메세지 : 4
- 토픽의 파티션을 늘리면 병렬 처리 방식으로 메시지를 보내 4개의 메시지를 1초만에 보낼 수 있다.
- 토픽의 수만큼 프로듀서 수도 늘려야 효과를 볼 수 있다.
무조건 파티션의 수가 많으면 좋을까?
- 그렇지 않다.
- 장애 복구 시간이 증가한다.
토픽의 적절한 파티션 수는?
- 원하는 목표 처리량을 기준으로 잡자.
- 프로듀서 입장에서 4개의 프로듀서를 통해 초당 10개의 메시지를 토픽으로 보낸다고 하자.
이때 토픽에서 초당 40개의 메시지를 받아야한다.
1파티션이 초당 10개의 메세지만 받을 수 있으면, 4파티션으로 설정함으로써 프로듀서의 목표치를 달성할 수 있다. - 컨슈머의 입장에서는 8개의 컨슈머를 통해 초당 5개의 메세지를 가져올 수 있다고 하자.
파티션 역시 8개로 맞춰 컨슈머 각각마다 파티션에 접근하도록 하는것이 효율적일 것이다. - 이처럼 프로듀서와 컨슈머를 고려하여 파티션 수를 잡아야한다.
- 파티션의 수 증가는 아무때나 변경이 가능하지만, 감소하는 방법은 제공하지 않는다.
- 따라서 적은수에서 부터 시작하여 늘여가는 것이 좋다.
프로듀서에서 보내는 메시지의 순서를 보장하고 싶다면?
- 파티션을 여러개로 설정할 경우 여러 메시지의 순서를 보장할 수 없다.
- 이러한 경우 파티션의 수를 1로 설정해야한다.
오프셋과 메시지 순서
- 각 파티션마다 메시지가 저장되는 위치를 오프셋이라고 한다.
- 프로듀서가 메시지를 보내면 메시지가 각 파티션 별로 분산되어 저장된다.
- 오프셋의 순서는 메시지의 순서와 관련있으며 컨슈머는 오프셋 순서대로 데이터를 가져간다.
카프카의 고가용성과 리플리케이션
- 서버의 장애 발생을 대비하여 가용성을 갖기 위해 리플리케이션(복제) 기능을 사용한다.
- 리플리케이션은 토픽을 복제하는 것이 아니라, 토픽을 이루는 각각의 파티션을 복제하는 것이다.
리플리케이션 팩터와 리더, 팔로워 역할
- 리플리케이션 팩터는 운영중에도 변경이 가능하다.
default.replication.factor=2
- 리플리케이션 설정을 하면 각 파티션은 리더와 팔로워를 갖는다. 이때 모든 쓰기와 읽기의 핵심은 리더를 통해서만 일어난다.
만약 장애가 발생할 경우에는?
- 팔로워 중 새로운 리더를 찾는다.
리플리케이션의 단점은?
- [1] 리플리케이션의 팩터 수만큼 저장소가 필요하다.
만약 팩터 수가 3이고 토픽의 사이즈가 100GB라면 총 3x100GB 가 필요하다.
- [2] 브로커의 리소스 사용량이 증가한다.
브로커에서는 내부적으로 리플리케이션이 잘 되고 있는지 체크하는 작업이 이뤄진다. 물론 처리 비용이 크지는 않다.
리더와 팔로워 관리
- 리더는 모든 데이터의 읽기 쓰기에 대한 권한을 갖는다.
- 팔로워는 리더를 보면서 데이터를 주기적으로 가져온다.
만약 팔로워에 문제가 있어 리더로부터 데이터를 가져오지 못한다면?
- 리더가 다운되면 팔로워가 새로운 리더로 승격된다. 이때 리더의 데이터와 일치하지 않을 수 있다.
- 이를 방지하기 위해 ISR(In Sync Replica) 개념을 도입했다.
- ISR 구성원에 있는 팔로워만이 리더가 다운되었을때 새로운 리더가 될 수 있다.
- 팔로워는 리더에 새로운 메시지가 저장된 것이 없는지 주기적으로 확인한다.
- 리더 역시 팔로워들이 주기적으로 데이터를 확인 하고 있는지 확인하여
일정 주기(replica.lag.time.max.ms)만큼 확인 요청이 오지 않으면 해당 팔로워를 ISR 그룹에서 추방한다.
모든 브로커가 다운된다면
- 카프카 클러스터가 다운된다면 두 가지 방법을 선택할 수 있다.
- 애플리케이션의 성격에 맞게 선택해야한다.
[1] 마지막 리더가 살아나기를 기다린다.
- 메시지의 일관성이 중요할 떄.
- 0.11.0.0 버전 이후 Default 설정.
[2] 먼저 살아나는 노드가 자동으로 리더가 된다.
- 시스템의 가용성이 중요할 떄.
- 먼저 살아나는 노드에 Old 리더가 동기화되므로 메시지는 유실 될 수 있다.