카프카의 탄생
링크드인(LinkedIn)에서 아키텍처가 점점 거대해지고 소스 애플리케이션과 타깃 애플리케이션의 개수가 점점 많아지면서 문제가 생겼고, 데이터를 전송하는 라인이 가하급수적으로 복잡해지기 시작한게 원인이 되었다. 시간이 갈수록 복잡해지는 아키텍처에서 파편화된 데이터 파이프라인은 서비스를 안정적으로 운영하는데 치명적일 것이 뻔했고, 이런 문제를 극복하기 위해서 각종 상용 데이터 프레임워크와 오픈소스 아키텍처에 녹여내어 데이터 파이프라인의 파편화를 개선하려고 시도했는데 여기서 나온 결과물이 아파치 카프카이다.
카프카는 어떻게 동작할까?
카프카는 각각의 애플리케이션끼리 연결하여 데이터를 처리하는 것이 아니라 한 곳에 모아 처리할 수 있도록 중앙집중화하였다.
또한, 카프카는 기업의 대용량 데이터를 수집하고, 실시간 스트림으로 소비할 수 있게 만들어주는 일종의 중추 신경과 같이 동작한다고 볼 수 있다.
카프카는 내부에 데이터가 저장되는 파티션의 동작은 FIFO(Queue) 방식으로 동작하며, 데이터를 보내는 것이 Producer, 데이터를 가져오는 것이 Consumer 이다. (ByteArray로 통신하기 때문에 자바에서 선언 가능한 모든 객체를 지원)
또한, 데이터를 묶음 단위로 처리하는 배치 전송을 통해 낮은 지연과 높은 데이터 처리량도 가지게 되었다.
카프카의 역할
기업에서 실시간으로 저장하는 데이터의 양이 최소 테라바이트를 넘어가며 많게는 엑사 바이트까지 저장이 된다. 빅데이터를 저장하고 활용하기 위해서는 일단 생성되는 데이터를 모두 모으는 것이 중요한데, 이때 사용되는 개념이 데이터 레이크이다.
데이터 레이크
호수라는 이름에서 유추할 수 있는 것처럼 데이터가 모이는 저장 공간을 뜻한다. 데이터 웨어하우스와 다르게 필터링되거나 패키지화되지 않은 데이터가 저장되는 점이 특징
서비스하는 애플리케이션이 적고 트래픽이 많지 않을 경우는 e2e(end-to-end) 방식으로 가능하지만, 서비스가 크고 복잡해지면 파이프라인이 파편화되고 복잡도가 올라가는 문제점이 발생한다. 이를 해결하기 위해 데이터를 추출, 변경, 적재하는 과정을 묶은 데이터 파이프라인을 구축해야 한다.
e2e 방식의 데이터 수집 및 적재를 개선하고 안정성을 추구하며, 유연하면서도 확장 가능하게 자동화한 것을 "데이터 파이프라인"이라고 부른다. 이 데이터 파이프라인을 안정적이고 확장성을 높게 운영하기 위한 좋은 방법 중 하나가 바로 "아파치 카프카"를 활용하는 것이다.
아파치 카프카의 장점
- 높은 처리량
- 많은 양의 데이터를 묶음 단위로 처리하는 배치로 빠르게 처리할 수 있기 때문에 대용량의 실시간 로그데이터를 처리하는데 적합
- 확장성
- 가변적인 호나경에서 안정적으로 확장 가능하도록 설계
- 영속성
- 전송받은 데이터를 메모리에 저장하지 않고 파일 시스템에 저장
- 고가용성
- 3개 이상의 서버들로 운영되는 카프카 클러스터는 일부 서버에 장애가 발생하더라도 무중단으로 안전하고 지속적으로 데이터를 처리할 수 있음
- 온프레미스 환경 서버 랙, 퍼블릭 클라우드의 리전 단위 장애에도 데이터를 안전하게 복제할 수 있는 브로커 옵션들이 준비됨
데이터 레이크 아키텍처
데이터 레이크 아키텍처에는 2가지가 있다. "람다 아키텍처", "카파 아키텍처" 이다.
람다 아키텍처
- 레거시 데이터 수집 플랫폼을 개선하기 위해 구성한 아키텍처
- 데이터를 배치로 모으는 구조는 유연하지 못했고, 실시간으로 생성되는 데이터들에 대한 인사이트를 서비스 애플리케이션에 빠르게 전달하지 못하는 단점
- 람다 아케틱처의 3가지 레이어
- 배치 레이어 : 배치 데이터를 모아 특정 시간, 타이밍마다 일괄 처리
- 서빙 레이어 : 가공된 데이터를 데이터 사용자, 서비스 애플리케이션이 사용하도록 데이터 저장하는 공간
- 스피드 레이어 : 서비스에 생성되는 원천 데이터를 실시간으로 분석하는 용도로 사용(람다 아키텍처에서 카프카는 스피드 레이어에 위치한다.)
- 단점
- 데이터를 분석, 처리하는 데에 필요한 로직이 2벌로 각각의 레이어에 따로 존재
- 배치 데이터와 실시간 데이터를 융합하여 처리할 때는 다소 유연하지 못한 파이프라인 생성
카파 아키텍처
- 람다 아키텍처와 유사하지만 배치 레이어를 제거하고 모든 데이터를 스피드 레이어에 넣어서 처리
- 람다 아키텍처의 단점인 로직 파편화, 디버깅, 배포, 운영 분리에 대한 이슈를 제거하기 위해 배치 레이어를 제거하고 스피드 레이어에서 데이터를 모두 처리
- 모든 데이터를 처리하므로 서비스에서 생성되는 모든 종류의 데이터를 스트림을 처리해야함
카프카의 미래
카파 아키텍처에서 서빙 레이어를 제거한 아키텍처인 스트리밍 데이터 레이크를 제안하였고, 스피드 레이어에서 데이터를 분석, 프로세상, 저장함으로써 단일 진실 공급원이 되도록 하였다. 이렇게 함으로써 데이터가 필요한 모든 고객과 서비스 애플리케이션은 스트리밍 데이터 레이크의 스피드 레이어만 참조함으로써 데이터의 중복, 비정합성과 같은 문제에서 벗어날 수 있다.
단일 진실 공급원이란?
단일 진실 공급원(SSOT)이란 모든 비즈니스 데이터를 하나의 공간에 저장하는 것을 말합니다. 단일 진실 공급원은 비즈니스 데이터를 하나의 공간에 저장하면 회사 내의 누구나 이러한 접근 가능 데이터를 바탕으로 중요한 비즈니스 의사 결정을 내릴 수 있을 것이라는 아이디어를 근간으로 합니다.
0개의 댓글
