DevOps 지식 허브
DevOps 지식 허브

운영 환경을 위한 Kafka 구성 모범 사례

이 가이드는 운영 환경을 위한 필수적인 Kafka 구성 모범 사례를 제공합니다. 토픽 및 파티션 전략 최적화 방법, 강력한 복제 및 내결함성 구현 방법(여기에는 `min.insync.replicas` 포함), SSL/TLS 및 ACL을 사용한 클러스터 보안 강화 방법, 최적의 성능을 위한 프로듀서/컨슈머 설정 조정 방법을 알아보세요. 안정적이고 확장 가능한 이벤트 스트리밍 플랫폼을 보장하기 위한 주요 모니터링 지표 및 전략을 확인하십시오.

51 조회수

프로덕션 환경을 위한 Kafka 구성 모범 사례

Apache Kafka는 실시간 데이터 파이프라인 및 스트리밍 애플리케이션 구축을 위한 사실상의 표준이 되었습니다. 분산된 특성, 내결함성 및 높은 처리량은 미션 크리티컬한 프로덕션 환경에 이상적입니다. 그러나 Kafka를 배포하는 것만으로는 충분하지 않습니다. 안정성, 확장성 및 최적의 성능을 보장하려면 적절한 구성이 매우 중요합니다. 이 문서는 토픽 관리, 복제, 보안 및 성능 튜닝과 같은 주요 영역을 다루며, 프로덕션 배포에 맞춰진 필수 Kafka 구성 모범 사례를 간략하게 설명합니다.

프로덕션을 위해 Kafka를 구성하려면 Kafka 아키텍처와 애플리케이션의 특정 요구 사항에 대한 깊은 이해가 필요합니다. 잘못된 구성은 데이터 손실, 성능 병목 현상 및 시스템 불안정으로 이어질 수 있습니다. 확립된 모범 사례를 준수하면 까다로운 워크로드를 처리하고 비즈니스 요구 사항에 따라 발전할 수 있는 강력하고 탄력적인 Kafka 인프라를 구축할 수 있습니다. 이 가이드는 이러한 목표를 달성하는 데 도움이 되는 중요한 구성 측면을 안내합니다.

주요 Kafka 구성 요소 및 구성 이해하기

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

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

토픽 및 파티셔닝 전략

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

파티션 수

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

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

파티셔닝 키

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

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

복제 및 내결함성

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

복제 계수(Replication Factor)

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

  • 이점: 복제 계수가 3이면 Kafka는 브로커가 최대 두 개까지 실패하더라도 데이터 손실 없이 또는 서비스 중단 없이 내결함성을 유지할 수 있습니다.
  • 구성: 이는 토픽 생성 시 또는 kafka-topics.sh 명령을 통해 토픽 수준에서 설정됩니다.
    bash # 예시: 복제 계수 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개 복제본 설정에서)이 데이터를 가지고 있음을 보장합니다.
  • 구성: 이는 브로커 수준 구성이며 토픽별로 설정할 수도 있습니다.
    ```properties
    # 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: 컨트롤러 쿼럼에 대한 broker_id:host:port 목록을 지정합니다. 이 목록이 정확하고 안정적인지 확인하십시오.
  • 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: 브로커로 전송될 수 있는 승인되지 않은 최대 요청 수를 제어합니다. 재시도 중 메시지 순서가 바뀌는 것을 방지하기 위해 acks=all의 경우 이 값을 1로 설정해야 합니다.
  • batch.size 및 linger.ms: 이 설정은 메시지 일괄 처리를 제어합니다. 더 큰 일괄 처리는 처리량을 향상시키지만 지연 시간을 증가시킵니다. linger.ms는 더 많은 메시지를 일괄 처리할 수 있도록 약간의 지연을 추가합니다.
    properties # 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로 설정합니다.
    properties # 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 메커니즘을 사용합니다.
  • 권한 부여(ACLs): 액세스 제어 목록(ACL)을 구성하여 어떤 사용자 또는 주체가 어떤 리소스(토픽, 컨슈머 그룹 등)에 대해 특정 작업(읽기, 쓰기, 토픽 생성 등)을 수행할 수 있는지 정의합니다.

암호화

  • ssl.enabled.protocols: TLSv1.2 또는 TLSv1.3과 같은 보안 프로토콜을 사용하고 있는지 확인하십시오.
  • ssl.cipher.suites: 강력한 암호화 스위트를 구성하십시오.

구성 예시(SSL/SASL_PLAINTEXT를 사용하는 프로듀서)

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: 팔로워 복제본의 최대 가져오기(fetch) 요청당 바이트 수를 제어합니다. 가져오기 효율성과 메모리 사용량 간의 균형을 맞추도록 조정하십시오.

JVM 튜닝

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

모니터링

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

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

컨슈머 그룹 재조정(Rebalances)

컨슈머 그룹 재조정은 컨슈머가 그룹에 참여하거나 떠나거나 파티션이 재할당될 때 발생합니다. 잦은 재조정은 처리를 방해할 수 있습니다.

  • session.timeout.ms: 브로커가 컨슈머가 죽었다고 간주하기 전에 하트비트를 보낼 때까지 기다리는 시간입니다. 값이 낮을수록 감지는 빠르지만 네트워크 결함으로 인해 조기 재조정이 발생할 수 있습니다.
  • heartbeat.interval.ms: 컨슈머가 하트비트를 보내는 빈도입니다. session.timeout.ms보다 훨씬 작아야 합니다.

  • max.poll.interval.ms: 컨슈머의 poll() 호출 간 최대 시간입니다. 컨슈머가 메시지 처리를 완료하고 다시 폴링하는 데 이 시간보다 오래 걸리면 죽은 것으로 간주되어 재조정이 트리거됩니다. 컨슈머가 이 간격 내에서 메시지를 처리할 수 있는지 확인하십시오.

  • 팁: 컨슈머 처리 논리를 최적화하여 max.poll.interval.ms 내에서 작업을 완료하고 느린 컨슈머로 인한 불필요한 재조정을 피하십시오.

결론

프로덕션을 위한 Kafka 구성은 세심한 계획, 세부 사항에 대한 주의 및 지속적인 모니터링이 필요한 지속적인 프로세스입니다. 이 문서에서 설명한 모범 사례(적절한 파티셔닝, 강력한 복제 전략, 강력한 보안 조치 및 성능 튜닝된 프로듀서/컨슈머 설정에 중점)를 구현함으로써 매우 안정적이고 확장 가능한 이벤트 스트리밍 플랫폼을 구축할 수 있습니다. 이러한 권장 사항을 특정 워크로드에 맞게 조정하고 클러스터 성능을 면밀히 모니터링하여 정보에 입각한 조정을 수행하는 것을 잊지 마십시오.