CHAPTER2. 카프카 설치하기

2.1 환경설정

2.1.1 운영체제 선택하기

• 책은 리눅스 기반 설명

2.1.2 자바 설치하기

• OpenJDK 기반 자바 구현체 위에서 원활히 작동

2.1.3 주키퍼 설치하기

아파치 카프카는 카프카 클러스터의 메타데이터와 컨슈머 클라이언트에 대한 정보를 저장하기 위해 아파치 주키퍼를 사용한다. 주키퍼는 설정 정보 관리, 이름 부여, 분산 동기화, 그룹 서비스를 제공하는 중앙화된 서비스이다.

• 독립 실행 서버
• 주키퍼 앙상블
  • 주키퍼는 고가용성을 보장하기 위해 앙상블이라 불리는 클러스터 단위로 작동하도록 설계되었다. 부하 분산 알고리즘 때문에 앙상블은 홀수 개의 서버를 가지는 것이 권장된다. 앙상블 멤버(쿼럼)의 과반 이상이 작동하고 있어야 하기 때문이다.

<aside> 💡

주키퍼 앙상블 크기 결정하기

주키퍼 앙상블을 구성할 때는 5개의 노드 크기를 고려하자.(장비 교체를 포함해서) 앙상블 설저을 변경할 수 있게 하려면, 한 번에 한 대의 노드를 정지시켰다가 설정을 변경한 뒤 다시 시작해야 한다. 만약 앙상블이 2대 이상의 노드 정지를 받아낼 수 없다면, 정비 작업을 수행하는 데는 위험이 따를 수밖에 없다. 그렇다고 해서 9대 이상의 노드를 사용하는 것도 권장하지 않는데, 합의(consensus) 프로토콜 특성상 성능이 내려가기 시작할 수 있기 때문이다. 또한, 클라이언트 연결이 너무 많아서 5대 혹은 7대의 노드가 부하를 감당하기에 모자란다는 생각이 들면 옵저버 노드를 추가함으로써 읽기 전용 트래픽을 분산시킬 수 있도록 해 보자.

</aside>

2.2 카프카 브로커 설치하기

2.3 브로커 설정하기

2.3.1 핵심 브로커 매개변수

• broker.id
  • 정수로 설정
• listeners
• zookeeper.connect
• log.dirs
  • 카프카는 모든 메시지를 로그 세그먼트(log-segment) 단위로 묶어서 log.dir 설정에 지정된 디스크 디렉토리에 저장한다.
• num.recovery.threads.per.data.dir
  • 설정 가능한 스레드 풀을 사용해서 로그 세그먼트를 관리한다. 현재 이 스레드 풀은 아래와 같은 작업을 수행한다.
    • 브로커가 정상적으로 시작되었을 때, 각 파티션의 로그 세그먼트 파일을 연다.
    • 브로커가 장애 발생 . 후다시 시작되었을 때, 각 파티션의 로그 세그먼트를 검사하고 잘못된 부분은 삭제한다.
    • 브로커가 종료할 때, 로그 세그먼트를 정상적으로 닫는다.
  • 기본적으로 하나의 디렉토리에 하나의 스레드만 사용된다.
  • 이 설정을 잡아 줄 때는 log.dirs에 지정된 로그 디렉토리별 스레드 수라는 점을 명심하자.
    • num.recovery.threads.per.data.dir 는 8개이고 log.dirs 3개면 총 24개의 스레드
• auto.create.topics.enable
  • 토픽생성을 명시적으로 관리할 경우 false 인데,
  • 기본설정 시 다음의 상황에서는 브로커가 토픽을 자동으로 생성하도록 되어 있다
    • 프로듀서가 토픽에 메시지를 쓰기 시작할 때
    • 컨슈머가 토픽으로부터 메시지를 읽기 시작할 때
    • 클라이언트가 토픽에 대한 메타데이터를 요청할 때
