빅데이터 플랫폼 아키텍처 기본개념
.
Data_engineering_TIL(20211204)
[학습자료]
youtube 채널 데브원영 “카파 아키텍처? 람다 아키텍처? 빅데이터 플랫폼 아키텍처의 미래 살펴보기”를 공부하고 정리한 내용입니다.
참고자료 URL : https://youtu.be/U5G-i73Wb6U
[학습내용]
많은 IT기업들은 데이터의 중요성을 파악하고 이를 효율적으로 처리하려는 시스템을 구축하기 위해 노력을 했다.
- 초기 빅데이터 플랫폼
초기에는 엔드투엔드로 각 서비스 어플리케이션으로부터 데이터를 배치로 모았었다. 데이터를 배치로 모으는 구조는 유연하지 못했을뿐만 아니라 실시간으로 생성되는 데이터들에 대한 인사이트를 서비스 어플리케이션에 빠르게 전달하지 못하는 단점이 있었다. 또한 원천데이터로부터 파생된 데이터의 히스토리를 파악하기가 어려웠고 계속되는 데이터의 가공으로 인해 데이터가 파편화되면서 데이터 거버넌스를 지키기가 어려웠다. 거버넌스라는 것은 빅데이터에 대한 체계적인 관리와 통제를 말한다. 예를 들어서 프라이버시나 품질, 데이터 생명주기와 같은 것을 뜻한다. 이런 단점들을 해소하고자 나온것이 람다 아키텍처이다.
- 람다 아키텍처
람다 아키텍처는 세가지 레이어로 나뉘어져있다. 배치 레이어, 서빙 레이어, 스피드 레이어이다. 배치 레이어는 배치 데이터를 모아서 특정 시간, 타이밍 마다 일괄처리하는 레이어이다. spark job과 같은 대규모 배치 잡이 배치 레이어에서 돌아간다. 서빙 레이어는 가공된 데이터를 데이터 사용자, 서비스 어플리케이션이 사용할 수 있도록 데이터가 저장된 공간이다. HDFS가 대표적인 서빙 레이어 시스템 중 하나이다. 엄청나게 많은 대용량 데이터를 안정적으로 저장하는 레이어다. 스피드 레이어는 서비스에서 생성되는 원천데이터를 실시간으로 분석하는 용도로 사용한다. 배치 데이터에 비해 낮은 지연으로 분석이 필요한 경우에는 스피드 레이어를 통해 데이터를 분석하는데 보통 카프카와 같은 이벤트 스트리밍 플랫폼이 스피드 레이어에 위치하게 된다.
- 람다 아키텍처의 문제점
그런데 데이터를 배치 처리하는 레이어와 실시간 처리하는 레이어를 분리한 람다 아키텍처는 데이터 처리 방식을 명확하게 나눌수 있지만 레이어가 결국에는 두개로 나누기 때문에 발생하는 문제점도 있다. 데이터를 분석하고 처리하는데 필요한 로직이 두벌로 각각의 레이어에 따로 존재해야 한다는 점이 첫번째 문제이고, 두번째 문제는 배치 데이터와 실시간 데이터를 융합해서 처리할때는 다소 유연하지 못한 파이프라인을 생성해야 한다는 점이다. 1개의 로직을 추상화하여 배치 레이어와 스피드 레이어에 적용하는 형태인 서빙버드라는 플랫폼도 있었지만 완벽하게 해결하는 것은 아니었다. 왜냐면 컴파일을 한번만 수행하더라도 배포는 두번 이루어져야하고 디버깅과 로깅 그리고 모니터링도 결국에는 각각해야 했기 때문이다. 람다 아키텍처의 단점을 해소하기 위해 제이 크랩스(카프카 창시자)는 카파 아키텍처를 제안했다.
- 카파 아키텍처
제이 크랩스는 람다 아키텍처에서 단점으로 부각되었던 로직의 파편화, 디버깅, 배포, 운영 분리에 대한 이슈를 제거하기 위해 배치 레이어를 제거하는 방안을 고려했다. 결국에 카파 아키텍처는 스피드 레이어에서 데이터를 모두 처리할 수 있었으므로 엔지니어들은 더욱 효율적으로 개발과 운영에 임할 수 있게 되었다. 많은 실리콘 밸리 기업에서 카파 아키텍처를 도입하여 효과적으로 빅데이터를 분석하고 있다.
- 스트리밍 데이터 레이크
카파 아키텍처에서 더 나아가 최근에 제이 크랩스는 2020년 카프카 서밋에서 카파 아키텍처에서 서빙 레이어를 제거한 아키텍처인 스트리밍 데이터 레이크를 제안했다. 카파 아키텍처를 살펴보면 데이터를 사용하는 고객을 위해 스트리밍 데이터를 서빙 레이어에 저장하도록 구조가 되어 있는데 스피드 레이어로 사용되는 카프카에 분석과 프로세싱을 완료한 거대한 용량의 데이터를 오랜 기간 저장하고 사용할 수 있다면 서빙 레이어는 제거해도 된다고 생각했다. 오히려 서빙 레이어와 스피드 레이어가 이중으로 관리되는 운영 리소스를 줄일 수 있다는 논리이다. 기존에 사용하던 HDFS를 카프카로 대체한다라는 것이다. 현실적으로 아직까지는 카프카를 스트리밍 데이터 레이크로 사용하기 위해 개선해야 하는 부분이 몇가지 있다. 첫번째는 스트리밍 데이터를 배치 데이터로 자유롭게 접근 가능해야 한다는 것이다. 스트리밍 데이터는 타임스탬프 기준으로 쿼리를 돌려 배치형태로 데이터를 일부 뽑아낼수는 있지만 아직까지는 오리지널 아파치 카프카로는 한계가 있다고 한다. 카프카 스트림즈를 활용하면 KTable 또는 GlobalKTable로 구체화된 뷰를 통해 조회할 수는 있지만 이거는 스트림즈를 사용할때만 가능한 부분이다. 확장성을 고려하면 아직은 더 많은 개선이 필요한 부분이라고 볼 수 있다. 두번째는 자주 접근하지 않는 데이터를 굳이 비싼 자원에 유지할 필요가 없다는 점이다. 카프카 클러스터에서 자주 접근하지 않는 데이터는 오브젝트 스토리지와 같이 저렴하면서도 안전한 데이터 저장소에 옮겨서 저장하고, 자주 사용하는 데이터만 브로커에서 사용하는 구분작업이 필요하다.