[아파치 카프카 애플리케이션 프로그래밍 with 자바 - 최원영 저] 한 장 요약

카프카의 탄생

- 링크드인에서 개발

- 각 애플리케이션의 데이터를 한 곳에 모아 중앙집중화

- 프로듀서 : 큐에 데이터를 보냄

- 컨슈머 : 큐에서 데이터를 가져감

- 카프카를 통해 전달할 수 있는 데이터 포멧은 사실상 제한이 없음

- 상용 환경에서 카프카는 최소 3대 이상의 서버(브로커)에서 분산 운영

- 일부 서버에 장애가 발생하더라도 데이터를 지속적으로 벅제, 안전하게 운영

- 데이터를 묶음 단위로 처리하는 배치 전송 -> 낮은 지연과 높은 데이터 처리량 가짐

## 빅데이터 파이프라인에서 카프카 역할

- 데이터 레이크 : 데이터가 모이는 저장 공간, 데이터 워어하우스와 다르게 필터링되거나 페키지화되지 않은 데이터를 저장

- 높은 처리량 - 프로듀서가 브로커로 데이터를 보낼 때와 컨슈머가 브로커로부터 데이터를 받을 때 모두 묶어서 전송

    대용량 실시간 로그데이터 처리에 적합

- 확장성 - 가변적인 환경에서 안정적으로 확장 가능

    클러스터 브로커 개수를 자연스럽게 늘려 스케일 아웃

    추가 서버들이 더 필요 없어지면 브로커 개수를 줄여 스케일 인

- 영속성 - 데이터 생성한 프로그램이 종료되더라도 데이터가 사라지지 않음

    데이터를 메모리에 저장하지 않고 파일 시스템에 저장

    페이지 캐시 영역을 메모리에 따로 생성하여 사용

- 고가용성 - 일부 서버에 장애가 발생해도 무중단 지속적 데이터 처리

    데이터 복제(replication) 기능 - 1대의 브로커에만 저장 X 다른 브로커에도 저장

## 데이터 레이크 아키텍처

- 람다 아키텍처 : 레거시 데이터 수집 플렛폼을 개선하기 위해 구성한 아키텍처

레거시 데이터 플렛폼 아키텍처

 

- 엔드 투 엔드로 각 서비스러부터 데이터를 배치로 모음

- 구조 유연 X, 느리게 전달, 히스터리 파악 어려움, 데이터 파편화

- 배치 레이어 : 배치 데이터를 모아서 특정 시간에 일괄 처리

- 서빙 레이어 : 가공된 데이터를 저장

- 스피드 레이어 : 생성된 데이터를 실시간으로 분석

- 레이어가 2개로 나뉘는 단점 - 배치 데이터와실시간 데이터를 융합하여 처리할 때는 유연하지 못함 

- 카파 아키텍처 : 베치 레이어를 제거하고 모든 데이터를 스피드 레이어에 넣음

- 데이터 로깅(데이터 집합)으로 부터 시작 : 지속적으로 추가, 각 데이터에 일정한 번호 붙음

    스트림으로 표현

카프카 빠르게 시작해보기

## 카프카 브로커 힙 메모리 설정

- 레코드의 내용은 페이지 캐시로 시스템 메모리를 사용

- 나머지 객체들은 힙 메모리에 저장하여 사용

- 브로커 운영 시 힙 메모리를 5GB이상으로 설정하지 않는 것이 일반적

## 주키퍼 실행

- 주키퍼 :  분산 코디네이션 서비스를 제공

    클러스터 설정 리더 정보, 컨트롤러 정보 가지고 있음.

    통상 3대 이상의 서버로 구성하여 사용

## 토픽

- 데이터를 구분하는 기본적인 개념

- RDB에서 테이블과 유사

- 여러개 존재 가능

- 파티션 존재, 최소 1개 이상임, 데이터 종류를 나누어 처리

- 파티션을 통해 한 번에 처리할 수 있는 데이터 양 증가

## producer

- 토픽에 넣는 데이터는 레코드라고 부름, 메시지 값으로 이루어짐

- 메시지 키는 자바의 null로 기본 설정되어 브로커로 전송

- String이 아닌 타입은 직렬화하여 전송할 수 없음

- 레코드는 토픽의 파티션에 저장 

- 메시지 키가 null일 때 프로듀서가 파티션으로 전송할 때 배치(레코드 전송 묶음) 단위로 라운드 로빈으로 전송

- 메시지 키가 존재하는 경우 키의 해시값을 작성하여 존재하는 파티션 중 한 개에 할당

- 메시지 키가 동일한 경우에는 동일한 파티션으로 전송

 

## Consumer

- 브로커로 부터 데이터를 받아옴

- 데이터의 순서가 현재 출력되는 순서와 다름

- 모든 파티션으로부터 동일한 중요도로 데이터를 가져감

