[카프카] 3장_카프카 디자인

카프카 디자인의 특징

분산 시스템

분산 시스템이란, 같은 역할을 하는 여러 대의 서버로 이뤄진 서버 그룹이다.
장점은,

  1. 단일 시스템 보다 높은 성능
  2. 하나의 서버가 장애가 발생해도 다른 서버가 대신 처리
  3. 시스템 확장 용이

페이지 캐시

OS 는 물리적 메모리에 애플리케이션이 사용하는 부분을 할당하고, 남은 잔여 메모리 일부를 페이지 케시로 이용한다.
즉, 디스크에 읽고 쓰기를 하지 않고 페이지 케시를 읽고 쓰는 방식으로 처리 속도가 빠르고 전체적인 성능을 향상 시킨다.

배치 전송 처리

서버와 클라이언트 사이, 또는 서버 내부적으로 데이터를 주고 받는 과정에서 I/O 가 발생한다.
작은 I/O 가 빈번하게 발생하는 것을 막기 위해, 작은 I/O 들을 묶어러 처리할 수 있도록 배치 작업으로 처리한다.

카프카 데이터 모델

토픽

메세지를 받을 수 있도록 논리적으로 묶은 개념이다. 메일 주소라고 생각하면 쉽다.

파티션

토픽을 분할한 것이다.
아래 그림에서, ‘뉴스 토픽’ 으로 4 개의 메세지를 보내는데 4 초가 걸린다.

아래 그림에서, ‘뉴스 토픽’ 으로 4 개의 메세지를 보내는데 1 초가 걸린다.

이렇게 빠른 전송을 위해서는, 토픽의 파티션 수와 프로듀서 수를 모두 늘려줘야한다.

그러면, 무조건 파티션 수를 늘려야 하나 ?

파티션 수가 늘어나면 카프카에 좋지 않은 영향을 끼칠 수 있다.

  1. 파일 핸들러의 낭비
    각 파티션은 브로커의 디렉토리와 매핑되고, 저장되는 데이터는 2 개의 파일 ( 인덱스, 실제 데이터 ) 이 있다.
    파티션이 많을 수록, 파일 핸들 수 역시 많아져 리소스가 낭비가 될 수 있다.

  2. 장애 복구 시간 증가

그러면, 토픽의 적절한 파티션 수는 ?

먼저, 원하는 목표 처리량의 기준을 정해야한다.

  1. 프로듀서
    4 개의 프로듀서가 초당 10 개의 메세지를 토픽으로 보내면, 토픽에서 초당 40 개의 메시지를 받아줘야한다.

  2. 토픽
    해당 토픽에서 파티션을 1로 했을 때 초당 10개의 메세지만 받아준다면, 파티션 수를 4로 조정하면 목표치를 달성한다.

  3. 컨슈머
    8 개의 컨슈머가 각각 초당 5 개의 메세지를 토픽에서 가져올 수 있으면, 토픽의 파티션수는 8개로 맞춰서 각 컨슈머마다 각각의 파티션에 접근하게 해줘야한다.
    주의할 점은, 파티션 수를 늘리는 것은 가능하지만 파티션 수을 줄이는 것은 불가능하다.

오프셋과 메세지 순서

오프셋이란, 각 파티션마다 메세지가 저장되는 위치이다.
파티션 내에서 유일한 숫자이고, 순차적으로 증가한다.
만약 컨슈머가 파티션 0 에서 데이터를 가져간다고 하면, 오프셋 0 1 2 3 4 5 순서대로 가져갈 수 있다.
절대로 오프셋 순서가 바뀐 상태로 가져갈 수 없다.

고가용성과 리플리케이션

토픽을 이루는 각각의 파티션을 리플리케이션 하는 것이다.

리플리케이션 팩터와 리더, 팔로워의 역할

위 그림은, 토픽이 replication-factor 2 로 생성된 상황이다.
모든 읽기와 쓰기는 리더를 통해서만 일어난다. 팔로워는 리더의 데이터를 그대로 리플리케이션만 한다.
리더와 팔로워는 저장된 데이터의 순서도 일치하고 동일한 오프셋과 메시지를 갖는다.
리플리케이션된 토픽의 서버가 다운되어도, 리더 변경으로 문제 없이 프로듀서의 요청을 처리할 수 있다.

리플리케이션도 단점은 있다.

  1. 디스크 사용량 증가
    토픽의 사이즈가 100 GB, 리플리케이션 팩터 3 이면, 카프카 클러스터 내 필요 저장소 크기는 300 GB 이다.

  2. 브로커 리소스 사용량 증가
    브로커는 리플리케이션 보장을 위해, 비활성화된 토픽이 리플리케이션을 잘하고 있는지 비활성화된 토픽을 계속 체크한다.

리더와 팔로워의 관리

팔로워에 문제가 있어서, 리더로부터 데이터를 가져오지 못하면 정합성이 맞지 않는다.
이를 해결하기 위해, ISR ( In Sync Replica ) 라는 개념이 있다. 현재 리플리케이션 되고 있는 리플리케이션 그룹이다.
ISR 에 속한 구성원만이 리더의 자격이 있다.
프로듀서 1, 브로커 3, 리플리케이션 팩터 3 일때, ISR 동작 순서는

  1. 프로듀서가 메세지를 토픽의 리더에게 보낸다.
  2. 리더는 메세지를 저장한다.
  3. 팔로워는 매우 짧은 주기로 리더에 새로운 메세지가 저장된 것이 있는지 확인한다.
  4. 팔로워 1은 잘 동작하고 2는 잘 동작하지 않는다고 가정하자.
  5. 리더는 팔로워가 일정 주기 동안 확인 요청을 하지 않으면 그 팔로워를 ISR 그룹에서 추방한다.
  6. 리더는 팔로워 2를 ISR 그룹에서 추방한다.
  7. 팔로워 1은 리더에게 새로운 메세지가 있음을 확인하고 메세지를 가져가서 저장한다.

모든 브로커가 다운된다면

  1. 마지막 리더가 살아나기를 기다린다.
    마지막 리더에게 모든 메세지가 저장되어 있을 때, 나중에 다시 살아난다면 메세지 손실이 없다.
    하지만 마지막 리더가 살아나지 않는 경우가 있을 수 있고, 결국 마지막 리더가 정상화 될때 까지 카프카 클러스터 장애가 길어진다.

  2. ISR 에서 추방되었지만 먼저 살아나면 자동으로 리더가 된다.
    메세지가 일부 손실되지만, 브로커 하나만이라도 정상화되어 서비스가 빠르게 정상화된다.

예시

아래 그림은,
Broker 3 / Topic “jko01” / Partition 2 / Replication Factor 3

아래 그림은,
Broker 3 / Topic “jko02” / Partition 2 / Replication Factor 2


카프카, 데이터 플랫폼의 최강자 <고승범, 공용준>

Comments