데이터 파이프라인 프로젝트 #1 아키텍처 구성

최근 데이터 엔지니어링에 대해 다시 공부하고있다. 지금까지 공부한 내용들을 바탕으로 하나의 작은 프로젝트를 해보려고 한다. 그리고 프로젝트가 아닌, 프로젝트 진행 과정에서 나의 작업과 활동을 중심으로 글을 써 내려갈 생각이다.

 

진행기간

2025년 2월 10일 ~ 2025년 2월 17일(예상)

 

프로젝트 목표

Data Pipeline 구축

본 프로젝트를 진행하는 목표는 지금까지 공부한 데이터 엔지니어링 생애 주기를 간단하게나마 구현해보면서 실제 기술들이 어떤 상황에서 왜 사용되는지 직접 확인해보는 것이다.

 

Infra 구축

데이터 파이프라인이 구성 될 인프라 부터 구축 하는 것이 목표다.

 

프로젝트를 진행하며 2개의 구축 목표와 ..목표를 세웠다. 구축을 통해 나의 기술적인 지식들을 향상시키고 점검 할 수 있을 것이며 장애 대응 능력을 기를 수 있을것으로 기대된다.

 

프로젝트 개요

1.주제

공유자전거와 서울시 교통 데이터를 시각화 해보고 더 나아가 어떤 곳에 공유자전거가 더 보급 되어야 할지 확인하는 것 까지가 최종 주제다. 

 

2.인프라 구성

로컬 환경의 k3s와 GCP를 사용 할 것이다. 전자를 사용하는 이유는 다음과 같다. 첫째 배포 단순화. k3s는 helm 등의 도구와 함께 사용하여 애플리케이션의 배포를 간단히 할 수 있다. 둘째 상태 확인 및 자가치유. pod 단위로 지속적인 상태 확인이 간편하다. 또 pod가 다운 됐을 때 혹은 장애가 생겼을 때 다른 노드로 스케줄링 하는 방식으로 자동으로 장애 대응이 가능하다. 셋째 오토스케일링. 부하가 많이 발생했을때 오토스케일링을 통해 다른 노드에 새로운 pod를 생성하고 해당 pod와 부하를 분산시킬 수 있게 된다. 

후자의 경우 가격적 메리트가 있어서 선택하게 되었다. AWS의 프리티어는 끝난지 오래이기때문에.. 거기에 더해 비교적 GCP가 저렴한 가격대에 형성되어 있기 때문에 선택하게 되었다.

 

그렇다면 왜 GCP의 관리형 K8S인 GKE나 Composer를 사용하지 않았는지 의문이 들 수 있다. k8s가 무조건적으로 사용되어야 한다면 관리형  제품을 사용했을 것이다. 하지만 비교적 구축이 편리한 k3s가 있기 때문에 구축에 드는 오버헤드가 k8s에 비해 현저히 줄어든다. 

 

3.파이프라인 개요

주제,인프라 구성 내용이 정해졌고 어떤 기술과 방식을 사용할지 정해야한다. 그래서 나는 프로젝트의 큰 그림을 다음과 같이 정했다.

 API 로부터 데이터를 스트리밍 하고, 전처리 후 Warehouse에 넣고 시각화

 

최종 아키텍처는 아래와 같다.

 

우선 로컬 k3s 내부에 airflow를 사용할 것이다. 먼저 airflow 내부의 python task가 api 데이터를 pub/sub으로 넣게 될 것이다. 다 그려놓고 보니 airflow에서 스트리밍을 하는 것이 맞는가? 하는 의문이 들었다. 하지만 우리에겐 마이크로 배치라는 귀한 기술이 있었다. airflow에서 배치로 동작하지만 주기를 짧게 하여 스트리밍과 유사하게 동작하도록 구현해 볼 것이다.

 

pub/sub은 kafka와 동일한 기능을 하는 이벤트 스트리밍 플랫폼이다. kafka를 사용하지 않고 pub/sub을 사용한 것은 구축에 발생하는 오버헤드 때문이다. 두 기술의 기능과 능력이 비슷하다면 구축에 오버헤드가 발생하는 kafka 보다는 pub/sub을 사용하는 것이 나을 것 이라는 판단이 있었다. 우선 프로젝트를 끝마친 후에 다시 kafka로 변경해서 구축해볼 예정이다.

 

pub/sub은 다시 local의 spark로 데이터를 전송한다. spark역시 k3s와 airflow 위에서 동작하게 된다. 이후 처리가 완료 된 데이터를 Bigquery로 전송 후 Looker를 통해 시각화를 하게 된다. 여기에 추가적으로 Object Stroage를 추가 할 것 까지 계획중에 있다.

 

---

프로젝트 시리즈

#1 아키텍처 구성