딱 한번 일어난 이벤트 데이터를 브로커에 저장함으로써 단일 진실 공급원으로 사용할 수 있음
장애가 발생했을 때, 장애가 발생한 지점부터 재처리를 할 수 있음
많은 양의 실시간 스트림 데이터를 효과적으로 처리 할 수 있음
이벤트 브로커로 클러스터를 구축하면?
이벤트 기반 마이크로 서비스 아키텍처로 발전하는데 아주 중요한 역할을 함
프로듀서 ⇒ 브로커에 메시지 넣음 ⇒ 컨슈머가 가져감
브로커를 관리하기 위해 주키퍼가 필요함
성능
파티션 파일은 OS의 페이지캐시(혹은 디스크 캐시) 사용
페이지캐시?
리눅스는 파일I/O의 성능 향상을 위해 페이지 캐시라는 메모리 영역을 만들어서 사용합니다. 상대적으로 많이 느린 디스크로의 접근을 최대한 피하기 위해 사용되는 메모리 영역입니다. 한 번 읽은 파일의 내용을 페이지 캐시라는 영역에 저장시켜 놨다가 다시 한번 동일한 파일 접근이 일어나면 디스크에서 읽지 않고 페이지 캐시에서 읽어서 제공해 주는 방식
파티션에 대한 파일 IO를 메모리에서 처리
서버에서 페이지캐시를 카프카만 사용해야 성능에 유리
Zero Copy
디스크 버퍼에서 네트워크 버퍼로 직접 데이터 복사
컨슈머 추적을 위해 브로커가 하는 일이 비교적 단순
메시지 필터, 메시지 재전송과 같은 일은 브로커가 하지 않음
프로듀서, 컨슈머가 직접 해야 함
브로커는 컨슈머와 파티션 간 매핑 관리
묶어서 보내기, 묶어서 받기 (batch) - 아래 프로듀서 기본흐름의 그림 중 '버퍼 안의 배치'
프로듀서 : 일정 크기만큼 메시지를 모아서 전송 가능
컨슈머 : 최소 크기만큼 메시지를 모아서 조회 가능
낱개 처리보다 처리량 증가
처리량 증대(확장)가 쉬움
1개 장비의 용량 한계 ⇒ 브로커 추가, 파티션 추가
컨슈머가 느림 ⇒ 컨슈머 추가(+파티션 추가)
리플리카
리플리카 : 파티션의 복제본
복제수만큼 파티션의 복제본이 각 브로커에 생김
리더와 팔로워로 구성
프로듀서와 컨슈머는 리더를 통해서만 메시지 처리
팔로워는 리더로부터 복제
장애 대응
리더가 속한 브로커 장애시 다른 팔로워가 리더가 됨
https://www.youtube.com/watch?v=xqrIDHbGjOY kafka 조금 아는 척하기 1~3 (개발자용) https://www.youtube.com/watch?v=H_DaPyUOeTo 카프카, 레빗엠큐, 레디스 큐의 큰 차이점! 이벤트 브로커와 메시지 브로커에 대해 알아봅시다.
