카프카 - 01 - 카프카의 디자인

카프카 디자인의 특징

• 분산 시스템
  아파치 카프카 문서에 따르면 링크드인에서 가장 사용량이 노퓨은 클러스터는 60대의 브로커를 운영하고 있다.
• 페이지 캐시
  카프카는 처리량을 높이기 위해 페이지 캐시를 이용한다.
  그래서 카프카를 구성할 때는 디스크 중에서 가격이 저렴한 SATA 를 사용해도 무방하다.
  
  카프카는 자바 기반의 JVM 을 사용하는 어플리케이션이다.
  카프카는 JVM 에서 1GB 의 힙메모리 영역을 사용하게 되어있다.
  컨플루언트 사의 문서에 따르면 카프카는 초당 메시지 단위, 메가비트 단위를 처리하기 위해 5GB 의 힙메모리면 충분하다고 한다.
  그리고 남아있는 메모리는 페이지 캐시로 사용하라고한다.
• 배치 I/O 처리
  카프카는 데이터 I/O를 배치로 묶어서 처리한다.

 

 

 

토픽

메시지를 받을 수 있도록 논리적으로 묵은 개념

 

 

 

파티션

토픽을 구성하는 데이터 저장소이다.

수평 확장이 가능한 단위이다.

카프카에서 효율적인 메시지 전송과 속도를 높이려면 토픽의 파티션수를 늘려야한다.

하지만 무작정 늘리는 것은 다음과 같은 이유로 바람직하지않다. 그 이유는 아래와 같다.

• 파티션은 브로커의 디렉토리와 매핑되므로 파티션 수가 많으면 파일 핸들 수가 많아진다. 즉 리소스가 낭비된다.
• 카프카는 높은 가용성을 위해 리플리케이션을 지원한다. 그런데 만약 원본이 있는 브로커가 장애가 나서 새로운 리더 파티션을 선출해야하는 경우, 모든 파티션에 대해 리더를 선택해줘야한다. 따라서 파티션이 지나치게 많다면 장애 복구시간이 증가하게된다.

 

 

 

파티션의 개수 산정 

토픽은 아래와 같은 사안들을 점검하여 적절한 파티션 수를 가져야한다.

• 프로듀서의 초당 메시지 생성량
• 프로듀서의 개수
• 파티션의 초당 메시지 처리량
• 컨슈머의 초당 메시지 처리량
• 컨슈머의 개수

파티션의 예상 사용량을 짐작하고 사용하는 것이 가장 이상적이지만 이는 현실적으로 힘들다.

따라서 그냥 일단 적은 숫자의 파티션을 운용하다 병목현상이 생기면 늘리는 식으로 운영하는 것이 좋다.

참고로 파티션은 확장은 쉽지만 축소는 어렵다.

파티션의 축소는 삭제하고 재생성해야한다.

따라서 적은 수 -> 큰 수로 확장하는 방식이 좋다.

 

 

 

오프셋과 메시지 순서

파티션은 파티션마다 메시지가 저장되는 위치를 뜻하는 오프셋을 가지고 있다.

오프셋은 파티션 내에서 유일한 값이다.

오프셋은 메시지가 들어올 때마다 순차적으로 증가하는 값이다.

메시지를 가져갈 땐 오프셋을 이용한다. 그리고 이를 통해 메시지의 순서를 보장한다.

메시지를 가져갈 때 오프셋은 순서가 바뀐 상태로 절대 가져갈 수 없다.

 

 

 

리플리케이션

카프카는 토픽 단위의 리플리케이션이 아닌 파티션 단위로 리플리케이션을 한다.

리플리케이션 팩터란 파티션을 몇개까지 리플리케이션 할 것인지를 뜻한다. (원본 포함, 이하 리플리케이션이라함은 원본도 포함을 뜻한다.)

주키퍼에서는 원본을 리더, 리플리케이션을 팔로워라고 부른다.

카프카에서는 원본을 리더, 리플리케이션을 팔로워라고 부른다.

래빗엠큐에서는 원본을 마스터큐, 리플리케이션을 미러드큐라고 부른다.

만약 리더가 있는 브로커가 장애가 난다면 팔로워가 새로운 리더가 된다.

 

 

 

리플리케이션의 단점

리플리케이션이 무조건 장점만 있는 것은 아니다.

리플레케이션 팩터 만큼 저장소 부담감이 더해진다.

브로커가 리플리케이션이 제대로 되고 있는지 체크해야하기 때문에 브로커의 리소스 사용량이 증가된다.

즉 이 숫자도 잘 산정해서 써야한다.

일반적으로 리플리케이션 팩터는 2~3을 가지게한다.

 

 

 

리더와 팔로워

리더와 팔로워는 각자 역할이 나뉘는데 가장 중요한 핵심은 모든 읽기, 쓰기가 리더를 통해서만 일어난다는 점이다.

팔로워는 주기적으로 리더의 데이터를 보면서 그대로 복제만할 뿐이다.

만약 리더가 있는 브로커가 장애가 난다면 팔로워가 새로운 리더가 된다.

이때 데이터의 정합성을 유지하기 위해서 카프카에서는 ISR 이라는 개념을 도입한다.

 

 

 

ISR 

현재 리플리케이션이 되고 있는 원본을 포함한 리플리케이션 그룹 

새로운 리더를 선출할 때는 만드시 ISR 에 속한 구성원만이 리더가 될 수 있다.

ISR 안에서 리더는 팔로둬들이 주기적으로 데이터를 확인하고 가져가고 있는지를 확인한다. (replica.lag.time.max.ms)

만약 특정 시간동안 데이터를 가져가지 않는다면 리더는 팔로워를 ISR 그룹에서 추방시킨다.

 

 

 

모든 브로커가 다운된다면?

ISR 관점에서 모든 브로커가 다운됬을 때 선택할 수 있는 방안은 두가지다. (unclean.leader.election.enable)

1. 마지막 리더가 재시작 될 때까지 기다리다 재시작되면 마지막 리더를 ISR 의 리더로 지정한다. (기본값)

다만 이는 마지막 리더가 정상화 될 때까지 전체 카프카 클러스터 장애가 길어진다.

2. 아무 브로커나 살린 뒤 이를 ISR 의 리더로 승격시킨다.

장애 발생 이후 빠른 서비스를 제공하기 위한 방법이다.

브로커가 차례대로 다운되면서 ISR 에서 추방된 브로커가 리더가 되므로 메시지 유실이 생길 수 있다.

 

 

 

카프카에서 주키퍼 지노드의 역할

• /my-kafka/controller
  현재 카프카 클러스터 컨트롤러의 정보를 확인할 수 있다.
  카프카에서는 컨트롤러 하나를 선정해 브로커의 실패를 감지한다.
  컨트롤러를 통해 많은 수의 파티션들을 매우빠르게 배치형태로 리더십 변경을 한다.
  컨트롤러는 클러스터 내 임의의 브로커가 선정된다.
  컨트롤러인 브로커가 다운되면 살아있는 다른 브로커가 새로운 컨트롤러가 된다.
• /my-kafka/brokers
  브로커 관련 정보가 저장된다.
• /my-kafka/consumers
  컨슈머 관련 정보가 저장된다.
  컨슈머가 파티션 별로 어디까지 읽었는지 기록하는 오프셋 정보가 저장된다. 
  오프셋 정보는 지워지면 안되므로 주키퍼의 영구 지노드로 저장된다.
  다만 이 마저도 0.9버전 이후부터는 오프셋을 카프카의 토픽에 저장하는 방식으로 변경된다.
• /my-kafka/config
  토픽의 상세 정보를 확인한다.