Event Streaming
- 위키백과에서의 Event Stream Processing → 실시간 스트리밍을 의미한다.
- 이벤트 스트리밍이 중요한 이유는 데이터 가용성(Availability) 때문이다.
- 스트리밍은 데이터를 추출하는 시점부터 시간과 주체에 구애받지 않고 접근이 가능하다.
- 이벤트 스트림의 형태로 실시간으로 데이터를 캡처하는 방식이다.
- 검색할 수 있도록 이벤트 스트림을 영구적으로 저장한다.
- 실시간으로 이벤트 스트림을 조작, 처리 및 반응한다.
- 필요에 따라 이벤트 스트림을 다른 목적지 기술로 라우팅할 수 있다.
특징
- 실시간으로 필요한 기능들을 처리할 수 있다.
- 실시간으로 추적하고 모니터링할 수 있다.
- 센서 데이터를 지속적으로 캡처하고 분석할 수 있다.
- 고객 상호 작용 및 데이터를 수집하고 즉시 대응할 수 있다.
- 여러 곳에서 생성된 데이터를 연결, 저장 및 사용 가능하게 한다.
- 이벤트 중심 아키텍처 및 마이크로서비스의 기반 역할을 한다.
Kafka - Event Streaming Platform
kafka는 세 가지 주요 기능을 통해 이벤트 스트리밍을 구현할 수 있다.
- To publish (write) and subscribe to (read) streams of events, including continuous import/export of your data from other systems.
- To store streams of events durably and reliably for as long as you want.
- To process streams of events as they occur or retrospectively.
- 프로듀서(Producer)
- 메시지를 생산하여 브로커의 토픽으로 전달하는 역할이다.
- 브로커(Broker)
- 카프카 애플리케이션이 설치되어 있는 서버 또는 노드를 지칭한다.
- 컨슈머(Consumer)
- 브로커의 토픽으로부터 저장된 메시지를 전달받는 역할이다.
- 주키퍼(Zookeeper)
- 분산 애플리케이션 관리를 위한 코디네이션 시스템이다.
- 분산된 노드의 정보를 중앙에 집중하고 구성관리, 그룹 네이밍, 동기화 등의 서비스를 수행한다.
작동방식
- 프로듀서는 새 메시지를 카프카에 전달한다.
- 전달된 메시지는 브로커의 토픽이라는 메시지 구분자에 저장한다.
- 컨슈머는 구독한 토픽에 접근하여 메시지를 가져온다. (pull 방식)
특징
- 다른 메시지 큐들과는 지향하는 바가 다르다.
- pub-sub 구조를 가진다.
- 메시지를 보내는 pub 역할과 받는 sub 역할이 완벽하게 분리되어 있다.
- 느슨한 결합을 통해 한쪽 시스템에서 문제가 발생하더라도 서로 의존성이 없으므로 연쇄작용이 발생할 확률이 낮다.
- 컨슈머의 서버가 추가 되더라도 카프카로만 보내면 되기 때문에 서버 추가에 대한 부담이 없다.
- 하나의 토픽에 여러 프로듀서 & 컨슈머들이 접근 가능한 구조이다.
- 하나 이상의 토픽으로 메시지를 보내고 가져올 수 있다.
- 디스크에 메시지를 저장한다.
- TCP/IP 통신을 통해 디스크에 바로 저장한다.
- RabbitMQ(APMQ 프로토콜 이용)
- kafka 외의 MQ의 경우 메모리에 저장하는 방식을 사용한다.
- 다른 MQ 또한 별도의 설정을 통해 디스크에 저장하는 방식을 사용하여 서버 다운에 대응할 수 있지만 Kafka는 별도의 설정을 할 필요가 없다.
- 통신방법의 차이로 초당 10만건의 데이터 처리가 가능하다.
- 특별한 설정 없이 데이터의 영속성(Persistence) 가 보장된다.
- 트래픽이 일시적으로 폭주해 컨슈머의 처리가 늦어지더라도 디스크에 보관되기 때문에 컨슈머는 손실 없이 메시지를 가져갈 수 있다.
- TCP/IP 통신을 통해 디스크에 바로 저장한다.
- 분산 환경에 특화되도록 설계되었다.
- 하나의 카프카 클러스터는 3대의 브로커로부터 시작해 수십대의 브로커로 확장 가능하다.
- 확장 작업은 카프카 서비스의 중단 없이 온라인 상태에서 작업이 가능하다.
- 트래픽 및 사용량 증가로 클러스터를 확장하는 작업은 간단하다.
- 클러스터 구성, fail-over , replication 등 여러 특징이 있다.
- 고성능을 유지하기 위해 내부적으로 분산 처리, 배치 처리 등 다양한 기법을 사용한다.
- 단일 시스템보다 성능이 좋다.
카프카 데이터 모델
토픽(Topic)
- 메시지를 논리적으로 묶은 개념이다.
- 데이터베이스의 테이블 및 파일시스템의 폴더와 유사한 개념이다.
- 프로듀서가 메시지를 보낼경우 토픽에 메시지가 저장된다.
파티션(Partition)
- 토픽을 구성하는 데이터 저장소이며 메시지가 저장되는 위치이다.
- 여러개의 프로듀서에서 한개의 파티션으로 메시지를 보낼 경우 병목이 생기고, 메시지의 순서를 보장할 수 없게 된다.
- 파티션을 여러개로 늘리고 그 수만큼 프로듀서도 늘려 하나의 파티션마다 하나의 프로듀서 메시지를 받으면 빠르다.
- 파티션이 무작정 많아질 경우
- 파일 핸들러의 낭비가 존재한다.
- 각 파티션은 브로커의 디렉토리와 매핑되고 저장되는 데이터마다 2개의 파일(인덱스, 실제 파일)이 있기 때문에 많은 파일 핸들이 생길 경우 리소스가 낭비된다.
- 장애 복구 시간이 증가할 수 있다.
- 카프카는 리플리케이션(Replication)을 지원하고, 이를 통해 지속적으로 리더 파티션을 팔로워 파티션으로 리플리케이션하게된다.
- 파티션 수가 너무 많을 경우 리플리케이션 수행이 느려져 장애복구시간이 증가할 수 있다.
- 파티션 수를 줄이는 것이 불가능하다.
- 카프카에서 파티션 수를 늘리는 것은 아무때나 가능하지만 파티션 수를 줄이는 방법은 제공하지 않는다.
- 줄이고 싶다면 토픽 자체를 삭제하는 것 말고는 방법이 없다.
- 파일 핸들러의 낭비가 존재한다.
오프셋과 메시지순서
- 오프셋(offset)
- 파티션마다 메시지가 저장되는 위치이다.
- 파티션 내에서 순차적으로 유니크하게 증가하는 숫자 형태로서 동일 파티션 내 메시지의 순서를 보장해준다.
- 컨슈머는 메시지를 가져올 때마다 오프셋 정보를 커밋(commit)함으로써 기존에 어디 위치까지 가져왔는지 알 수 있게 된다.
파티션과 메시지순서
- 파티션을 여러개 지정할 경우
- 프로슈머가 메시지를 보낼 때 파티션이 여러개인 경우 메시지는 각각의 파티션으로 순차적으로 배분한다. (Round-robin 방식)
- 메시지의 순서는 오로지 동일 파티션 내 오프셋을 기준으로만 보장된다.
- 여러개의 파티션을 사용할 경우 동일 파티션 내에서는 순서가 보장되지만, 파티션과 파티션 사이에서는 순서를 보장하지 못하기 때문에 전체 메시지를 출력할 경우 순서가 섞일 수 있다.
- 전체 메시지의 순서를 보장하고 싶은 경우 partition을 1개로만 설정해야 한다.
- 이 경우, 파티션이 하나이므로 분산 처리가 불가능하다.
리플리케이션
- 고가용성 및 데이터 유실을 막기 위해 리플리케이션을 수행한다.
- 원본 파티션의 경우 '리더'가 되고, 복제 파티션의 경우 '팔로워'가 된다.
- 리더 파티션이 있는 브로커가 다운될 경우
- 복제 파티션을 가진 브로커의 팔로워 파티션이 새로운 리더가 되어 정상적으로 프로듀서의 요청을 처리한다.
ISR(In Sync Replica)
- 리더와 팔로워로 이루어진 리플리케이션 그룹이다.
- 리플리케이션 그룹 내 동기화 및 신뢰성을 유지한다.
- 팔로워는 Read/Write 권한이 없고 오로지 리더로부터 데이터를 복제하기 때문에 특정 팔로워가 다운되서 리플리케이션을 못할 경우 동기화 문제가 발생한다.
- 문제가 감지된 팔로워 즉, 설정된 일정주기(replica.lag.time.max.ms)만큼 요청이 오지 않는 팔로워는 ISR 그룹에서 추방된다.
Consumer 그룹
- 컨슈머가 메시지를 소비하는 시간보다 프로듀서가 메시지를 전달하는 속도가 더 빨라서 메시지가 점점 쌓일 경우를 대비한다.
- 동일 토픽에 대해 여러 컨슈머가 메시지를 가져갈 수 있도록 컨슈머 그룹이라는 기능을 제공한다.
- 하나의 consumer가 프로듀서의 메시지 전송 속도를 따라가지 못할 경우
