프로덕션 환경을 위한 Kafka 설정 모범 사례

Kafka는 개발 환경에서는 관대하지만 프로덕션 환경에서는 훨씬 덜 관대합니다. 하나의 복제본만 있는 토픽은 브로커가 죽을 때까지 잘 작동합니다. 약한 승인을 사용하는 프로듀서는 장애 중에 메시지가 사라질 때까지 빠르게 보입니다. 오프셋을 자동 커밋하는 컨슈머는 아직 완료되지 않은 작업을 커밋할 때까지 간단해 보입니다. 프로덕션 Kafka 설정은 주로 어떤 장애를 감수할 것인지 결정하고 그 결정을 명시적으로 만드는 것입니다.

이 가이드는 완벽한 설정 파일이 하나 있다고 가정하지 않고 프로덕션 환경을 위한 Kafka 설정 모범 사례를 다룹니다. 올바른 설정은 워크로드, 지연 시간 요구 사항, 내구성 요구 사항, 운영 성숙도 및 Kafka 버전에 따라 달라집니다. 아래 예제는 자체 트래픽에서 테스트해야 하는 시작점입니다.

주요 Kafka 구성 요소 및 설정 이해

특정 설정을 살펴보기 전에 Kafka의 핵심 구성 요소와 해당 설정이 전체 시스템 동작에 미치는 영향을 이해하는 것이 중요합니다.

브로커: 데이터를 저장하고 클라이언트 요청을 처리하는 Kafka 서버입니다. 브로커 설정은 성능, 리소스 사용률 및 내결함성을 결정합니다.
토픽: 게시되는 메시지의 카테고리 또는 피드입니다.
파티션: 토픽은 하나 이상의 파티션으로 나뉘어 처리 및 저장의 병렬 처리를 가능하게 합니다.
복제: 브로커 장애 시 데이터 내구성과 가용성을 보장하기 위해 여러 브로커에 파티션을 복사하는 프로세스입니다.
컨슈머 그룹: 토픽의 메시지를 소비하기 위해 협력하는 컨슈머 그룹입니다. Kafka는 토픽 내의 각 메시지가 각 컨슈머 그룹 내에서 최대 하나의 컨슈머에게 전달되도록 보장합니다.

토픽 및 파티션 전략

효과적인 토픽 및 파티션 설정은 Kafka의 확장성과 성능의 기초입니다.

파티션 수

올바른 파티션 수를 선택하는 것은 중요한 결정입니다. 파티션이 많을수록 컨슈머 측에서 더 높은 병렬 처리가 가능하므로 더 많은 컨슈머 인스턴스가 데이터를 동시에 처리할 수 있습니다. 그러나 너무 많은 파티션은 브로커 리소스(메모리, 디스크 I/O)에 부담을 주고 지연 시간을 증가시킬 수 있습니다. 일반적인 경험 법칙은 예상되는 최대 컨슈머 처리량을 반영하는 파티션 수로 시작하고 필요에 따라 나중에 파티션을 더 추가할 수 있다는 점을 고려하는 것입니다.

고려 사항: 브로커가 처리할 수 있는 최대 파티션 수는 메모리에 의해 제한됩니다. 각 파티션은 리더 및 팔로워 복제본을 위해 메모리가 필요합니다.
권장 사항: 컨슈머 병렬 처리 요구 사항에 맞는 파티션 수를 목표로 하지만 과도한 파티셔닝은 피하십시오. 최적의 균형을 찾으려면 브로커 리소스 사용률을 모니터링하십시오.

파티셔닝 키

메시지를 생성할 때 파티셔닝 키(종종 레코드 키)는 메시지가 기록될 파티션을 결정합니다. 일관된 파티셔닝은 컨슈머 그룹 내에서 순서가 지정된 처리를 위해 필수적입니다.

partitioner.class: 이 프로듀서 설정은 org.apache.kafka.clients.producer.internals.DefaultPartitioner(기본값, 키의 해시 사용) 또는 사용자 정의 파티셔너로 설정할 수 있습니다.
모범 사례: 메시지를 파티션 전체에 균등하게 분산시키는 키를 사용하십시오. 동일한 키를 가진 메시지를 순서대로 처리해야 하는 경우 Kafka는 파티션 내에서만 순서를 보장합니다.

복제 및 내결함성

복제는 데이터 내구성과 가용성을 보장하는 Kafka의 주요 메커니즘입니다.

