[ 파티셔너 ]
피텨셔너는 프로듀서가 토픽으로 메세지를 보낼 때,
토픽의 어느 파티션으로 메세지를 보내야 할지를 결정합니다.
메세지 키를 해시처리해 파티션을 구하는 방식을 결정합니다.
라운드로빈 전략
별도의 메세지 키가 지정되지 않으면 라운드로빈 알고리즘을 활용해
토픽의 파티션들로 랜덤 전송합니다.
producer로 전송을 위한 파티션별 최소 레코드 수 기준(batch size)을 채우지 못한 경우,
프로듀서의 버퍼 메모리 영역에서 대기가 길어질 수 있습니다.
스티키 파티셔닝 전략
카프카 2.4버전 이후로 이를 위해 스티키 파티셔닝 전략을 사용하게 됩니다.
배치 전송을 위한 필요 레코드수를 하나의 파티션에 먼저 채워서
빠르게 배치 전송하는 전략입니다.
P1, P2 .. 는 batch.size이고
P1 + P2 .. + P5는 buffer.memory를 의미합니다.
[ 프로듀서 배치 ]
프로듀서는 처리량을 높이기 위해 배치 전송을 권장합니다.
프로듀서 옵션 | 설명 |
buffer.memeory | 프로듀서의 버퍼 메모리 옵션으로 기본값 32MB로 되어있습니다. |
batch.size | 배치 전송을 위한 배치 크기 옵션입니다. 기본값은 16KB입니다. |
linger.ms | 버퍼메모리에서 최대 대기시간을 설정하는 옵션 입니다. 단위는 밀리초(ms)이면 기본값은 0 입니다. |
- 처리량을 높이려면 batch.size, linger.ms을 크게 설정하고
지연없는 전송을 위해서라면 작게 설정해야합니다.
- buffer memory 크기는 batch size * number of partitions + 여러번 재전송시 필요한 여분으로
이러한 부분까지 고려해야 합니다.
[ 중복 없는 전송 ]
적어도 한번 전송은 메세지 손실 가능성은 없지만, 메세지 중복 가능성이 있고,
최대 한번 전송은 메세지 손실 가능성이 있지만, 메세지 중복 가능성은 없습니다.
중복 없는 전송은 적어도 한번 전송 특징과 비슷하지만,
재전송시에 메세지의 PID와 메세지 번호를 비교해서
이미 브로커에 저장되어 있는 것을 확인하고, 있다면 ACK만 보냅니다.
단점은 메세지 비교 동작에는 오버헤드가 생길 수 있습니다. (약 20%)
중복 없는 전송을 위한 프로듀서 설정
프로듀서 옵션 | 값 | 설명 |
enable.idempotence | true | - 프로듀서가 중복 없는 전송 허용 옵션 - 기본 값은 false - true로 설정시 아래 값도 같이 변경해야 ConfigException이 발생하지 않음 |
max.in.flight.requests.per.connection | 1 ~ 5 | - ACK를 받지 않은 상태에서 하나의 커넥션에 보낼 수 있는 최대 요청 수 - 기본값은 5 |
acks | all | - acks관련 옵션으로 기본값은 1 |
retries | 5 | ACK를 받지 못할 경우 재시도 횟수 |
[ 정확히 한 번 전송 ]
- 정확히 한번 처리하는 프로세스를 관리하기 위해 카프카에서는 별도의 프로세스가 있는데 이를 트랜잭션 API라고합니다.
- 트랜잭션 코디네이터가 서버측에 존재하며, 역할은 프로듀서가 전송한 메세지의 커밋, 중단 등을 표시합니다.
- 트랜잭션 로그를 카프카 내부 토픽인 _transaction_state에 저장합니다.
- 트랜잭션 코디네이터를 통해 메세지의 커밋, 실패를 식별하여 정확히 한 번 전송이 가능하게합니다.
자세한 내용 참조 : https://developer.confluent.io/courses/architecture/transactions/
'DataPipeline > Kafka' 카테고리의 다른 글
실전 카프카 - 10장 스키마 레지스트리 (0) | 2025.01.30 |
---|---|
실전 카프카 - 6장 컨슈머 동작원리와 구현 (0) | 2024.12.31 |
실전 카프카 - 4장 내부 동작 원리와 구현 (0) | 2024.12.01 |
실전 카프카 - 3장 기본 개념과 구조 (0) | 2024.12.01 |
Kafka - CDC Connector Debezium 예제 (0) | 2024.11.29 |