- 사실상 카프카를 사용하는 이유
- 토픽을 생성하면 한 파이프라인이 만들어짐
- 카프카에서 데이터를 구분하는 단위
- "구체화된 이벤트 스트림" 이라고 불림
어떤 일어난 일, 시스템 사이를 오가는 불변하는 데이터
레코드 또는 메시지
관련된 이벤트들을 뜻함 (순서를 가지고 있음)
- 토픽을 이루고 있는 단위
- 토픽에 속한 레코드를 실제 저장소에 저장하는 가장 작은 단위
- Append Only로 저장되는 로그 파일
- 프로듀서가 보낸 데이터들이 파티션에 들어가 저장되며, 이데이터는 레코드라고 함
- 큐와 비숫한 구조(FIFO)이나, 처리 후 삭제하지 않음
- 먼저 들어간 레코드는 컨슈머가 먼저 가져감
- 파티션의 각 레코드에는 오프셋(Offset)이라는 식별자가 붙음
* Kafka에서 유지 관리하는 증분 및 변경 불가능한 숫자
* 레코드가 파티션에 기록되면 다음 순차 오프셋을 할당하여 로그 끝에 추가
* 파티션 내의 메시지는 순서가 정해져 있지만 토픽 전체의 메시지는 순서가 보장되지 않음
- 토픽의 파티션을 여러 브로커에 분산시킴
- 브로커에 파티션을 분산하면 수평적으로 확장하는 효과
* 싱글 브로커보다 훨씬 뛰어난 성능을 제공
- 다른 컨슈머들이 토픽을 병렬적으로 사용 가능함
* 여러 파티션을 설정하면 더 많은 컨슈머를 사용할 수 있게 됨
- 매우 높은 메시지 처리량
* 각 컨슈머의 인스턴스는 한 파티션에서 메시지를 제공받게 됨
* 각 레코드는 메시지 처리 담당자가 존재하게 됨
- 파티션은 카프카가 복제하는 방식
* 여러 브로커에 동일한 파티션의 복제본을 2개 이상 가지고 있음
* 브로커가 다운되면 다운된 브로커가 가지고 있는 파티션의 복제본을 사용함
- 프로듀서는 레코드를 특정 파티션으로 보내야 함
1. 파티션 키 사용
2. 카프카가 파티션을 결정
3. 사용자 지정 파티셔너 결정
- 파티션키를 사용할 데이터를 설정 (ConsumerId, _id)
- Hashing 함수를 통해 전달됨
- 동일 키로 생성한 모든 레코드는 동일 파티션에 저장되며 정확한 순서가 보장될 수 있음
- 키가 잘 분산되지 않을 가능성이 있음
- 한 고객 ID가 전체 트래픽의 70%이상을 발생시키면 브로커가 다운 될 수 있으므로, 분산이 잘되는지 확인해야 함
- 컨슈머가 브로커 파티션에 연결하고 순서대로 메시지를 읽음
- 오프셋이 컨슈머의 커서로 작동함
- 컨슈머는 오프셋을 트래킹하면서 사용한 메시지를 추적함
- 컨슈머는 메시지를 읽고 다음 오프셋으로 이동
- 각 파티션에 마지막으로 소비된 메시지의 오프셋을 기억
- 어떤 시점의 파티션에 들어가더라도 오프셋 위치에서 작업을 재개 할수 있음
- 하나 이상의 컨슈머가 있더라도 문제 없음
- 각 컨슈머는 각 파티션에 대해 어디까지 읽었느닞 자신만의 기록을 가지게 되며, 이를 통해 충돌이 나지 않게 됨
- 파티션 단위의 분산 처리
- 파티션이 많다면 동시 처리량이 늘어남 (높은 throughput)
- 파티션이 많아진 상태에서 노드가 다운되면, 토픽안의 파티션 단위로 분산처리 하기때문에 복구가 복잡함
- 카프카는 모든 디렉토리의 파일에 대한 파일 핸들을 열기 때문에 파티션이 많아질수록 리소스가 낭비됨
- 원하는 목표 처리량의 기준 필요
ex) 프로듀서 3개에 초당 10개의 메시지를 보낸다면, 토픽에서는 최소한 초당 30개의 메시지를 받아줘야함
1개의 파티션이 1초에 10개를 받아준다면, 파티션을 최소 3개로 늘려 이를 처리할 수 있도록 수정
- 파티션을 늘린 다음엔 줄일 수 없음
* 삭제 하고 토픽을 재생성 해야 함
- 적은 수의 파티션으로 운영을 하면서 늘려주는 것이 이상적