1. 아파치 카프카 개요
서비스 초기에는 Source Application과 Target Application이 직접 연결된 단방향 구조를 사용한다.
하지만 애플리케이션 수가 늘어날수록 각 애플리케이션 간 데이터 흐름이 복잡해지고 포맷 파편화나 배포 충돌, 장애 대응의 어려움 같은 문제가 발생한다.
이러한 문제를 해결하기 위해 등장한 것이 Apache Kafka이다‼️
Kafka는 메시지 브로커(message broker)로서 Source와 Target 사이에 위치한다.
즉 데이터 생산자와 소비자 간의 결합도를 낮추는 역할을 수행하는 것이다.
👉 Source Application은 데이터를 Kafka에 전송하고
👉 Target Application은 Kafka에서 원하는 데이터를 구독한다.
2. 토픽이란?
Kafka에서 데이터를 구분하고 저장하기 위해 사용하는 논리적인 단위이다.
데이터베이스의 테이블, 파일 시스템의 폴더처럼 데이터의 카테고리를 나누는 개념이다.
-
즉
Producer는 특정 Topic에 데이터를 보내고Consumer는 해당 Topic에서 데이터를 구독해 처리한다. -
Topic은 목적에 따라 이름을 명확하게 짓는 것이 좋다 🔽
Partition이란❓
Kafka에서 데이터의 저장과 처리 단위를 나누기 위한 물리적 단위이다.
하나의 Topic은 내부적으로 여러 개의 Partition으로 나뉜다.
각 Partition은 append-only 로그 구조로 데이터를 순차적으로 저장한다.
Consumer는 가장 오래된 데이터부터 순서대로 읽어간다.
데이터를 읽은 후에도 삭제되지 않고 새로운 Consumer가 붙으면 다시 읽을 수 있다.
🌟 Partition 수만큼 Consumer를 병렬로 붙일 수 있어 성능 확장성이 뛰어나다.
✅ 메시지 분배 방식
producer가 특정 Partition에 분배할 때는
- 라운드 로빈 : 키를 지정하지 않은 경우, 순차적으로 Partition에 분배
- 키 기반 : 해시 메시지에 키가 있는 경우, 해시값을 기준으로 특정 Partition에 분배
메시지 삭제 방법은 아래와 같은 설정으로 처리한다.
log.retention.ms 메시지 보존 최대 시간 (기본값: 7일)
log.retention.bytes 최대 저장 크기
3. 브로커, 복제, ISR(In-Sync-Replication)
➡️ broker란?
Kafka가 설치되어 있는 서버 단위
복제는 하나의 파티션 데이터를 여러 브로커에 복제 저장하는 방식이다. 이를 통해 고가용성(HA)을 확보할 수 있다.
예를 들어, 파티션 수가 1이고 replication이 3이면 다음과 같은 구조가 된다.
partition: 1 → 실제 저장할 파티션은 하나replication: 3 → 총 3개의 브로커에 해당 파티션이 복제됨
⚠️ 즉 브로커 개수가 3이면 replication이 4가 될 수 없음
- Leader: 실제로 Producer로부터 데이터를 받아 저장하는 주체
- Follower: Leader의 데이터를 따라 복제만 수행함
- Producer는 오직 Leader 파티션에만 데이터 전송을 시도함
➡️ ISR이란?
Leader와 동기화된 상태의 Follower들 집합을 의미한다.
만약 Leader가 장애로 중단되면, ISR 내에서 가장 적합한 Follower가 새로운 Leader 역할을 승계한다. 이를 통해 무중단 운영 및 데이터 손실 없는 전환이 가능해진다.
➡️ ack 옵션
Producer는 데이터를 보낼 때 ack 옵션을 설정할 수 있고 이는 데이터 전송에 대한 신뢰 보장 수준을 정한다.
옵션 값 (acks) | 동작 방식 | 데이터 신뢰성 | 특징 |
|---|---|---|---|
0 | Producer가 Leader에게 데이터 전송 후 응답 없이 종료 | 매우 낮음 | 매우 빠르지만, 데이터 손실 위험 존재 |
1 | Leader가 데이터를 받으면 즉시 응답 | 중간 | Leader까지만 확인 (Follower 복제 미보장) |
all | 모든 ISR(In-Sync Replica)에 복제 완료 후 응답 | 매우 높음 | 가장 안전하지만, 가장 느린 방식 |
❓그럼 복제 수는 많을수록 좋을까?
복제 수가 많을수록 안정성은 높아지지만 브로커 리소스를 더 많이 사용하게 된다.
Kafka 클러스터의 브로커 수, 데이터 처리량, 보관 시간 등을 고려하여 적절한 복제 수를 설정하는 것이 중요하다!!
4. 파티셔너(Partitioner)란?
레코드에 포함된 메시지 키 또는 값에 따라서 어떤 파티션에 넣을지 결정하는 역할을 한다.
Producer를 사용할때 파티셔너를 따로 설정하지 않으면 UniformStickyPartitioner로 설정된다.
이것은 메시지 키가 있을때와 없을때 다르게 동작한다.
👉 메시지 키 있을 때
- 파티셔너에 의해 특정한 해시값 생성
- 동일한 키 -> 동일한 해시값 -> 동일한 파티션에 들어감
- 즉, 순서를 지켜 데이터 처리한다는 장점이 있음
👉 메시지 키 없을 때
- 프로듀서에서 배치로 모을 수 있는 최대한의 레코드를 모아 파티션으로 보냄
- 라운드 로빈 방식
📢 카프카는 커스텀 파티셔너를 만들 수 있도록 파티션 인터페이스를 제공한다.
- 메시지 키,값,토픽이름에 따라 어느 파티션에 데이터를 보낼지 결정 가능
- ex) vip 고객의 데이터를 더 빠르게 처리해야하는 상황 -> 10개의 파티션 중 8개를 vip 고객 데이터를 처리하도록 함
5. 컨슈머 랙(Consumer Lag)이란?
파티션에 데이터가 하나씩 들어갈 때 오프셋이라는 숫자가 붙게된다. Producer가 데이터를 넣는 속도가 Consumer가 가져가는 속도보다 빠르다면 👉 Producer가 넣은 데이터의 오프셋과 Concumer가 가져간 데이터의 오프셋에 차이가 발생한다. 이것이 Consumer lag이다.
- lag 숫자를 통해 해당 토픽에 파이프라인으로 연계되어 있는 Producer, Consumer 상태 유추가 가능
- 주로 Consumer 상태에 대해 볼 때 사용
만약 여러 파티션이 존재한다면❓
한개의 토픽에 여러 파티션이 존재한다면 여러 lag가 존재하며, 그 중 높은 숫자의 lag를 records-lag-max라고 부른다.
6. 컨슈머 랙 모니터링 애플리케이션, 카프카 버로우(Burrow)
Cusumer lag 모니터링을 도와주는 독립적인 애플리케이션
아래와 같은 3가지 큰 특징이 존재한다 :
➡️ 멀티 카프카 클러스터 지원
카프카 클러스터가 여러개라도 Burrow 한개만 실행해서 연동한다면 카프카 클러스터들에 붙은 컨슈머의 lag를 모두 모니터 가능
➡️ Sliding window를 통한 Consumer의 status 확인
status를 'ERROR', 'WARNING', 'OK'로 표현
WARNING: 데이터가 일시적으로 많아져 프로듀서 offset이 컨슈머 offset보다 더 빠르게 증가
ERROR: 데이터의 양이 많은데 컨슈머가 다 가져가지 못하는 경우
➡️ HTTP api 제공
response 받은 데이터를 시계열DB 같은 곳에 저장하는 application을 만들어서 사용할 수도 있음
7. 카프카, 레빗엠큐, 레디스 큐의 차이점
메시징 플랫폼이라고 부르는 것들은 두가지로 나뉜다.
✔️ 메시지 브로커
데이터를 보내고 처리하고 삭제한다.
ex) 레빗엠큐, 레디스 큐
✔️ 이벤트 브로커
데이터 처리 후 삭제하지 않고 이벤트 브로커의 큐에 저장한다.
ex) 카프카, AWS의 키네시스
- 단일 진실 공급원으로 사용 가능
- 장애가 발생했을 때 장애가 일어난 시점부터 처리 가능
- 많은 양의 실시간 데이터를 효과적으로 처리
⚠️이벤트 브로커는 메시지 브로커로 역할을 할 수 있지만 반대는 불가하다.