복제 팩터

복제 팩터는 각 파티션의 복사본이 클러스터 전체에 유지되는 수를 결정합니다. 프로덕션 환경에서는 최소 복제 팩터 3을 적극 권장합니다.

이점: 복제 팩터가 3이면 Kafka는 일반적으로 브로커 장애를 견딜 수 있으며 다른 복제본을 사용할 수 있습니다. 정확한 가용성은 min.insync.replicas, 프로듀서 acks, 리더 선출 설정 및 어떤 브로커가 실패하는지에 따라 다릅니다.
설정: 토픽 생성 중 또는 kafka-topics.sh 명령을 통해 토픽 수준에서 설정됩니다.

# 예: 복제 팩터 3으로 토픽 생성
kafka-topics.sh --create --topic my-production-topic --bootstrap-server kafka-broker-1:9092 --replication-factor 3 --partitions 6

`min.insync.replicas`

이 브로커 설정은 쓰기 작업이 성공한 것으로 간주되기 전에 승인해야 하는 최소 복제본 수를 결정합니다. 복제 팩터가 N인 토픽의 경우 min.insync.replicas=M(여기서 M < N)으로 설정하면 M개의 복제본이 확인한 후에만 쓰기가 승인됩니다. 데이터 손실을 방지하려면 가용성 및 내구성 트레이드오프에 따라 min.insync.replicas를 일반적으로 N-1 또는 N/2 + 1로 설정해야 합니다.

권장 사항: 중요 토픽의 경우 min.insync.replicas를 replication_factor - 1로 설정하십시오. 이렇게 하면 쓰기를 승인하기 전에 (3-복제본 설정에서) 적어도 두 개의 복제본에 데이터가 있어 리더가 실패할 경우 손실을 방지할 수 있습니다.
설정: 브로커 수준 설정이며 토픽별로도 설정할 수 있습니다.

# broker.properties
min.insync.replicas=2

# 토픽 수준 설정 (브로커 설정 재정의)
# kafka-configs.sh --alter --topic my-critical-topic --bootstrap-server ... --add-config min.insync.replicas=2

리더 선출 및 컨트롤러

Kafka는 컨트롤러 브로커를 사용하여 파티션 리더십을 포함한 클러스터 상태를 관리합니다. 강력한 컨트롤러 설정은 매우 중요합니다.

controller.quorum.voters: KRaft 기반 클러스터에서 컨트롤러 쿼럼 투표자를 지정합니다. ZooKeeper 기반 클러스터는 다른 제어 평면 설정을 사용하므로 이 설정을 아키텍처 간에 맹목적으로 복사하지 마십시오.
num.io.threads 및 num.network.threads: 이러한 브로커 설정은 I/O 및 네트워크 요청 처리 전용 스레드 수를 제어합니다. 워크로드와 사용 가능한 CPU에 따라 조정하십시오.

프로듀서 및 컨슈머 설정

프로듀서 및 컨슈머 설정을 최적화하는 것은 높은 처리량과 낮은 지연 시간을 달성하는 데 중요합니다.

프로듀서 설정

acks: 복제본에 필요한 승인 수를 제어합니다. acks=all(또는 -1)로 설정하면 가장 강력한 내구성 보장을 제공합니다. min.insync.replicas와 결합하면 프로덕션에 중요합니다.
retries: 일시적인 장애가 메시지 손실로 이어지지 않도록 높은 값(예: Integer.MAX_VALUE)으로 설정하십시오. 재시도와 함께 max.in.flight.requests.per.connection을 효과적으로 사용하십시오.
max.in.flight.requests.per.connection: 브로커로 보낼 수 있는 승인되지 않은 최대 요청 수를 제어합니다. 이전 클라이언트는 재시도로 인한 재정렬을 피하기 위해 종종 1을 사용했습니다. 최신 멱등성 프로듀서는 더 높은 안전 한계로 순서를 유지할 수 있지만 클라이언트 버전과 설정을 확인하십시오.
batch.size 및 linger.ms: 이러한 설정은 메시지 배치를 제어합니다. 배치가 클수록 처리량이 향상될 수 있지만 지연 시간이 증가합니다. linger.ms는 더 많은 메시지를 함께 배치할 수 있도록 약간의 지연을 추가합니다.

# producer.properties
acks=all
retries=2147483647
max.in.flight.requests.per.connection=1
batch.size=16384
linger.ms=5

