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