Kafka 확장: 높은 처리량과 낮은 지연 시간을 위한 전략

Kafka를 확장한다는 것은 지연 시간, 컨슈머 지연 또는 브로커 부하가 통제 불능 상태가 되지 않도록 하면서 처리량을 늘리는 것을 의미합니다. 대부분의 확장 작업은 파티션, 프로듀서 배치, 컨슈머 병렬 처리, 브로커 리소스 및 복제 설정에 달려 있습니다.

"Kafka를 더 빠르게 만드는" 단일 스위치는 없습니다. 먼저 병목 지점을 찾은 다음, 실제로 클러스터를 제한하는 파이프라인 부분을 조정해야 합니다.

Kafka의 확장성 기반 이해하기

Kafka의 확장성은 몇 가지 핵심 개념을 기반으로 구축됩니다.

브로커: Kafka는 토픽 파티션을 여러 브로커에 분산하여 스토리지, 네트워크 및 CPU 부하를 공유할 수 있도록 합니다.
파티션: 파티션은 순서 지정 및 병렬 처리의 단위입니다. 더 많은 파티션은 더 많은 프로듀서 및 컨슈머 병렬 처리를 허용할 수 있습니다.
복제: 각 파티션에는 리더와 팔로워 복제본이 있습니다. 복제는 가용성을 향상시키지만 디스크 및 네트워크 작업을 추가합니다.
클라이언트: 프로듀서 및 컨슈머 설정은 종종 브로커 설정만큼 중요합니다.

높은 처리량을 위한 전략

Kafka에서 높은 처리량을 달성하는 것은 주로 병렬 처리를 극대화하고 데이터 흐름을 최적화하는 데 중점을 둡니다.

효과적인 파티셔닝 전략 선택

파티션의 수와 설계는 처리량에 매우 중요합니다. 일반적으로 더 많은 파티션은 더 많은 병렬 처리를 의미하지만, 수확 체감의 법칙과 잠재적인 단점이 있습니다.

하나의 토픽이 포화 상태일 때 파티션 수를 늘리십시오. 더 많은 파티션은 쓰기 및 읽기 부하를 더 많은 브로커와 컨슈머에 분산시킬 수 있습니다.
핫 파티션을 피하는 키를 선택하십시오. tenant_id와 같은 키는 테넌트가 유사한 경우 괜찮을 수 있지만, 하나의 거대한 테넌트가 하나의 파티션에 과부하를 줄 수 있습니다. 이 경우 복합 키나 다른 토픽 설계가 필요할 수 있습니다.
무분별하게 과도하게 파티셔닝하지 마십시오. 너무 많은 파티션은 메타데이터, 파일 핸들, 리더 선출 작업 및 컨슈머 리밸런스 시간을 증가시킵니다.

예를 들어, orders 토픽이 region으로만 키 지정되어 있고 트래픽의 80%가 us-east인 경우 하나의 파티션이 핫스팟이 될 수 있습니다. customer_id 또는 region.customer_id와 같은 키는 애플리케이션에 필요한 순서를 유지하면서 트래픽을 더 균등하게 분산시킬 수 있습니다.

프로듀서 구성 조정

프로듀서 설정을 최적화하면 쓰기 처리량을 획기적으로 향상시킬 수 있습니다.

acks: acks=all은 적절한 min.insync.replicas와 함께 사용할 때 가장 강력한 내구성을 제공하지만 지연 시간을 추가할 수 있습니다. acks=1은 리더만 쓰기를 승인하므로 더 빠릅니다. acks=0은 가장 빠르지만 브로커 승인이 없습니다.
batch.size 및 linger.ms: 더 큰 배치는 요청 오버헤드를 줄입니다. 작은 linger.ms는 프로듀서가 배치를 채울 시간을 주지만 대기 시간이 추가됩니다.
압축: lz4, snappy 또는 zstd는 네트워크 및 디스크 압력을 줄일 수 있습니다. 압축은 CPU를 사용하므로 실제 메시지 형태로 테스트하십시오.
max.request.size: 합법적인 배치 또는 레코드에 필요한 경우에만 이 값을 높이십시오. 또한 message.max.bytes 및 토픽 수준의 max.message.bytes와 같은 브로커 측 제한을 확인하십시오.

브로커 리소스 및 스레드 조정

브로커 설정은 데이터를 처리하는 효율성에 직접적인 영향을 미칩니다.

num.network.threads: 클라이언트 및 기타 브로커의 네트워크 요청을 처리하는 스레드를 제어합니다.
num.io.threads: 디스크 I/O 및 요청 처리 작업에 사용되는 스레드를 제어합니다.
num.partitions: 새로 생성된 토픽의 기본 파티션 수를 설정합니다. 기존 토픽의 크기는 조정하지 않습니다.
log.segment.bytes: 로그 세그먼트 크기를 제어합니다. 세그먼트 크기는 보존 정리, 압축 동작 및 파일 관리에 영향을 미칩니다.

