7.1 안정적인 운영을 위한 카프카 구성
- 카프카 애플리케이션이 워낙 안정적이라 일반적으로 클러스터 구성 후 신경을 쓰지 않는 경우도 많다.
- 하지만 초기부터 꼼꼼하게 SPOF를 제거하고 클러스터를 구성하여 더 안정적인 운영을 할 수 있다.
7.1.1 주키퍼 구성
- 카프카에서 주키퍼의 역할
- 파티션과 브로커의 메타데이터를 저장
- 컨트롤러 서버의 선출
- 하지만 카프카 오픈소스 진영에선 주키퍼 의존성을 제거하려고 했고 4.0 버전부터는 주키퍼 없이 카프카를 이용할 수 있게 되었다.
KRaft
https://kafka.apache.org/documentation/
“Apache Kafka 4.0 only supports KRaft mode - ZooKeeper mode has been removed.”
(Apache Kafka 4.0은 KRaft 모드만 지원하며, ZooKeeper 모드는 제거되었습니다)
- KRaft란?
- KRaft(Kafka Raft)는 카프카에서 주키퍼를 대체하기 위해 도입된 분산 합의(protocol) 및 메타데이터 관리 체계이다.
- Raft 합의 알고리즘을 기반으로 카프카 클러스터의 메타데이터 관리, 리더 선출, 데이터 일관성 보장을 담당
- KRaft가 하는 역할
- 카프카 클러스터 메타데이터 관리(브로커, 토픽, 파티션 정보 등)
- 컨트롤러 리더 선출 및 클러스터 제어 권한 조정
- 분산 시스템에서의 데이터 일관성 보장(Raft 알고리즘 사용)
- 카프카 클러스터 구성 변경 및 상태 동기화
- KRaft가 주키퍼 모드 대비 갖는 장점
- 주키퍼 별도 클러스터 운영 필요 없어져서 시스템 구조가 훨씬 단순해짐
- 메타데이터 변경 속도 및 확장성 크게 향상됨
- 운용 난이도 하락: 주키퍼와 카프카 각각 관리할 필요 없어짐
- 장애 발생 시 복구 및 장애 지점 명확해서 트러블슈팅 쉬워짐
- 클러스터 관리하는 복잡한 작업(리더 선출, 컨트롤러 장애 복구 등)이 내부적으로 자동 처리됨
- 새로운 클러스터 도입, 이관, 버전 업그레이드 작업이 쉽게 가능해짐
- 전체 시스템의 안정성 및 신뢰성 강화됨 (Raft 베이스 합의 프로토콜로 일관성 보장)
7.1.2 카프카 구성
카프카 서버 수량
- 카프카 클러스터를 최소로 구성하기를 원한다면 3대의 브로커를 권장한다.
- 카프카가 추천하는 안정적인 리플리케이션 팩터 수인 3으로 토픽을 구성하기 위함이다.
- 카프카의 서버 확장은 쉽기 때문에 현재 꼭 필요한 수량만큼 구성하는 편이 좋다.
카프카 하드웨어
- CPU
- 고성능 CPU를 고집할 필요는 없지만 코어 수가 많은 CPU로 구성할 것을 권장한다.
- 프로듀서나 컨슈머 처리량 향상을 위한 배치와 압축으로 인해 CPU 사용률이 높기 때문
- 메모리
- 128GB, 256GB 또는 조금 더 타이트하게 운영한다면 최소 32GB 이상 구성하는 것을 추천한다.
- 카프카에서 요구하는 JVM 힙 크기가 일반적으로 6GB
- 힙 크기 말고도 나머지 물리 메모리는 모두 페이지 캐시로 사용해 빠른 처리를 돕고 있기에 어느 정도 메모리 여유가 필요한 것
- 디스크
- 여러 선택지가 있지만 성능이 가장 낮은 SATA 디스크도 괜찮은데 이는 로그 마지막에 순차적으로 쓰는 방식으로 로그를 기록하기 때문
- 다만 브로커 한 대의 디스크를 사용하는 것이 아닌 병렬 처리를 위해 서버에 약 10개 정도 디스크를 장착한다.
- 토픽 파티션 로그가 가득 차는 것을 방지하기 위해 토픽 보관 주기를 충분하게 설졍하려면 4TB 용량 이상의 디스크를 선정하는 것을 추천한다.
- AWS EC2의 EBS는 안정적이다.
- 네트워크 카드
- 10G 이더넷 카드로 구성하는 것을 추천
- 브로커 한 대당 네트워크 사용량 비율이 50%가 넘지 않도록 최대한 토픽을 분산해 운영해야 한다.
카프카 배치
- 모든 카프카 서버를 하나의 랙에 마운트하는 것은 위험하기에 여러 랙에 분산시켜 배치하는 것을 추천한다.
- AWS에 카프카를 구성하는 경우 멀티 가용 영역으로 구성하는 것을 추천한다.