- 토픽에 넣은 데이터 순서와 가져가는 순서가 달라짐

- 만약 데이터 순서를 보장하고 싶으면 파티션을 1개로 구성된 토픽을 만들어야함.

카프카 기본 개념 설명

## 브로커 

클라이언트와 데이터를 주고받기 위해 사용하는 주체, 데이터를 분산 저장

    - 하나의 서버에는 한 개의 브로커 프로세스가 실행

    - 안전하게 보관하고 처리하기 위해 3대 이상의 브로커 서버를 1개의 클러스터로 묶어서 운영

    - 카프카 클러스터로 묶인 브로커들은 프로듀서가 보낸 데이터를 안전하게 분산 저장, 복제 수행

    - 저장된 데이터는 파일 시스템에 저장

    - 컨슈머가 데이터를 요청하면 파티션에 저장된 데이터를전달

    - 페이지 캐시를 사용해서 디스크 입출력 속도를 높임

   -  페이지 캐시 OS에서 파일 입출력 성능 향상을 위해 만들어 놓은 메모리 영역, 동일 파일 점근시 디스크에서 읽지 않고 메모리에서 직접    읽음

    - 데이터 복제는 파티션 단위로 이루어짐

 

## 데이터 리플리케이션

- 데이터 복제는 파티션 단위로 이루어짐

- 복제된 파티션은 리더와 팔로워로 구성

- 프로듀서 또는 컨슈머와 직접 통신하는 파티션을 리더, 나머지 복제 데이터 파티션은 팔로워

- 팔로워 파티션들은 리더 파티션의 오프셋을 확인, 오프셋과 차이가 나는 경우 리더 파티션으로부터 데이터를 가져와 자신의 파티션에 저장

- 리더 파티션 장애시 팔로워 파티션 중 하나가 리더 지위를 넘겨받음

    ## 컨트롤러

- 다수 브로커 중 한 대가 컨트롤러 역할을 함

- 다른 브로커들의 상태를 체크

- 리더 파티션을 재분배

- 컨트롤러 역할을 하는 브로커가 장애시 다른 브로커가 컨트롤러 역할을 함

## 데이터 삭제

- 컨슈머가 데이터를 가져가더라도 토픽의 더이터는 삭제되지 않음

- 컨슈머나 프로듀서가 데이터 삭제를 요청할 수도 없음

- 오직 브로커만 데이터 삭제 가능

- 데이터 삭제는 로그세그먼트(파일 단위) 로 이루어짐

## 컨슈머 오프셋 저장

- 컨슈머는 토픽이 특정 파티션으로부터 데이터를 가져가서 처리하고 이 파티션의 어느 레코드까지 가져갔는지 확인하기 위해 오프셋을 커밋

## 코디네이터

- 브로커 중 한 대는 코디네이터 역할을 수행

- 컨슈머 그룹의 상태를 체크, 파티션을 컨슈머와 매칭되도록 분배

- 매칭되지 않은 파티션을 정상 동작하는 컨슈머로 할당, 끊임없이 데이터가 처리되도록 도와줌

- 리벨런스 :  파티션을 컨슈머로 재할당 하는 과정

## 주키퍼

- 카프카의 메타데이터를 관리하는데 사용 

 

## 토픽

- 데이터를 구분하기 위해 사용하는 단위

- 토픽은 1개 이상의 파티션을 소유

- 프로듀서가 보낸 데이터들이 들어가 저장

- 레코드 : 데이터

- 파티션은 레코드를 병렬로 처리할 수 있도록 매칭

- 데이터를 가져가도 레코드를 삭제하지 않음, 여러 컨슈머 그룹들이 토픽의 데이터를 여러번 가져감

## 레코드

- 타임스템프, 메시지 키, 메시지 값, 오프셋, 헤더로 구성

- 메시지 키의 해시값을 토대로 파티션을 지정

- 메시지 키와 메시지 값은 직렬화되어 브로커로 전송

- 이전에 전송된 레코드의 오프셋 + 1 값으로 생성

- 오프셋은 카프카 컨슈머가 데이터를 가져갈 때 사용

- 컨슈머 그룹으로 이루어진 카프카 컨슈머들이 파티션의 데이터를 어디까지 가져갔는지 명확히 지정

- 헤더는 레코드의 추가적인 정보를 담는 메타데이터 저장소

 

## 프로듀서

- 카프카에 필요한 데이터를 선언

- 브로커의 특정 토픽의 파티션에 전송

- 카프카 브로커와 직접 통신

- 데이터 전송시 내부적으로 퍼티셔너, 배치 생성 단계를 거침

- 데이터를 전송하기 전 , 어큐뮬레이터에 데이터를 버퍼로 쌓아놓고 발송

- 들어오는 대로 파티션을 순회하여 전송, 배치로 묶이는 빈도가 적음

