Search

카프카 이야기

tl;dr 이 책의 단원별로 그대로 정리할 것은 아니지만 기본적인 순서나 큰 틀은 따라가며 정리할 것

카프카의 탄생

링크드인에서 만들어 아파치 라이선스로 배포했다. 카프카라는 독특한 DB이자 프로그램이 나오기까지를 이해하려면 역시 DDIA 읽는 것을 추천한다(마치 SRE를 읽으면 보그에서 쿠버네티스가 되는 과정을 상상할 수 있듯).
목적은 수 많은 양의 데이터, 그걸 처리하는 많은 종류의 소스, 타겟(싱크) 애플리케이션의 복잡도를 해결하기 위해서이다.
또 실시간성에도 목적이 있다. 카프카가 실시간성이 있을만큼 성능이 좋은 것은 다른 DB와 달리 데이터를 (append only) 로그로 다루었기 때문이다. 로그는 이벤트이고 로그의 연속은 스트림이다. 그리고 그것의 압축은 구체화 뷰이다.
아파치 카프카는 계속하여 Kafka Improvement Proposals(KIP)이라는 방법을 통해, 오픈소스로써 계속 진화하고 있다:
kafka
apache

빅데이터 파이프라인에서 카프카의 역할

빅데이퍼 파이프라인은, 과거엔 원본 데이터를 추출, 변환, 적재(ETL; Extract, Transform, Load)하여 데이터 웨어하우스를 구축했다. 하지만 트렌드는 별도의 ETL 과정 없이 데이터 레이크로 원본 데이터를 적재한다. 필요할 때 원하는대로 추출, 변환, 가공하려고 한다. 생기는 그리고 다뤄야 할 데이터의 양이 훨씬 많아졌기 때문.
여기서 카프카는 그런 데이터 레이크 구축을 가능하게 하는 중앙 버스 역할을 한다. 책에선 다음의 네가지를 카프카의 특징으로 말한다: 높은 처리량, 확장성, 영속성, 고가용성
높은 처리량은, 앞서 이야기 한, 데이터를 단순한 로그들로 바라보는 패러다임의 전환이 크다고 생각한다.
영속성은 좀 특이하다. 카프카는 데이터를 바로 파일 시스템에 저장하기 때문(데이터 이름’만’ 로그가 아니다). 대신 페이지 캐시를 최대로 활용하여 입출력 속도의 제약을 없앴다고 한다.
확장성과 고가용성은 다른 클러스터 구조의 분산 시스템 앱들과 크게 다르다고 느껴지지 않는다.

데이터 레이크 아키텍처와 카프카의 미래

데이터 레이크 아키텍처는 과거, 현재(?) 그리고 미래(??) 순서대로 다음과 같다:
레거시(배치) 아키텍처 → 람다 아키텍처 → 카파(kappa) 아키텍처

레거시 아키텍처

레거시 레이어는 원본 데이터를 가져오는 원천, 그걸 배치처리하여 가공하는 파생 그리고 DB에 질의하면 응답을 받는 서빙 레이어까지 세 레이어 구조였다. 각 레이어마다 앱 별로 데이터를 모았다. 이는 다른 앱의 데이터들을 처리할 때 유연하지 않았다. 또 모든 데이터 처리는 배치로하여 조회(질의)의 실시간성이 없었다(배치를 좀 빨리, 안전하게 하려던게 맵리듀스 같다).

람다 아키텍처

그러다 실시간성을 위한 스피드(스트림) 레이어가 등장한다. 스피드 레이어 중심에 카프카가 있다. 기존 방식대로 처리하기 위해 배치 레이어는 여전히 있고, 아래 그림에선 생략됐지만, 배치 레이어에서 질의받고 보여주기 위한 서빙 레이어가 필요하다. 하지만 람다 아키텍처에서 중요한 것을 실시간 처리를 위한 스피드 레이어의 분리이다. 또 스트림 데이터로부터 구체화 뷰를 만들어, 별도의 서빙 레이어를 거치지 않고, 스피드 레이어에서 그대로 질의하고 보여줄 수도 있다.

카파 아키텍처

단순하게는 스피드 레이어, 즉 카프카로 모든 데이터를 처리 및 서빙하는 것이다. 모든 데이터를 로그로 취급한다. 그런 로그들의 연속, 스트림 자체로써 changlog이자 구체화 뷰를 만듬(로그 압축)으로 스냅샷을 만들 수 있기에 순서나 시점을 잘 기록하면 된다.
개념은 간결하지만 현실은 그렇지 않다. 훨씬 많은 데이터를 저장해야 하기 때문에 저장 공간과 비용에 대한 문제가 있다. 이 문제는 비교적 최근 버전(3.6+) 카프카에서 장기간 보관 데이터를 위한 스토리지 기능(Tiered Storage)를 구현하여 해결해 나가고 있다.
또 스트림 처리 역시 로그만 쌓는다고 자동으로 되는 것은 아니기에 아키텍처에서 그 구성이 필요하다. 간단하게는 스트림즈 앱, 또는 아파치 플링크나 스톰 같은 스트리밍 엔진이 필요하다.

참고