728x170
해당 글에서는 Apache Kafka에 대해 이해를 돕기 위해 작성한 글입니다.
💡 [참고] Docker 기반의 초기 Apache Kafka 구성이나 혹은 Apache Kafka 이론에 대해 궁금하시면 아래의 글을 참고하시면 도움이 됩니다.
분류 | 설명 | 링크 |
Docker | Docker 기반 Apache Kafka 환경 구축하기 | https://adjh54.tistory.com/637 |
이해하기 | Apache Kafka 이해하기 -1: 주요 모델 및 구성요소 | https://adjh54.tistory.com/636 |
이해하기 | Apache Kafka 이해하기 -2 : Zookeeper, KRaft(Kafka Raft), 비교 | https://adjh54.tistory.com/639 |
Java 활용 | Spring Boot Kafka 이해하고 활용하기 -1 : 주요 특징, 활용 사례, 클래스/메서드 | https://adjh54.tistory.com/640 |
Java 활용 | Spring Boot Kafka 이해하고 활용하기 -2 : 환경 구성 및 사용 예시 | https://adjh54.tistory.com/641 |
Github | Docker Compose를 이용한 KRaft 구성 예시 Repository | https://github.com/adjh54ir/multiflex-docker/tree/main/simple-apache-kafka |
Github | Spring Boot Kafka를 이용한 예시 Repository | https://github.com/adjh54ir/blog-codes/tree/main/spring-boot-kafka |
1) Apache Kafka
💡 Apache Kafka
- 실시간으로 스트림 데이터를 수집하고 처리하는 데 최적화된 ‘분산 이벤트 스트리밍 플랫폼(Distributed Data Streaming Platform)’입니다. 이는 실시간으로 발생하는 대량의 데이터를 중앙 허브를 통해 흐르도록 설계되어 있습니다. 이를 통해 데이터의 일관성을 유지하고 시스템 전반의 복잡성을 줄일 수 있습니다.
- 이러한 다량의 데이터는 A 지점에서 B 지점까지만의 데이터가 이동되는 것뿐만 아니라, A 지점에서 Z지점까지의 필요한 모든 곳에 대규모 데이터를 동시에 전달할 수 있습니다.
- 현대적인 데이터 파이프라인 구축에 필수적인 도구로 자리잡았으며, Netflix, LinkedIn, Uber 등 많은 기업들이 핵심 인프라로 사용하고 있습니다.
[ 더 알아보기 ]
💡 Kafka에 의해 처리되는 스트림(Stream)과 스트리밍(Streaming)은 무엇일까?
- 스트림(Stream)이란 시간에 따라 연속적으로 발생하는 데이터의 흐름을 의미합니다. 예를 들어, 실시간 주식 거래 데이터, SNS 피드, IoT 센서 데이터 등이 스트림의 예시입니다.
- 스트리밍(Streaming)은 이러한 데이터 스트림을 실시간으로 처리하는 과정을 말합니다
💡 분산 이벤트 스트리밍 플랫폼(Distributed Event Streaming Platform)이란?
- 여러 서버에 걸쳐 이벤트 데이터를 실시간으로 처리하고 저장하는 시스템을 의미합니다. 주요한 특징은 분산 처리를 실시간으로 처리하며, 데이터 복제를 통해 장애 상황에서도 데이터 손실을 방지하며, 이벤트 발생 순서대로 처리하여 데이터의 일관성을 보장합니다.
1. 등장 배경
💡 등장 배경
- 2011년 LinkedIn에서 처음 개발되었습니다. LinkedIn은 실시간으로 발생하는 대량의 사용자 활동 데이터(예: 프로필 조회, 메시지, 연결 요청 등)를 효율적으로 처리하고 분석해야 하는 과제에 직면했습니다.
💡 [참고] 아래의 글을 참고하여 등장 배경을 확인하였습니다.
💡 기존 LinkedIn의 아키텍처
- LinkedIn 아키텍처 내에서는 “필요에 따라 시스템과 애플리케이션 간에 임시 파이프를 구축하고 모든 비동기 처리를 요청-응답 웹 서비스에 강제로 처리하였다”라고 이야기하고 있습니다.
- 그렇기에, 시간이 지남에 따라 이러한 설정은 점점 더 복잡해져서 결국 모든 종류의 다른 시스템 간에 파이프라인을 구축하게 되었습니다. 그렇지만, "각 파이프라인은 고유한 방식으로 문제가 있었습니다. 로그 데이터 파이프라인은 확장 가능했지만 손실이 있었고 지연 시간이 긴 데이터만 제공할 수 있었습니다.”
💡 LinkedIn의 Apache Kafka를 적용한 아키텍처
- 스트림 중심의 아키텍처로 구성이 되었습니다. 이 설정에서 Kafka는 일종의 범용 데이터 파이프라인 역할을 합니다.
- 각 시스템은 이 중앙 파이프라인에 공급하거나 공급받을 수 있습니다.
- 애플리케이션이나 스트림 프로세서는 이를 탭하여 새로운 파생 스트림을 생성할 수 있으며, 이는 다시 다양한 시스템에 공급되어 제공됩니다.
2. 주요 특징
💡 주요 특징
- 주요한 특징은 ‘실시간 처리’와 '고가용성'입니다.
- 데이터를 실시간으로 처리하면서, 시스템이 장시간 동안 중단 없이 지속적으로 운영될 수 있는 능력을 의미합니다.
특징 | 설명 |
높은 처리량 | 대용량의 실시간 로그 데이터를 처리하는데 적합하며, 초당 수백만 건의 메시지를 처리할 수 있습니다. |
확장 가능 | 최대 1,000개의 브로커, 하루 수조 개의 메시지, 페타바이트 규모의 데이터, 수십만 개의 파티션까지 프로덕션 클러스터를 확장할 수 있으며, 저장소와 처리를 탄력적으로 확장하고 축소할 수 있습니다. |
낮은 지연시간 | 실시간 데이터 파이프라인을 구성하는데 적합한 밀리초 단위의 지연시간을 제공합니다. |
높은 가용성 | 가용성 영역에 걸쳐 클러스터를 효율적으로 확장하거나 여러 지리적 영역에 걸쳐 있는 개별 클러스터를 연결합니다. |
영속성 | 디스크에 데이터를 저장하여 데이터의 영속성을 보장하며, 데이터 손실을 방지합니다. |
3. 주요 사용 사례
💡 주요 사용 사례
- 주요 사용되는 사례는 ‘실시간 스트리밍 애플리케이션’을 구축하거나 ‘실시간 스트리밍 데이터 파이프 라인’을 구축, 메시지 브로커로 사용합니다.
1. 실시간 스트리밍 애플리케이션
- 실시간으로 발생하는 데이터를 지속적으로 처리하고 분석하는 애플리케이션입니다.
- 예를 들어 실시간 로그 분석, 실시간 모니터링 시스템 등이 있습니다.
2. 데이터 파이프 라인
- 데이터를 안정적으로 처리하고 한 시스템에서 다른 시스템으로 이동하며, 스트리밍 애플리케이션은 데이터 스트림을 소비하는 애플리케이션입니다.
- 예를 들어서, 사용자 활동 데이터를 받아 사람들이 웹사이트를 어떻게 사용하는지 실시간으로 추적하는 데이터 파이프라인을 만들려면 Kafka를 사용하여 스트리밍 데이터를 수집 및 저장하면서 데이터 파이프라인을 구동하는 애플리케이션에 읽기 서비스를 제공할 수 있습니다.
3. 메시징 시스템(브로커)
- 애플리케이션 간의 메시지 전달을 중개하는 미들웨어 시스템입니다. 발신자(Producer)와 수신자(Consumer) 사이에서 메시지를 전달하는 중간 역할을 수행합니다.
사용 사례 | 설명 |
스트리밍 애플리케이션 | 실시간 데이터 스트림을 처리하는 애플리케이션을 구축하여 즉각적인 분석과 대응이 가능합니다. |
메시징 시스템 | 애플리케이션 간의 비동기 통신을 위한 메시지 브로커 역할을 수행하며, 시스템 간 안정적인 데이터 전달과 통신을 중재합니다. |
데이터 파이프라인 | 실시간 데이터를 수집하고 저장하면서 다른 시스템으로 안정적으로 전달하는 파이프라인을 구축합니다. |
활동 추적 | 웹사이트나 애플리케이션의 사용자 행동 데이터를 실시간으로 수집하고 분석하여 사용 패턴을 파악합니다. |
로그/메트릭 수집 | 여러 서비스의 로그와 성능 지표를 중앙 집중화하여 모니터링하고 관리합니다. |
4. Apache Kafka vs RabbitMQ
💡 Apache Kafka vs RabbitMQ
- 주요한 차이점은 Apache Kafka의 경우는 ‘분산 스트리밍 플랫폼’이고, RabbitMQ의 경우는 ‘메시지 브로커’입니다.
- 즉, Apache Kafka의 경우는 메시지 브로커의 역할도 수행하며, 데이터 스트림의 저장, 처리, 실시간 분석 등 더 광범위한 데이터 처리 추가 기능 제공하며 이는 더 포괄적인 개념이라고 할 수 있습니다.
특성 | Apache Kafka | RabbitMQ |
아키텍처 | 분산 스트리밍 플랫폼 | 메시지 브로커 |
프로토콜 | TCP를 이용한 바이너리 프로토콜 | 메시징 큐 프로토콜(AMQL) : MQTT, STOMP |
메시징 모델 | 발행-구독(Pub/Sub) 기반 스트리밍, 대기열(Queue) 모델 | 메시지 큐잉과 라우팅 중심 |
성능 | 대용량 데이터 처리에 최적화 (높은 처리량) | 낮은 지연시간, 중소규모 메시징에 적합 |
데이터 보존 | 설정된 기간동안 데이터 보존 (영속성) | 메시지 전달 후 즉시 삭제 |
확장성 | 수평적 확장이 용이, 대규모 확장 가능 | 수직적 확장 중심, 중소규모에 적합 |
사용 사례 | 로그 수집, 스트림 처리, 이벤트 소싱 | 마이크로서비스 간 통신, 작업 큐 |
메시지 순서 | 파티션 내에서 순서 보장 | FIFO 큐에서 순서 보장 |
복잡성 | 설정과 운영이 상대적으로 복잡 | 설정과 운영이 비교적 간단 |
💡 [참고] RabbitMQ에 대해 궁금하시면 아래의 글을 참고하시면 도움이 됩니다.
분류 | 링크 |
Spring Boot AMQP RabbitMQ -1 : 구조 및 종류 이해하기 | https://adjh54.tistory.com/284 |
Spring Boot AMQP RabbitMQ -2 : 로컬 환경 구성하기 | https://adjh54.tistory.com/285 |
Spring Boot AMQP RabbitMQ -3 : Java 환경 구축 및 간단 예시 | https://adjh54.tistory.com/292 |
Spring Boot AMQP RabbitMQ -4 : Exchange 종류 별 이해 및 사용예시 | https://adjh54.tistory.com/497 |
Spring Boot AMQP RabbitMQ -5 : TTL 및 데드 레터링 사용예시 | https://adjh54.tistory.com/501 |
Spring Boot AMQP RabbitMQ -6 : 메시지 큐 종류, 큐 우선순위 | https://adjh54.tistory.com/518 |
Docker : Docker를 이용하여 RabbitMQ 구축하기 | https://adjh54.tistory.com/496 |
Docker : Docker Compose를 이용하여 RabbitMQ Node Cluster 구축하기 | https://adjh54.tistory.com/517 |
API Document : QueueBuilder API Document | https://adjh54.tistory.com/505 |
API Document : ExchangeBuilder API Document | https://adjh54.tistory.com/506 |
API Document : MessageProperties, MessagePropertiesBuilder, MessageBuilderSupport | https://adjh54.tistory.com/508 |
Spring Boot AMQP RabbitMQ Github : Event Producer | https://github.com/adjh54ir/blog-codes/tree/main/spring-boot-rabbitmq |
Spring Boot AMQP RabbitMQ Github : Event Consumer | https://github.com/adjh54ir/blog-codes/tree/main/spring-boot-rabbitmq-consumer |
2) Apache Kafka 모델
1. 대기열(Queue) 모델
💡 대기열 (Queue) 모델
- 생성자(Producer)가 생성한 데이터를 여러 소비자(Consumer)에게 분산하는 기능을 합니다. 해당 모델은 여러 소비자(Consumer)가 동시에 구독할 수 없다는 한계가 있습니다.
- 즉, 생성자는 데이터를 큐에 적재하고 큐에서는 순차적으로 데이터가 추출되기에 모든 소비자에게 동시에 전달이 아닌 순차적으로 전달이 됩니다.
- 이를 통해서 순서가 보장이 되며, 메시지 중복 처리를 방지하고 작업을 분산하는데 효과적인 방법입니다.
💡 대기열(Queue) 모델 처리 과정
1. 생성자(Producer) → 데이터(Data) → 대기열(Queue)
- 생성자는 애플리케이션이나 서비스를 의미하며, 대기열(Queue)로 스트림 데이터를 전송합니다.
- 전송된 데이터는 대기열(Queue)에 FIFO(First In First Out) 형태로 순차적으로 적재가 됩니다.
2. 대기열(Queue) → 소비자(Consumer)
- 대기열(Queue)에 있는 데이터는 소비자(Consumer)가 하나씩 가져가서 처리합니다.
- 데이터는 순차적으로 처리되며, 하나의 데이터는 하나의 소비자에 의해서만 처리됩니다.
- 소비자가 데이터를 성공적으로 처리하면 해당 데이터는 대기열에서 제거됩니다.
2. 게시-구독(Publish-Subscribe) 모델
💡 게시-구독(Publish-Subscribe) 모델
- 게시자(Publisher)가 발행한 메시지를 여러 소비자(Consumer)가 동시에 구독하고 처리할 수 있습니다. 각 소비자는 독립적으로 메시지를 받아 처리할 수 있습니다.
- 작업 부하를 분산하기 위해서는 각 구독자가 서로 다른 메시지를 처리해야 하는데, 게시-구독 모델에서는 모든 구독자가 동일한 메시지를 받기 때문에 이것이 불가능합니다.
- 즉, 해당 모델에서는 하나의 메시지가 모든 구독자에게 복사되어서 전달이 됩니다. 예를 들어서, 메시지 A가 발행되면 구독자 1, 2, 3에게 모두 동일한 메시지 A가 전달이 됩니다.
1. 게시자(Publisher) → 데이터(Data) → PubSub(Publisher Subsciber)
- 게시자는 애플리케이션이나 서비스를 의미하며, 데이터를 스트림 형태로 발행(Publish)합니다.
2. PubSub(Publisher Subsciber) → 구독자(Subscriber)
- 발행된 스트림 데이터는 이를 구독(Subscribe)하고 있던 모든 구독자(Subsciber)에게 전달이 됩니다.
- 전달된 구독자는 Single Consumer에게 전달되거나 혹은 여러 Consumer(Consumer Group)에게 다시 전달이 됩니다.
3) Apache Kafka 요소
💡 Apache Kafka 요소
- Apache Kafka는 다음과 같은 주요 구성 요소들로 이루어져 있습니다. 각 요소들은 서로 유기적으로 연결되어 분산 스트리밍 플랫폼으로서의 기능을 수행합니다.
구성 요소 | 설명 | 주요 특징 |
생성자(Producer) | 메시지를 생성하고 발행하는 애플리케이션 | - 동기/비동기 전송 지원 - 파티션 분배 역할 - 메시지 신뢰성 보장 |
소비자(Consumer) | 토픽으로부터 메시지를 구독하고 읽는 애플리케이션 | - 메시지 오프셋 관리 - 자동/수동 커밋 - 병렬 처리 가능 |
소비자 그룹(Consumer Group) | 협력하여 메시지를 처리하는 소비자들의 집합 | - 자동 로드 밸런싱 - 장애 복구 기능 - 파티션별 할당 |
파티션(Partition) | 토픽을 나누는 물리적 단위 | - 병렬 처리 지원 - 순서 보장 - 확장성 제공 |
토픽(Topic) | 메시지가 저장되는 논리적 단위 | - 카테고리 분류 - 다중 구독 가능 - 영구 저장소 |
오프셋(Offset) | 파티션 내 각 메시지의 고유한 위치 식별자 | - 메시지 순서 보장 - 소비 위치 추적 - 재처리 가능 |
브로커(Broker) | 카프카 서버 | - 메시지 저장/관리 - 복제 관리 - 장애 복구 |
카프카 클러스터(Kafka Cluster) | 여러 브로커들의 분산 시스템 집합 | - 고가용성 보장 - 확장성 제공 - 부하 분산 |
1. 생성자(Producer)
💡 생성자(Producer)
- Kafka에서 메시지를 생성하고 발행하는 애플리케이션이나 서비스를 의미합니다.
- 동기/비동기 전송을 지원하며, 다양한 설정으로 성능과 신뢰성을 조절할 수 있습니다.
- 생성된 메시지를 토픽의 특정 파티션에 분배하는 역할을 합니다
기능 | 설명 | 세부 사항 |
메시지 발행 | 토픽에 데이터를 전송하는 역할을 담당합니다. | |
파티션 할당 | 메시지를 특정 토픽의 파티션에 분배하는 역할을 합니다. | - Round-Robin: 순차적으로 파티션에 할당 - Key-based: 메시지 키를 기반으로 특정 파티션에 할당 - Custom: 사용자 정의 파티션 전략 사용 |
신뢰성 보장 | 메시지 전송의 신뢰성 수준을 설정합니다. | - acks=0: 메시지 전송 후 응답을 기다리지 않음 - acks=1: 리더 파티션의 응답만 기다림 - acks=all: 모든 복제본의 응답을 기다림 |
배치 처리 | 성능 향상을 위해 여러 메시지를 묶어서 한 번에 전송할 수 있습니다. |
2. 소비자(Consumer)
💡 소비자(Consumer)
- Kafka Topic으로부터 메시지를 구독(Subscribe)하고 읽어오는 애플리케이션이나 서비스를 의미합니다.
- 하나 이상의 토픽을 구독(Subscribe)하여 메시지를 지속적으로 소비합니다. 구독 과정에서 특정 토픽의 파티션에 할당되어 메시지를 읽어옵니다.
- Consumer Group을 통해 여러 Consumer가 협력하여 병렬 처리가 가능합니다.
기능 | 설명 | 세부 사항 |
메시지 소비 | 토픽으로부터 메시지를 읽어오는 기본적인 기능을 수행합니다. | - 자동/수동 커밋 지원 - 오프셋 관리 |
Consumer Group | 여러 Consumer를 그룹화하여 병렬 처리를 가능하게 합니다. | - 파티션당 하나의 Consumer 할당 - 자동 로드 밸런싱 - Failover 지원 |
오프셋 관리 | 메시지 소비 위치를 추적하고 관리합니다. | - earliest: 가장 처음부터 소비 - latest: 최신 메시지부터 소비 - 특정 오프셋부터 소비 |
재조정(Rebalancing) | Consumer Group 내에서 파티션을 재분배합니다. | - Consumer 추가/제거시 자동 재조정 - 장애 발생시 자동 복구 |
3. 소비자 그룹(Consumer Group)
💡 소비자 그룹(Consumer Group)
- 하나의 토픽에 대해 협력하여 메시지를 처리하는 소비자(Consumer)들의 집합을 의미합니다. 즉, 동일한 토픽을 구독하는 소비자들의 논리적인 그룹입니다.
- 하나의 파티션은 동일한 Consumer Group 내에서 하나의 Consumer에만 할당됩니다.
- 파티션의 수보다 Consumer가 많으면 일부 Consumer는 유휴 상태가 됩니다.
- 예를 들어서 하나의 토픽에는 3개의 파티션이 있고 Consumer Group 내에 2개의 Consumer가 있다고 가정합니다.
- 이때는, Consumer 1은 파티션 1, 2를 처리하고, Consumer 2는 파티션 3을 처리하여 하나의 토픽에 대해 협력하여 처리합니다.
기능 | 설명 | 세부사항 |
로드 밸런싱 | 파티션을 Consumer들에게 균등하게 분배합니다. | - 자동 파티션 할당 - Consumer 수에 따른 동적 조정 - 효율적인 부하 분산 |
장애 복구 | Consumer 장애 시 자동으로 재조정됩니다. | - 자동 리밸런싱 - 장애 Consumer 감지 - 파티션 재할당 |
확장성 | Consumer를 추가하여 처리량을 증가시킬 수 있습니다. | - 동적 Consumer 추가/제거 - 수평적 확장 가능 - 파티션 수 제한 |
오프셋 관리 | 그룹 단위로 메시지 소비 위치를 추적합니다. | - 중복 처리 방지 - 그룹별 독립적 관리 - 커밋 포인트 저장 |
[ 더 알아보기 ]
💡 Consumer Group 병렬 처리는 어떻게 수행이 될까?
- 예를 들어서, 하나의 토픽 내에 파티션이 6개가 있고, Consumer Group 내에는 3명이 있다고 가정하에 있습니다.
- 이때, Consumer 1은 P1, P2를 처리하고 Consumber2는 P3, P4를 처리하고 Consumer 3에서는 P5, P6를 처리합니다.
- 이를 통해서 독립적으로 분산 처리를 수행하게 됩니다.
4. 메시지(Message)
💡 메시지(Message)
- Kafka에서 데이터를 전송하는 기본 단위입니다.
- 키(Key), 값(Value), 타임스탬프(Timestamp)로 구성되며, 선택적으로 헤더(Headers)를 포함할 수 있습니다.
- 메시지는 한번 기록되면 변경할 수 없는 불변(Immutable) 특성을 가집니다.
구성요소 | 설명 | 특징 |
키(Key) | 메시지를 식별하는 선택적 메타데이터 | - 파티션 결정에 사용 - 동일한 키는 동일한 파티션에 저장 - null 가능 |
값(Value) | 실제 전송하려는 데이터 내용 | - 바이트 배열 형태로 저장 - 다양한 형식 지원 (JSON, Avro, 등) - 압축 가능 |
타임스탬프 | 메시지가 생성된 시간 정보 | - 메시지 순서 보장 - 데이터 추적 - 보존 정책에 활용 |
헤더 | 추가적인 메타데이터를 저장 | - 키-값 쌍으로 구성 - 선택적 사용 - 애플리케이션별 커스텀 정보 저장 |
5. 파티션(Partition)
💡 파티션(Partition)
- 토픽을 여러 개의 파티션으로 나누어 병렬 처리를 가능하게 하는 물리적 단위입니다
- 각 파티션은 순서가 있는 불변의 시퀀스로 구성되며, 고유한 오프셋을 가집니다
- 파티션을 통해 데이터를 여러 브로커에 분산 저장하여 높은 처리량과 확장성을 제공합니다
기능 | 설명 | 세부사항 |
병렬 처리 | 토픽의 데이터를 여러 파티션으로 분할하여 동시 처리를 가능하게 합니다. | - 높은 처리량 제공 - 수평적 확장성 지원 - 다중 컨슈머 병렬 처리 |
순서 보장 | 각 파티션 내에서 메시지의 순서가 보장됩니다. | - 파티션 내 순차적 오프셋 - FIFO(First In First Out) 방식 - 파티션 간 순서는 보장되지 않음 |
복제 | 데이터 안정성을 위해 파티션을 여러 브로커에 복제합니다. | - 리더-팔로워 구조 - 복제 팩터 설정 - 자동 장애 복구 |
로드 밸런싱 | 파티션을 통해 브로커 간 부하를 분산합니다. | - 균등한 데이터 분배 - 효율적인 리소스 활용 - 동적 파티션 재분배 |
6. 토픽(Topic)
💡 토픽(Topic)
- Kafka에서 메시지가 저장되는 논리적인 채널 또는 피드의 이름을 의미합니다.
- 생성자(proceduer)가 메시지를 발행하고 소비자(proceduer)는 이를 구독하는 대상이 됩니다.
- 하나의 토픽은 여러 개의 파티션으로 분할될 수 있습니다.
기능 | 설명 | 세부사항 |
메시지 구성 | 토픽은 관련된 메시지들의 스트림을 구성합니다. | - 메시지는 키-값 쌍으로 구성 - 시간 순서로 저장 - 고유한 오프셋 보유 |
확장성 | 파티션을 통해 수평적 확장이 가능합니다. | - 다수의 파티션으로 분할 가능 - 파티션별 독립적 처리 - 병렬 처리 지원 |
데이터 보존 | 설정된 보존 정책에 따라 메시지를 유지합니다. | - 시간 기반 보존 - 크기 기반 보존 - 압축 로그 지원 |
접근 제어 | 토픽별로 접근 권한을 관리할 수 있습니다. | - 읽기/쓰기 권한 설정 - ACL 기반 보안 - 다중 구독자 지원 |
7. 오프셋(Offset)
💡오프셋(Offset)
- 파티션 내에서 각 메시지를 고유하게 식별하는 순차적인 ID 번호입니다.
- 파티션 내에서 순차적으로 증가하는 정수값으로, 메시지의 위치를 나타냅니다.
- Consumer가 어디까지 메시지를 읽었는지 추적하는 데 사용됩니다.
- 예를 들어서, 데이터가 1, 2, 3, 4, 5, 6이라는 값이 순차적으로 Topic 내에 파티션에 들어갔다고 가정하에 Consumer는 3개 있을 때를 가정하에 있습니다.
- 이는 Consumer Group을 이루어서 Consumer 1은 1, 4 오프셋을 찾아서 데이터를 가져오고, Consumer 2는 2,5를 가져오고 Consumer 3는 3, 6의 값을 가져오는 서로 다른 파티션을 병렬 처리를 수행합니다.
💡 아래의 그림에서 Consumer 1, Consumer2에서는 Topic 내에 Partition을 가져오는 역할을 수행하고 있습니다.
- Consumer 1은 offset 4라는 값과 Consumer2는 offeset 3이라는 값을 가리키고 있어서 각각의 순차적인 ID 번호 값을 가져오는 역할을 수행합니다.
구성요소 | 설명 | 세부사항 |
시작 오프셋 | 파티션에서 가장 오래된 메시지의 위치 | - earliest: 가장 처음 메시지부터 읽기 - 보관 정책에 따라 변경될 수 있음 |
현재 오프셋 | Consumer가 현재까지 읽은 위치 | - Consumer Group별로 관리 - 자동/수동 커밋 가능 |
최신 오프셋 | 파티션에서 가장 최근에 추가된 메시지의 위치 | - latest: 최신 메시지부터 읽기 - Producer가 새 메시지 추가시 증가 |
커밋된 오프셋 | Consumer가 성공적으로 처리했다고 표시한 위치 | - 중복 처리 방지 - 장애 복구시 활용 - Consumer Group별 독립적 관리 |
8. 브로커(Broker)
💡 브로커(Broker)
- Kafka 클러스터를 구성하는 서버 단위입니다. 이는 메시지를 수신하고 저장을 담당하는 역할을 의미합니다.
- 생성자(Producer)로부터 전달받은 토픽의 파티션을 저장하고 관리하는 역할을 합니다.
- 소비자(Consumer)로부터 요청에 따라 저장된 메시지를 전달하는 역할을 수행합니다.
- 생성자와 소비자 간의 메시지 전달을 중개하는 역할을 수행합니다.
- 카프카 클러스터(Kafka Cluster)내에서 각 브로커 마다 고유한 ID를 가지며, 다른 브로커들과 협력하여 데이터를 복제하고 동기화를 수행합니다.
기능 | 설명 | 세부 사항 |
메시지 저장 | 토픽의 파티션을 디스크에 저장하고 관리합니다. | - 설정된 보관 기간 동안 메시지 보존 - 디스크 기반 저장으로 영속성 보장 |
복제 관리 | 데이터의 안정성을 위해 파티션 복제본을 관리합니다. | - 리더와 팔로워 파티션 관리 - 자동 장애 복구 지원 - 복제 팩터 설정 가능 |
부하 분산 | 클러스터 내에서 데이터와 요청을 분산 처리합니다. | - 파티션의 균등한 분배 - 네트워크 트래픽 분산 - 리소스 사용 최적화 |
컨트롤러 기능 | 클러스터 내 리더 선출과 관리를 담당합니다. | - 브로커 상태 모니터링 - 파티션 리더 선출 - 클러스터 메타데이터 관리 |
9. 클러스터(Cluster)
💡 클러스터(Cluster)
- 여러 대의 브로커(Broker)들이 모여 구성된 분산 시스템입니다.
- 각 브로커들은 서로 협력하여 데이터를 안전하게 저장하고 처리합니다.
기능 | 설명 | 세부사항 |
고가용성 | 클러스터 내 복제를 통해 안정성을 보장합니다. | - 브로커 장애 시 자동 복구 - 데이터 복제 - 무중단 운영 지원 |
확장성 | 필요에 따라 브로커를 추가하여 확장할 수 있습니다. | - 수평적 확장 가능 - 동적 클러스터 조정 - 부하 분산 |
관리 기능 | 클러스터의 상태를 모니터링하고 관리합니다. | - 브로커 상태 감시 - 리소스 사용량 추적 - 성능 모니터링 |
데이터 분산 | 여러 브로커에 걸쳐 데이터를 분산 저장합니다. | - 파티션 분산 - 균형있는 저장소 사용 - 효율적인 데이터 접근 |
오늘도 감사합니다 😀
그리드형
'공통 > OpenSource' 카테고리의 다른 글
[OpenSource] Keycloak 이해하기 -1 : 주요 기능, 구성 요소, 로그인 과정 (0) | 2025.01.21 |
---|---|
[OpenSource] Apache Kafka 이해하기 -2 : Zookeeper, KRaft(Kafka Raft), 비교 (0) | 2025.01.08 |
[OpenSource] Vault 이해하기 -1 : 이론, 구성요소, 처리과정 (0) | 2024.04.15 |
[OpenSource] sonarQube 이해하기 -1 : 정의, 주요특징, 구성요소, 수행 프로세스 (0) | 2024.01.06 |