아키텍처 설계 및 파이프라인 설계

데이터 엔지니어 관점에서 데이터레이크 아키텍처 주된 관심사는 파이프라인 설계입니다. 데이터 수집부터 분석, 시각화 환경까지 데이터를 견고하게 전달할 수 있는 아키텍처를 설계를 목표로 하게 되죠. 파이프라인 설계는 환경마다 다르기 때문에 정답은 없습니다. 온프레미스 환경이든 클라우드 환경 (AWS, Azure, GCP 등) 요구사항에 맞춰서 구현이 가능하나 실시간 수집이 필요한가?? 에 대한 여부에 따라 파이프라인 설계를 구분할 수 있을 겁니다.

Lambda & Kappa Architecture

실시간 수집이 필요한 경우 참조할 수 있는 아키텍처는 대표적으로 람다와 카파 아키텍처로 소개할 수 있습니다. 우선 람다 아키텍처 부터 알아보시죠

Lambda Architecture

람다 아키텍처는 2011년 제시된 아키텍처로 실시간 수집이 필요한 경우 배치처리와 스트림 처리를 모두 이용할 수 있는 아키텍처입니다. 크게 배치 Layer, 서빙 Layer, 스피드 Layer로 구분이 됩니다.

배치 Layer

마스터 정보 또는 배치뷰에 제공하기 위해 데이터 전처리 수행, 정제된 데이터를 보관하는 영역 예를들어 고객 마스터 테이블, 제품 마스터 테이블, 고객별 기간별 주문금액을 집계해 놓은 테이블 등이 있으며 일반적으로 하루에 1회 또는 2회 테이블 갱신이 이루어 집니다.

서빙 Layer

배치 Layer에 저장된 데이터를 빠르게 보여주기 위한 서비스계층으로 사용자가 쿼리할 수 있도록 하며 필요에 따라 스피드 Layer에 있는 데이터를 결합하기도 한다.

스피드 Layer

실시간 수집 데이터의 빠른 근사치 처리를 담당하는 레이어입니다. 예를 들어 실시간 클릭 로그 집계 트랜잭션 모니터링 등이 있습니다.

Kappa Architecture

람다 아키텍처 처럼 배치 vs 스트림으로 나누지 않고, 모든 데이터를 스트림 방식으로 처리하는 구조입니다. 배치 Layer를 제거하되 배치 Layer에서 하던 일 (전처리하여 필요한 테이블로 재구성하는 작업)을 모두 스피드 Layer에서 수행합니다. 데이터 소스는 Message Queue를 의미합니다. Message Queue에는 여러 솔루션이 존재하지만 Kafka를 개발한 Jay Kreps가 만든 카파 아키테처에서 데이터 소스는 곧 Kafka Cluster를 의미합니다. 즉, 카파 아키텍처에서 모든 데이터는 Kafka로 수집함을 의미합니다. 그러나 데이터레이크 구성시 모든 소스를 kafka cluster만으로 수집하는 경우는 많지 않으며 일반적으로 Batch pipeline도 많이 활용됩니다.

종합적으로 파이프라인 설계는 실시간 수집의 필요성에 따라 구조가 달라지며 람다 아키텍처는 배치 + 실시간 처리, 카파 아키텍처는 단일 스트림 기반으로 운영과 유지보수를 간소화 합니다. 온프레미스든 클라우드 환경이든 상관없이 로그수집 → 실시간, 배치 처리 → 분석, 시각화 연동의 흐름을 중심으로 설계하면 데이터 레이크 기반에서도 안정적이고 확장성 있는 파이프라인을 구현할 수 있습니다.