카프카 디자인 특징
1. 분산 시스템
분산 시스템은 네트워크로 이루어진 컴퓨터들의 그룹으로서 시스템 전체가 공통의 목표를 가지고 있습니다.
같은 역할을 하는 여러대의 서버로 이루어진 서버그룹을 분산 시스템이라고 합니다.
=> 단일 시스템보다 더 높은 성능을 얻을 수 있다.
=> 분산 시스템 중 하나의 서버 또는 노드 등이 장애가 발생하면 다른 서버 또는 노드가 대신 처리한다.
=> 시스템 확장이 용이하다
2. 페이지 캐시
카프카는 처리량을 높이기 위해 페이지 캐시를 이용합니다.
OS는 물리적 메모리에 애플리케이션이 사용하는 부분을 할당하고 남은 잔여 메모리 일부를 페이지 캐시로 유지해 OS의 전체적인 성능 향상을 높이게 됩니다.
이러한 잔여 메모리를 이용해 디스크에 읽고 쓰기를 하지않고, 페이지 캐시를 통해 읽고 쓰는 방식을 사용하면 처리 속도가 매우 빠르기 떄문에 전체적인 성능을 향상시킬 수 있습니다.
카프카는 이러한 특징을 이용해 빠른 액세스를 하기 위해 OS의 페이지 캐시를 이용하도록 디자인 됨
3. 배치 전송 처리
\서버와 클라이언트 사이 또는 서버 내부적으로 데이터를 주고받는 괒어에서는 I/O가 발생하기 마련인데, 작은 I/O를 묶어서 처리할 수 있도록 배치 작업으로 처리합니다.
메세지를 보내는 시간을 1초라고 가정했을때, 작은 메세지 4개를 전송하면 총 4초가 소요됩니다. 이때 한번에 4개의 메세지를 전송하게 되면 1초의 시간이 소요됩니다.
이러한 배치 작업은 속도 향상에 매우 큰 도움을 줍니다.
카프카 데이터 모델
카프카가 고성능 고가용성 메시징 애플리케이션으로 발전한 데는 토픽과 파티션이라는 데이터 모델의 역할이 컸습니다.
토픽은 메시지를 받을 수 있도록 논리적으로 묶은 개념이고, 파티션은 토픽을 구성하는 데이터 저장소로서 수평 확장이 가능한 단위
토픽의 이해
카프카 클러스터는 토픽이라 불리는 곳에 데이터를 저장합니다.
예를 들어 메일 시스템에서는 메일 서버에 저장되는 메세지들을 메일 주소로 구분해 저장합니다. 이때 메일 주소의 역할을 카프카의 토픽이 하게되는것입니다.
카프카는 데이터를 구분하기 위한 단위로 토픽이라는 용어를 사용합니다.
토픽으 ㅣ이름은 249자 미만으로 영문, 숫자 ’.‘, ’_‘,’-‘를 조합하여 자유롭게 만들 수 있습니다.
여러 서비스에서 공통으로 사용하게 된다면, 각자 형식에 맞춰 토픽 이름을 구분해 주는것이 좋습니다.
토픽에 접두어로 서비스명 등을 추가해 다른 서비스에서 사용하는 토픽 이름과 중복을 피할 수 있습니다.
파티션의 이해
카프카에서 파티션이란 토픽을 분할한 것입니다.
왜 파티셔닝을 하는 것일까요 ?
예) 4개의 메세지를 전송하는 데, 메세지를 하나 보내는데 걸리는 시간을 1초라고 가정하겠습니다. 이때 프로듀서는 뉴스토픽으로 메시지를 보내기 위해 A메시지 전송 완료된 후 B, C,D 순으로 메시지를 보냅니다. 이;때 4초가 소요되었습니다.
메시지의 순서가 보장되어야 하기 때문에, 메시지 처리가 완료된 후 다음 메시지 를 처리하게 됩니다.
카프카에서 효율적인 메시지 전송 속도를 늘리려면 토픽의 파티션 수를 늘려줘야 합니다.
토픽을 1개에서 4개로 변경하고, 프로듀서도 4개로 늘려주었을 경우 메시지를 병렬처리 방식으로 동시에 뉴스토픽으로 메시지를 보낼 수 있게 되어 4개의 메시지가 1초 소요되게 됩니다.
파티션을 늘리는 만큼, 프로듀서의 수도 증가시켜주어야 제대로 된 효과를 볼 수 있습니다.
파티션 수를 무조건 늘려야 하는가?
그렇지 않습니다!
파티션을 무조건 적으로 늘리는 경우 파일 핸들러의 낭비, 장애 복구 시간 증가 등 오히려 좋지 않은 영향을 미칠 수도 있습니다.
- 파일 핸들러의 낭비
- 각 파티션은 브로커의 디렉토리와 매핑되고, 저장되는 데이터마다 2개의 파일(인덱스와 실페 데이터)이 있습니다. 카프카에서 모든 디렉토리의 파일들에 대해 파일 핸들을 열게됩니다.
결국 파티션이 많을수록 파일 핸들 수 역시 많아지게 되어 리소스가 낭비되게 됩니다.
- 장애 복구 시간 증가
카프카는 높은 가용성을 위해 리플리케이션을 지원합니다.
브로커에는 토픽이 있고, 토픽은 여러개의 파티션으로 나뉘어 있으므로, 브로커에는 여러개의 파티션이 존재합니다. 또한 각 파티션 마다 리플리케이션이 동작하게 되며, 하나는 파티션의 리더이고 나머지는 파티션의 팔로워가 됩니다.
만약 브로커가 다운되면 해당 브로커에 리더가 있는 파티션은 일시적으로 사용할 수 없게 되므로, 카프카 리더를 팔로워 중 하나로 이동시켜 클라이언트 요청을 처리할 수 있게 합니다.
내 토픽의 적절한 파티션 수는?
예상 목표치를 가지고 파티션 수를 할당하는 것이 가장 이상적인 방법입니다.
늘린 후 파티션 수를 줄이는 방법은 제공하지 않기때문에 , 이떄 줄이기 위해서는 토픽을 지울 수 밖에 없게됩니다.
그렇기 때문에 일단 파티션을 적은 파티션을 운영해보고, 프로듀서 또는 컨슈머에서 병목현상이 발생하게 될때 조금씩 파티션 수와 프로듀서 또는 컨슈머를 늘려가는 방법이 적정 파티션을 할당할 수 있는 방법입니다.
오프셋과 메시지 순서
카프카는 각 파티션 마다 메시지가 저장되는 위치를 오프셋 이라고 부르고, 오프셋은 파티션 내에서 유일하고 순차적으로 증가하는 수자(64비트 정수) 형태로 되어 있습니다.
이러한 숫자는 파티션마다 유니크한 값을 가지며 카프카에서 이를 오프셋이라고 합니다. 오프셋은 하나의 파티션 내에서만 유일한 숫자를 가집니다.
컨슈머가 파티션에서 데이터를 가져간다고 가정한다면, 오프셋 0,1,2,3,4,5 순서대로만 데이터를 가져갈 수 있고, 절대로 오프셋 순서가 바뀐 상태로는 가져갈 수 없습니다.
카프카의 고가용성과 리플리케이션
카프카는 분산 애플리케이션으로 서버의 물리적 장애가 발생하는 경우에도 높은 가용성을 보장합니다. 카프카는 리플리케이션(복제)기능을 제공합니다.
리플리케이션 팩터와 리더, 팔로워의 역할
카프카 config 설정에서 리플리케이션 팩터(replicationFactor)라는 것이 존재합니다.
default.replication.factor라는 항목을 찾은 뒤 2 또는 3등 원하는 숫자로 변경하면 복제 숫자를 지정할 수 있습니다.
이 설정 값은 옵션을 주지 않고 토픽을 생성할 때 적용되는 값이고, 각 토픽별로 다른 리플리케이션 팩터 값을 설정 할 수 있습니다.
운영중에도 이 팩터 값은 변경할 수 있습니다.
클러스터 내의 모든 브로커에 동일하게 설정해야 하며, 컨피그 내용을 변경한 후 브로커 1대씩 재시작을 하면 변경 내용이 적용됩니다.
카프카는 토픽을 복제하는 것이 아닌, 토픽을 이루는 각각의 파티션을 복제하는 것입니다.
카프카 클러스터가 3대의 브로커로 구성하고 프로듀서가 피터라는 토픽으로 메세지를 보내는 상황일 때, peter토픽은 복제로 구성되지 않아 브로커 1에만 위치하고 있으며, 프로듀서가 피터토픽으로 메시지를 보내고 카프카는 피터 토픽으로 오는 프로듀서 요청을 처리하고 메시지를 저장하는 상태입니다.
이때 브로터3에서 서버의 물리적인 장애가 발생하면, 브로커3는 다운 되었지만, 피터 토픽은 브로커 1에 있기 때문에 영향을 미치지 않습니다.
이때 만약 브로커 1이 장애가 발생한다면
'Backend' 카테고리의 다른 글
| [kafka] 카프카 관리를 위한 주키퍼 (0) | 2025.04.01 |
|---|---|
| [Kafka] 카프카의 동작 방식과 원리 (0) | 2025.04.01 |
| [Backend] Kafka 명령어 (0) | 2025.03.15 |
댓글