카프카의 기본 개념과 원리에 대해 알아보는 시간이다.
카프카의 정의
카프카란 고성능 분산 이벤트 스트리밍 플랫폼이다.
❓ ❓
처음 카프카를 공부하기 시작했을 때는, 저 단어들이 무슨 의미인지 전혀.. 감이 오지 않았다;;
뒤에 언급하겠지만, 쉽게 말하면 대용량의 데이터를 안정적으로 저장 및 전달할 수 있게 해주는 시스템이다.
데이터 전달에만 초점을 둔 RabbitMQ와는 달리, Kafka는 서버에 데이터를 저장할 수 있다는 장점이 있다!
카프카 기본 용어
카프카와 관련된 기본적인 용어들을 살펴보자!
레코드(Record)
레코드는 카프카에서 다루는 데이터로, 메시징 큐에서의 메시지와 같은 개념이라고 볼 수 있다.
하지만 데이터라고 해서 단순히 하나의 값만 담고 있는 것은 아니다.
레코드의 기본 구성은 다음과 같다.
- Key: 레코드를 식별하기 위한 값
- Value: 실제로 전송하고자 하는 데이터 값
- Topic: 레코드가 속한 채널 이름
- Header: 레코드의 메타데이터를 담을 수 있다.
레코드는 Producer Record와 Consumer Record로 나뉘어진다.
즉, 보내는 쪽과 받는 쪽의 레코드 구성이 서로 다르다.
Producer 레코드는 위의 4가지 구성 요소 + Partition, TimeStamp 정보, 총 6개의 요소로 이루어진다.
Consumer 레코드는 위의 4가지 구성 요소 + Partition, TimeStamp, Offset 정보, 총 7개 요소로 이루어진다.
- TimeStamp: 레코드를 생성한 시간 혹은 서버에 레코드가 저장된 시간
- Offset: 레코드가 위치하는 주소 값(파티션 내의 고유한 위치 값을 의미한다.)
토픽(Topic) / 파티션(Partition)
이제 위에서 언급되었던 토픽(Topic)과 파티션(Partition)에 대해 더 자세히 알아보자.
토픽(Topic)은 데이터를 구분하기 위한 폴더와 같은 개념이다.
예를 들어, 결제 관련된 데이터들은 payments라는 토픽에 저장한다.
파티션(Partition)은 토픽을 물리적으로 나눈 단위이다.
특정 토픽으로 데이터가 들어올 때, 각 파티션에 순서대로 데이터가 추가된다. 파티션 내에 레코드들은 인덱스처럼 고유한 오프셋(Offset)을 가진다.
이때, 파티션은 Replication(복제) 구조를 가지게 된다.
Replication 구조란 파티션의 복제본을 여러 카프카 서버에 나누어 보관하는 것을 의미한다.
해당 구조를 지향하는 이유는 고가용성(High Availability) 때문이다. 하나의 브로커가 고장나도, 다른 브로커의 복제본이 존재하기 때문에 장애 대응에 용이하다!
스트림(Stream)과 스트리밍(Streaming)
스트림(Stream)은 토픽에 지속적으로 쌓이는 레코드들의 흐름을 의미한다.
스트리밍(Streaming)은 데이터를 한꺼번에 모아서 처리(Batch)하지 않고, 발생하는 즉시 실시간으로 처리하는 방식을 의미한다.
※ 스트리밍 데이터(Streaming Data)는 수천 개의 데이터 소스에서 지속적으로 생성되는 데이터를 의미한다.
ex) 실시간 심박수, 로그 기록 등
카프카의 원리
먼저 생성자(Producer)와 소비자(Consumer)의 개념에 대해 알아보자.
생성자는 데이터를 만들어 카프카 서버로 전송하고, 소비자는 카프카 서버에 저장된 데이터를 가져온다.
소비자까지 데이터가 도달하는 원리는 다음과 같다.
- 생성자가 데이터를 만들어 브로커(카프카 서버)로 보낸다.
- 브로커는 보내온 데이터를 파티션에 저장한다.
- 소비자가 브로커에게 저장된 데이터를 요청하여 데이터를 가져간다.
이 과정을 통틀어 데이터 파이프라인이라고 한다.
컨슈머 그룹(Cousumer Group)
데이터를 읽어오는 소비자가 하나뿐이라면, 속도나 처리 효율에 한계가 생긴다.
이를 해결하기 위한 개념이 바로 컨슈머 그룹(Consumer Group)이다.
컨슈머 그룹은 토픽으로 들어오는 데이터를 여러 소비자가 나누어 병렬로 처리할 수 있게 해준다.
컨슈머 그룹에서의 가장 중요한 법칙은 "하나의 파티션은 한 컨슈머만 담당"한다는 것이다.
하나의 파티션을 여러 컨슈머가 담당하게 된다면, 파티션 내에 레코드의 처리 순서가 보장되지 않는다.
즉, 오프셋 순서에 따른 순차적인 소비가 불가능해진다.
예를 들어, 특정 토픽에 4개의 파티션이 있다고 가정해보자.
1> 만약 토픽을 구독하는 컨슈머가 하나라면?
혼자서 4개의 파티션을 담당해야 한다. 그러면 위의 말처럼 속도가 매우 느릴 것이다..
2> 하지만 컨슈머가 둘이라면?
2개의 파티션을 다른 컨슈머에게 나눠주어, 2개씩 파티션을 전담할 수 있다.
3> 만약 컨슈머가 20개라면?
4개의 파티션은 최대 4개의 컨슈머가 담당할 수 있으므로, 나머지 16의 컨슈머는 파티션을 할당받지 못한 채 유휴 상태로 대기하게 된다.
만약 파티션을 할당받은 하나의 컨슈머가 장애로 인해 죽게 된다면❓ 16의 컨슈머 중 하나가 파티션을 차지하게 된다.
대기 중인 컨슈머가 많을수록 불필요한 자원 낭비가 발생하게 되는 것이다.
따라서, 최적의 효율을 위해서는 1) 파티션을 늘리거나 2) 필요없는 컨슈머들을 꺼주는(off) 작업이 필요하다.
카프카 설계의 핵심은 데이터의 유입량과 처리 속도를 분석하여,
병렬 처리를 극대화할 수 있는 최적의 파티션 개수와 브로커 규모를 산정하는 것이다.
예를 들어, 1) 컨슈머 1대는 초당 1000건을 처리할 수 있고 2) 데이터는 초당 10000건이 유입된다고 가정하자.
그렇다면, 파티션은 최소 10개 이상 산정하면 좋다...
[참고]
https://damdam-kim.tistory.com/17
'Development > 프로젝트' 카테고리의 다른 글
| [Kafka] 카프카 활용, 예제 (with SpringBoot) (2) (0) | 2026.03.05 |
|---|