메트릭을 염두에 두고 이러한 설정을 변경하십시오. 디스크가 포화 상태이면 더 많은 스레드가 클러스터를 고치지 못합니다. CPU를 사용할 수 있는 동안 네트워크 요청 큐가 증가하고 있다면 스레드 조정이 도움이 될 수 있습니다.

낮은 지연 시간을 위한 전략

Kafka에서 낮은 지연 시간은 종종 프로듀서에서 컨슈머로의 메시지 전달 지연을 최소화하는 것을 의미합니다.

낮은 지연 시간을 위한 컨슈머 조정

컨슈머는 전달 파이프라인의 마지막 단계입니다.

fetch.min.bytes: 값이 낮을수록 데이터를 더 빨리 반환하지만 더 많은 가져오기 요청을 생성합니다.
fetch.max.wait.ms: 값이 낮을수록 트래픽이 적을 때 대기 시간이 줄어듭니다.
컨슈머 그룹 크기: 컨슈머 그룹은 할당된 파티션 수까지 토픽을 병렬로 처리할 수 있습니다. 파티션 수를 초과하는 추가 컨슈머는 해당 토픽에 대해 유휴 상태가 됩니다.
처리 시간: 느린 다운스트림 데이터베이스 쓰기, HTTP 호출 또는 무거운 변환은 Kafka 자체가 정상인 경우에도 종종 지연을 유발합니다.

네트워크 거리 줄이기

프로듀서, 브로커 및 컨슈머 간의 네트워크 지연 시간은 중요한 요소입니다.

가능하면 프로듀서, 브로커 및 지연 시간에 민감한 컨슈머를 가까이 두십시오. 리전 간 Kafka 트래픽은 지연 시간과 장애 모드를 추가합니다. 다중 리전 전달이 필요한 경우, 먼 네트워크에 걸쳐 하나의 저지연 클러스터를 확장하는 것이 아니라 복제 또는 데이터 이동 설계 문제로 취급하십시오.

브로커를 리소스 압박에서 유지

낮은 지연 시간은 안정적인 브로커에 달려 있습니다. CPU, 디스크 I/O 대기, 페이지 캐시 동작, 네트워크 포화, 요청 핸들러 유휴 비율 및 복제 미달 파티션을 주시하십시오. 브로커가 과부하 상태이면 클라이언트 조정은 증상을 잠시 숨길 뿐입니다.

복제와 내결함성 균형 맞추기

복제는 주로 내결함성을 위한 것이지만 성능과 확장에 영향을 미칩니다.

복제 요소: 복제 요소 3은 생산 토픽에서 일반적입니다. 단일 복제본보다 브로커 손실을 더 잘 견딜 수 있기 때문입니다.
min.insync.replicas: acks=all과 함께 사용하면 프로듀서가 성공을 얻기 전에 동기화된 복제본이 쓰기를 승인해야 하는 수를 제어합니다.
ISR 상태: 축소되는 동기화된 복제본 세트는 경고 신호입니다. 이는 종종 느린 디스크, 네트워크 문제 또는 과부하된 브로커를 나타냅니다.

각 변경 전후 모니터링

지속적인 모니터링은 병목 지점을 식별하고 성능을 조정하는 데 필수적입니다.

브로커 CPU, 디스크 I/O, 네트워크 처리량, 요청 지연 시간, 파티션 처리량, 생성 오류율, 복제 미달 파티션 및 컨슈머 지연을 추적하십시오. Kafka는 JMX를 통해 이러한 많은 정보를 노출하며, 팀은 일반적으로 Prometheus 및 Grafana 또는 Kafka 관련 플랫폼을 사용하여 이를 수집합니다.

한 번에 하나의 의미 있는 변경을 수행하십시오. 파티션을 늘리면 리밸런스 영향과 핫 파티션 동작을 측정하십시오. 프로듀서 배치를 변경하면 평균 처리량뿐만 아니라 지연 시간 백분위수와 오류율을 측정하십시오.

핵심 내용

병목 지점에서부터 Kafka를 확장하십시오. 파티션 분포와 클라이언트 배치로 시작한 다음, 컨슈머 지연, 브로커 디스크 및 네트워크 압력, 복제 상태를 확인하십시오. 잘 확장된 Kafka 클러스터는 단순히 더 큰 것이 아닙니다. 균형 잡힌 파티션, 예측 가능한 클라이언트 동작 및 장애에 대비한 충분한 여유 공간을 갖추고 있습니다.