1D1DL

Confluent에서 제공하는 Confluent Platform Reference Architecture는 kafka 구성시 참조 아키텍처들을 정리해놓았다.

https://www.confluent.io/resources/apache-kafka-confluent-enterprise-reference-architecture/?test=hushlylp&var=original

에 들어가서 Download Reference Architecture 를 클릭하고 문서를 다운 받으면 된다.

Large Cluster Reference Architecture

높은 처리량의 장기적인 확장성을 위해 구축된 Confluent Platform 클러스터 아키텍처이다. 확장성을 위해 구축되었다 보니 각 서비스가 각각의 서버를 구성하고 있다. Zookeeper node 도 5개 정도로 많이 사용하고 있다. Zookeeper와 broker를 완전히 분리시켜서 broker 전용 서버를 사용하고 있다.

Small Cluster Reference Architecture

Confluent Platform의 채택 초기 단계에서 주로 사용하는 아키텍처이다. Broker node들을 zookeeper와 같이 설치해서 사용하는 것이 작은 클러스터를 구성할 때 많이 사용하는 방법이다. connector나 replicator 등을 하나의 장비에서 관리한다.

Hardware Recommendations for On-Premises Deployment

데이터 센터 위에서 kafka를 deploy 할 때의 하드웨서 구성 추천에 대해 알아본다.

Large Cluster

Small Cluster

Public Cloud Deployment

AWS EC2 최소 사양

이번에는 kafka를 실제 운영환경에서 어떻게 사용하면 좋을지 살펴본다.

Broker

Broker 설치 구성

Broker는 분리된 각각의 전용 서버에 분리하여 설치 구성하는 것을 권장한다.

N개의 Broker가 있으면, Replication Factor(RF)는 최대 N까지 사용하여 Topic 생성 가능
- Mission Critical Topic에는 Replication Factor는 보통 3 을 많이 사용
- 3 개의 Broker로 구성하고 하나의 Broker가 장애 상태시, RF 3인 Topic 생성 불가능
- 따라서, Broker는 4 개 이상 하나의 Cluster로 구성하는 것을 권장
데이터 유실 방지를 위해서, min.insync.replicas는 2 를 많이 사용
- 3 개의 Broker로 구성하고 1 개의 Broker가 장애 상태시, Topic에 Write는 가능
- 1 개의 Broker가 추가로 장애시, 데이터 유실의 가능성이 높아짐
- 따라서, Broker는 4 개 이상 하나의 Cluster로 구성하는 것을 권장

Broker CPU

Broker는 CPU를 많이 사용하지는 않으나, 처리량에 따라서 Thread 파라미터 튜닝이 필요하며, Thread 증가에 따라 CPU 사용량이 증가한다.

설정을 잘 못 하거나, 메모리가 충분하지 않거나, Bug로 인해 CPU 사용률이 높을 수도 있음
Reference Architecture에서는 Dual 12-core Sockets를 권장
Broker 파라미터
- num.io.threads (기본값 : 8) : Disk 개수보다 크게 설정
- num.network.threads (기본값 : 3) : 암호화를 사용할 경우 두 배 이상으로 설정
- num.recovery.threads.per.data.dir (기본값 : 1) : Broker 시작시 빠른 기동을 위해서 core수까지만 설정
- num.replica.fetchers (기본값 : 1) : Leader Broker에서 메시지를 복제하는데 사용되는 Thread 수. 빠르게 복제하기 위해 값을 증가(Latency를 만족하는). Broker의 CPU 사용률과 네트워크 사용률이 올라감, 보통4~6개 값을 많이 사용함.
- num.cleaner.threads (기본값 : 1) : Disk 개수 혹은 core 개수까지만 설정

Open File Descriptors

Broker는 많은 수의 parotition을 지원하고, client들이 많이 붙기 때문에 file을 많이 사용한다. 따라서 Broker는 많은 수의 Partition을 지원하므로 상대적으로 소규모 배포에서도 Open File Handle 수가 기본값을 쉽게 초과할 수 있다.

최소
- ulimit ‒n 100000

Broker Memory

Broker의 메모리는 OS Page Cache를 많이 사용한다. OS Page Cache를 통해서 Zero Copy 전송을 수행해서 빠르게 네트워크 버퍼에 있는 데이터를 디스크로 내린다. OS Page Cache는 많으면 많을수록 성능에 유리하다.

운영환경용 Broker 메모리는 최소 32 GB 이상 권장하며, 처리량에 따라서 64 GB 이상 사용 권장
매우 큰 Cluster 혹은 매우 많은 Partition이 필요한 경우 12 GB 이상 사용
Broker의 OS만을 위해서는 보통 1 GB 정도 할당

Broker Network

메세지는 복제본을 포함해서 네트워크를 통해 전달된다.

처리량이 작은 Application일 경우, Broker의 NW은 1 Gigabit(Gb) 으로 충분
처리량이 큰 Application일 경우, Broker의 NW은 10 Gigabit(Gb) 이상 필요
Producer에서 압축 옵션을 사용하면 네트워크를 보다 효율적으로 사용 가능
Internal 과 External 트래픽 간 분리 가능 https://cwiki.apache.org/confluence/display/KAFKA/KIP-103%3A+Separation+of+Internal+and+External+traffic

Broker Disk

Kafka Broker의 data log 용 Disk는 OS 용 Disk와 분리 권장한다.

Broker의 data log용으로 여러 개의 Local Disk 사용을 권장(RAID10 권장, JBOD 사용 가능)
Broker의 파라미터 중 log.dirs 에 콤마(,)로 구분한 디렉토리들로 정의
SSD Disk를 권장
XFS 파일시스템을 사용해야 함
mount시에 noatime 옵션 사용 - Linux가 각 파일에 마지막으로 액세스한 시간을 기록하는 파일 시스템 메타데이터를 유지 관리하는 방식을 off (켜두면 업데이트에 많은 시간을 소요)
하나의 Partition은 하나의 volume에서 생성됨
Partition들은 log.dirs 의 디렉토리에 round-robin 방식으로 분배
NAS 사용 불가

Virtual Memory

Memory swapping 최소화
- vm.swappiness=1 (기본값 : 60)
Blocking Flush (synchronous) 빈도 감소
- vm.dirty_ratio=80 (기본값 : 20)
Non-Blocking background flushes (asynchronous) 빈도 증가
- vm.dirty_background_ratio=5 권장(기본값 : 10)
이 파라미터들은 /etc/sysctl.conf 에 설정하고 sysctl -p 명령어로 Load함

Zookeeper

Zookeeper 하드웨어 권장 사양

홀수 개로 구성
최소 2 Core ‒ 권장 4 Core
Memory 8 GB
Transaction log (dataLogDir) 512 GB SSD
Database snapshots (dataDir) 2 TB SSD RAID 10

Zookeeper Disk

ZooKeeper 의 server.properties 내의 purge snapshots 파라미터를 설정한다.

권장 옵션은 24 시간마다 3 개를 제외한 모든 스냅샷을 제거하는 설정
- autopurge.snapRetainCount : 보존할 SnapShot 개수(권장 3)
- autopurge.purgeInterval : Purge Interval(권장 24)
미션 크리티컬 시스템의 경우에는 3-5개 Zookeeper 노드에 추가 스토리지를 사용하여 보존할 SnapShot 수를 조정하는 경우도 있음