참고 자료

https://www.youtube.com/watch?v=0Ssx7jJJADI

정의

분산 이벤트 스트리밍 플랫폼

⇒ 스트리밍을 처리하기 위한 플랫폼

• 고성능

카프카 개념

기본 구조 (구성요소)

1. 카프카 클러스터

• 메시지를 저장하는 저장소
• 데이터가 이동하는데 필요한 핵심 역할을 함
• 하나의 카프카 클러스터는 여러개의 브로커 로 구성이 됨.
  • 브로커
    • 각각의 서버로 보면 됨
    • 메시지를 나누어서 저장함
    • 이중화 처리도 함.
    • 장애가 나면 대체도 하고 그런 역할을 함.

2. 주키퍼 클러스터 (앙상블)

• 카프카 클러스터를 관리함.
• 카프카 클러스터 정보가 기록이 됨.

3. 프로듀서 (Producer)

• 카프카 클러스터에 메시지를 보냄.

4. 컨슈머 (Consumer)

• 메시지를 카프카에서 읽어옴.

토픽과 파티션

토픽

• 메시지를 저장하는 단위 ⇒ 메시지를 구분하는 용도로 사용함.
• 파일 시스템의 폴더와 유사한 개념
• 한 개의 토픽은 한 개 이상의 파티션으로 구성됨.

파티션

• 메시지를 저장하는 물리적인 파일을 의미.
• append-only 파일 ⇒ 추가만 가능한 파일

⇒ 프로듀서와 컨슈머가 토픽을 기준으로 메시지를 주고 받음

→ 프로듀서가 카프카에 저장할 때, 어떤 토픽에 메시지를 저장해달라고 요청

→ 컨슈머는 어떤 토픽에서 메시지를 읽어옴.

오프셋과 메시지 순서

• 오프셋은 각 메시지 저장 위치를 의미.
• 프로듀서가 넣은 메시지는 파티션의 맨 뒤에 추가
• 컨슈머는 오프셋 기준으로 메시지를 순서대로 읽음
• 메시지는 삭제되지 않음 (설정에 따라 일정 시간이 지난 뒤 삭제

여러 파티션과 프로듀서

• 프로듀서는 라운드로빈 또는 키로 파티션을 선택해서 메시지를 저장한다.
  ⇒ 같은 키를 가지면, 같은 파티션에 저장이됨. ↔ 아니면 라운드로빈

여러 파티션과 컨슈머

• 컨슈머는 컨슈머 그룹에 속하게 됨.
• 한 개의 파티션은 컨슈머그룹의 한 개 컨슈머만 연결이 가능하다.
  ⇒ 즉, 하나의 컨슈머 그룹에 속한 컨슈머들은 한 파티션을 공유할 수 없다.
  ⇒ 이를 통해 하나의 컨슈머 그룹 기준으로 파티션 메시지는 순서대로 처리가 된다.

성능

• OS 페이지 캐시 사용
• Zero Copy
• 브로커가 컨슈머 추척을 위해 작업을 하지 않음 ⇒ 하는 일이 적음.
• 메시지를 묶어서 보내고, 묶어서 받을 수 있음 (batch)
  ⇒ 낱개 처리보다 처리량이 증가함.
• 처리량 증대(수평 확장)이 쉬움.
  • 1개의 장비의 용량 한계 ⇒ 브로커 추가, 파티션 추가하면 됨.
  • 컨슈머가 느림 ⇒ 컨슈머 추가하면 됨.

리플리카 - 복제 (고가용성)

• 리플리카: 파티션의 복제수
  • 복제수만큼 파티션의 복제본이 각 브로커에 생김
  • 리더와 팔로워 브로커로 구성 ⇒ 프로듀서와 컨슈머는 리더를 통해서만 메시지 처리함.
• 장애 대응용

Producer

• byte 배열로 변환
• 파티션 결정
• 버터에 배치로 메시지 저장 (성능이 좋은 이유)
• 배치 전송

sender

• sender는 별도 스레드로 동작
• 배치가 찾는지 여부와 관계 없이 브로커에 전송

전송 결과 확인 안함

전송 결과를 확인하기 위해서는

Future 사용

• 단점
  • 블로킹이 발생해서 배치가 1개씩밖에 못쌓임
    • 배치 효과가 떨어져서 처리량 저하
• 처리량이 낮아도 되는 경우에만 사용

Callback 사용

• 처리량 저하 없음

전송 보장과 ACK

• ACK = 0
  • 전송 보장 X
• ACK = 1
• ACK = all (-1)
  • 전송 보장 O

에러 유형

• 전송 과정에서 실패
• 전송 전에 실패

실패 대응

• 재시도 (무한 재시도 X)
  • 브로커 응답이 늦게와서 중복 전송될 가능성이 있음.
  • 순서가 바뀔수도 있음.
• 기록

Consumer

특정 토픽의 파티션에서 레코드를 조회하는 역할을 함.

• 메시지 읽어 옴 → 역직렬화 → 카프카 컨슈머 객체 생성 → 내가 구독할 토픽을 전달
• 토픽 파티션은 그룹 단위로 할당됨.
• 파티션보다 컨슈머가 더 많이 생성되면 노는 컨슈머가 생길 수 있음
  ⇒ 컨슈머 개수가 파티션 개수보다 커지면 안됨!!
  - 만약 처리 속도가 느려져서 컨슈머 수를 늘린다면, 파티션의 수도 같이 늘려줘야함.

커밋과 오프셋

컨슈머는 읽다가, 마지막 offset commit함.

다음에는 이 offset부터 읽음

컨슈머는 스레드로 사용하면 안됨!