https://youtu.be/0Ssx7jJJADI?si=_phzVmPI-on5Aj81
카프카란?
- 분산 이벤트 스트리밍 플랫폼
- 고성능
1. 카프카 클러스터 : 메시지를 저장하는 저장소, 데이터를 이동하는 데 필요한 핵심 역할 수행
2. 브로커 : 각각의 서버라고 보면 됨
3. 주키퍼 클러스터(앙상블) : 카프카 클러스터와 관련된 정보가 기록 및 관리됨
4. 프로듀서 : 메시지를 카프카에 넣음
5. 컨슈머 : 메시지를 카프카에서 읽어옴
토픽
- 메시지를 저장 및 구분하는 단위
- 파일 시스템의 폴더와 유사함
- 한 개의 토픽은 한 개 이상의 파티션으로 구성
파티션
- 메시지를 저장하는 물리적인 파일
- (기본적으로) 추가만 가능한(append-only) 파일
- 오프셋 : 각 메시지의 저장 위치
- 프로듀서가 넣은 메시지는 파티션의 맨 뒤에 추가
- 컨슈머는 오프셋 기준으로 메시지를 순서대로 읽음
- 메시지는 삭제되지 않음(설정에 따라 일정 시간이 지난 뒤 삭제)
여러 파티션과 프로듀서
- 프로듀서는 라운드로빈 또는 키로 파티션을 선택 -> 같은 키를 갖는 메시지는 같은 파티션에 저장(같은 키는 순서 유지)
여러 파티션과 컨슈머
- 컨슈머는 컨슈머 그룹에 속함
- 한 개 파티션은 컨슈머 그룹의 한 개 컨슈머만 연결 가능
=> 컨슈머 그룹에 속한 컨슈머들은 한 파티션을 공유할 수 없음
=> 한 컨슈머 그룹 기준으로 파티션의 메시지는 순서대로 처리
카프카의 성능
- 파티션 파일은 OS 페이지 캐시 사용
=> 파티션에 대한 파일 IO를 메모리에서 처리
=> 서버에서 페이지 캐시를 카프카만 사용해야 성능에 유리
- Zero Copy
=> 디스크 버퍼에서 네트워크 버퍼로 직접 데이터 복사
- 컨슈머 추적을 위해 브로커가 하는 일이 비교적 단순
=> 메시지 필터, 메시지 재전송과 같은 일은 브로커가 하지 않음 -> 프로듀서, 컨슈머가 직접 해야 함
=> 브로커는 컨슈머와 파티션 간 매핑 관리
- 묶어서 보내기, 묶어서 받기(batch)
=> 프로듀서 -> 일정 크기만큼 메시지를 모아서 전송 가능, 컨슈머 -> 일정 크기만큼 메시지를 모아서 조회 가능
- 낱개 처리보다 처리량 증가
- 처리량 증대(확장)가 쉬움(수평 확장이 매우 용이함)
=> 1개 장비의 용량 한계 -> 브로커 추가, 파티션 추가
=> 컨슈머가 느림 -> 컨슈머 추가(+ 파티션 추가)
리플리카 - 복제 => 고가용성
- 리플리카 : 파티션의 복제본 -> 복제수(replication factor)만큼 파티션의 복제본이 각 브로커에 생김
- 리더와 팔로워로 구성
=> 프로듀서와 컨슈머는 리더를 통해서만 메시지 처리
=> 팔로워는 리더로부터 복제
- 장애 대응
=> 리더가 속한 브로커 장애 시 다른 팔로워가 리더가 됨
'공부 기록 > 영상 후기' 카테고리의 다른 글
kafka 조금 아는 척하기 3 (개발자용)- 컨슈머 (0) | 2023.11.07 |
---|---|
kafka 조금 아는 척하기 2 (개발자용) - 프로듀서 (0) | 2023.11.07 |
TwoSum 문제를 풀면서 배우는 내가 짠 코드의 성능을 개선하는 과정!! (feat. 코딩 테스트) (0) | 2023.11.06 |
1장 데이터베이스와 NoSQL - 1. 데이터베이스 기본 (0) | 2023.09.13 |
데드락(교착상태)은 프로그램에 치명적이죠 T^T 언제 발생하고 어떻게 해결하는지 살펴봅시다~! 간단한 자바 예제도 있어요~!! (0) | 2023.09.11 |