카프카란 무엇일까요..?
Kafka
카프카는 분산 메시징 시스템으로, 실시간 데이터 스트리밍, 로그 수집 및 처리, 이벤트 기반 아키텍처 구성 등에 주로 사용합니다.
Kafka의 기원
Kafka는 2011년 LinkedIn에서 시작되어 오픈소스로 공개된 분산 메시징 시스템입니다.
대규모 실시간 로그 수집과 데이터 스트리밍 문제를 해결하기 위해 개발되었습니다.
Kafka 핵심 특징
Kafka는 확장성, 내구성, 높은 처리량을 모두 갖춘 분산 메시징 시스템입니다.
수평 확장이 용이한 구조로 브로커를 손쉽게 추가할 수 있어서 확장성이 뛰어나고, 메시지를 디스크에 저장하고 복제(Replication) 기능을 통해 장애 발생 시에도 데이터를 안전하게 보존할 수 있어 내구성도 우수합니다.
또한 메시지를 묶어서 처리하는 배치 처리와 압축 전송을 통해, 초당 수십만 건 이상의 데이터를 처리할 수 있는 높은 처리량을 가집니다.
Kafka 아키텍처, Producer와 Consumer
Producer
Kafka의 Producer는 데이터를 생성하여 카프카 클러스터로 전송하는 역할을 합니다.
메시지 전송 과정에서는 특정 Topoic의 Partition으로 데이터가 전달됩니다.
Partition은 라운드 로빈이나 키 기반 해시 등의 전략으로 선택됩니다.
또한, 메시지 전송의 안정성을 위해 Ack(Acknowledge) 설정이 가능합니다. 예시로, acks=all로 설정하는 경우, 해당 파티션의 모든 복제본에 메시지가 저장되어야 성공으로 간주되며, 이는 높은 내구성을 보장합니다.
Consumer
Consumer는 Kafka에서 데이터를 읽는 역할을 합니다.
Consumer Group를 사용하면 병렬 처리(분산 처리)가 가능합니다. 하나의 Consumer Group 내에서는 각 Partition은 하나의 Consumer에만 할당합니다. 이를 통해서 중복 없이 데이터를 병렬로 처리할 수 있습니다.
또한, 데이터의 중복 소비나 누락을 방지하기 위해 Offset을 관리합니다. 여기서, Offset은 Kafka가 데이터를 어디까지 읽었는지를 기억하기 위한 위치 정보를 의미합니다.
하나의 Consumer Group 내에서는 각 Partition은 하나의 Consumer에만 할당 한다는게 무슨 뜻인가요?
하나의 Topic이 여러 Partition으로 나뉘어 있고, 하나의 Consumer Group에 여러 Consumer가 있을 때, 한 Partition은 여러 Consumer가 동시에 처리하지 않고, 오직 하나의 Consumer만이 해당 Partition의 데이터를 처리한다는 의미입니다.
데이터의 중복은 같은 메시지를 여러 Consumer가 중복으로 처리하지 않게 하는 것을 의미합니다.
Producer-Consumer 흐름
데이터 흐름은 다음과 같습니다.
Producer → Topic(Partition) → Consumer 구조로 대용량 데이터를 실시간으로 빠르고 안정적으로 처리할 수 있습니다.
Producer는 데이터를 생성하고 Kafka의 Topic에 전송합니다.
Kafka는 이 데이터를 Partition 단위로 나누어 저장하고, Consumer는 각 Partition에서 데이터를 읽어옵니다.
여러 Partition에서 병렬로 처리되기 때문에 많은 데이터를 빠르게 처리할 수 있습니다.
따라서, Partition 수를 늘리고 Consumer Group을 확장하면 시스템 전체 성능을 높일 수 있습니다.
Kafka 아키텍처, Broker와 Topic
Broker
Kafka 클러스터를 구성하는 개별 서버 노드입니다. Kafka는 여러 개의 Broker로 이루어져 있습니다.
Broker Cluster
여러 개의 Broker로 구성된 클러스터입니다.
각 Broker는 특정 Partition의 데이터를 저장하고 관리합니다.
리더와 팔로워 구조
리더는 해당 Partition의 주요 데이터를 처리하는 Broker입니다. Producer와 Consumer는 리더 Broker를 통해 데이터를 주고받습니다.
팔로워는 리더의 데이터를 복제하고, 리더에 장애가 생기면 리더 역할을 대신할 준비를 합니다.
Kafka에서 하나의 토픽은 여러 개의 파티션으로 나뉘며, 각 파티션은 여러 브로커에 복제됩니다. 이때 파티션마다 하나의 리더 브로커가 존재하고, 나머지는 팔로워 브로커입니다.
리더는 해당 파티션에 대해 읽기와 쓰기 작업을 모두 처리하는 주체입니다. 프로듀서가 메시지를 보내거나 컨슈머가 메시지를 읽을 때 모두 리더를 통해 이루어집니다.
팔로워는 리더의 데이터를 실시간으로 복제하며, 읽기나 쓰기 요청은 직접 처리하지 않습니다. 대신 리더가 장애가 발생했을 때 자동으로 새로운 리더가 팔로워 중에서 선출되어 클러스터의 안정성과 가용성을 유지합니다.
이 구조 덕분에 Kafka는 고가용성과 데이터 손실 방지라는 두 가지 목적을 달성할 수 있습니다.
Topic
Topic은 Kafka에서 메시지를 분류하는 단위로 메시지 카테고리 역할을 합니다.
하나의 Topic은 여러 Partition으로 구성되고, 각 Partition은 데이터를 나누어 저장함으로써 병렬 처리를 가능하게 합니다.
이를 통해서 데이터 처리 성능과 확장성을 확보할 수 있습니다.
Kafka는 발행과 구독 모델을 기반으로 동작하며, Producer는 Topic에 메시지를 발행하고 Consumer는 Topic을 구독하여 메시지를 소
비합니다.
Broker-Topic 관계
Kafka에서 하나의 토픽은 여러 개의 파티션으로 나누고, 이 파티션들은 여러 브로커에게 분산되어 저장됩니다.
이렇게 분산 저장함으로써 하나는 장애가 나더라도 전체 시스템이 멈추지 않고, 여러 브로커가 동시에 데이터를 처리하니 성능도 좋아집니다.
Kafka 아키텍처, Partition과 Replication
Partition
Kafka에서 파티션은 데이터를 저장하고 처리하는 핵심 단위입니다. 하나의 토픽은 여러 개의 파티션으로 나뉘고, 각 파티션은 고유한 번호를 가지고 있습니다. 이 파티션들은 물리적으로 서로 다른 브로커에 분산되어 저장될 수 있기 때문에, 데이터 부하를 분산시킬 수 있습니다.
파티션 단위로 병렬 처리가 가능하기 때문에, Kafka는 고성능 대용량 데이터를 빠르게 처리할 수 있습니다. 각 파티션은 로그 파일 형식으로 데이터를 저장하며, 새로운 데이터는 맨 뒤에 추가되는 방식으로 쌓이게 됩니다.
즉, 파티션은 Kafka가 빠르고 안정적으로 데이터를 처리하고 저장할 수 있도록 해주는 구조입니다.
Replication
Kafka는 데이터를 여러 곳에 복제해서 저장함으로써, 장애가 나더라도 데이터를 안전하게 보호하고 서비스를 계속 유지할 수 있습니다.
Kafka의 파티션은 Leader-Follower 구조로 동작합니다. Leader는 실제 데이터를 주고 받는 주 역할을 하고, Follower는 Leader의 데이터를 복제해서 백업합니다. 만약, Leader가 장애로 멈추는 경우, Follower가 대신 Leader가 됩니다.
복제 개수를 정하는 설정을 Replication Factor라고 합니다. 보통 하나의 파티션당 2~3개의 복제본을 유지하는데, 복제본이 많을수록 장애에 강해지지만, 리소스(디스크, 네트워크 등) 사용량도 늘어납니다. 그래서 장애 내성과 자원 사용량 사이에서 적절한 균형을 잡아야 합니다.
Partition-Replication 관계
Kafka에서 Partition과 Replication은 함께 동작하면서 시스템의 안정성을 높여줍니다.
각 파티션은 복제본을 여러 개 만들어 두는데, 이 덕분에 데이터가 손실되지 않고 안전하게 보관됩니다.
이렇게 복제본을 유지하면 특정 브로커가 장애를 일으켜도 다른 복제본이 있기 때문에 서비스가 계속 동작할 수 있습니다.
즉, Partition-Replication 구조는 데이터의 내구성(데이터 손실 방지)과 고가용성(장애 시에도 서비스 유지)을 함께 보장해주는 중요한 역할을 합니다.
Kafka 아키텍처, Offset
Offset을 이용하면 Consumer는 이전에 읽었던 위치부터 정확히 이어서 메시지를 읽을 수 있습니다.
Offset을 사용하면 다음과 같은 장점이 있습니다:
1. 메시지 순서를 유지할 수 있습니다.
읽는 순서가 섞이지 않고, 항상 순차적으로 처리됩니다.
2. 중복 처리를 방지할 수 있습니다.
이전에 처리한 메시지를 또 읽지 않도록 할 수 있습니다.
3. 처리 일관성을 유지할 수 있습니다.
중간에 장애가 나도 마지막에 읽은 위치부터 다시 처리 가능하므로 안정적입니다.
즉, Offset은 Kafka에서 메시지를 안정적이고 정확하게 소비하기 위한 핵심 요소입니다.
Offset 관리 방식
Kafka에서 Offset은 메시지를 어디까지 읽었는지를 저장하는 값인데, 이 Offset을 어떻게 저장할지는 두 가지 방식이 있습니다.
1. 자동 커밋
Kafka가 일정 시간마다 자동으로 Offset을 저장합니다.
개발자가 따로 신경 쓰지 않아도 되지만, 처리 중 문제가 생기면 이미 읽은 것으로 기록되어 데이터 손실 위험이 있습니다.
2. 수동 커밋
Consumer가 직접 “지금까지 처리 완료”라고 명시적으로 Offset을 저장합니다.
메시지를 완전히 처리한 뒤 커밋하면, 안전하게 중복 없이 처리할 수 있습니다.
Offset과 메시지 처리 일관성
Kafka에서 Offset을 잘 관리하면 메시지를 정확하게 한 번만 처리할 수 있습니다. 이를 Exactly-once 처리라고 부릅니다.
이렇게 하면 다음과 같은 효과가 있습니다:
1. 메시지를 중복 없이 정확히 한 번만 처리할 수 있습니다.
2. 데이터를 처리하는 순서와 결과가 항상 같아서 일관성을 유지할 수 있습니다.
3. 시스템 장애나 재시도 상황에서도 같은 메시지를 두 번 처리하는 것을 방지할 수 있습니다.
결국 Offset과 메시지 처리를 함께 잘 다루면, 안정적이고 신뢰성 있는 데이터 흐름을 만들 수 있습니다.
흐름
Producer → Topic(Partition) → Broker → Consumer(Offset 관리)
1. Producer가 메시지를 생성합니다.
Producer는 어떤 데이터를 전송하려고 합니다.
이 데이터는 특정 Topic으로 보냅니다.
2. Kafka가 메시지를 Topic의 Partition에 저장합니다.
Kafka는 메시지를 받을 때, 그 Topic의 여러 Partition 중 하나에 저장합니다.
어떤 Partition에 넣을지는 Kafka가 내부 규칙(Round-robin, key 해시 등)으로 결정합니다.
3. Partition은 특정 Broker가 관리합니다.
각 Partition은 하나의 Kafka Broker가 저장소 역할을 하며 관리합니다.
이때 해당 Partition의 Leader Broker가 쓰기/읽기 모두 담당합니다.
4. Consumer가 읽기를 요청합니다.
Consumer는 특정 Topic을 구독(subscribe) 합니다.
Kafka는 그 Topic의 Partition 중 일부를 Consumer에게 할당합니다.
Consumer는 자신이 할당받은 Partition에 대해, 해당 Partition의 Leader Broker에 직접 요청해서 메시지를 가져옵니다.
5. Offset 기반으로 데이터 읽기
Consumer는 메시지를 읽을 때, Offset(어디까지 읽었는지 위치)을 기준으로 데이터를 순서대로 받아갑니다.
'Kafka' 카테고리의 다른 글
Kafka Transactional Producer (0) | 2025.04.22 |
---|---|
Dead Letter Topic (0) | 2025.04.21 |
Kafka 재고 차감 방식 (0) | 2025.04.21 |
Kafka 사용 사례 (0) | 2025.04.16 |