카프카, 데이터 플랫폼의 최강자 의 3장 카프카 디자인 요약
카프카 디자인
- 대용량 데이터 처리
- ex 실시간 로그 집계
- 어플리케이션의 처리량이 높아야
- 배치 전송, 파티션, 분산 처리
- 데이터의 안정적인 저장
- 리플리케이션 기능
- 분산된 서버에서 자동으로 파티션의 리더를 선출
카프카 디자인의 특징
- 필요
- 분산된 데이터 파이프 라인의 표준화/통합
- 높은 처리량
- 목적
- 높은 처리량
- 빠른 메시지 전송
- 운영 효율화
- 구현
- 분산 시스템
- 페이지 캐시
- 배치 전송 처리
카프카 디자인 1 - 분산 시스템
- 분산 시스템은 네트워크로 이루어진 컴퓨터들의 그룹
- 시스템 전체가 공통의 목표를 공유
- 같은 역할을 하는 여러 대의 서버로 이뤄진 서버 그룹
- 장점
- 단일 시스템보다 더 높은 성능을 얻을 수 있음
- 분산 시스템 중 하나의 서버 또는 노드 등이 장애가 발생하면 다른 서버 또는 노드가 대신 처리
- 시스템 확장이 용이
카프카 디자인 2 - 페이지 캐시
- OS는 물리적 메모리에 애플리케이션이 사용하는 부분을 할당
- 남은 잔여 메모리 일부를 페이지 캐시를 이용해 디스크에 읽고 쓰기를 하지 않고 페이지 캐시를 통해 읽고 쓰는 방식을 사용
- 처리 속도가 매우 빠르기 때문에 전체적인 성능이 향상
- 가격이 가장 저렴한 SATA 디스크를 사용해도 무방
카프카 디자인 3 - 배치 전송 처리
- 데이터를 주고 받는 과정에서 서버와 클라이언트 사이의 IO가 빈번하게 발생
- IO를 묶어서 처리할 수 있도록 배치 작업으로 처리
- 작은 메시지들을 묶어서 한 번에 보내게 되면 네트워크 왕복 오버헤드 등의 비용이 절감
카프카 데이터 모델
- 토픽
- 메시지를 받을 수 있도록 논리적으로 묶은 개념
- 파티션
- 토픽을 구성하는 데이터 저장소, 수평 확장이 가능한 단위
토픽의 이해
- 카프카의 데이터 저장소
- 데이터를 구분하기 위한 단위
- 249자 미만
- 토픽 이름 규칙의 예
- sbs-news, sbs-video, kbs-news, kbs-video …
파티션의 이해
- 토픽을 분할한 것
- 메시지 전송의 처리량을 높이기 위해서, 하나의 토픽을 여러개로 파티셔닝
- 메시지의 순서가 보장되어야 함
- 빠른 전송을 위해서는 토픽의 파티션을 늘려줘야 하며, 그 수만큼 프로듀서 수도 늘려야 제대로 된 효과를 볼 수 있음
파티션 수를 늘려야 좋은 건가 ?
- 파일 핸들러 낭비
- 각 파티션은 브로커의 디렉토리와 매핑되고, 2개의 데이터 파일이 저장(인덱스와 실제 데이터)
- 모든 디렉토리의 파일들에 대해 파일 핸들을 오픈
- 파티션 수가 많을 수록 파일 핸들 수 역시 많아지게 되어 리소스를 낭비
- 장애 복구 시간 증가
- 리플리케이션 구성을 통해서 하나는 파티션의 리더가 되고 나머지는 파티션의 팔로워가 된다.
- 브로커가 다운되면 해당 브로커에 리더가 있는 파티션은 일시적으로 사용할 수 없게 되기 때문에, 카프카는 리더를 팔로워 중 하나로 이동
- 장애 처리는 컨트롤러로 지정된 브로커가 수행
- 컨트롤러는 클러스터 내에 하나만 존재
- 만약 컨트롤러 역할을 수행하는 브로커가 다운되면 살아 있는 브로커 중 하나가 자동으로 컨트롤러 역할을 대신 수행
- 컨트롤러의 페일오버는 자동으로 동작하지만 새 컨트롤러가 초기화하는 동안 주키퍼에서 모든 파티션의 데이터를 읽어야 함
그렇다면 어떻게 적절한 파티션의 수를 알 수 있을까?
- 원하는 목표 처리량의 기준을 설정
- (예) 4 producer * 10개/s = 1개의 토픽이 초당 40개 처리
- 토픽의 파티션이 초당 10개의 메시지만 수신할 수 있는 환경
- 파티션을 4로 늘려서 목표 처리량을 처리
- 컨슈머 입장에서 8개의 컨슈머를 통해 각각 초당 5개의 메시지를 카프카의 토픽에서 수신
- 토픽의 파티션은 컨슈머 수와 동일하게 8개로 맞추어 컨슈머 마다 각각의 파티션에 접근
파티션 수를 정할 때 추천하는 방법
- 파티션의 수는 증가 시킬 수는 있지만, 줄일 수는 없다
- 토픽을 삭제하는 방법 말고는 다른 해결책이 없다.
- 적은 수의 파티션으로 운영해보고, 프로듀서 또는 컨슈머에서 병목현상이 발생하게 될 때 조금씩 파티션 수와 프로듀서 또는 컨슈머를 늘려가는 방법으로 적정 파티션을 결정
오프셋과 메시지 순서
- 각 파티션 마다 메시지가 저장되는 위치
- 파티션 내에서 유일하고 순차적으로 증가하는 숫자(64비트 정수) 형태
카프카의 고가용성과 리플리케이션
- 카프카의 리플리케이션은 토픽 자체를 복제하는 것이 아니라, 토픽을 이루는 각각의 파티션을 리플리케이션
리플리케이션 팩터와 리더, 팔로워의 역할
- 리플리케이션 팩터
- 리더와 팔로워
- 모든 읽기와 쓰기가 리더를 통해서만 일어난다.
- 팔로워는 리더의 데이터를 그대로 리플리케이션만 하고 읽기와 쓰기에는 관여하지 않는다.
- 리더와 팔로워는 저장된 데이터의 순서도 일치하고 동일한 오프셋과 메시지들을 갖게된다.
- 토픽의 리더를 포함하고 있는 브로커가 다운되면, 팔로워가 새로운 리더가 되어 프로듀서의 요청에 응답한다.
- 리플리케이션 기능을 이용해 리플리케이션된 토픽의 서버가 다운되는 상황이 발생하더라도 리더 변경으로 별다른 문제 없이 프로듀서의 요청을 처리
- 리플리케이션 팩터 만큼 저장소가 필요
- 브로커의 리소스 사용량 증가
- 비활성화된 토픽이 리플리케이션을 잘하고 있는지, 비활성화된 토픽의 상태를 주기적으로 체크
- 데이터의 중요도에 따라서 리플리케이션 팩터를 2 또는 3으로 설정
리더와 팔로워의 관리
- 팔로워에 문제가 있어 리더로부터 데이터를 가져오지 못하면서 정합성이 맞지 않게 된다면 ?
- 리더가 다운되는 경우, 팔로워가 새로운 리더로 승격되어야 하는데 데이터가 일치하지 않으므로 큰 문제가 발생할 수 있는 가능성이 있음
- In Sync Replica(ISR) 도입
- 현재 리플리케이션 되고 있는 리플리케이션 그룹
- ISR에 속해 있는 구성원만이 리더로 선출 가능
- ISR 내에서 리더와 팔로워 사이의 데이터 동기화 작업을 중요하게 처리하고 유지
- 이를 통해서 리플리케이션의 신뢰성을 증가
ISR의 동작
- 환경
- 리플리케이션 팩터 3
- ISR내에 리더1과 팔로워1, 팔로워2
- 프로듀서는 토픽의 리더에게 메시지를 전송
- 프로듀서가 전송한 메시지는 토픽의 리더만 읽고 쓴다.
- 팔로워들은 매우 짧은 주기로 리더에 새로운 메시지가 저장된 것이 없는지 확인
- 팔로워1은 정상동작, 팔로워2는 문제발생
- 리더는 팔로워들이 주기적으로 데이터를 확인하고 있는지 확인
- 설정된 일정주기(replica.lag.time.max.ms) 만큼 확인 요청이 오지 않으면, 해당 팔로워의 이상을 감지하고 ISR 그룹에서 추방
- 추방당한 팔로워는 리더 자격을 박탈당함
- ISR 그룹의 구성원은 리더와 팔로워1로 축소 구성
Comments