[Kafka]주키퍼(Zookeeper), 카프카(Kafka) 설치전 알고가기

in etc on Kafka


이 글은 카프카, 데이터 플랫폼의 최강자 고승범/공용준 님의 책을 공부하며
정리하는 글입니다.

[Kafka]주키퍼(Zookeeper), 카프카(Kafka) 설치전 알고가기

설치에 앞서서 주의사항을 알아보자

설치 전 주의사항

  • 카프카와 주키퍼를 동일한 서버에 같이 운영해도 될까?
    • 가능하지만, 소규모 환경에서 사용하고 대규모로 카프카를 운영하는 환경에서는 좋은 방법이 아니다.
    • 카프카는 클러스터 3대로 구성했을 때 2대가 다운되어도 서비스가 가능하지만,
    • 주키퍼는 앙상블을 3대로 구성했을 때 2대가 다운되면 과반수에 미치지 못하기 때문에 장애가 발생한다.
    • 카프카가 문제가 없더라도, 주키퍼가 코디네이션 역할을 못하는 경우 통신 장애 발생.

  • 결론은 주키버 서버와 카프카 서버를 별도로 나눈다.

  • 주키퍼는 몇개? 카프카는 몇개? 설정해야 할까?
    • 과반수 이상 운영되어야 하는 방식인 주키퍼는 3대 이상의 홀수로 구성.
    • 주키퍼는 다운이되어도 과반수 이상이 살아있으면 서비스가 가능하다.
    • 카프카는 3대 이상 자유구성.


주키퍼를 사용하는 자바 애플리케이션 주의사항

  • 자바 애플리케이션들이 간혹 메모리를 전부 사용하는 경우 풀CG 발생.
    • 풀GC: Full Garbage Collection
  • 자바 애플리케이션의 주키퍼 세션 타임아웃 설정을 짧게 하면 GC타임으로 인해 노드가 다운된 것으로 간주.
    • 그렇기 때문에 GC타임을 주기적으로 체크하고, 세션 타임아웃 설정도 3초 이상을 권장.


주키퍼(Zookeeper) 초기 셋팅 팁

Hardware

- 다양한 비즈니스 요구 사항을 고려한 결정

Memory : znode 크기에 따라 관련이 있고, 일반적인 환경에서는 최소 8GB RAM을 전용으로 사용한다. 왜냐하면 Zookeeper가 주어진 시간에 모든 znode 내용을 메모리에 보유하기 때문이다.

CPUs : 주키퍼는 카프카의 메타데이터 저장소로서 CPU를 많이 소비하지는 않는다.

Disk : 주키퍼 앙상블을 유지 관리하는데 중요하다. IO가 빈번히 일어나므로 SSD를 선택하는 것이 탁월하고, 일반적으로 최소 64GB ~ 250GB 로 잡아둔다. 또한 스냅샷 및 로그 디렉토리의 자동 제거 정책에 대한 구성을 설정하여 모든 로컬 스토리지를 채우지 않도록하는 것이 좋다.

JVM : 주키퍼는 JVM으로 실행되기 때문에 모니터링에 1GB의 힙 크기가 권장된다.

참고
https://docs.confluent.io/current/zookeeper/deployment.html
카프카 데이터 플랫폼의 최강자


카프카(Kafka) 셋팅 팁

Hardware

  • 카프카의 일부(설정의 경우 제외)를 제외하고 모든 데이터는 파일 시스템에 영구적인 로그형태로 즉시 기록된다.

Memory : kafka는 힙 공간을 주의해서 사용하기 때문에 힙 크기를 5GB 이상 설정 안해도 된다. 참고글을 보면 32GB memory machine이 28~30GB의 이상의 파일 시스템 캐시 결과를 냈다고 한다. 32GB 선택은 좋지만 비생산적인 경향이 있습니다 (결국 많은 소형 기계가 필요합니다)

CPUs : kafka는 CPU에 대한 요구사항은 높지 않다. 다만 SSL을 사용하게 된다면 CPU의 요구 사항이 높아질 수 있다. -> 현재 프로젝트에서는 SSL 사용이 무의미할 듯 싶다. 권장 24core.

Disk : 쓰기 처리량과 디스크 장애시 어레이 재구성의 I/O 비용이 적기 때문에 RAID 5 또는 RAID 6을 권장하지 않는다. 일반적으로 재구성 비용은 RAID에 적용되지만 그것은 RAID 6와 RAID 5에서 최악). 추가 비용이 허용되는 경우 RAID 10을 사용하는 것이 좋다

Filesystem : XFS 또는 ext4에서 Kafka를 실행하는 것이 좋다.

일반적으로 고려해야할 사항: 수십 개의 CPU 코어, 수 백 기가바이트의 RAM을 갖춘 머신과 EC2와 같은 클라우드 플랫폼에서 수천 개의 작은 가상 시스템. 어떤 구성이 좋은 구성일까?

  • 일반적으로 medium-to-large box를 선호하는 것이 좋다. 수 천개의 클러스터를 관리하고 싶지 않으므로 작은 머신을 피해야한다. 이는 명백하게 Kafka를 운영하는데 있어서 오버헤드가 커진다.

  • 하지만 정말 고성능의 기계는 피해라. 리소스가 불균형 해지면, 예를 들어, 모든 메모리가 사용되지만 CPU는 사용되지 않습니다. 시스템 당 여러 개의 노드를 실행해야하는 경우 병목 현상을 추가할 수 있다.

JVM

  • 최신 버전의 JDK 1.8을 G1 콜렉터와 함께 실행하는 것이 좋다.

서버의 수

  • 예상 메시지 크기 * 초당 예상 메시지 수를 가져 와서 카프카 클러스터에서 메시지를 사용할 수있는 시간 (초)을 곱하자.
  • 그런 다음 복제 팩터 (예 : 중복성)를 선택하는 것에 따라서 이 크기를 두 개 이상으로 늘리고, 클러스터에 몇 명의 브로커를 둘 것인지 나누자.
  • 이렇게하면 브로커마다 필요한 하드 드라이브 공간이 얼마나되는지 알 수 있다.

참고
https://docs.confluent.io/current/kafka/deployment.html#hardware
http://sori-nori.gitlab.io/docs/Kafka-Operations/

용어 정리
디스크 캐시 : 하드디스크에 접근하는 시간을 개선하기 위해서 메모리에 저장하는 기법
캐시 메모리 : 램에 접근하지 않고 캐시를 이용하여 더 빠른 시간으로 접근가능한 메모리
SSL : 네트워크 내에서 메시지 전송의 안전을 관리하기 위해 넷스케이프에 의해 만들어진 프로그램 계층(Layer)