카프카, 데이터 플랫폼의 최강자 - 3장 카프카 디자인

카프카, 데이터 플랫폼의 최강자 - 3장 요약 정리 내용임.

 

3.1 카프카 디자인의 특징

분산시스템

카프카는 분산 시스템으로 구성되어 있어서 분산 시스템의 장점을 갖는다.

• 단일 시스템 대비 높은 성능
• 높은 가용성
• 확장성이 좋음 (아파치 카프카 문서에 따르면 링크드인에서 가장 사용량이 높은 클러스터는 60대의 브로커 운영한다고 함)

 

페이지 캐시

카프카는 처리량을 높이기 위해 페이지 캐시를 이용한다.

OS는 물리적 메모리에 애플리케이션을 위한 부분을 할당하고 남은 잔여 메모리 일부를 페이지 캐시로 사용해 OS의 전체적 성능을 높인다.

(페이지 캐시라는 것은 카프카가 구현한 기능이 아니고 OS 레벨에서 제공하는 기능)

 

페이지 캐시를 사용하면 디스크 I/O 양이 줄기 때문에 처리 속도가 매우 빨라서 전체적인 성능을 향상시킬 수 있음

 

페이지 캐시 때문에 카프카 구성 시 디스크 중 가격이 가장 저렴한 SATA를 사용해도 무방하고

페이지 캐시라는 것이 OS 레벨의 기능이기 때문에 다른 애플리케이션들을 한 서버에 같이 실행하면 효율이 떨어지므로 권장하지 않음

 

컨플루언트 사 도큐먼트에 따르면 초당 메가비트 단위의 메시지를 처리함에 있어 5GB의 힙 메모리면 충분하고 남아있는 메모리는 페이지 캐시로 사용하기를 권장한다고 함

 

배치 전송 처리

작은 I/O가 빈번하게 발생하면 속도를 저하시키는 원인이 될 수 있는데,

카프카는 작은 I/O들을 묶어서 배치 작업으로 처리한다.

 

프로듀서가 카프카에 배치로 묶어서 전송할 수 있도록 지원한다.

(카프카에서 제공하는 프로듀서 외에 자체적으로 만들어서 쓰거나 http api 같은것은 쓴다면 배치 전송은 구현하기 나름이 될 것 같다.)

 

3.2 카프카 데이터 모델

파티션의 이해

카프카에서 파티션이란 토픽을 분할한 것이다.

토픽을 파티셔닝하는 이유는? 빠른 전송을 위해서이다.

 

토픽의 파티션이 1개일 때 프로듀서 4개가 동시에 메시지를 보내더라도 프로듀서 1개로 메시지를 순차적으로 보내는 것과 같은 속도로 처리된다. 파티션 갯수만큼 동시에 카프카 토픽이 받을 수 있기 때문이다.

 

메시징 큐 시스템은 메시지 순서를 보장해야한다는 제약이 있는데, 이 때문에 이전 메시지 처리 완료 후 다음 메시지를 처리한다.

메시지 전송과 속도를 높이려면 토픽 파티션 갯수를 늘리고 그 수만큼 프로듀서 수도 늘려야 한다.

(파티션 갯수를 2개 이상으로하면 파티션 단위로는 순서 보장이 안되게 되는 것 아닌가?)

 

파티션 수는 클수록 좋은가

그러면 빠른 속도를 위해 파티션 수를 무조건 크게 잡을 수록 좋은가? 그건 아니다. 얻는게 있으면 잃는게 있는 법이다.

파티션 수가 많으면 파일 핸들러 낭비, 장애 복구 시간 증가라는 단점이 생긴다.

 

적절 파티션 수 결정

그러면 적절한 파티션 수는 어떤 기준으로 정할 수 있을까?

먼저 원하는 목표 처리량이 어느 정도인지 정한 후 그에 맞게 지연없이 처리될 수 있도록 계산하면 된다.

 

예) 프로듀서 4개에서 초당 10개의 메시지를 보내고 하나의 파티션에서 초당 10개 메시지 처리가 가능하다면,