컨슈머 설정

auto.offset.reset: 프로덕션의 경우 재시작 시 이전 메시지를 다시 처리하지 않도록 latest가 선호되는 경우가 많습니다. 처음부터 메시지를 다시 처리해야 하는 경우 earliest를 사용할 수 있습니다.
enable.auto.commit: 안정적인 처리를 위해 false로 설정하십시오. 수동 커밋은 오프셋이 커밋되는 시점을 제어하여 메시지 재전송 또는 손실을 방지합니다. 명시적 커밋에는 commitSync() 또는 commitAsync()를 사용하십시오.
max.poll.records: 단일 poll() 호출에서 반환되는 최대 레코드 수를 제어합니다. 처리 부하를 관리하고 컨슈머 리밸런스를 방지하기 위해 조정하십시오.
isolation.level: Kafka 트랜잭션을 사용할 때 read_committed로 설정하여 컨슈머가 커밋된 메시지만 읽도록 합니다.

# consumer.properties
group.id=my-consumer-group
auto.offset.reset=latest
enable.auto.commit=false
isolation.level=read_committed
max.poll.records=500

보안 고려 사항

프로덕션 환경에서 Kafka 클러스터를 보호하는 것은 필수입니다.

인증 및 권한 부여

SSL/TLS: 클라이언트와 브로커 간, 그리고 브로커 간 통신을 암호화합니다. 이를 위해서는 인증서 생성 및 배포가 필요합니다.
SASL(Simple Authentication and Security Layer): GSSAPI(Kerberos), PLAIN 또는 SCRAM과 같은 SASL 메커니즘을 사용하여 클라이언트를 인증합니다.
권한 부여(ACL): 특정 사용자 또는 주체가 특정 리소스(토픽, 컨슈머 그룹)에서 특정 작업(읽기, 쓰기, 토픽 생성 등)을 수행할 수 있는지 정의하는 ACL(Access Control List)을 구성합니다.

암호화

ssl.enabled.protocols: TLSv1.2 또는 TLSv1.3과 같은 보안 프로토콜을 사용해야 합니다.
ssl.cipher.suites: 강력한 암호 제품군을 구성합니다.

설정 예제 (TLS를 통한 SASL 사용 프로듀서)

security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="myuser" password="mypassword";
ssl.truststore.location=/path/to/truststore.jks
ssl.truststore.password=password

성능 튜닝 및 모니터링

최적의 성능을 유지하려면 지속적인 모니터링과 튜닝이 필수적입니다.

브로커 튜닝

num.partitions: 토픽 수준 설정이지만 브로커는 전체 파티션 수를 처리해야 합니다. CPU, 메모리 및 디스크 I/O를 모니터링하십시오.
log.segment.bytes 및 log.roll.hours: 로그 세그먼트의 크기와 롤링 빈도를 제어합니다. 세그먼트가 작을수록 더 많은 열린 파일 핸들과 오버헤드가 증가할 수 있습니다. 세그먼트가 클수록 세그먼트당 더 많은 디스크 공간을 소비할 수 있지만 오버헤드는 줄어듭니다.
message.max.bytes: 메시지의 최대 크기(바이트)입니다. 사용 사례에 충분히 크지만 과도하게 크지 않은지 확인하십시오.
replica.fetch.max.bytes: 팔로워 복제본의 가져오기 요청당 최대 바이트 수를 제어합니다. 가져오기 효율성과 메모리 사용량의 균형을 맞추기 위해 조정하십시오.

JVM 튜닝

힙 크기: Kafka를 실행하는 JVM에 충분한 힙 메모리를 할당하십시오. 힙 사용량 및 GC 활동을 모니터링하십시오.
가비지 수집기: 적절한 GC 알고리즘을 선택하십시오(예: G1GC는 Kafka에 자주 권장됨).

모니터링

Prometheus/Grafana, Datadog 또는 Kafka 관련 모니터링 솔루션과 같은 도구를 사용하여 포괄적인 모니터링을 구현하십시오.

주요 지표: 브로커 상태, 토픽 처리량, 컨슈머 지연, 복제 상태, 요청 지연 시간 및 리소스 사용률(CPU, 메모리, 디스크, 네트워크)을 모니터링하십시오.
알림: 높은 컨슈머 지연, 브로커 응답 없음 또는 디스크 공간 소진과 같은 중요한 조건에 대한 알림을 설정하십시오.

