들어가며
들어가며
카프카의 탄생
2011년, ‘링크드인’에서는 소스 애플리케이션에서 생성되는 데이터들을 타깃 애플리케이션에 1:1 단방향으로 연동해 데이터를 적재해왔으나 링크드인의 백엔드 아키텍처가 거대해지면서 이 방식에 문제가 생겼다. 소스 애플리케이션과 타깃 애플리케이션을 연결하는 파이프라인 개수가 기하급수적으로 많아졌기 때문이다.
참고로 카프카는 자바에서 선언 가능한 모든 객체를 데이터로 전달할 수 있으며 3대 이상의 서버에 분산 운영하기 때문에 데이터를 파일 시스템에 안전하게 기록할 수 있다.
빅데이터 파이프라인에서 카프카의 역할
데이터 레이크 빅데이터가 모이는 저장 공간
필터링되거나 패키지화되지 않은 날 것의 데이터가 저장된다.
데이터 과학자나 데이터 분석가가 데이터 레이크에 모인 데이터를 토대로 인사이트를 찾는다.
데이터를 데이터 레이크로 모으려면 어떻게 해야 할까?
웹, 앱, 백엔드 서버, DB에서 발생하는 데이터를 데이터 레이크에 1:1로 연결한다.
데이터를 추출하고 변경, 적재하는 과정을 묶은 데이터 파이프라인을 구축한다.
1번 방식은 서비스가 비대해질 수록 복잡해진다는 문제가 있다.
카프카는 2번 방식으로 데이터를 데이터 레이크로 모은다.
아파치 카프카가 데이터 파이프라인으로 적합한 이유
1. 높은 처리량
많은 양의 데이터를 묶음 단위로 처리하는 배치 사용 → 대용량 실시간 로그데이터 처리에 적합
데이터를 여러 파티션에 분배해 데이터를 병렬 처리 → 동일 시간당 데이터 처리량 증가
2. 확장성
들어오는 데이터 개수가 가변적인 환경에서도 안정적으로 확장 가능
데이터가 적을 때 : 카프카 클러스터의 브로커를 최소한의 개수로 운영(스케일 인)
데이터가 많을 때 : 브로커 개수를 자연스럽게 늘림(스케일 아웃)
스케일 인과 스케일 아웃은 무중단 운영을 지원한다.
3. 영속성
전송받은 데이터를 파일 시스템에 저장해 영속성 보장
4. 고가용성
3개 이상의 서버 중 일부에 장애가 발생해도 무중단으로 안전하고 지속적으로 데이터 처리
카프카를 안전하게 운영하기 위해 최소 3대 이상의 브로커로 클러스터를 구성하자.
데이터 레이크 아키텍처와 카프카의 미래
데이터 레이크 아키텍처의 역사
1. 람다 아키텍처
기존의 end-to-end 구조의 문제점들을 해결하기 위해 고안된 아키텍처
배치 레이어: 배치 데이터를 모아 특정 시간, 타이밍마다 일괄 처리
서빙 레이어: 가공된 데이터를 데이터 사용자에게 전달하기 위해 데이터를 저장하는 공간
스피드 레이어: 서비스에서 생성되는 원천 데이터를 실시간으로 분석하는 용도
여기서 카프카는 스피드 레이어에 위치해 실시간 데이터를 짧은 지연시간으로 처리하고 분석한다.
그러나 람다 아키텍처는 배치 처리 레이어와 실시간 처리 레이어에 대한 2개의 로직이 필요하다는 단점이 있다.
2. 카파 아키텍처
람다 아키텍처의 단점을 해소하기 위해 링크드인에서 제안된 아키텍처
배치 레이어를 제거하고 모든 데이터를 스피드 레이어에 넣어 처리한다.
이를 위해서는 서비스에서 생성되는 모든 종류의 데이터를 스트림 처리해야 한다.
데이터를 스트림 프로세스로 처리하는 방법은? 모든 데이터를 로그(log)로 바라보자!
배치 데이터를 로그로 표현하기 위해 각 시점의 데이터 변환 기록을 시간 순서대로 기록한다.
즉, 각 시점의 모든 스냅샷 데이터를 저장하지 않고도 배치 데이터를 표현할 수 있게 됐다.
카프카의 미래
머지 않아 서빙 레이어도 빠지고, 오직 스피드 레이어 하나로만 데이터를 가공할 수 있다.
데이터의 접근 빈도에 따라 다른 저장소에 저장할 수 있도록 개발 중이다.
사용자들이 카프카의 데이터를 쿼리할 수 있는 주변 데이터 플랫폼 기능 개발이 필요하다.
Last updated