Kafka topic에는 압축을 사용하는 것을 강력히 권장합니다. 압축을 사용하면 성능 저하를 거의 없이 데이터 전송 비용을 크게 절감할 수 있습니다.
Kafka의 메시지 압축에 관해 자세히 알아보려면 먼저 이 가이드를 참고하십시오.
DEFAULT는 지원되지 않습니다.- 가장 작은 (XS) 레플리카 크기로 실행할 경우, 개별 메시지의 기본 제한 크기는 16MB(비압축)이며 더 큰 레플리카에서는 32MB(비압축)입니다. 이 한도를 초과하는 메시지는 오류와 함께 거부됩니다. 더 큰 메시지가 필요하면 지원팀에 문의하십시오.
ClickPipes for Kafka는 기본적으로 Kafka consumer group offset을 통해 수집 진행 상황을 추적하며 최소 한 번 전송을 보장합니다. 또한 pod 재시작, consumer 리밸런싱, 삽입 실패가 발생하더라도 각 Kafka 레코드가 ClickHouse에 정확히 한 번만 삽입되도록 하는 정확히 한 번 처리 의미 체계를 선택적으로 지원합니다.
정확히 한 번 처리를 구현하기 위해 ClickPipes는 내부 상태 저장소에 각 파티션의 진행 상황을 다음 두 값으로 기록합니다.
- High-water mark — 해당 파티션의 모든 레코드가 ClickHouse에 삽입된 것으로 확인된 마지막 offset입니다. 재시작 시 ClickPipes는 이 표시 이하의 모든 레코드를 버리므로 이미 저장된 데이터가 다시 전송되지 않습니다.
- Pending ranges — ClickHouse로 전송되었지만 아직 확인되지 않은 삽입 블록의 offset 범위입니다. 장애 발생 후 ClickPipes는 정확히 이 범위만 재생합니다.
각 삽입 블록은 연속된 offset 범위를 포함하며 topic:partition:firstOffset-lastOffset 형식의 결정론적 중복 제거 토큰을 갖습니다. 재생 시 ClickPipes는 동일한 offset 범위와 그에 따른 동일한 토큰을 재현하므로 ClickHouse가 중복을 거부합니다. 토큰은 offset 범위에만 의존하므로 재구성된 블록이 바이트 단위로 완전히 동일하지 않아도 재생 시 중복이 제거됩니다.
주요 절충점은 파트 크기입니다. 더 큰 삽입 블록은 ClickHouse에서 더 적고 큰 파트를 생성하므로 머지 오버헤드가 낮게 유지됩니다. ClickPipes는 블록을 생성하는 동안 파티션의 행을 메모리에 유지하므로, 생성 가능한 파트 크기는 파이프에 할당된 메모리에 따라 달라집니다. 메모리가 부족하면 더 작은 블록을 생성하게 되고 테이블에는 더 많은 파트가 누적됩니다. 파이프에 더 많은 메모리를 할당하면 더 큰 블록을 생성할 수 있어 파트 수가 줄어듭니다.
파티션 수가 내부 삽입 “worker” 수와 비슷할 때 파이프가 가장 효율적으로 작동합니다. 이 경우 각 worker는 대략 하나의 파티션을 처리하며 큰 블록을 생성할 수 있는 충분한 메모리 여유를 확보할 수 있습니다. worker 수와 사용 가능한 메모리는 모두 설정 -> 고급 설정 -> 스케일링에서 구성하는 레플리카 크기 및 수에 따라 스케일링됩니다.
Apache Kafka 프로토콜 데이터 소스의 경우 ClickPipes는 TLS 암호화와 함께 SASL/PLAIN 인증을 지원하며, SASL/SCRAM-SHA-256 및 SASL/SCRAM-SHA-512도 지원합니다. 스트리밍 소스(Redpanda, MSK 등)에 따라 호환성에 기반해 이러한 인증 메커니즘 전체 또는 일부만 사용할 수 있습니다. 필요한 인증 방식이 이와 다르다면 피드백을 보내주십시오.
ClickPipes는 한 시점에 단일 ClickPipes 노드에서 처리되는 데이터 크기를 제한하기 위해 Kafka 설정 max.fetch_bytes를 사용합니다. 일부 경우에는
Warpstream이 이 설정을 준수하지 않아 예기치 않은 파이프 장애가 발생할 수 있습니다. ClickPipes 장애를 방지하려면 WarpStream 에이전트를 구성할 때 Warpstream 전용 설정 kafkaMaxFetchPartitionBytesUncompressedOverride를
8MB(또는 그 이하)로 설정하는 것을 강력히 권장합니다.
ClickPipes는 다음과 같은 AWS MSK 인증 방식을 지원합니다.
IAM 인증을 사용하여 MSK 브로커에 연결하는 경우, IAM 역할에 필요한 권한이 있어야 합니다.
아래는 MSK의 Apache Kafka API에 필요한 IAM 정책 예시입니다.
IAM role ARN을 사용해 MSK에 인증하는 경우, 역할을 수임할 수 있도록 ClickHouse Cloud 인스턴스에 대한 신뢰 관계를 추가해야 합니다.
역할 기반 접근은 AWS에 배포된 ClickHouse Cloud 인스턴스에서만 작동합니다.
- 배치 크기가 최대 크기에 도달한 경우(100,000행 또는 파드 메모리 1GB당 28MB)
- 배치가 열린 상태로 유지된 시간이 최대 허용 시간에 도달한 경우(5초)
지연 시간(Kafka 메시지가 생성된 시점부터 해당 메시지를 ClickHouse에서 사용할 수 있게 될 때까지의 시간으로 정의)은 여러 요인(예: 브로커 지연 시간, 네트워크 지연 시간, 메시지 크기/포맷)에 따라 달라집니다. 또한 위 섹션에서 설명한 배칭도 지연 시간에 영향을 미칩니다. 예상 지연 시간을 파악하려면 일반적인 부하 조건에서 해당 사용 사례를 직접 테스트해 볼 것을 항상 권장합니다.
ClickPipes는 지연 시간에 관해 어떠한 보장도 제공하지 않습니다. 낮은 지연 시간에 대한 구체적인 요구 사항이 있다면 문의해 주십시오.
ClickPipes for Kafka는 수평 및 수직 스케일링이 가능하도록 설계되었습니다. 기본적으로는 consumer 1개를 포함하는 consumer group이 생성됩니다. 이 설정은 ClickPipe를 생성할 때 구성할 수 있으며, 이후에도 설정 -> 고급 설정 -> 스케일링에서 언제든지 변경할 수 있습니다.
ClickPipes는 가용 영역에 분산된 아키텍처를 통해 고가용성을 제공합니다.
이를 위해서는 최소 2개의 consumer로 스케일링해야 합니다.
실행 중인 consumer 수와 관계없이 장애 허용은 기본적으로 제공됩니다.
consumer 또는 이를 뒷받침하는 인프라에 장애가 발생하면,
ClickPipe가 자동으로 consumer를 다시 시작하고 메시지 처리를 계속합니다.
아래는 기준 성능을 대략적으로 파악하는 데 참고할 수 있는 ClickPipes for Kafka의 비공식 벤치마크입니다. 성능에는 메시지 크기, 데이터 타입, 데이터 포맷 등 다양한 요소가 영향을 미칠 수 있다는 점을 알아두는 것이 중요합니다. 실제 환경에 따라 결과는 달라질 수 있으며, 여기 제시된 수치가 실제 성능을 보장하는 것은 아닙니다.
벤치마크 세부 정보:
- 처리량이 ClickHouse 측 삽입 처리에 의해 병목되지 않도록, 충분한 리소스를 갖춘 프로덕션용 ClickHouse Cloud 서비스를 사용했습니다.
- ClickHouse Cloud 서비스, Kafka 클러스터(Confluent Cloud), ClickPipe는 모두 동일한 리전(
us-east-2)에서 실행되었습니다.
- ClickPipe는 L 크기의 단일 레플리카(4 GiB RAM, 1 vCPU)로 구성했습니다.
- 샘플 데이터에는
UUID, String, Int 데이터 타입이 혼합된 중첩 데이터가 포함되어 있었습니다. Float, Decimal, DateTime과 같은 다른 데이터 타입은 성능이 더 낮을 수 있습니다.
- 압축 데이터와 비압축 데이터를 사용했을 때 성능 차이는 거의 없었습니다.
