1. 개요#

카프카 설정 및 환경구성시 고려사항들에 대해 다룬다

2. 주키퍼 설정#

2.1 앙상블#

• 주키퍼 앙상블은 주키퍼 서버의 집합을 의미한다.
• 주키퍼 앙상블은 홀수개의 서버로 구성하는 것이 좋다. 이는 주키퍼의 부하 분산 알고리즘에 기인한다.
• 주키퍼 서버가 요청에 응답하려면 쿼럼이라 불리는 앙상블 내의 과반수 이상의 서버가 작동 중이어야 한다.
• ex) 5개의 주키퍼 서버로 구성된 앙상블에서는 3개의 서버가 작동 중이어야 한다.
• 주키퍼 앙상블의 서버는 서로 동일한 설정을 가져야 한다.
• 카프카는 주키퍼의 지연과 타임아웃에 민감하기 때문에 주키퍼의 앙상블에 부하를 줄 수 있는 작업들은 격리하는 것이 좋다.

3. 브로커 설정#

핵심 브로커 매개변수#

Key Takeaway

• listeners 설정에서 host 를 0.0.0.0 으로 설정하면 모든 네트워크 인터페이스에서 접근 가능하다.
• 카프카는 모든 메시지를 로그 세그먼트 단위로 묶어서 log.dir 디렉터리에 저장한다.
• 기본적으로 같은 파티션에 속하는 로그 세그먼트는 같은 디렉터리에 저장된다.
• num.recovery.threads.per.data.dir 설정은 디스크를 읽기 및 복구하는 스레드의 수를 결정한다.
• 하나의 로그 디렉토리에 대해 하나의 스레드만 사용된다.
• 기본적으로 작업 시작과 종료 시점에 스레드풀이 사용되기 때문에 병렬처리를 할 경우 많은 수의 스레드를 할당해 놓는 것이 좋다.
• auto.leader.rebalance.enable 설정은 브로커의 리더 역할를 분산하는 작업을 을 자동으로 실행할지 여부를 결정한다.

토픽별 기본 값#

Key Takeaway

• 파티션 수의 증가는 클러스터 안에서 토픽의 물리적 크기의 증가를 의미한다.
• 브로커가 추가될 때 클러스터 전체에 걸쳐 메시지 부하를 분산할 수 있도록 파티션 맞춰줘야 한다.
• 토픽의 목표 처리량과 컨슈머의 예상 처리량의 추정치가 존재할 경우 -> 목표 처리량 / 컨슈머의 예상 처리량 = 파티션 수 -> ex) 1일에 1TB의 데이터를 처리하고, 컨슈머가 1시간에 10GB의 데이터를 처리한다면, 1TB / 10GB = 100 파티션
• 처리량에 대한 예상치가 없을 경우 -> 매일 디스크 내 파티션 용량을 6G 미만 으로 유지
• log.retention.ms 와 log.retention.byte 를 둘 다 설정할 경우 둘 중 하나만 만족해도 로그 세그먼트가 삭제된다.

파티션 수의 결정방법 고려 해야 할 요소들

• 토픽의 목표 처리량
• 단일 컨슈머의 처리량
• 브로커별 사용가능한 디스크 공간
• 네트워크 대역폭

4. 하드웨어 선택#

하드웨어 수준에서 병목이 발생하는 지점은 크게 3가지가 있다.

• Disk I/O
• Network I/O
• Memory

Disk I/O#

• 처리해야할 클라이언트 커넥션 수가 많을 경우 SSD 가 보다 나은 선택이다.
• 자주 사용하지 않는 데이터를 많이 저장해야하는 경우 HDD 가 더 나은 선택이다.
• 일반적으로 Disk I/O 가 클라이언트의 읽기 및 쓰기 성능에 가장 큰 영향을 미친다.
• 디스크

대개의 문제는 디스크 I/O와 네트워크 I/O에서 발생한다. CPU는 대개 주요한 병목지점이 되지 않는다.

Memory#

• 카프카 컨슈머는 기본적으로 페이지 캐시라 불리는 OS의 메모리를 사용한다.

Concept

• 페이지 캐시 : 페이지 캐시는 리눅스 커널의 메모리 관리 시스템의 일부로서, 파일 시스템의 데이터를 캐싱하는 데 사용된다.

Network I/O#

• Bandwidth는 카프카가 처리할 수 있는 트래픽의 최대량을 결정한다.

5. 클라우드에서 카프카 사용#

• Latency가 낮아야할 경우 local ssd가 내장된 IO 성능이 높은 인스턴스를 선택한다.

6. 카프카 클러스터 설정하기#

클러스터를 쓰는 핵심적인 두가지 이유는 부하의 분산과 복제로 인한 데이터 유실 방지이다.

6.1 브로커 설정#

복수의 카프카 브로커로 클러스터를 구성하기 위한 조건

1. 모든 브로커들이 동일한 zookeeper.connect 설정을 가져야 한다.
2. 클러스터 안의 모든 브로카가 유일한 broker.id를 가져야 한다.

6.2 OS 튜닝하기#

Key Takeaway

• 스왑은 권장하지 않는다.
• 가상 메모리 시스템이 디스크로 페이지를 스왑할 경우 카프카가 사용하는 페이징 캐시로 사용될 메모리에 영향을 준다.
• 디스크는 Extents File System(EFS)을 사용하는 것이 좋다.
• 메모리 동기화 블록으로 인한 갑작스러운 성능 저하와 응답 지연을 피하기 위하 더티 페이지 비율을 적절히 작게 설정하는 것이 좋다.
• 마운트 옵션으로 noatime을 사용하는 것이 좋다.(카프카 인스턴스에서 필요없는 파일 시스템 메타데이터 업데이트를 줄일 수 있다.
• 네트워크 설정에서 기본적으로 소켓의 송신, 수신 버퍼에 할당되는 기본, 최대 메모리 양을 증가 시켜줄 수 있다.
• TCP 소켓의 송신,수신 버퍼 또한 카프카 브로커에 실제 작업 부하를 바탕으로 조정할 수 있다.
• TCP 윈도우 스케일링을 통해 카프카 브로커의 네트워크 처리량을 높일 수 있다.

7. 프로덕션 환경에서의 고려 사항#

• 카프카 클러스터의 브로커가 서로 다른 rack에 위치하게끔 해야한다.
• 전원이나 네트워크 같은 인프라 측면에서의 단일 장애점을 가능한 없도록 해야한다.

Concept

• Rack : 서버, 네트워크 장비, 스토리지 등 IT 인프라 구성 요소를 설치 및 보관하는 데 사용되는 물리적인 구조물

Key TakeAway

• 많은 수의 클라이언트 연결을 받을 경우 SSD가 더 나은 선택이다.
• 카프카 컨슈머는 오프셋부터 메시지를 읽어온다. 구체적으로는 시스템의 페이지 캐시에 저장된 메시지들을 읽어온다.
• 따라서 페이지 캐시로 쓸 수 있는 메모리를 더 많이 할당함으로써 컨슈머 클라이언트의 성능 향상을 도모할 수 있다.
• 카프카를 하나의 시스템에서 다른 어플리케이션과 같이 쓰는 것은 권장하지 않는다.
• 이는 다른 어플리케이션과 페이지 캐시를 공유하기 때문이고 그에 따라 카프카 컨슈머 성능을 저하시킬 수 있기 때문이다.
• GICG는 전체 힙을 한번에 정리하는 것이 아니라 작은 영역을 여러번 정리하는 방식으로 동작한다. -> 힙영역이 거대할 수록 보다 잘 동작한다.