컨슈머 그룹 리밸런스

컨슈머 그룹 리밸런스는 컨슈머가 그룹에 참여하거나 떠날 때 또는 파티션이 재할당될 때 발생합니다. 빈번한 리밸런스는 처리를 방해할 수 있습니다.

session.timeout.ms: 브로커가 컨슈머를 죽은 것으로 간주하기 전에 하트비트를 보낼 때까지 기다리는 시간입니다. 값이 낮을수록 감지가 빠르지만 네트워크 결함으로 인한 조기 리밸런스가 발생할 수 있습니다.
heartbeat.interval.ms: 컨슈머가 하트비트를 보내는 빈도입니다. session.timeout.ms보다 훨씬 작아야 합니다.
max.poll.interval.ms: 컨슈머의 poll 호출 사이의 최대 시간입니다. 컨슈머가 메시지를 처리하고 다시 폴링하는 데 이 시간보다 오래 걸리면 죽은 것으로 간주되어 리밸런스가 트리거됩니다. 컨슈머가 이 간격 내에 메시지를 처리할 수 있는지 확인하십시오.
팁: max.poll.interval.ms 내에 작업을 완료하고 느린 컨슈머로 인한 불필요한 리밸런스를 방지하도록 컨슈머 처리 로직을 최적화하십시오.

명시적으로 결정해야 할 프로덕션 기본값

중요한 Kafka 동작을 우연한 기본값에 맡기지 마십시오. 일부 기본값은 일반적인 사용에 적합하지만 프로덕션 시스템에는 데이터와 일치하는 결정이 필요합니다.

중요한 이벤트 스트림의 경우 클러스터에 이를 지원할 충분한 브로커와 랙이 있는 경우 복제 팩터 3 이상을 사용하십시오. 프로듀서의 acks=all과 3-복제본 토픽의 min.insync.replicas=2를 함께 사용하십시오. 이 조합은 리더와 동기화된 팔로워가 모두 있을 때만 쓰기가 승인됨을 의미합니다. 너무 많은 복제본이 동기화되지 않으면 프로듀서는 약한 내구성을 조용히 수락하는 대신 오류를 수신합니다.

이러한 트레이드오프는 의도적입니다. 장애 중에 내구성이 높은 토픽은 하나의 브로커에만 있는 데이터를 승인하는 대신 쓰기를 거부할 수 있습니다. 일부 시스템은 특정 텔레메트리 또는 클릭스트림 데이터에 대해 내구성보다 가용성을 선호합니다. 그것이 의식적인 선택이라면 괜찮습니다. 아무도 토픽이 그렇게 구성되었는지 깨닫지 못할 때 위험합니다.

데이터 손실이 허용되지 않는 토픽의 경우 비정상 리더 선출을 비활성화하십시오. 비정상 선출은 동기화되지 않은 복제본을 선택하여 파티션을 다시 온라인 상태로 만들 수 있지만 해당 복제본은 장애 기록 및 프로듀서 설정에 따라 승인된 레코드가 누락될 수 있습니다. 중요한 데이터의 경우 경고 없이 레코드를 잃거나 되감는 것보다 사용할 수 없는 상태를 유지하는 것이 더 나은 경우가 많습니다.

파티션 수: 처리량 및 운영을 위해 선택

파티션 수는 병렬 처리를 제어하지만 더 많은 파티션이 무료는 아닙니다. 모든 파티션은 메타데이터, 파일 핸들, 복제 작업, 리더 선출 작업 및 복구 오버헤드를 추가합니다. 또한 컨슈머 그룹 동작에 영향을 미칩니다. 200개의 파티션이 있는 토픽은 12개의 파티션이 있는 토픽보다 더 많은 컨슈머 병렬 처리를 지원할 수 있지만 브로커 재시작 및 리밸런스 중에 더 많은 움직이는 부분을 생성합니다.

컨슈머 병렬 처리 및 처리량을 추정하는 것부터 시작하십시오. 소비 서비스가 최대 12개의 인스턴스로 실행되는 경우 48개의 파티션으로 충분할 수 있습니다. 수백 개의 독립적인 처리 스레드가 예상되는 경우 더 많은 파티션이 필요할 수 있습니다. 성장 여유를 남겨두십시오. 나중에 파티션을 늘리면 키가 있는 메시지의 키 분포 및 순서 지정 동작이 변경될 수 있기 때문입니다.

