MOM(Meesage Oriented Middle ware) 아키텍처
카프카 아키텍처에 대해서 이야기하기 전에 먼저 MOM과 메시지 브로커(Pub/Sub 패턴)을 정리하겠습니다.
- 메시지 공급자를 이용하여 클라이언트(애플리케이션)들의 메시지를 중간에서 관리해줌
- 메시지를 보낸(송신) 클라이언트는 응답이 오지 않더라도 다른 작업을 계속 수행할 수 있음(비동기)
- 메시지 공급자는 수신 클라이언트가 메시지를 소비할 때까지 메시지를 보관
- 시스템의 개별 구성 요소나 연결이 실패하여도 중단 없이 안정적으로 작동할 수 있는 느슨한 연결을 함
여기서 중요한 것은 MOM은 이론, 개념, 어떤 설계적인 방향성을 제시하고 있고 직접적인 구현체는 아닙니다.
메시지 브로커(Pub/Sub 패턴)
- 메시지 브로커는 송신자(Publisher)로 부터 전달받은 메시지를 수신자(Subscriber)로 전달해주는 역할
- 메시지 큐는 메시지가 적재되는 공간을 의미함
- FIFO(First In First Out)
- 비동기적 특성 : 메시지 저장, 전송에 대해 동기 처리 하지않고 큐에 넣어 나중에 처리가 가능함
- Topic은 메시지의 그룹을 의미
메시지브로커는 송신자(Pub)가 보낸 메시지를 메시지큐(Queue)에 적재하고 이를 수신자(Sub)가 받아서 사용하는 구조로
Publish-Subscribe(Pub/Sub) 패턴이라고 하며 Producer-Consumer 패턴이라고 합니다.
- Producer-Consumer 패턴은 카프카에서 주로 사용하는 용어
MOM의 개념, 설계를 가지고 만든 구현체가 카프카라고 할 수 있으며 카프카는 대표적인 메시지 브로커 프로젝트 입니다.
카프카 아키텍처
카프카는 위에서 말한 MOM, 메시지 브로커의 아키텍처를 가지고 있으며 여기서는 카프카 아키텍처의 발전과 구성에 대해서 이야기하겠습니다.
카프카의 발전
0.9.0 버전의 카프카는 메시지 시스템의 기능을 제공하는 분산, 분할, 복제 커밋 로그 서비스라고 소개하고 있습니다.
Producer-Consumer 패턴을 보이고 있으며 메시지 브로카 자리에 카프카 클러스터가 위치하는 것을 알 수 있습니다.
2.4.x 버전의 카프카는 분산형 스트리밍 플랫픔으로 소개하고 있습니다.
0.9.0 보다는 더욱 발전된 형태를 보이고 있고 데이터 허브의 역할을 수행하고 있습니다.
스트리밍 플랫폼
스트리밍 플랫폼에는 3가지의 주요한 기능이 있습니다.
- Fault-Tolerant 방식으로 레코드 스트림을 저장
- 레코드 스트림이 발생할 때 처리
- 메시지 큐, 메시징과 비슷하게 레코드 스트림을 Pub/Sub 방식으로 처리
카프카의 컨셉
- 여러 데이터 센터에 걸쳐 있는 하나 이상의 서버에서 클러스터로 실행
- 카프카 클러스터는 Topic이라고 불리는 카테고리에 레코드 스트림을 저장
- 레코드에는 Key, Value, Timestamp가 포함
2.5.x 버전 이후의 카프카는 이벤트 스트리밍 플랫으로 소개하고 있습니다.
이벤트 스트리밍 플랫폼
- 데이터베이스, 센서, 모바일 디바이스, 클라우드 서비스 등등 다양한 이벤트 소스에서 이벤트 스트림 형태로 실시간으로 데이터를 가져온다
- 나중에 검색할 수 있도록 이벤트 스트림을 지속적으로 저장, 조작, 처리한다.
- 필요에 따라 다양한 목적지로 이벤트 스트림을 전달 할 수 있다.
- 다른 시스템에서 데이터를 지속적으로 가져오거나 내보낼 수 있다.
- 이벤트 스트리밍은 데이터의 지속적인 흐름과 처리를 보장하며 올바른 정보가 적절한 장소, 시간에 제공되도록 한다.
카프카 아키텍처 구성
- Producer : 데이터를 만들고 Kafka Broker에 데이터를 적재하는 프로세스
- Consumer : Broker에서 데이터를 읽고 소비하는 프로세스
- Consumer Group : Consumer의 집합을 구성하는 단위
- Kafka Cluster : Broker와 Zookeeper로 구성
- Broker : Kafka를 구성하는 각 서버(노드)를 의미하며 Producer와 Consumer 사이에서 데이터를 중계하는 역할
- Zookeeper : Kafka를 운용하기 위한 Cooditation Service
- Topic : 데이터를 저장하는 공간
- Partition : 실제 데이터가 Kafka Topic 내에서 저장되는 공간으로 Topic이 복사되어 나누어지는 단위
- Records/Messages : Partition에 저장되는 데이터를 의미하며 Key, Value, Timestamp, (metadata headers)가 포함
카프카 구성요소
카프카에서 클라이언트와 서버간의 통신은 TCP 프로토콜로 이루어집니다.
Topics and Partition
Topic
- 레코드(데이터)가 저장되는 공간
- 보통 다수의 Consumer(0 or 1 이상)가 작성된 데이터에 Subscribe 할 수 있음
- 파티션이라는 단위로 복사되어 나누어 짐
Partition
- 실제 레코드가 저장이 되는 곳, 저장되는 레코드는 순서(offset)를 가지게 되지만 변하지 않는다는 특징이 있다.
- 보존기간(retention time)을 정하고 기간이 지나면 저장 공간 확보를 위하여 레코드를 삭제함
- 레코드에는 offset(오프셋)이라는 ID가 할당됨
- Consumer는 offset을 통해 과거의 레코드를 소비하거나 과거를 건너뛰고 현재의 레코드를 소비할 수 있음
- Fault Tolerance를 위하여 복제됨(replication)
- 리더와 팔로워로 역할이 나누어짐
- 리더 : Partition에 대하여 모든 읽기 및 쓰기 요청을 처리함
- 팔로워 : 리더를 복제함, 만약 리더 파티션이 중단되면 나머지 팔로워 중 자동으로 새 리더가 선택됨
Producer
- 메시지를 생산해서 Broker의 Topic으로 보내는 역할을 하는 프로세스
- 전송하는 메시지에 키 값을 지정하면 워하는 파티션으로 전송
- 키 값을 지정하지 않는다면 RR(Round-Robin) 방식으로 전송
- RR(Round-Robin) : 우선순위를 두지 않고, 순새대로 시간단위로 할당하는 방식
Consumer
- Broker를 통하여 Partition에 저장되어 있는 레코드를 소비하는 프로세스
- 레코드를 받을 때 순서를 보장하지 않음
- Consumer Group ID를 통하여 Label을 지정
- Partition 수 >= Consumer 수를 권장
- Partiion 수 == Consumer 수 : Consumer Group B처럼 로드 밸런싱
- Partion 수 > Consumer 수 : Consumer Group A처럼 브로드캐스트
- Partiion 수 < Consumer 수 : 동작하지 않고 대기(Idle)하는 Consumer가 발생
- Partition에 저장되어 있는 레코드의 순서 그대로 받고 싶다면 Partion : 1, Consumer :1로 설정
참고자료
'데이터 엔지니어링' 카테고리의 다른 글
[Flink] Flink Architecture (0) | 2024.08.24 |
---|---|
[kafka] kafka cluster 구축하기 (2) | 2024.01.28 |
[Kafka] Apache kafka 소개와 배경 (1) | 2024.01.19 |
[빅데이터를 지탱하는 기술] 빅데이터의 축적 # 2 (0) | 2023.05.27 |
[빅데이터를 지탱하는 기술] 빅데이터의 축적 # 1 (0) | 2023.05.26 |