Kafka 심화 개념 - 3

3-1. Apache Kafka and Confluent Reference Architecture

 

Confluent에서 제공하는 Confluent Platform Reference Architecture

참조 아키텍처 및 환경 별 참조 HW 사양

 

Large Cluster Reference Architecture

 

Small Cluster Reference Architecture

> Zookeeper와 Broker를 같이 구성

 

Large Cluster용 HW 권장 사양

> Connect 올라가면 CPU 사용량은 올라감. 여기서는 구축 시 권장 사양일 뿐.

 

Small Cluster용 HW 권장 사양

 

Public Cloud Deployment(AWS, MS Azure, Google Cloud Platform) 사용 시 유의점

> Core: Cloud Provider는 시스템 크기 조정시 가상 Core 사용. 일반적으로 데이터 센터에서 사용하는 최신 코어보다 성능 낮을 수도.

> Network: 대부분의 Cloud Provider는 최상위 계층 노드에서만10GbE 사용

> On-Premises 환경 설치 시 HW 사양을 Public Cloud 환경에서도 권장

 

AWS EC2 최소 사양

 

Google Cloud Compute Engine 최소 사양

 

Kafka Sizing을 위한 도구

> Eventsizer - Sizing Calculator

 

3-2. Kafka In Real Environment

 

Broker 설치 구성 > 전용 서버 권장

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

> N개의 Broker가 있으면 Replication Factor(RF)는 최대 N개까지 사용하여 Topic 생성가능

> Mission Critical Topic에는 Replication Factor는 보통 3 사용

 -> Broker는 4개 이상 하나의 Cluster로 구성하는 것 권장

> 데이터 유실방지를 위해 min.insync.replicas는 2를 많이 사용

 

Broker CPU : 처리량에 따라 Thread 관련 파라미터 튜닝 필수

> Thread 증가에 따라 CPU 사용량 증가

> 설정 잘못하거나 메모리 충분하지 않거나 Bug로 인해 CPU 사용률 높을 수 있음

> Reference Architecture에는 Dural 12-core sockets 권장

 

Broker 파라미터

 

Open File Descriptors

> Broker는 File을 많이 사용함

 

Broker Memory > JVM Heap + OS Page Cache

> JVM Heap많이 사용하지 않음

> 운영환경의 경우 대부분 6GB 할당(Heap)

> 매우 큰 Cluster이거나 많은 파티션 필요하면 12GB(Heap)

> OS만을 위해서는 보통 1GB 할당

> Broker는 OS Page Cache로 Zero copy 전송 수행, 많을수록 성능 유리

> 운영환경용 Broker 메모리는 최소 32GB~64GB 권장

 

Broker Java Heap Mamory 설정 방법

> Kafka-server-start 스크립트에 설정 옵션 있음

> $KAFKA_HEAP_OPTS 등

 

Broker Network

> 전체 처리 메시지(복제 포함)가 네트워크 통해 전달

> 처리량이 작은 경우, Broker의 NW은 1GB 충분

> 처리량이 큰 경우, Broker의 NW은 10GB 이상 필요

> Producer의 압축옵션으로 네트워크 효율적 사용 가능

> Internal 과 External 트래픽 간 분리 가능

 

Broker Disk

> Kafka 성능에 큰 영향을 미치는 요소(Disk,Network)

> Kafka Broker의 data log용 Disk는 Os용 Disk와 분리 권장

> 여러개의 Local Disk 사용 권장(RAID10 권장, JBOD 사용 가능)

> SSD Disk 권장

> XFS 파일시스템 사용

> mount 시에 noatime 옵션 사용 - Linux가 각 파일에 마지막으로 액세스한 시간기록하는 파일 시스템의 메타데이터 유지관리방식 off

> Broker 파라미터 중 log.dirs에 콤마로 구분한 디렉토리로 정의

> 하나의 파티션은 하나의 볼륨에서 생성됨

> 파티션들은 Log.dirs의 디렉토리에 라운드로빈방식 분배

> NAS(Network Attached Storage) 사용 불가

 

Virtual Memory

> Kafka 성능에 큰 영향

 

Zookeeper 권장 사양

> 홀수 개로 구성