순서는 파티션 내에서만 보장됩니다. customer_id=123에 대한 모든 이벤트를 순서대로 처리해야 하는 경우 해당 고객 ID를 기반으로 안정적인 키를 사용하십시오. 전체 토픽에서 순서를 기대하지 마십시오. 또한 핫 키를 주시하십시오. 한 고객, 테넌트 또는 장치가 트래픽의 많은 부분을 생성하는 경우 키 기반 파티셔닝은 다른 파티션이 유휴 상태인 동안 하나의 파티션에 과부하를 줄 수 있습니다.

멀티 테넌트 시스템의 경우 하나의 공유 토픽과 여러 테넌트 토픽 중 어느 것이 운영하기 더 쉬운지 고려하십시오. 매우 작은 토픽이 많으면 메타데이터 오버헤드가 발생할 수 있습니다. 하나의 거대한 공유 토픽은 보존, 액세스 제어 및 인시던트 대응을 복잡하게 만들 수 있습니다. 최선의 선택은 격리 요구 사항과 트래픽 형태에 따라 다릅니다.

보존은 브로커 설정일 뿐만 아니라 제품 결정입니다.

Kafka 보존은 데이터를 재생하는 데 사용할 수 있는 기간을 결정합니다. 짧은 보존은 디스크를 절약하지만 복구를 제한합니다. 긴 보존은 백필 및 감사 워크플로를 가능하게 하지만 스토리지 비용과 복구 시간을 증가시킵니다.

데이터 사용 방식에 따라 토픽별로 보존을 설정하십시오. 명령 토픽은 짧은 기간만 필요할 수 있습니다. 이벤트 기록 토픽은 며칠 또는 몇 주가 필요할 수 있습니다. 최신 상태를 나타내는 압축된 토픽은 다른 모델을 사용합니다. Kafka는 압축 후 키당 가장 최근 값과 삭제 정리까지 삭제 툼스톤을 유지합니다.

일반적인 설정은 다음과 같습니다.

retention.ms=604800000
retention.bytes=-1
cleanup.policy=delete

압축된 토픽의 경우:

cleanup.policy=compact
min.cleanable.dirty.ratio=0.5
delete.retention.ms=86400000

대용량 메시지에 주의하십시오. Kafka는 일관되게 구성될 때 더 큰 레코드를 처리할 수 있지만 message.max.bytes를 늘리면 프로듀서 max.request.size, 컨슈머 fetch.max.bytes, 브로커 복제본 가져오기 설정 및 메모리 영향을 확인해야 합니다. 많은 시스템에서 대용량 페이로드를 객체 스토리지에 저장하고 Kafka를 통해 참조를 보내는 것이 더 간단하고 안정적입니다.

고통을 피하는 프로듀서 설정

대부분의 프로덕션 프로듀서의 경우 특별한 이유가 없는 한 멱등성을 활성화하십시오. 멱등성 생산은 일시적인 장애 후 재시도로 인한 중복 쓰기를 방지하는 데 도움이 됩니다. 많은 최신 Kafka 클라이언트는 특정 구성에서 자동으로 활성화하지만 프로듀서 구성에서 결정을 표시하는 것이 좋습니다.

프로듀서 기준 예:

acks=all
enable.idempotence=true
retries=2147483647
delivery.timeout.ms=120000
request.timeout.ms=30000
linger.ms=5
batch.size=32768
compression.type=zstd

압축 선택은 CPU 예산과 Kafka 버전에 따라 다릅니다. zstd는 종종 강력한 압축을 제공하는 반면 lz4 및 snappy는 일반적인 저지연 선택입니다. 페이로드로 테스트하십시오. JSON 로그, Avro 레코드, protobuf 메시지 및 이미 압축된 바이너리 데이터는 다르게 동작합니다.

배치는 또 다른 트레이드오프입니다. 작은 linger.ms는 프로듀서가 레코드를 그룹화할 수 있는 짧은 기간을 제공하여 처리량과 압축을 향상시킬 수 있습니다. 너무 높게 설정하면 지연 시간이 추가됩니다. 사용자 대면 요청 경로의 경우 지연 시간 예산을 염두에 두십시오. 백그라운드 수집의 경우 약간 더 많은 지연이 허용될 수 있습니다.

