일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 코틀린
- SWIFT
- swagger
- props
- Nest.js
- vue
- 상속
- file upload
- 개발이 취미인 사람
- 반복문
- Sequelize
- back-end
- javascript
- 개발자
- AWS
- 조건문
- jpa
- class
- restful api
- It
- Producer
- java
- spring boot
- kafka
- node.js
- react
- Kotlin
- front-end
- component
- state
- Today
- Total
개발이 취미인 사람
[Kafka] - Producer 파티셔너(partitioner)와 메시지 발송 전략 본문
개요
안녕하세요. 이번 시간에는 파티셔너(partitioner)와 메시지 발송 전략에 대해 알아보겠습니다.
혹시 Producer에 대한 개념을 놓치고 오셨다면 아래 링크를 통해 학습하고 오시는 걸 추천드리겠습니다.
[Kafka] - Kafka Producer 메시지 생성
파티셔너(Partitioner)
Kafka 프로듀서에서 파티셔너는 특정 메시지가 어느 파티션에 기록될지를 결정하는 역할을 합니다.
Kafka의 각 토픽(topic)은 여러 개의 파티션으로 나뉘어 있고, 파티셔너는 메시지를 특정 파티션에 고르게 또는 특정 기준에 따라 분배하는 기능을 합니다.
프로듀서가 파티션을 결정하는 알고리즘은 기본적으로 메시지(레코드)의 키를 해시(hash) 처리해 파티션을 구하는 방식을 사용합니다.
따라서 메시지의 키 값이 동일하면 해당 메시지들은 모두 같은 파티션으로 전송됩니다.
위와 같이 user1이라는 키를 통해 메시시를 전송하면 동일한 파티션에 메시지가 전송됩니다.
하지만 운영상 이슈로 파티션을 늘리게 되면 어떻게 될까요? 파티션을 결정하는 알고리즘은 기본적으로 해시방식을 사용한다고 했습니다.
만약 파티션이 늘리게 되면 기존 파티션 1이 아닌 다른 파티션으로 메시지가 전송됩니다.
위와 같은 이슈를 해결하기 위해서는 파티션을 지정하는 방식이 있습니다. 메시지 순서 보장을 하기 위해서는 특정 파티션을 고정으로 사용해서 메시지를 전송합니다. (파티션은 늘리는 건 가능하지만... 줄일 수는 없습니다. 만약 줄이고 싶으면... 토픽을 삭제하고 재 생성해야 합니다.)
파티션을 함부로 지정하고 줄이는 방법은 올지 않을 수 있으니 이 부분은 내부 동료들과 상의하시는 걸 추천드리겠습니다.
메시지 발송 전략
Kafka 프로듀서는 메시지를 전송할 때 여러 가지 전송 방식을 사용합니다. 하나씩 알아보겠습니다.
1. 라운드 로빈 전략 (Round Robin)
라운드 로빈 방식은 키가 없는 메시지에 대해 사용되는 기본적인 파티셔닝 전략입니다. 이 방식은 메시지를 균등하게 분산시키는 방법입니다.
각 메시지가 들어올 때마다, 프로듀서는 사용 가능한 모든 파티션에 대해 순차적으로 메시지를 전송합니다. 모든 파티션이 동일한 양의 메시지를 받도록 하여 부하를 고르게 분산시킵니다.
기본적으로 메시지를 발송할 때 키(key)를 설정하지 않고 발송하면 라운드 로빈 방식으로 파티션에 분배됩니다.
메시지를 분배해서 전송하는 방법은 부하를 줄이는데 좋은 방식일 수 있지만, 배치 방식에는 안 좋을 수 있습니다. 그 이유는 스티키 파티셔닝 전략을 설명하면 말씀드리겠습니다.
2. 스티키 파티셔닝 전략 (Sticky Partitioning)
스티키 파티셔닝은 Kafka 2.4.0부터 도입된 새로운 메시지 파티셔닝 전략입니다. 이 전략은 메시지를 전송할 때 특정 파티션을 유지하는 방식으로 성능을 최적화합니다.
여러 파티션이 존재할 때 순차적으로 메시지를 분산시키는 게 아니라 특정 파티션에 메시지가 모두 채워지면 다음 파티션에 메시지를 채우는 방식을 사용합니다.
스티키 파티셔닝 전략을 사용하기 위해서는 partitioner.class 에 설정을 org.apache.kafka.clients.producer.StickyPartitioner로 설정하면 적용이 됩니다.
3. 배치 전송 전략
Kafka에서는 토픽을 처리량을 높이기 위한 방법으로 파티션을 나눠서 처리하기도 하지만 메시지를 모아서 한 번에 전송하는 배치 전략을 권장합니다.
아무래도 네트워크 I/O가 큰 비용을 차지하기 때문이라고 생각합니다. 배치 설정은 아래 옵션을 지정해서 사용할 수 있습니다.
- batch.size: 프로듀서가 한 번에 전송할 수 있는 최대 메시지 크기 (바이트 단위). - 기본 값 16KB
- linger.ms: 프로듀서가 배치 전송을 위해 대기하는 시간 (밀리초 단위). 이 시간이 경과하면 배치가 전송됩니다. - 기본 값 0
- buffer.memory: 프로듀서가 메시지를 버퍼링 하는 데 사용할 수 있는 메모리 양 (바이트 단위). 이 메모리가 가득 차면 추가 메시지는 대기해야 합니다. - 기본 값은 32MB
위 설정을 통해 메시지를 즉시 발송 하는 게 아니라 대기열에 메시지를 모아서 한번에 전송합니다.
라운드 로빈 방식 보다 스티키 파티셔닝 전략이 높은 처리량을 보장할 수 있다고 생각합니다.
이번 시간에는 카프카 메시지 전송 방식에 대해 알아봤습니다. 헷깔리시는 부분은 댓글을 남겨주시면 감사하겠습니다.