1. Kafka의 기원
카프카는 링크드인 내부에서 데이터 파이프라인 문제를 해결하기 위해 개발된 시스템으로 다양한 종류의 데이터를 다루고 고성능 메시지 교환 시스템 역할을 할 수 있도록 설계되었습니다.
그렇다면 데이터 파이프 라인 문제란 무엇일까요?
이를 이해하기 위해서는 먼저 발행/구독(Pub/Sub) 메시징 개념을 알아볼 필요가 있습니다.
Pub/Sub 메시징 패턴에서는 전송자(메시지 발행)가 데이터를 특정 수신자(구독하는 쪽)에게 직접 보내는 것이 아니라, 브로커를 통해 분류된 메시지를 전송하고, 수신자는 자신이 필요한 메시지를 구독하는 방식으로 데이터를 전달받습니다. 이때 브로커는 메시지를 중개하며, 데이터의 흐름을 효과적으로 관리하는 역할을 합니다.
그렇다면 왜 브로커가 필요하고 데이터 파이프 라인 문제를 어떻게 해결할 수 있을까요?
예시를 통해 알아보겠습니다.
처음에는 한 서비스에서 단순한 지표를 수집한다고 가정해 보겠습니다.
지표 데이터는 각 서버에서 하나의 지표 서버로 전송되어 저장 혹은 분석됩니다.
하지만 시간이 지나면서 이 지표를 여러 목적으로 활용하는 서비스가 하나씩 추가된다면 아래와 같은 상황이 발생하게 됩니다.
여러 애플리케이션이 직접 연결되면서 연결의 추적이 힘들어질 뿐더러, 새로운 서비스가 추가될수록 관리 또한 어려워지게 됩니다.
이러한 문제를 해결하기 위해, 모든 애플리케이션이 데이터를 보내는 중앙 서버를 두고, 이 지표를 필요로 하는 어느 시스템이든 지표를 질의할 수 있도록 해주는 서버를 제공한다면 아래와 같은 형태가 되게 됩니다.
이를 통해 복잡한 데이터 파이프라인을 단순화하고, 새로운 서비스가 추가되더라도 기존 시스템에 미치는 영향을 최소화할 수 있습니다.
위 사진에서 보았듯이, 지금까지의 문제를 해결하기 위해 만들어진 메시지 발행/구독 시스템이 바로 Kafka입니다.
2. Kafka 내부를 알아보자
아파치 카프카는 위에서 설명한 것과 같은 문제를 해결하기 위해 고안된 메시지 발행/구독 시스템으로
'분산 커밋 로그' or '분산 스트리밍 플랫폼' 이라고 불리기도 합니다.
일반적으로 파일 시스템이나 데이터베이스의 커밋 로그(commit log)는 트랜잭션 기록을 저장해 시스템을 복구할 수 있도록 합니다. 카프카도 이와 비슷한 방식으로 데이터를 순서대로 저장하고, 필요할 때 언제든 읽을 수 있도록 설계되었습니다. 또한, 카프카는 데이터를 여러 서버에 나누어 저장하여 확장성을 높이고, 장애가 발생하더라도 데이터 손실 없이 사용할 수 있도록 합니다.
그렇다면 카프카 내부에서는 이 모든 과정이 어떻게 이루어질까요?
이를 가능하게 하는 카프카의 핵심 요소들을 하나씩 살펴보겠습니다.
2-1 토픽과 파티션
카프카에 저장되는 메시지는 토픽(topic) 단위로 분류되고, 각 토픽은 다시 여러 개의 파티션으로 나뉩니다.
파티션이란?
파티션은 순차적으로 추가되는 로그 파일과 유사하며, 메시지는 한 번 기록되면 수정할 수 없고 항상 새로운 메시지가 뒤에 추가됩니다. 읽을 때는 처음부터 끝까지 순서대로 처리되지만, 토픽 내 여러 개의 파티션이 존재하기 때문에 전체 메시지의 순서는 보장되지 않고 개별 파티션 내에서만 순서가 유지됩니다.
파티션의 장점 : 복제와 안정성
파티션은 서로 다른 서버에 분산 저장될 수 있어 하나의 토픽이 여러 서버로 확장될 수 있으며, 이를 통해 더 높은 처리량과 저장 용량을 확보할 수 있습니다. 또한, 각 파티션은 복제본을 가질 수 있어 특정 서버에 장애가 발생하더라도 데이터 손실 없이 안정적으로 운영될 수 있습니다.
2-2 프로듀서와 컨슈머
프로듀서는 새로운 메시지를 생성하는 역할을 합니다. 이 때 생성된 메시지는 특정한 토픽에 쓰여지고, 기본적으로 프로듀서는 메시지를 쓸 때 토픽에 속한 파티션들 사이에 고르게 나뉘어 쓰도록 되어있습니다.
하지만 필요에 따라 프로듀서가 특정한 파티션을 지정해서 메시지를 쓰기도 하며. 이 때 메시지 키와 키값의 해시를 특정 파티션으로 대응시켜주는 파티셔너(partitioner)를 사용함으로써 동일한 키 값을 가진 메시지는 같은 파티션에 저장되게할 수 있습니다.
컨슈머는 메시지를 읽는 역할을 합니다. 1개 이상의 토픽을 구독해 저장된 메시지들을 각 파티션에 쓰여진 순서대로 읽어옵니다. 이 때 파티션에 쓰여진 메시지의 오프셋을 기록함으로써 메시지를 어디까지 읽었는지 유지합니다. 이를 통해 읽기 작업이 정지되었다가 다시 시작하더라도 마지막으로 읽었던 메시지의 바로 다음 메시지부터 읽을 수 있습니다.
오프셋이란?
카프카가 메시지를 저장할 때 각각 메시지에 부여해주는 메타데이터로 각 메시지는 고유한 오프셋을 가진다.
컨슈머는 컨슈머 그룹의 일원으로 작동하며, 컨슈머 그룹은 하나 이상의 컨슈머로 구성되어 저장된 데이터를 읽어오는 역할을 합니다.
컨슈머 그룹에서는 각 파티션이 하나의 컨슈머에 의해 소비되도록 할당되므로 같은 그룹 내의 컨슈머들은 서로 다른 파티션의 데이터를 처리하게 됩니다. (컨슈머가 2개 이상의 파티션을 읽는 경우도 존재) (But 하나의 파티션은 항상 하나의 컨슈머만 읽을 수 있다)
이를 통해 컨슈머를 수평적으로 확장하여 대량의 메시지를 가진 토픽을 효과적으로 처리할 수 있습니다. 또한, 컨슈머 중 하나가 장애가 발생하더라도 그룹 내 다른 컨슈머가 해당 파티션을 재할당받아 계속해서 데이터를 읽을 수 있어 안정적인 운영이 가능합니다.
2-3 브로커와 클러스터
하나의 카프카 서버를 브로커라고 합니다.
브로커는 프로듀서로부터 메시지를 전달받아 오프셋을 할당한 뒤 디스크 저장소에 쓰게되고, 컨슈머의 파티션 읽기 요청을 처리하고 발행된 메시지를 보내주는 역할을 합니다.
(하드웨어 성능에 따라 달라지겠지만 하나의 브로커는 초당 수천 개의 파티션과 수백만 개의 메시지를 처리할 수 있습니다.)
카프카 브로커는 클러스터의 일부로 작동하도록 되어있는데 하나의 클러스터 안에 여러개의 브로커가 포함될 수 있으며 그 중 하나의 브로커가 클러스터의 컨트롤러 역할을 하게됩니다. 컨트롤러는 파티션을 브로커에 할당해주거나 장애가 발생한 브로커를 모니터링 등의 관리 기능을 담당합니다.
파티션은 클러스터 안의 브로커중 하나가 담당하며 그 브로커를 파티션 리더라고 합니다.
복제된 파티션이 여러 브로커에 할당될 수도 있는데 이것을 파티션 팔로워라고 부릅니다.
복제 기능은 파티션 메시지를 중복 저장함으로써 리더 브로커에 장애가 발생했을 때 팔로워 중 하나가 리더 역할을 이어받을 수 있도록 합니다. 모든 프로듀서는 리더 브로커에 메시지를 발행해야하지만 컨슈머는 리더나 팔로워 중 하나로부터 데이터를 읽어올 수 있습니다.
또한 카프카에는 메시지를 일정 기간 동안 메시지를 보관할 수 있는 기능이 존재하는데 특정기간 혹은 파티션의 크기가 특정 사이즈에 도달할 때까지 보존하고 사이즈를 초과하거나, 기간이 만료되면 메시지를 삭제하게 됩니다.
참고
카프카 핵심 가이드
'Kafka' 카테고리의 다른 글
| Kafka가 신뢰성을 보장하는 방법 (0) | 2025.07.16 |
|---|---|
| [Kafka 정리] Kraft모드로 Kafka 실행하기 (feat. Docker) (0) | 2025.04.24 |
| [Kafka 정리] 카프카 내부 메커니즘 (1) | 2025.04.10 |
| [Kafka 정리] 카프카 컨슈머(KafkaConsumer) (0) | 2025.03.31 |
| [Kafka 정리] 카프카 프로듀서(Kafka Producer) (0) | 2025.03.30 |
1. Kafka의 기원
카프카는 링크드인 내부에서 데이터 파이프라인 문제를 해결하기 위해 개발된 시스템으로 다양한 종류의 데이터를 다루고 고성능 메시지 교환 시스템 역할을 할 수 있도록 설계되었습니다.
그렇다면 데이터 파이프 라인 문제란 무엇일까요?
이를 이해하기 위해서는 먼저 발행/구독(Pub/Sub) 메시징 개념을 알아볼 필요가 있습니다.
Pub/Sub 메시징 패턴에서는 전송자(메시지 발행)가 데이터를 특정 수신자(구독하는 쪽)에게 직접 보내는 것이 아니라, 브로커를 통해 분류된 메시지를 전송하고, 수신자는 자신이 필요한 메시지를 구독하는 방식으로 데이터를 전달받습니다. 이때 브로커는 메시지를 중개하며, 데이터의 흐름을 효과적으로 관리하는 역할을 합니다.
그렇다면 왜 브로커가 필요하고 데이터 파이프 라인 문제를 어떻게 해결할 수 있을까요?
예시를 통해 알아보겠습니다.
처음에는 한 서비스에서 단순한 지표를 수집한다고 가정해 보겠습니다.
지표 데이터는 각 서버에서 하나의 지표 서버로 전송되어 저장 혹은 분석됩니다.
하지만 시간이 지나면서 이 지표를 여러 목적으로 활용하는 서비스가 하나씩 추가된다면 아래와 같은 상황이 발생하게 됩니다.
여러 애플리케이션이 직접 연결되면서 연결의 추적이 힘들어질 뿐더러, 새로운 서비스가 추가될수록 관리 또한 어려워지게 됩니다.
이러한 문제를 해결하기 위해, 모든 애플리케이션이 데이터를 보내는 중앙 서버를 두고, 이 지표를 필요로 하는 어느 시스템이든 지표를 질의할 수 있도록 해주는 서버를 제공한다면 아래와 같은 형태가 되게 됩니다.
이를 통해 복잡한 데이터 파이프라인을 단순화하고, 새로운 서비스가 추가되더라도 기존 시스템에 미치는 영향을 최소화할 수 있습니다.
위 사진에서 보았듯이, 지금까지의 문제를 해결하기 위해 만들어진 메시지 발행/구독 시스템이 바로 Kafka입니다.
2. Kafka 내부를 알아보자
아파치 카프카는 위에서 설명한 것과 같은 문제를 해결하기 위해 고안된 메시지 발행/구독 시스템으로
'분산 커밋 로그' or '분산 스트리밍 플랫폼' 이라고 불리기도 합니다.
일반적으로 파일 시스템이나 데이터베이스의 커밋 로그(commit log)는 트랜잭션 기록을 저장해 시스템을 복구할 수 있도록 합니다. 카프카도 이와 비슷한 방식으로 데이터를 순서대로 저장하고, 필요할 때 언제든 읽을 수 있도록 설계되었습니다. 또한, 카프카는 데이터를 여러 서버에 나누어 저장하여 확장성을 높이고, 장애가 발생하더라도 데이터 손실 없이 사용할 수 있도록 합니다.
그렇다면 카프카 내부에서는 이 모든 과정이 어떻게 이루어질까요?
이를 가능하게 하는 카프카의 핵심 요소들을 하나씩 살펴보겠습니다.
2-1 토픽과 파티션
카프카에 저장되는 메시지는 토픽(topic) 단위로 분류되고, 각 토픽은 다시 여러 개의 파티션으로 나뉩니다.
파티션이란?
파티션은 순차적으로 추가되는 로그 파일과 유사하며, 메시지는 한 번 기록되면 수정할 수 없고 항상 새로운 메시지가 뒤에 추가됩니다. 읽을 때는 처음부터 끝까지 순서대로 처리되지만, 토픽 내 여러 개의 파티션이 존재하기 때문에 전체 메시지의 순서는 보장되지 않고 개별 파티션 내에서만 순서가 유지됩니다.
파티션의 장점 : 복제와 안정성
파티션은 서로 다른 서버에 분산 저장될 수 있어 하나의 토픽이 여러 서버로 확장될 수 있으며, 이를 통해 더 높은 처리량과 저장 용량을 확보할 수 있습니다. 또한, 각 파티션은 복제본을 가질 수 있어 특정 서버에 장애가 발생하더라도 데이터 손실 없이 안정적으로 운영될 수 있습니다.
2-2 프로듀서와 컨슈머
프로듀서는 새로운 메시지를 생성하는 역할을 합니다. 이 때 생성된 메시지는 특정한 토픽에 쓰여지고, 기본적으로 프로듀서는 메시지를 쓸 때 토픽에 속한 파티션들 사이에 고르게 나뉘어 쓰도록 되어있습니다.
하지만 필요에 따라 프로듀서가 특정한 파티션을 지정해서 메시지를 쓰기도 하며. 이 때 메시지 키와 키값의 해시를 특정 파티션으로 대응시켜주는 파티셔너(partitioner)를 사용함으로써 동일한 키 값을 가진 메시지는 같은 파티션에 저장되게할 수 있습니다.
컨슈머는 메시지를 읽는 역할을 합니다. 1개 이상의 토픽을 구독해 저장된 메시지들을 각 파티션에 쓰여진 순서대로 읽어옵니다. 이 때 파티션에 쓰여진 메시지의 오프셋을 기록함으로써 메시지를 어디까지 읽었는지 유지합니다. 이를 통해 읽기 작업이 정지되었다가 다시 시작하더라도 마지막으로 읽었던 메시지의 바로 다음 메시지부터 읽을 수 있습니다.
오프셋이란?
카프카가 메시지를 저장할 때 각각 메시지에 부여해주는 메타데이터로 각 메시지는 고유한 오프셋을 가진다.
컨슈머는 컨슈머 그룹의 일원으로 작동하며, 컨슈머 그룹은 하나 이상의 컨슈머로 구성되어 저장된 데이터를 읽어오는 역할을 합니다.
컨슈머 그룹에서는 각 파티션이 하나의 컨슈머에 의해 소비되도록 할당되므로 같은 그룹 내의 컨슈머들은 서로 다른 파티션의 데이터를 처리하게 됩니다. (컨슈머가 2개 이상의 파티션을 읽는 경우도 존재) (But 하나의 파티션은 항상 하나의 컨슈머만 읽을 수 있다)
이를 통해 컨슈머를 수평적으로 확장하여 대량의 메시지를 가진 토픽을 효과적으로 처리할 수 있습니다. 또한, 컨슈머 중 하나가 장애가 발생하더라도 그룹 내 다른 컨슈머가 해당 파티션을 재할당받아 계속해서 데이터를 읽을 수 있어 안정적인 운영이 가능합니다.
2-3 브로커와 클러스터
하나의 카프카 서버를 브로커라고 합니다.
브로커는 프로듀서로부터 메시지를 전달받아 오프셋을 할당한 뒤 디스크 저장소에 쓰게되고, 컨슈머의 파티션 읽기 요청을 처리하고 발행된 메시지를 보내주는 역할을 합니다.
(하드웨어 성능에 따라 달라지겠지만 하나의 브로커는 초당 수천 개의 파티션과 수백만 개의 메시지를 처리할 수 있습니다.)
카프카 브로커는 클러스터의 일부로 작동하도록 되어있는데 하나의 클러스터 안에 여러개의 브로커가 포함될 수 있으며 그 중 하나의 브로커가 클러스터의 컨트롤러 역할을 하게됩니다. 컨트롤러는 파티션을 브로커에 할당해주거나 장애가 발생한 브로커를 모니터링 등의 관리 기능을 담당합니다.
파티션은 클러스터 안의 브로커중 하나가 담당하며 그 브로커를 파티션 리더라고 합니다.
복제된 파티션이 여러 브로커에 할당될 수도 있는데 이것을 파티션 팔로워라고 부릅니다.
복제 기능은 파티션 메시지를 중복 저장함으로써 리더 브로커에 장애가 발생했을 때 팔로워 중 하나가 리더 역할을 이어받을 수 있도록 합니다. 모든 프로듀서는 리더 브로커에 메시지를 발행해야하지만 컨슈머는 리더나 팔로워 중 하나로부터 데이터를 읽어올 수 있습니다.
또한 카프카에는 메시지를 일정 기간 동안 메시지를 보관할 수 있는 기능이 존재하는데 특정기간 혹은 파티션의 크기가 특정 사이즈에 도달할 때까지 보존하고 사이즈를 초과하거나, 기간이 만료되면 메시지를 삭제하게 됩니다.
참고
카프카 핵심 가이드
'Kafka' 카테고리의 다른 글
| Kafka가 신뢰성을 보장하는 방법 (0) | 2025.07.16 |
|---|---|
| [Kafka 정리] Kraft모드로 Kafka 실행하기 (feat. Docker) (0) | 2025.04.24 |
| [Kafka 정리] 카프카 내부 메커니즘 (1) | 2025.04.10 |
| [Kafka 정리] 카프카 컨슈머(KafkaConsumer) (0) | 2025.03.31 |
| [Kafka 정리] 카프카 프로듀서(Kafka Producer) (0) | 2025.03.30 |