프로듀서 오류를 무시하지 마십시오. 브로커 문제 중에 acks=all 및 min.insync.replicas가 쓰기를 거부하면 유용한 백프레셔입니다. 애플리케이션은 재시도, 버퍼링, 요청 실패 또는 대체 경로로 라우팅할지 결정해야 합니다. 오류를 기록하고 이벤트를 삭제하는 것은 내구성 전략이 아닙니다.

처리 의미 체계와 일치하는 컨슈머 설정

컨슈머 오프셋 커밋은 "처리됨"의 의미를 정의합니다. enable.auto.commit=true를 사용하면 클라이언트가 애플리케이션이 작업을 안전하게 완료하기 전에 오프셋을 커밋할 수 있습니다. 이는 일회용 분석에는 허용될 수 있지만 지불, 주문, 배포 또는 이벤트 누락이 중요한 모든 것에는 위험합니다.

안정적인 처리를 위해 자동 커밋을 비활성화하고 작업이 완료된 후 커밋하십시오.

enable.auto.commit=false
max.poll.records=500
max.poll.interval.ms=300000
session.timeout.ms=45000
heartbeat.interval.ms=15000
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor

커밋 전략은 애플리케이션에 따라 다릅니다. commitSync()는 더 간단하고 명확한 실패 동작을 제공하지만 지연 시간을 추가할 수 있습니다. commitAsync()는 처리량을 향상시킬 수 있지만 콜백 실패를 신중하게 처리해야 합니다. 많은 서비스는 성공적인 배치 후에 주기적으로 커밋하고 다운스트림 쓰기를 멱등성으로 만들어 재생이 안전하도록 합니다.

하나의 메시지를 처리하는 데 오랜 시간이 걸릴 수 있는 경우 max.poll.records를 줄이거나 max.poll.interval.ms를 늘리거나 폴 루프가 책임감 있게 계속되는 동안 내부 대기열 뒤로 느린 작업을 이동하십시오. 너무 오랫동안 폴링을 중지하는 컨슈머는 리밸런스를 트리거하고 반복적인 리밸런스는 전체 그룹을 불안정하게 보이게 만듭니다.

자주 다시 시작하지만 안정적인 ID로 돌아오는 컨슈머에는 정적 멤버십을 사용하십시오. 롤링 배포 중에 불필요한 리밸런스를 줄일 수 있습니다. 클라이언트 지원에 따라 협력적 리밸런싱은 적극적 리밸런싱에 비해 중단을 줄일 수도 있습니다.

팀이 운영할 수 있는 보안

프로덕션 Kafka는 트래픽이 신뢰할 수 없는 네트워크를 통과하거나 중요한 데이터를 전송할 때 전송 중 암호화를 사용해야 합니다. 대부분의 조직은 클라이언트-브로커 통신 및 브로커 간 통신에 TLS를 사용해야 합니다. 인증은 환경에 따라 상호 TLS, SASL/SCRAM, Kerberos, OAuth 또는 기타 지원되는 메커니즘이 될 수 있습니다.

ACL은 우발적인 손상을 방지할 수 있을 만큼 구체적이어야 합니다. orders.created용 프로듀서는 모든 토픽에 쓸 권한이 필요하지 않습니다. 청구용 컨슈머 그룹은 브로커 구성을 변경할 권한이 필요하지 않습니다. ACL을 읽기 쉽게 만드는 명명 규칙을 사용하고 서비스 주체를 개별 인간이 아닌 애플리케이션에 연결하십시오.

비밀은 교체가 필요합니다. SASL 자격 증명 또는 키 저장소가 서버에 수동으로 복사되면 교체가 고통스러워지고 결국 중단됩니다. 가능하면 플랫폼의 비밀 관리자를 사용하십시오. 롤링 클라이언트 재시작을 포함하여 스테이징에서 교체를 테스트하십시오.

또한 누가 토픽을 만들 수 있는지 결정하십시오. 자동 토픽 생성은 개발 환경에서 편리하고 프로덕션 환경에서 위험합니다. 토픽 이름의 오타는 기본 파티션, 기본 복제 및 기본 보존으로 새 토픽을 만들 수 있습니다. 많은 프로덕션 클러스터는 자동 토픽 생성을 비활성화하고 인프라 코드 또는 승인된 워크플로를 통해 토픽을 관리합니다.

브로커 및 스토리지 확인

