카프카의 탄생
링크드인에서 만들었다. 링크드인은 아래와 같은 문제점을 겪었다.
- 데이터를 생성하는 소스 애플리케이션과 데이터가 최종 적재되는 타킷 애플리케이션이 1:1 단방향 통신으로 연결되어 있었다. 아키텍처가 거대해지면서 소스 애플리케이션과 타킷 애플리케이션의 수가 많아지면서 데이터 전송 라인이 복잡해지고 문제가 생기기 시작했다.
- 소스 애플리케이션과 타깃 애플리케이션으 연결하는 파이프라인 개수가 많아지면서 소스코드 및 버전 관리에 이슈가 생겼다.
- 타깃 애플리케이션에 장애가 생길 경우 그 영향이 소스 애플리케이션에 그대로 전달되었다.
링크드인 데이터팀이 다양한 메시지 플랫폼과 ETL 툴을 적용하여 아키텍처를 변경하려고 했지만 해결하지 못했다. 그래서 결국 새로운 시스템을 만들기로 했고, 그 결과물이 아파치 카프카다.
- 카프카는 애플리케이션끼리 연결하여 데이터를 처리하는 것이 아니라 한 곳에 모아서 처리할 수 있도록 중앙집중화했다. 카프카가 대용량 데이터를 수집하고 이를 실시간 스트림으로 소비할 수 있게 만들어주는 일종의 중추 신경으로 동작하게 됐다.
- 중앙집중화한 카프카는 소스 애플리케이션과 타깃 애플리케이션 사이의 의존도를 최소화했고 커플링을 완화했다. 한쪽 애플리케이션의 이슈가 다른 애플리케이션에 미치는 영향을 최소화했고, 소스 애플리케이션에서 생성되는 데이터가 어느 타킷 애플리케이션에 보낼 것인지 고민하지 않고 카프카에 보내면 된다.
상용 환경에서는 최소 3대 이상의 서버(브로커)에서 분산 운영하여 프로듀서를 통해 전송받은 데이터를 시스템에 안전하게 기록한다. 서버 3대 이상으로 이루어진 카프카 클러스터 중 일부 서버에 장애가 발생하더라도 데이터를 지속적으로 복제하기 때문에 안전한게 운영할 수 있다. 또한, 데이터를 묶음 단위로 처리하는 배치 전송을 통해 낮은 지연과 높은 데이터 처리량도 가지게 되었다.
빅데이터 파이프라인에서 카프카의 역할
빅데이터를 저장하고 활용하기 위해서는 일단 생성되는 데이터를 모두 모으는 것이 중요한데, 이때 사용되는 개념이 데이터 레이크이다. 데이터 레이크는 빅데이터를 관리하고 사용하는 측면에서 중요한 용어이다. 데이터 레이크는 데이터가 모이는 저장 공간을 뜻하며, 데이터 웨어하우스와 다르게 필터링되거나 패키지화되지 않은 데이터가 저장된다는 점이 특징이다. 즉, 운영가능한 모든 데이터를모으는 것이다.
서비스에서 데이터를 데이터 레이크로 모을 때 소스에서 발생하는 데이터를 데이터 레이크에 직접 End to End 모을 수 있다. 하지만 위에서 얘기했듯이 서비스가 커지고 복잡해지면 파편화되고 복잡도가 올라가는 문제가 발생한다. 이를 해결하기 위해서 데이터를 추출하고 변경, 적재하는 과정을 묶은 데이터 파이프라인을 구축해야 한다.
End to End방식의 데이터 수집 및 적재를 개선하고 안정성을 추구하며, 유연하면서도 확장 가능하게 자동화한 것을 데이터 파이프라인이라고 부른다. 빅데이터를 활용하는 기업에 필수적이며 데이터 파이프라인을 구축하지 않으면 위에서 언급한 문제가 발생하고 기술 부채로 남아 지속적으로 개발자들을 괴롭힌다.
아파치 카프카는 데이터 파이프라인 구축에 적합하다. 그 이유는 아래와 같다.
- 높은 처리량
카프카는 많은 양의 데이터를 묶음 단위로 처리하는 배치 방식으로 빠르게 처리할 수 있기 때문에 대용량의 실시간 로그데이터를 처리하는 데에 적합하다. 또한, 파티션을 통해 동일 목적의 데이터를 여러 파티션에 분배하고 데이터를 병렬로 처리할 수 있다. - 확장성
카프카는 안정적으로 확장 가능하도록 설계되었다. 데이터가 적을 때는 카프카 클러스터의 브로커를 최소한의 개수로 운영하다가 데이터가 많아지면 클러스터의 브로커 개수를 늘려 스케일 아웃할 수 있다. 반대로 데이터 개수가 적어지고 추가 서버들이 더는 필요 없어지면 브로커 개수를 줄여 스케일 인할 수 있다. 카프카의 스케일 아웃, 스케이 인 과정은 클러스터의 무중단 운영을 지원하므로 365일 24시간 데이터를 처리해 하는 커머스나 은행 같은 비즈니스 모델에서도 안정적인 운영이 가능하다. - 영속성
카프카는 다른 메시징 플랫폼과 다르게 전송받은 데이터를 메모리에 저장하지 않고 파일 시스템에 저장한다. 디스크 기반의 파일 시스템을 활용한 덕분에 브로커 애플리케이션이 장애 발생으로 급작스럽게 종료되더라도 프로세스를 재시작하여 안전하게 데이터를 다시 처리할 수 있다. - 고가용성
3개 이상의 서버들로 운영되는 카프카 클러스터는 일부 서버에 장애가 발생하더라도 무중단으로 안전한고 지속적으로 데이터를 처리할 수 있다. 클러스터로 이루어진 카프카는 데이터의 복제를 통해 고가용성의 특징을 가지게 되었다.
데이터 레이크 아키텍처와 카프카의 미래
카프카의 미래를 알기 위해 데이터 레이크를 구성하는 아키텍처의 역사에 대해 알아본다.
데이터 레이크의 종류
- 람다 아키텍처
- 카파 아키텍처
람다 아키텍처
람다 아키텍처는 레거시 데이터 수집 플랫폼을 개선하기 위해 구성한 아키텍처이다. 초기 빅데이터 플랫폼은 End to End로 각 서비스 애플리케이션으로부터 데이터를 배치로 모았다. 데이터를 배치로 모으는 구조는 유연하지 못했고, 실시간으로 생성되는 데이터들에 대한 인사이트를 서비스 애플리케이션에 빠르게 전달하지 못했다. 또한, 원천 데이터로부터 파생된 데이터의 히스토리를 파악하기가 어려웠고 계속되는 데이터의 가공으로 인해 데이터가 파편화되면서 데이터 표준 및 정책을 지키기 어려웠다. 이를 해결하기 위해 기존의 배치 데이터를 처리하는 부분 외에 스피드 레이어라고 불리는 실시간 데이터ETL작업 영역을 정의한 아키텍처를 만들었는데, 이것이 아래 그림인 람다 아키텍처다.
이미지 출처
람다 아키텍처는 3가지 레이어로 나뉜다. 배치 레이어는 배치 데이터를 모아서 특정 시간, 타이밍마다 일괄 처리한다. 서빙 레이어는 가공된 데이터를 데이터 사용자, 서비스 애플리케이션이 사용할 수 있도록 데이터가 저장된 공간이다. 스피드 레이어는 서비스에서 생성되는 원천 데이터를 실시간으로 분석하는 용도로 사용한다. 배치 데이터에 비해 낮은 지연으로 분석이 필요한 경우에 스피드 레이어를 통해 데이터를 분석한다. 스피드 레이어에서 가공, 분석된 실시간 데이터는 사용자 또는 서비스에서 직접 사용할 수 있지만 필요한 경우에는 서빙 레이어로 데이터를 보내서 저장하고 사용할 수 있다. 람다 아키텍처에서 카프카는 스피드 레이어에 위치한다.
데이터를 배치 처리하는 레이어와 실시간 처리하는 레이어를 분리한 람다 아키텍처는 데이터 처리 방식을 명확히 나눌 수 있었지만 레이어가 2개로 나뉘기 때문에 생기는 아래 2가지 단점이 있다.
- 데이터를 분석, 처리하는 데에 필요한 로직이 2벌로 각각의 레이어에 따로 존재해야 한다는 점
- 배치 데이터와 실시간 데이터를 융합여 처리할 때는 다소 유연하지 못한 파이프라인을 생성해야 한다는 점
람다 아키텍처의 단점으 해소하기 위해 제이 크랩스(카프카를 최초로 고안한 개발자)는 카파 아키텍처를 제안했다. 카파 아키텍처는 람다 아키텍처와 유사하지만 베치 레이어를 제거하고 모든 데이터를 스피드 레이어에 넣어서 처리한다는 점이 다르다.
카파 아키텍처
람다 아키텍처에서 단점으로 부각되었던 로직의 파편화, 디버깅, 배포, 운영 분리에 대한 이슈를 제거하기 위해 배치 레이어를 제거한 카파 아키텍처는 스피드 레이어에서 데이터를모두 처리할 수 있었으므로 엔지니어들은 더욱 효율적으로 개발과 운영에 임할 수 있게 되었다.
카파 아키텍처는 스피드 레이어에서 모든 데이터를 처리하므로 서비스에서 생성되는 모든 종류의 데이터를 스트림 처리해야 한다. 배치 데이터를 스트림 프로세스로 처리할 수 있게 된 배경에는 제이 크랩스가 모든 데이터를 로그로 바라보는 것에서 시작하였다. 여기서 로그는 애플리케이션을 로깅하는 텍스트 로그가 아닌 데이터의 집합을 뜻한다. 이 데이터는 지속적으로 추가가 가능하며 각 데이터에는 일정한 번호(또는 타임 스탬프)가 붙는다.
일반적으로 데이터 플랫폼에서 배치 데이터를 표현할 때는 각 시점(시간별, 일자별 등)의 전체 데이터를 백업한 스냅샷 데이터를 듯했다. 그러나 배치 데이터를 로그로 표현할 때는 각 시점의 배치 데이터의 변환 기록을 시간 순서대로 기록함으로써 각 시점의 모든 스냅샷 데이터를 저장하지 않고도 배치 데이터를 표현할 수 있게 되었다.
로그로 배치 데이터와 스트림 데이터를 저장하고 사용하기 위해서는 변환 기록이 일정 기간 동안 삭제되어서는 안 되고 지속적으로 추가되어야 한다. 모든 데이터가 스피드 레이어에 들어오는 것을 감안하면 스피드 레이어를 구성하는 플랫폼은 Single Point of Failure가 될 수 있으므로 반드시 내결함성과 장애 허용 특징을 지녀야 했다. 아파치 카프카는 이러한 특징에 정확히 부합한다.
카프카의 미래
제이 크랩스는 카파 아키텍처에서 서빙 레이어를 제거한 아키텍처인 스트리밍 데이터 레이크를 제안했다. 카파 아키텍처는 데이터를 사용하는 고객을 위해 스트림 데이터를 서빙 레이어에 저장한다. 스피드 레이어에서 사용되는 카프카에 분석과 프로세싱을 완료한 거대한 용량의 데이터를 오랜 기간 저장하고 사용할 수 있다면 굳이 카프카를 통해 분석하고 프로세싱한 데이터를 다시 서빙 레이어에 저장할 필요가 없다. 그래서 서빙 레이어는 제거되어도 되고 그럼으로써 서빙 레이어와 스피드 레이어가 이중으로 관리도는 운영 리소스를 줄일 수 있는 것이다.
스피드 레이어에서 데이터를 분석, 프로세싱, 저장함으로써 Single Source of Truth가 되는 것이다. 데이터가 필요한 모든 고객과 서비스 애플리케이션은 스트리밍 데이터 레이크의 스피드 레이어만 참조함으로써 데이터의 중복, 비정합성과 같은 문제에서 벗어날 수 있다.
아직은 카프카를 스트리밍 데이터 레이크로 사용하기 위해 다음과 같이 개선해야 하는 부분이 있다.
- 자주 접근하지 않는 데이터를 굳이 비싼 자원(브로커의 메모리, 디스크)에 유지할 필요가 없다.
- 데이터를 사용하는 고객이나 서비스 애플리케이션에서 카프카의 데이터 쿼리할 수 있는 주변 데이터 플랫폼이 필요하다.
ksqlDB가 있으나 아직 타임스탬프, 오프셋, 파티션 기반 쿼리를 제공하지 않기 때문에 배치 데이터를 완벽히 처리하기에는 부족하다.