파티션도 4개로 설정하면 둘 다 초당 40개의 처리를 하게 된다.

 

컨슈머 입장도 고려해야 한다는데 만약 컨슈머가 파티션 갯수보다 크면 노는 컨슈머가 생길 수 있다.

그래서 컨슈머 수와 파티션 수를 같게 해주면 성능이 더 좋아진다.

(컨슈머와 파티션이 1대1로 연결되는 건 아니기 때문에 처리량만 커버된다면 상관없는게 아닌가 싶기도 하다.)

 

주의점은 파티션 수 증가는 가능하지만 축소는 안된다.

토픽을 삭제하는 방법 외에 다른 해결책이 없다.

그래서 적절 파티션 수 측정이 어렵다면 일단 적게 설정해서 운영해보고 병목이 생길 경우

파티션 수와 프로듀서/컨슈머 수를 조절하는 방법을 추천한다고 한다.

 

참고로 카프카는 브로커당 2000개 정도의 최대 파티션 수를 권장한다고 한다.

 

오프셋과 메시지 순서

각 파티션마다 메시지가 저장되는 위치를 오프셋이라고 하며

하나의 파티션 내에서만 유일한 숫자이다.

 

 

메시지의 순서를 보장하기 위해 사용되며, 컨슈머는 오프셋 순서대로 메시지를 가져간다.

(파티션 내에서만 유일하기 때문에 토픽 전체에서 순서를 보장하는 기능은 없는가 보다.)

 

3.3 고가용성과 리플리케이션

카프카의 리플리케이션은 토픽 단위가 아니라 파티션 단위로 이루어진다.

복제수(리플리케이션 팩터)는 기본값이 1이고 설정 파일에서 변경 가능하다.

 

원본이 있는 브로커는 리더, 복제본이 있는 브로커들은 팔로워라고 부른다.

모든 읽기, 쓰기는 리더를 통해서 일어나고 팔로워는 리더의 데이터를 그대로 복제한다.

 

리더가 있는 브로커에 문제 발생 시 팔로워 중 하나가 새로운 리더가 되게된다.

 

복제수만큼 저장소를 더 사용하고 복제 처리에 그만큼 오버헤드가 있기 때문에

모든 토픽에 복제수 3을 설정하기 보다는 데이터 중요도에 따라 2나 3으로 운영하는게 효율적이다.

 

리더와 팔로워의 관리

기존 리더의 문제로 새로운 리더 선출 시 데이터 정합성이 맞는 팔로워만 선출되어야 하는데,

이를 위해 정합성이 맞는 팔로워를 ISR(In Sync Replica) 이라는 그룹으로 관리하고 여기 속한 팔로워만 새로운 리더가 될 수 있다.

 

리더가 ISR을 관리하며 (주기적으로 팔로워들이 데이터 동기화를 하고 있는지 체크함)

이상 감지 시 ISR 그룹에서 추방시킴

 

3.4 모든 브로커가 다운된다면

클러스터의 모든 브로커가 다운되는 최악의 상황에서는 선택지가 두 가지 있다.

1. 마지막 리더가 살아나기를 기다린다.
2. ISR에서 추방되었지만 먼저 살아나면 자동으로 리더가 된다.

두 가지 방법 모두 장단점이 있는데,

1번은 다른 팔로워들이 살아나더라도 마지막 리더가 복구되기를 기다려야 하므로 장애 시간이 길어질 수 있다.

2번은 메시지는 일부 손실되겠지만 서비스 정상화를 빨리 할 수 있다.

 

0.11.0.0 버전부터 1번 방법이 기본값인데 설정 변경 가능하며,

가용성과 일관성 중 어느 것이 중요할지에 따라서 선택해야할 문제인 것 같다.

 

(그런데 꼭 마지막 리더가 아니더라도 ISR에 속한 팔로워 중에 살아나는 것을 리더해서 복구해도 되지 않나 싶다.)