• auto.leader.rebalance.enable
  • 모든 토픽의 리더 역할이 하나의 브로커에 집중됨으로써 카프카 클러스터의 균형이 깨지는 수가 있다. 이 설정을 활성화해주면 가능한 한 리더 역할이 균등하게 분산되도록 함으로써 이러한 사태가 발생하는 것을 방지할 수 있다.
  • 이 설정을 켜면 파티션의 분포 상태를 주기적으로 확인하는 백그라운드 스레드가 시작된다.
• delete.topic.enable
  • false : 클러스터의 토픽을 임의로 삭제하지 못하게,

2.3.2 토픽별 기본값

• num.partitions
  • 기본값은 1이고, 새로운 토픽이 생성될 때 몇 개의 파티션을 갖게 되는지를 결정, 늘릴 수는 있지만 줄일 수는 없다.
  • 브로커가 추가될 때 클러스터 전체에 걸쳐 메시지 부하가 고르게 분산되도록 파티션 개수를 잡아 주는 게 중요하다.
  • 얼만큼의 데이터를 쓰고 싶은 상황이고 (1GB), 소비는 얼만큼 가능할 때 (50MB),몇 개의 파티션이 필요한가?
• default.replication.factor
• log.retention.ms
  • 메시지 보존 기간
• log.retention.bytes
  • 파티션 단위의 크기 적용
• log.segment.bytes
• log.roll.ms
• min.insync.replicas
• message.max.bytes

2.4 하드웨어 선택하기

2.4.1 디스크 처리량

• 로그 세그먼트를 저장하는 브로커의 디스크의 처리량은 프로듀서 클라이언트의 성능에 가장 큰 영향을 미친다. (중략) 즉, 디스크 쓰기 속도가 빨라진다는 것은 곧 쓰기 지연이 줄어드는 것이다.

2.4.2 디스크 용량

• 보존 공간, 예비 공간

2.4.3 메모리

• 카프카 그 자체는 JVM의 많은 힙 메모리를 필요로 하지 않는다. 초당 15만개의 메시지에 200MB의 데이터 속도 를 처리하는 브로커일지라도 5GB 힙과 함께 돌아간다.
• 시스템 메모리의 나머지 영역은 페이지 캐시로 사용되어 시스템이 사용중인 로그 세그먼트를 캐시하도록 함으로써 카프카의 성능을 향상시킬 수 있는 것이다. 이것은 카프카를 하나의 시스템에서 다른 애플리케이션과 함께 운영하는 것을 권장하지 않는 주된 이유다. 이 경우 페이지 캐시를 나눠서 쓰게 되기 때문이고, 이것은 카프카의 컨슈머 성능을 저하시킨다.

2.4.4 네트워크

• 사용 가능한 네트워크 대역폭은 카프카가 처리할 수 있는 트래픽의 최대량을 결정한다. 이것을 디스크의 용량과 함께 클러스터의 크기를 결정하는 가장 결정적인 요인이라고 할 수 있다.
• 카프카가 다수의 컨슈머를 지원하기 때문에 인입되는 네트워크 사용량과 유출되는 네트워크 사용량의 불균형이 발생한다.
• 클러스터 내부의 복제나 미러링 역시 요구 조건을 증대시킨다.
• 네트워크 문제 발생 시 10GB 네트웍 카드를 사용해라

2.4.5 CPU

• 크게 중요하지는 않지만 받은 메시지의 압축해제 및 전달할 메시지의 압축 작업 등이 많을 경우 CPU의 성능을 올리는게 필요할 수도 있다.

2.5 클라우드에서 카프카 사용하기

2.5.1 마이크로소프트 에져

• 프리미엄 SSD
• Azure Managed Disk
• Azure Blob Storage

2.5.2 아마존 웹 서비스

• SSD 인스턴스
• AWS Elastic Block Store

2.6 카프카 클러스터 설정하기

클러스터는 부하는 다수의 서버로 확장하여 이점이 있다.

2.6.1 브로커 개수

