Kafka 특징 (1)
Kafka 특징
- 카프카는 토픽에 메시지를 발행(Publish) 및 구독(Subscribe) 구조
- 토픽은 병렬 처리를 위해 파티션 단위로 구성
- 파티션은 안정성을 위해 레플리카로 복제 구성
- 분산 이벤트 스트리밍 플렛폼
카프카 클러스터 (Kafka Cluster)
- 메세지 저장하는 저장소
- 여러개의 브로커(broker)로 구성
- 이중화도하고 장애가 나면
주키퍼 (ZooKeeper)
- 주키퍼 클러스터 카프카 관리
프로듀서(Producer)
- 메세지를 브로커에 메시지 전송하는 역할
컨슈머(Consumer)
- 메시지를 읽어오는 역할 봐서 필요한 작업
토픽(Topic)
- 메시지를 구분하는 단위 : 파일 시스템의 폴더와 유사
- 한 개의 토픽은 한 개 이상의 파티션으로 구성
- 프로듀서가 토픽에 전송해줘
- 컨슈머는 토픽에서 메시지 읽어와줘
파티션 (Partition)
- 파티션은 추가만 가능한(append-only) 파일
- 각 메시지 저장 위치를 오프셋(offset)이라고 함
- 프로듀서가 넣은 메시지는 파티션의 맨 뒤에 추가
- 컨슈머는 오프셋 기준으로 메시지 순서대로 읽음
- 메시지는 삭제되지 않음(설정에 따라 일정 시간이 지난 뒤 삭제)
- 한 파티션 내에서만 메시지 순서 보장
여러 파티션과 프로듀서
- 프로듀서는 라운드로빈 또는 키로 파티션 선택
- 같은 키를 갖는 메시지는 같은 파티션에 저장 -> 같은 키는 순서 유지
여러 파티션과 컨슈머
- 컨슈머는 컨슈머그룹에 속함
- 한 개 파티션은 컨슈머 그룹의 한 개 컨슈머만 연결 가능
- 즉 컨슈머그룹에 속한 컨슈머들은 한 파티션을 공유할 수 없음
- 한 컨슈머그룹 기준으로 파티션의 메시지는 순서대로 처리
카프카 성능
- 파티션 파일은 OS 페이지 캐시 사용
- 파티션에 대한 파일 IO를 메모리에서 처리
- 서버에서 페이지캐시를 카프카만 사용해야 성능에 유리
- ZERO COPY
- 디스크 버퍼에서 네트워크 버퍼로 직접 데이터 복사
- 컨슈머 추척을 위해 브로커가 하는 일이 비교적 단순
- 메시지 필터, 메시지 재전송과 같은 일은 브로커가 하지 않음
- 프로듀서, 컨슈머가 직접해야함
- 브로커는 컨슈머와 파티션 간 매핑 관리
- 묶어서 보내기, 묶어서 받기(batch)
- 프로듀서 : 일정 크기만큼 메시지를 모아서 전송 가능
- 컨슈머 : 최소 크기만큼 메시지를 모아서 조회 가능
- 낱개 처리보다 처리량 증가
- 처리량 증대(확장)가 쉬움
- 1개 장비의 욜량 한계 -> 브로커 추가, 파티션 추가
- 컨슈머가 느림 -> 컨슈머 추가(+파티션 추가)
리플리카 - 복제
- 리플리카 : 파티션의 복제본
- 복제수(replication factor) 만큼 파티션의 복제본이 각 브로커에 생김
- 리더와 팔로워로 구성
- 프로듀서와 컨슈머는 리더를 통해서만 메시지 처리
- 팔로워는 리더로부터 복제
- 장애 대응
- 리더가 속한 브로커 장애시 다른 팔로워가 리더가 됨
리더 레플리카 팔로워 레플리카 서로다른 브로커로 퍼져 위치 배달이라는 토픽이 3개 파티션과 복제개수 3개 복제
- 상태기반(StateFul) 시스템
- 발행되는 메시지는 브로커의 파일 시스템에 저장
- 토픽 파티션 별 로그 세그먼트(Log Segment)에 메시지가 저장
- 브로커가 토픽 파티션의 메시지를 저장하고 있다.
- = 브로커가 토픽 파티션의 레플리카를 가지고 있다.
- = 브로커가 토픽 파티션의 상태(State)를 가지고 있다.
- 카프키는 브로커가 가지고 있는 레플리카를 다른 브로커로 임의로 옮기지 않는다.
- = 운영자가 직접 상태를 관리해줘야한다.
- 위의 그림과 같이 Broker 2번처럼 망가져있다면 2번 브로커의 레플리카를 다른 브로커로 옮겨줘야한다.
댓글남기기