- 어큐뮬레이터에서 데이터가 배치로 모두 묶일 때 까지 기다렸다가 배치로 묵인 데이터는 모두 동일한 파티션에 전송

- 비동기로 결과를 받을 경우 더 빠른 속도로 데이터를 추가처리하나, 데이터 순서를 보장하지 않음

## 컨슈머

- 컨슈머 운영방법 

    1. 1개 이상의 컨슈머로 이루어진 컨슈머 그룹을 운영

 

 

- 한 파티션은 한 컨슈머만, 한 컨슈머는 여러 파티션 가능

- 컨슈머 수가 파티션보다 많을 시 불필요한 스레드로 남음

- 컨슈머 그룹은 다른 컨슈머 그룹과 격리

- 장애가 발생한 컨슈머에 할당된 파티션은 다른 컨슈머에 소유권이 넘어감 (리벨런싱)

- 컨슈머 내부 토픽에서 데이터를 어디까지 커밋했는지 기록

 

 

    2. 토픽의 특정 파티션만 구독하는 컨슈머 운영

### 오프셋 커밋 방법

1. 비명시 오프셋 커밋 : 일정 간격마다 자동으로 커밋

    - 편리하나, 리벨런싱 또는 컨슈머 강제 종료 발생 시 컨슈머가 처리하는 데이터가 중복 또는 유실

2. 명시적 오프셋 커밋 : 메서드 호출 이후 반환받은 데이터 처리가 완료되고 커밋

    - 가장 마지막 오프셋 기준으로 커밋 수행

    - 오래 걸림

3. 비동기 오프셋 커밋 : 커밋 요청 전송 후 응답 오기전까지 데이터 처리 수행 

   - 커밋 요청 실패시 현재 처리중인 데이터 순서를 보장 X, 데이터 중복 처리 가능

 

### 리벨런스 리스너

- 리벨런스 발생 시 데이터를 중복 처리하지 않게 하기 위해 리벨런스 발생시 처리한 데이터를 기준으로 커밋 시도

 

## 카프카 스트림즈

- 토픽에 적재된 데이터를 상태기반 또는 비상태기반으로 실시간 변환하여 다른 토픽에 적재

- 장애가 발생하더라도 정확히 한 번 할 수 있도록 하는 장애 허용 시스템 가짐

- 내부적으로 스레트를 1개 이상 생성, 각 스레드는 1개 이상 테스크를 가짐

- 만약 3개의 파티션으로 이루어진 토픽을 처리하는 스트림즈 애플리케이션을 실행시 내부에 3개의 테스크가 생김

 

 

//토폴로지, 프로세서 정리 TODO

 

## 커넥트

- 데이터 파이프라인 생성 시 반복 작업을 줄이고 효율적인 전송 지원

- 파일 소스 커넥터 : 파일의 데이터를 카프카 토픽으로 전송하는 프로듀서 역할

- 파일 싱크 커넥터 : 토픽의 데이터를 파일로 저장하는 컨슈머 역할

- 컨버터는 데이터를 처리하기 전에 스키마를 변경하도록 도와줌

- 트렌스폼은 데이터 처리 시 각 메시지 단위로 데이터를 간단하게 변환

### 소스 커넥터

- 소스 어플리케이션 또는 소스 파일로부터 데이터를 가져와 토픽으로 넣는 역할

- 테스크를 실행하기 전 커넥터 설정파일을 초기화, 어떤 테스크 클래스를 사용할 것인지를 정의

- 소스 테스크는 소스 어플리케이션 또는 파일로 부터 데이터를 가져와서 토픽으로 데이터를 전송

- 토픽에서 사용하는 오프셋이 아닌 자체적으로 사용하는 오프셋 사용

- 소스 테스크에서 마지막 지점을 저장하기 위해 오프셋 스토리지에 데이터를 저장

## 싱크 커넥터

- 토픽의 데이터를 타깃 애플리케이션 또는 타킷 파일로 저장

- 테스크를 실행하기 전 사용자로부터 입력 받은 설정값을 초기화, 어떤 테스크 클래스를 사용할 것인지 정의

- 데이터를 처리하는 로직은 싱크 테스크로 구현

- 컨슈머 역할을 하고 데이터를 저장

 

카프카 상세 개념 설명

## 토픽 생성 시 파티션 개수 고려사항

1. 데이터 처리량 : 컨슈머 전체 데이터 처리량이 프로듀서 데이터 처리량 보다 많아야 

2. 메시지 키 사용 여부: 데이터 처리 순서를 지켜야 하는 경우도 고려

3. 브로커, 컨슈머 영향도

 

- 파티션 개수가 달라지는 순간 메시지 키를 사용하는 컨슈머들은 순서를 보장받지 못함

// 토픽 상세 정책 정리 TODO

// 프로듀서 전략 정리 TODO

// 컨슈머 전략 정리 TODO