Kafka 압축 코덱 비교: Zstd vs. Snappy vs. Gzip

Kafka 압축은 병목 지점을 변경합니다: 네트워크 및 디스크 트래픽은 줄이고, 프로듀서와 컨슈머의 CPU 작업은 늘립니다. Kafka는 대량의 데이터를 처리하는 데 탁월하지만, 성능 최적화는 종종 몇 가지 주요 매개변수 조정을 수반합니다. 특히 대용량 또는 네트워크 제약 환경에서 튜닝의 가장 중요한 영역 중 하나는 메시지 압축입니다.

최적의 Kafka 압축 코덱은 CPU, 네트워크 대역폭, 브로커 디스크 또는 컨슈머 용량 중 어느 것이 부족한지에 따라 달라집니다.

Kafka에서 압축 이해하기

Kafka는 프로듀서가 브로커로 메시지를 보내기 전에 압축할 수 있도록 합니다. 브로커는 압축된 배치를 저장하고, 컨슈머는 데이터를 검색하여 압축 해제합니다. 이 과정은 계산 부하를 네트워크/디스크 계층에서 CPU 계층으로 이동시킵니다. 코덱 선택은 이러한 리소스 간의 균형을 결정하기 때문에 중요합니다.

Kafka는 일반적으로 none, gzip, snappy, lz4, zstd를 지원하지만, 정확한 지원은 브로커 및 클라이언트 버전에 따라 다릅니다.

압축 구성

압축은 일반적으로 compression.type 속성을 사용하여 프로듀서 측에서 구성됩니다. 브로커는 프로듀서가 사용하는 코덱을 읽을 수 있어야 합니다.

# 예제 프로듀서 구성
compression.type=zstd

Kafka 압축 코덱 심층 분석

일반적으로 사용되는 세 가지 주요 코덱(Gzip, Snappy, Zstd)을 일반적인 성능 프로필을 기준으로 비교합니다.

1. Gzip (GNU Zip)

Gzip은 DEFLATE 알고리즘을 기반으로 하는 잘 정립된 범용 압축 알고리즘입니다. 종종 강력한 압축을 제공하지만, Zstd는 레벨과 데이터 형태에 따라 많은 이벤트 페이로드에서 이를 따라잡거나 능가할 수 있습니다.

압축률: 높음, 특히 텍스트가 많은 페이로드의 경우.
CPU 사용량: 높음 (압축 및 압축 해제 모두에 상당한 CPU 시간 필요).
지연 시간 영향: 집중적인 CPU 사용으로 인해 눈에 띄는 지연 시간이 발생할 수 있으며, 특히 대용량 배치를 압축할 때 그렇습니다.

최적 사용 사례: 스토리지 절약 및 네트워크 대역폭 보존이 가장 중요하고 CPU 리소스가 풍부한 시나리오, 또는 메시지 처리량 요구 사항이 상대적으로 낮은 경우.

2. Snappy

Google이 개발한 Snappy는 최대 압축보다는 속도를 위해 설계되었습니다. 결과 파일 크기가 Gzip이나 Zstd보다 크더라도 매우 빠른 압축 및 압축 해제 속도를 우선시합니다.

압축률: 중간에서 낮음.
CPU 사용량: 낮음 (매우 빠른 실행 시간).
지연 시간 영향: 최소. Snappy는 종단 간 지연 시간에 거의 영향을 미치지 않는 것으로 알려져 있습니다.

최적 사용 사례: 낮은 지연 시간이 절대 최우선인 고처리량 시스템. 계산 병목 현상을 최소화하면서도 네트워크 절감 효과를 제공하기 때문에 많은 Kafka 배포에서 기본 선택인 경우가 많습니다.

3. Zstandard (Zstd)

원래 Facebook(Meta)에서 개발한 Zstandard는 현대적인 경쟁자입니다. Zstd는 선택한 압축 수준에 따라 Gzip에 가깝거나 더 나은 압축률을 달성하면서 Snappy보다 우수한 성능을 제공하는 것을 목표로 합니다.

Zstd는 조정 가능한 압축 수준을 지원합니다. Kafka 클라이언트는 이를 지원하는 클라이언트에서 코덱별 구성을 통해 노출합니다.

레벨 1 (빠름): 종종 속도 면에서 Snappy를 능가하면서 Snappy보다 더 나은 압축을 제공합니다.
레벨 3-5 (균형): 일반적인 최적 지점으로, 낮은 CPU 오버헤드로 좋은 압축률을 제공합니다.
레벨 10+ (높음): Gzip의 압축률에 근접하지만 일반적으로 압축 해제 속도는 더 빠릅니다.
압축률: 가변적 (중간에서 매우 높음).
CPU 사용량: 선택한 레벨에 따라 매우 다양함 (낮거나 높을 수 있음).
지연 시간 영향: 일반적으로 낮은 레벨에서는 매우 낮음; Snappy와 비슷함.