• 클러스터의 크기 결정 요소
  • 디스크 용량
  • 브로커당 레플리카 용량
  • CPU 용량
  • 네트워크 용량
• 파티션 레플리카 개수를 브로커당 14,000개, 클러스터 당 100만개 이하로 유지할 것을 권장한다.

2.6.2 브로커 설정

2.6.3 운영체제 튜닝하기

• 리눅스 /etc/sysctl.conf
• 가상메모리
  • 일반적으로, 리눅스의 가상 메모리 시스템은 시스템 부하에 따라 자동으로 메모리 사용량을 조절한다. 카프카의 경우 카프카의 부하 특성에 맞게 스왑 공간이나 더티 메모리 페이지(dirty memory page)가 사용되는 방식을 조절해 줄 수 있다.
  • vm.swappiness
    • 최소값 1로 설정하는 것 권장
  • 카프카는 로그 세그먼트를 저장하고 연결을 열기 위해 파일 디스크립터를 사용한다.
    • 파일 디스크립터 계산
      • 파티션 수 * (파티션수/세그먼트크기) + 브로커에 생성된 네트워크 연결 수
  • vm_overcommit_memory
• 디스크
  • 파일시스템
• 네트워킹
  • 대량의 네트워크 트래픽을 발생시키는 애플리케이션을 사용할 때 리눅스 네트워킹 스택의 기본 설정값을 조정해주는 것은 흔한 일이다. 리눅스 커널은 기본적으로 대량의 데이터를 빠르게 주고받는 데 최적화되어 있지 않기 때문이다.
  • 소켓의 송수신 버퍼
    • net.core.wmem_default
    • net.core.rmem_default
  • TCP 소켓의 송수신 버퍼 크기
    • net.ipv4.tcp_wmem
    • net.ipv4.tcp_rmem
  • TCP 윈도우 스케일링 기능
    • net.ipv4.tcp_max_syn_backlog
  • 커널이 처리해야할 패킷
    • net.core.netdev_max_backlog

2.7 프로덕션 환경에서의 고려 사항

2.7.1 가비지 수집기 옵션

• 카프카에는 G1GC를 기본으로 적용할 것을 권장한다.
• G1GC는 서로 다른 작업 부하를 자동으로 조절하고 애플리케이션 실행되는 동안 더 일정한 정지시간을 보여주도록 설계되었다
• G1GC는 전체 힙을 처리하는 대신 여러 개의 작은 영역으로 나눠서 처리함으로써 커다란 크기를 가진 힙 영역을 더 잘 처리한다
• MaxGCPauseMillis
  • GC중단 시간 설정
• InitiatingHeapOccupancyPercent
  • G1GC가 수집 사이클을 시작하기 전까지 전체 힙에서 사용 가능한 비율을 백분율로 지정,
  • 기본값 45

2.7.2 데이터센터 레이아웃

카프카는 브로커에 새 파티션을 할당할 때 랙 위치를 고려함으로써 특정 파티션의 레플리카가 서로 다른 랙에 배치되도록 할 수 있다.

• broker.rack

2.7.3 주키퍼 공유하기

카프카는 브로커, 토픽, 파티션에 대한 메타데이터 정보를 저장하기 위해 주키퍼를 사용한다. 컨슈머 그룹 멤버나 카프카 클러스터 자체에 뭔가 변동이 있을 때만 주키퍼 쓰기가 이루어진다. (중략) 하지만, 컨슈머 애플리케이션을 개발할 때는 주키퍼에 대한 의존성 없이 카프카를 사용해서 오프셋을 커밋하는 최신 카프카 라이브러리를 사용할 것이 권장된다. 다수의 카프카 클러스터가 하나의 주키퍼 앙상블을 공유하는 경우를 제외하면, 다른 애플리케이션과 주키퍼 앙상블ㅇ르 공유한느 것은 피할수 있다면 피하는 것이 좋다.

2.8 요약