Apache Kafka 주요 개념 정리

# Apache Kafka 주요 개념 정리

- 최근 이슈 카프카의 메타데이터 관리 도구인 주키퍼가 제거 될 예정...

* 적용 전 고려사항

1) 하나의 파티션을 두개이상의 컨슈머가 소비할 수 없다. 

2) 파티션을 늘리면 줄이질 못한다. 파티션을 초기 2, 4로 작게 생성 하고 향후 컨슈머의 LAG 등을 보면서 조금씩 늘리는게 좋다.

3) 브로커를 스케일 아웃을 하면 기존에 사용하고 있던 파티션들의 데이터가 자동으로 신규로 확장된 브로커로 전달되지 않고,

새로운 토픽의 데이터들만 전달 된다. 그래서 기존 토픽 데이터를 새로운 브로커로 전달하기 위해서는 partiton reassign 작업을 진행해 줘야한다.

- 추후 고려사항 생기면 계속 업로드 예정...

0. Kafka란?

- 고성능 : 프로듀서와 컨슈머가 브로커를 통해 데이터를 주고 받을 때, 한 번에 대용량의 데이터를 전송 가능하다.

컨슈머의 개수를 늘리면서 병렬 처리까지 가능하기 때문에 처리 효율을 높일 수 있다.

- 고가용성 및 확장성 : 카프카는 클러스터 개념으로 동작하며, 스케일 아웃을 지원한다. 다수의 브로커를 기반으로 운영이 되므로 장애에 대해서도 유연한 대응이 가능하다.

- 디스크에 저장 : 카프카 데이터는 디스크에 저장되므로 데이터 유실에 대한 걱정이 없지만, 퍼블릭 클라우드 관점에서는 데이터 스토리지에 대한 최적화 작업이 필요하다. (디스크 사이즈가 크면 많은 비용이 발생)

- 분산처리에 특화 : 여러개의 파티션을 서버에 분산하여 처리하므로 처리 속도가 빠르다.

1. Kafka의 주요 특징

- 메세지 큐와 카프카의 핵심 구성을 비교하면 아래와 같다.

메세지 큐 : 송신자와 수신자간 1:1 관계

카프카 : 퍼블리싱-서브스크라이빙 구조로 M:N 의 관계이다. (ex) 1: 100)

2.  Kafka 주요 개념 이해

1) Producer (프로듀서)

- 이벤트 (데이터)를 생성해 카프카 클러스터에 전송한다.

2) Topic (토픽)

- 메세지를 논리적으로 묶는 단위, DB에서 Table, 파일 개념으로 볼땐 폴더의 개념으로 이해하면 된다.

- 프로듀서에서 데이터를 보낼경우 저장되는 장소 이다.

- 하나의 토픽은 여러개의 파티션으로 구성 되어 있다. (파티션 개념은 아래를 참고) 

3) Partition (파티션)

- 토픽 내 분리된 공간, Kafka Config (server.properties)에서 num.partitions=1 옵션으로 토픽당 파티션수 조정.

- 주요 옵션 관련사항은 아래의 링크를 참고...

- 아래의 Anatomy of a Topic에서 보는것과 같이 구성 된다고 보면 된다.

4) Broker (브로커)

- 카프카 서버에 여러개의 브로커 생성 가능.

- 메세지를 저장하고 관리한다.

5) Consumer (컨슈머)

- 메세지(데이터)를 구독하고 Polling 방식으로 받아온다.

- 하나의 컨슈머에서 여러개의 토픽 데이터를 Polling할경우 과부하가 발생할 수 있다.

이럴경우는 같은 컨슈머 그룹 내에 또다른 컨슈머를 추가하여 병렬로 처리를 할 수 있다. ← 테스트 해봐야 함.

6) Zookeeper (주키퍼)

- 분산 메세지 큐의 메타 데이터를 관리한다. 예를들면 브로커 id, 컨트롤렁 정보, 즉 분산되어 있는 애플리케이션 정보를 중앙에서 주키퍼가 집중 관리 한다.

- 주키퍼는 홀수의 서버로 작동하도록 설계 되어 있다. (최소3, 권장5)

3. offset (오프셋)

- 오프셋이란?

DB의 PK와 비슷하다고 볼수 있다.

각 파티션마다 저장되는 위치를 의미하고, 파티션 내에서 고유하고, 순차적으로 처리된다.