최적 사용 사례: 거의 모든 최신 Kafka 배포. Zstd는 균형을 정밀하게 조정할 수 있는 유연성을 제공합니다. 낮은 지연 시간이 필요하면 레벨 1 또는 3을 사용하십시오. 스토리지 절약이 필요하면 더 높은 레벨(예: 9 또는 11)을 사용하십시오.

비교 분석: 코덱 선택하기

최적의 코덱은 전적으로 특정 클러스터 아키텍처의 병목 지점에 따라 달라집니다.

코덱	압축률	압축 속도	압축 해제 속도	CPU 오버헤드	이상적인 사용 사례
Snappy	낮음	매우 빠름	매우 빠름	가장 낮음	지연 시간에 민감한 고처리량
Zstd (레벨 1-3)	중간	빠름	매우 빠름	매우 낮음	현대적이고 균형 잡힌 성능
Zstd (레벨 5-11)	높음	보통	빠름	중간	유연한 스토리지/성능 절충
Gzip	가장 높음	느림	느림	가장 높음	스토리지 아카이빙, 낮은 처리량

실용적인 결정 가이드

다음 지침을 사용하여 요구 사항을 코덱에 매핑하십시오:

지연 시간이 중요한 경우 (예: 실시간 금융 피드): Snappy 또는 Zstd 레벨 1을 선택하십시오. 이들은 CPU 저항이 가장 적습니다.
스토리지 비용이 중요한 경우 (예: 데이터를 몇 달간 보관): Gzip 또는 높은 레벨(15+)의 Zstd를 선택하십시오. 더 많은 CPU 리소스를 할당할 준비를 하십시오.
일반 목적의 고처리량 시스템: **Zstd (레벨 3 또는 5)**가 압도적으로 권장됩니다. 속도를 크게 희생하지 않으면서 Snappy보다 더 나은 효율성(압축된 바이트당 CPU 감소)을 제공하는 경우가 많습니다.

예제 구성: 속도 최적화 (Zstd)

Zstd를 사용하고 Snappy에 가까운 성능과 약간 더 나은 압축을 원한다면 프로듀서 구성에서 레벨을 명시적으로 설정하십시오:

# Zstd를 사용하여 속도를 우선시하는 프로듀서 구성
compression.type=zstd
compression.zstd.level=3

압축 레벨에 대한 경고: Kafka 클라이언트는 지원되는 경우 compression.zstd.level 및 compression.gzip.level과 같은 코덱별 레벨 설정을 노출합니다. Snappy는 같은 방식으로 레벨을 조정할 수 없습니다. 레벨을 높이면 배치가 전송되기 전에 발생하는 압축 시간이 크게 증가한다는 점에 유의하십시오.

프로듀서와 컨슈머를 위한 성능 고려 사항

압축이 연결의 양쪽 모두에 영향을 미친다는 점을 기억하는 것이 중요합니다:

프로듀서 영향 (압축 시간)

프로듀서는 전체 레코드 배치가 준비될 때까지 기다린 후 압축하여 전송해야 합니다. 압축 시간이 linger.ms를 초과하면 프로듀서가 배치를 너무 일찍 또는 너무 늦게 보낼 수 있습니다. 매우 느린 압축(예: 높은 레벨의 Gzip)은 프로듀서가 더 작은 배치를 더 자주 보내도록 강제하여 요청 오버헤드를 증가시킬 수 있습니다.

컨슈머 영향 (압축 해제 시간)

컨슈머는 데이터를 처리하기 전에 압축을 해제하기 위해 CPU 사이클을 소비해야 합니다. 컨슈머 CPU가 최대치에 도달하면 네트워크 처리량이 충분하더라도 압축 해제가 병목 현상이 되어 컨슈머 지연이 발생할 수 있습니다. 압축 해제 속도는 압축 속도보다 더 중요한 경우가 많습니다. 컨슈머 지연 시간에 직접적인 영향을 미치기 때문입니다.

이러한 이유로 압축 해제 루틴이 비교적 느린 Gzip보다 Snappy 및 Zstd(압축 해제 루틴이 매우 빠름)와 같은 코덱이 선호됩니다.

결론

새로운 Kafka 워크로드의 경우 낮거나 중간 수준의 Zstd로 시작한 다음 실제 페이로드로 벤치마킹하십시오. 프로듀서 또는 컨슈머 CPU가 부족하고 지연 시간이 가장 중요한 경우 Snappy를 사용하십시오. 호환성 또는 스토리지 감소가 추가 CPU 비용보다 중요한 경우에만 Gzip을 사용하십시오.