Kafka는 디스크에 민감합니다. 예측 가능한 지연 시간이 있는 스토리지를 사용하고 디스크 사용량을 적극적으로 모니터링하며 보존, 복제 따라잡기 및 운영 실수를 위해 충분한 여유 공간을 확보하십시오. 디스크가 가득 찬 브로커는 CPU가 높은 브로커보다 훨씬 더 큰 인시던트를 만들 수 있습니다.

Kafka 로그를 관련 없는 시끄러운 워크로드와 분리하십시오. 다른 프로세스가 갑자기 I/O를 소비할 수 있는 공유 디스크에 Kafka 데이터를 두지 마십시오. 클라우드 환경에서 볼륨 처리량 제한, 버스트 크레딧 및 복구 동작을 이해하십시오. 잠시 동안 잘 벤치마킹된 디스크라도 지속적인 복제 및 압축에서 여전히 어려움을 겪을 수 있습니다.

여러 가용 영역 또는 랙이 있는 경우 랙 인식이 중요합니다. 복제본이 모두 동일한 장애 도메인에 있지 않도록 브로커 랙 ID와 토픽 배치를 구성하십시오. 하나의 랙 또는 영역 문제로 세 개의 복제본이 모두 사라지면 복제 팩터 3이 덜 유용합니다.

실제 장애를 포착하는 모니터링 및 알림

유용한 Kafka 모니터링 설정은 Kafka 내부와 클라이언트 경험을 모두 관찰합니다. 브로커 메트릭만으로는 컨슈머가 따라잡고 있는지 또는 프로듀서가 오류를 보고 있는지 알 수 없습니다.

복제 미달 파티션, 오프라인 파티션, 활성 컨트롤러 수, 요청 지연 시간, 생성 및 가져오기 오류율, 네트워크 처리량, 디스크 사용량, 디스크 I/O 지연 시간, ISR 축소 및 확장 속도, 컨트롤러 이벤트 대기열 시간, 컨슈머 지연, 리밸런스 속도 및 클라이언트 재시도/오류 수를 모니터링하십시오.

컨슈머 지연에는 컨텍스트가 필요합니다. 시간당 수백만 개를 수신하는 토픽에서 100개의 레코드 지연은 괜찮을 수 있습니다. 볼륨이 낮은 명령 토픽에서 100개의 지연은 심각할 수 있습니다. 가능하면 원시 레코드 수뿐만 아니라 지연 기간 또는 따라잡는 시간에 대해 알림을 설정하십시오.

첫 번째 실제 장애 전에 유지 관리 기간 동안 브로커 재시작을 테스트하십시오. 프로덕션 Kafka 클러스터는 데이터 손실 없이 예정된 브로커 재시작을 견디고 클라이언트를 놀라게 하지 않아야 합니다. 하나의 브로커 재시작이 주요 인시던트를 생성하는 경우 클러스터는 이미 취약했습니다.

프로덕션 준비 확인

Kafka 클러스터를 프로덕션 준비가 되었다고 부르기 전에 다음 항목을 확인하겠습니다.

중요 토픽에는 명시적인 파티션, 복제 팩터, 보존, 정리 정책 및 min.insync.replicas가 있습니다.
중요 토픽의 프로듀서는 acks=all, 지원되는 경우 멱등성, 재시도 및 명확한 오류 처리를 사용합니다.
컨슈머는 애플리케이션이 의도한 처리 지점에 도달한 후에만 오프셋을 커밋합니다.
TLS, 인증 및 ACL이 활성화되고 테스트되었습니다.
자동 토픽 생성이 비활성화되었거나 엄격하게 제어됩니다.
모니터링은 브로커 상태, 클라이언트 오류, 컨슈머 지연, 디스크 및 복제를 다룹니다.
백업 또는 재생 기대치가 문서화되어 있습니다. Kafka 보존은 모든 백업 요구 사항을 대체하지 않습니다.
브로커 재시작, 클라이언트 배포 및 자격 증명 교체 절차가 테스트되었습니다.

실용적인 요점

Kafka 프로덕션 설정은 보편적인 레시피가 아니라 일련의 트레이드오프입니다. 내구성, 순서, 재생, 보안 및 지연 시간 선택을 토픽 및 애플리케이션별로 명시적으로 만드십시오. 그런 다음 프로덕션 트래픽이 교훈을 가르치기 전에 브로커 재시작, 클라이언트 장애, 느린 컨슈머 및 디스크 가득 참 시나리오로 해당 선택을 테스트하십시오.