> HW 권장 사양

 

Zookeeper Disk - Auto Purge 옵션

> server.properties 내의 purge snapshots 파라미터 설정

 

3-3. Installation, Cluster Configuration

 

설치 환경 정보

> Confluent Platfrom(CP)사용

> Ubuntu 18.04

> Production 환경(Zookeeper 3, Broker 3, Control Center 1)

> Open JDK 혹은 OracleJDK 1.8/1.11 사용 가능

Control center : Kafka 모니터링 및 관리를 위한 Web UI 도구

 

OS 구성

> Linux 계정 생성 (root 사용 지양)

> JDK 구성(설치 및 환경변수 추가)

 

Confluent Platform 다운하여 Linux 계정의 홈 디렉토리에서 압축 풀고 환경변수 추가

 

Zookeeper Node 구성

> ${CONFLUENT_HOME}/etc/kafka/zookeeper/properties

 

Broker Node 구성

> ${CONFLUENT_HOME}/etc/kafka/server.properties

 

Control Center Node 구성

> ${CONFLUENT_HOME}/etc/confluent-control-center/control-center-production.properties

 

Confluent platform 실행

> 항상 이렇게 실행시킬 수 없어 nohup 스크립트 실행

 

3-4. Log Retention, Cleanup policy

 

Log 파일 관리 : Log Cleanup Policy

> Log는 Consume되어도 지우지 않음

> Broker 혹은 Topic 단위로 Cleanup 정책 설정

> log.cleanup.policy 파라미터

> 현재 Active Segment의 log는 cleanup 대상 아님

 

Delete Cleanup Policy

> Log Cleaner Thread가 Segment File 삭제

 

Topic의 메시지 모두 삭제하기

> retention.ms 활용 (운영환경에서는 권장하지 않음)

 

Compact Cleanup Policy

> 주어진 key의 최신 value만 유지하는 정책

 

Log Compaction - 시스템 오류 후 상태 복원 시 유용

 

Log Compaction 동작 원리

 

Log Compaction 설정

> Compaction 성능 튜닝 관련 옵션

 

Tombstone Message

> Log Compaction시 특정 key 데이터 삭제

 

3-5. Kafka Cluster Expansion, Shrink

 

Kafka Cluster 확장

> 고유한 ID 부여하여 새로운 Broker를 Zookeeper Ensemble에 연결만 하면 됨

> 자동으로 파티션을 새로운 Broker로 옮겨주지는 않음

  -> kafka-reassign-partitions 도구 또는

  -> confluent Auto Data Balancer/Self-Balancing Cluster 기능 사용하여 해결

 

kafka-reassign-partitions 명령

> 리밸런싱을 직접 계산해서 Topic별 실행해야 함

 

Confluent ADB

> Broker 전체에 대한 파티션 리밸런싱 자동화

> 한번에 하나의 리밸런싱만 가능

> 시스템 자원 많이 사용 - Throttle(bytes/sec) 옵션으로 제어

> Cluster내의 전체 브로커가 살아 있을 때만 실행됨

> 파티션 이동 - Replica를 생성 후 기존 Replica 삭제 하는 방식 (Disk 사용률 증가)

 

Kafka Cluster 축소

> Cluster 사용률이 낮아서 비용 아끼기 위해 축소

> Broker 장비에 대한 유지보수 등

 

Broker 해제 방법

> Auto Data Balancer 또는 kafka-reassign-partition 사용하여 제거할 브로커의 파티션들을 다른 브로커에 재할당

> kafka-reassign-partition: 브로커의 파티션들 수작업으로 옮기기

> Auto Data Balancer: —remote-broker-ids 옵션으로 제거할 브로커 지정하여 파티션 재할당

> 제거한 브로커를 Controlled Shutdown(kafka-server-stop) 실행

> Self-Balancing Cluster는 kafka-remove-brokers 명령으로 가능

 

Broker 장비 교체

> 교체 대상 브로커의 ID만 동일하게 설정하고 새로운 브로커 가동

> 주의점: 피크 시간 피해서 수행

  > 이유: 브로커는 Recovery 중에 가능한한 빨리 데이터를 복사. 이는 네트워크에 중요한 impact 발생 가능.