컨슈머가 어디까지 읽었는지 알고 있기 때문에 다음 읽을 메세지의 정보를 확인 할 수 있다.

예를들어 현재의 오프셋이 5라고 가정하고, 컨슈머가 4까지 읽었다면 다음에 5를 읽어야 한다는 정보를 알 수 있다.

그래서 오프셋을 통해 데이터의 순서 보장이 된다.

4. Consumer Group (컨슈머 그룹)

간단히 말해서 여러개의 컨슈머들을 하나로 묶는 개념이다.

컨슈머가 여러개 생기는 이유는 스케일 아웃으로 인해 컨슈머가 여러개 생길수 있고,

또한 장애 대응을 위해 컨슈머를 여러개 둘 수 있다. (Active - Standby)

장애가 발생하거나, 스케일 아웃으로 인해 여러개의 컨슈머가 생길경우 컨슈머 그룹중 하나의 컨슈머만 데이터 처리 작업을 진행한다.

-  Rebalancing (리밸런싱)

리 밸런싱이란 1,2번 컨슈머가 있다고 가정할때 1번 컨슈머의 소유권을 2번 컨슈머가 이전 받는것이라고 볼 수 있다.

컨슈머 그룹 내에서의 컨슈머들을 파티션을 서로 공유 하므로 리밸런싱이 가능하다.

리밸런싱 시 메세지 처리에 대한 다운타임이 발생할 수 있지만, 리밸런싱을 통해 컨슈머 그룹은 가용성과 확장성을 확보 할 수 있다는 장점이 존재 한다.

- 리밸런싱이 발생하는 시기?

컨슈머그룹을 생성하면 컨슈머 그룹 코디네이터라는 애기 컨슈머 그룹을 관리한다. 그리고 아래와 같은 신호가 있을경우 리 밸런싱을 시도한다.

1.session.timeout.ms 설정시간에 heartbeat 시그널을 받지 못하는 경우
2.max.poll.interval.ms 설정시간에 poll() 메소드가 호출되지 않는 경우

 - 관련 옵션 항목은 아래와 같다.

session.timeout.ms (기본값 10초) : 기본값의 시간이 지나면 컨슈머가 종료되었거나 장애가 발생한 것으로 판단 후 리밸런싱을 시도한다.

heartbeat.interval.ms (기본값 3초) : 컨슈머가 정상적으로 살아있는지 체크하는 옵션이다. 일반적으로 session.timeout.ms값의 3분의1로 지정한다.

max.poll.interval.ms (기본값 5분) : 컨슈머가 폴링 후 커밋할때 까지의 대기 시간이다. 장애시 장애를 가진 컨슈머가 해당 파티션을 점유 하지 못하도록 주기적으로 polling 하고 기본값만큼 대기 후 응답이 없으면 장애라고 판단하여 컨슈머 그룹에서 제외 처리를 진행 후 리밸런싱을 진행한다.

max.poll.records (기본값 500) : 컨슈머가 최대로 가져갈 수 있는 개수이며 polling loop 옵션에서 양 조절이 가능하다.

enable.auto.commit (기본값 true) : 백그라운드에서 주기적으로 오프셋을 커밋한다.

auto.commit.interval.ms (기본값 5초) : 주기적으로 오프셋을 커밋하는 시간이다.

auto.offset.reset (기본값 latest) : 3가지 옵션이 존재

- earliest: 가장 초기의 offset 값으로 설정

- latest: 가장 마지막의 offset 값으로 설정 (보통 이값으로 설정)

- none: 이전 offset 값을 찾지 못하면 error 발생

 

추가 : 폴링(polling)이란 하나의 장치(또는 프로그램)가 충돌 회피 또는 동기화 처리 등을 목적으로 다른 장치(또는 프로그램)의 상태를 주기적으로 검사하여 일정한 조건을 만족할 때 송수신 등의 자료처리를 하는 방식을 말한다.

1) Polling () : 아래의 그림을 보면 컨슈머는 폴링을 통해 컨슈머가 바라보고 있는 topic에 대해 1번 파티션으로 데이터 동기화 요청을 한다.

2) Response (data) : 파티션 1번은 1)의 요청에 응답하고, 요청 데이터를 담아서 응답한다.

3) 2)에서 받아온 데이터를 처리한다.  

4) 카프카 서버로 모든 작업이 끝났다는 신호를 보낸후 커밋한다.

 

- 끝 -