서버리스(Serverless) 데이터 파이프라인 구축기

동아리 프로젝트에서 서버리스 서비스들을 이용해 데이터 파이프라인을 구축했습니다.

이번 글에서는 어떤 데이터 파이프라인을 구축했는지, 왜 서버리스로 데이터파이프라인을 구축했는지에 대해서 설명드리겠습니다.

프로젝트 소개

프로젝트를 간단히 소개하자면, 사용자의 현재 위치를 기반으로 주변의 다양한 맛집을 빠르게 추천해주는 애플리케이션입니다. 짧은 시간 내에 다양한 맛집 정보를 효율적으로 제공하려 했습니다.
오늘 글은 데이터 파이프라인에 초점을 맞춰 설명드리고자 하므로, 프로젝트에 대한 내용은 간략하게만 적겠습니다.

Serverless 데이터 파이프라인 소개

네이버, 다이닝코드, 카카오

저희 프로젝트는 네이버, 카카오, 다이닝코드 라는 3개의 플랫폼에서 맛집 정보를 크롤링한 후, 해당 데이터를 각각의 플랫폼별 폴더 구조에 맞춰 S3 경로에 저장했습니다. 이후 저장된 파일들을 읽어 전처리한 뒤, 데이터베이스(RDS)에 적재하는 파이프라인을 구축해야 했습니다. 

• E : 네이버, 카카오, 다이닝코드 사이트에서 맛집 데이터를 수집하기 위해 (분산) 크롤링 진행.
• L : 크롤링한 음식점 데이터를 플랫폼, 음식점별로 S3에 저장.
• T : S3에 저장된 음식점 데이터들을 AWS Glue를 통해 하나의 음식점 정보로 전처리 및 통합 후 RDS에 적재.

하는 ELT 데이터 파이프라인을 계획했습니다.

Serverless를 선택한 이유

데이터 파이프라인을 구축할 때 다음과 같은 이유로 Serverless 아키텍처를 도입하기로 했습니다.

1. 매일 크롤링해야 하는 데이터가 아니다.
2. 빠르게 개발하고, 최대한 단순하게 진행하고 싶음.
3. 파이프라인 실행 시 대량의 데이터를 유연하게 수집·처리할 수 있는 확장성이 필요함

그래서 저희 프로젝트에서는 Serverless 데이터 파이프라인을 도입하기로 결정했습니다.

Serverless란?

“서버가 없다” 라는 뜻이 아닌 고객이 Server를 관리할 필요 없이 애플리케이션과 서비스를 구축하고 실행하는 방식입니다.

즉, 어플리케이션의 실행은 서버에서 실행되지만, 서버의 관리는 클라우드측에서 진행을 하게 되는 것입니다. 서버에 대한 관리가 필요 없고, 인프라의 확장과 유지보수를 클라우드(AWS)측에 위임하므로 개발자는 빠르게 개발할 수 있고, 코드 작성과 어플리케이션 개발에 시간을 더 쓸 수 있다는 장점이 있습니다.

Serverless 단점

https://velog.io/@juy4556/%EC%8A%A4%ED%81%AC%EB%9E%98%ED%95%91-%EC%9D%B8%ED%94%84%EB%9D%BC-%EC%84%A4%EA%B3%841

그러면 Serverless가 무조건 좋은거 아니야? 쓸때만 쓰고, 서버 관리할 필요도 없고, 확장성도 좋고, 그냥 개꿀인데...? 라고 생각하실 수 있습니다... 저도 그랬거든요... 그러나 서버리스 아키텍처를 도입해서 프로젝트를 진행하면서 다양한 어려움을 겪었습니다.

• 디버깅이 어렵고, 시간이 많이 소모됨.
• 개발 환경 세팅의 어려움. (ex : Library 버전 충돌 or 설치 적용 X)
• 동시성 제한 등의 제약이 존재.
• 등등...

아무래도 Serverless의 경우에는 인프라 설정에 대한 권한을 AWS에 전적으로 맡기기 때문에 원하는 대로 개발 환경을 세팅하기에는 어려움을 느꼈습니다. (ㅜ.ㅜ)

자세한 내용은 다음 글로 프로젝트를 통해 배운 점을 작성할 때 다뤄보겠습니다.

아무튼 그래서 저희 팀은 어떤 AWS Service를 이용해서 어떤 데이터 파이프라인을 구축했는지 소개하겠습니다.

어떤 AWS 서비스를 이용?

저희 팀은 앞서 얘기한 것을 이유로 AWS Managed Service를 최대한 활용해서 Serverless 데이터 파이프라인을 구축했습니다 

• 워크플로우 관리 : Apache Airflow → AWS Step Function
• 데이터 크롤링 : EC2 → Lambda
• 데이터 전처리 : Apache Spark → AWS Glue

서비스 하나하나씩 소개를 해보겠습니다.

AWS Step Function

AWS Step Function

• 워크플로를 정의하고 실행 및 관리할 수 있는 관리형 서비스입니다.
• AWS 의 서비스들과 제어 흐름을 정의하여 워크플로를 정의할 수 있습니다.

맨 처음에 trigger 되는 Lambda에서는 서울 지도를 block 단위로 잘게 잘라서 해당 block 영역에 있는 음식점의 이름을 다음 크롤링 Lambda에게 넘겨주는 역할을 합니다. 이렇게 넘겨진 음식점의 정보와 Step Function의 Map State를 이용해서 음식점의 수만큼 Lambda Instance의 수를 확장하는 방법을 이용해 분산(병렬) 크롤링을 실행했습니다.

이때 저희는 아직 서비스 규모가 작은 편이어서 Lambda 호출 규모가 작아 Map State의 Inline 모드로 충분했지만, 병렬 작업이 많아지거나 대규모 데이터 처리 요구가 생기면 Map State의 Distributed 모드를 사용하는 것이 더 적합할 것 같습니다.

아래에 Map workflow State에 대해 정리한 글이 있어서 첨부드립니다!

• Map 워크플로 상태 - AWS Step Functions

AWS Lambda

음식점 크롤링을 실행하기 위해 AWS Lambda를 활용했습니다. 

AWS Lambda는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있는 Serverless 컴퓨팅 서비스로, 다음과 같은 이유들 덕분에 저희 크롤링 아키텍처에 잘 어울렸다고 생각했습니다.

1. 함수가 호출될 때만 실행되므로 불필요한 리소스 낭비를 최소화할 수 있다.
2. 코드가 실행되지 않을 때는 요금이 발생하지 않아 비용 효율적이다.
3. 자동으로 확장되기 때문에 유연하게 대응할 수 있다.

로컬에서 테스트한 결과 정상적으로 동작하는 것을 확인한 후 Lambda에 배포했지만, 실행 도중 Timeout 문제가 발생했습니다. AWS Lambda는 최대 실행 시간 15분 제한이 있어 장시간 실행되는 크롤링 작업에는 적합하지 않았습니다.

이를 해결하기 위해 여러 개의 탭을 활용하여 병렬 크롤링을 시도했지만, 클릭 버튼 조작이나 페이지 이동 시 Timeout 오류가 발생했습니다. 해당 문제가 네트워크 성능 문제인지, Lambda의 Process, Thread 특성으로 인한 것인지 이유를 정확하게 파악하지는 못했지만 다른 방법을 찾아야했습니다.

이러한 Timeout 문제를 해결하기 위해 각 플랫폼 별로 하나의 음식점 정보를 크롤링하는 Lambda를 구성하고, 음식점의 개수만큼 Lambda의 수를 늘리는 방법을 선택했습니다.

AWS Glue (Workflow)

Glue Workflow와 Workflow에 포함된 Glue Job들

Lambda의 모든 작업이 완료된 후, Glue를 활용하여 플랫폼별로 저장된 음식점 정보를 전처리하고 하나의 음식점 단위로 통합하는 작업을 수행하였습니다. 또한, 통합된 데이터가 RDS에 올바른 순서로 적재될 수 있도록 Glue Workflow를 구성하였습니다.

각각의 Glue Job은 s3에 적재된 각각 플랫폼별 저장된 파일을 전처리하여 하나의 음식점 단위로 통합한 이후 RDS에 적재하는 형태로 구성했습니다.

데이터 적재 순서를 고려하여 store → menu + review 순으로 Glue Job을 실행합니다. 이를 통해 menu 및 review 테이블에서 store 테이블의 기본키를 외래키로 활용할 수 있도록 하였습니다.

프로젝트 후기

서버리스 파이프라인을 구축하면서 편리한 점도 많았지만, 서버리스의 특성상 다양한 어려움에 직면하기도 했습니다. 또한, 취업 준비와 학업을 병행하느라 충분한 시간을 투자하지 못해서 더 많은 시간을 들였다면, 더욱 완성도 높은 데이터 파이프라인을 만들 수 있지 않았을까? 하는 아쉬움이 남습니다.  
그래도 Serverless 서비스를 활용해 데이터 파이프라인을 구축해보고, 마주한 여러 문제를 해결하기 위해 다양한 방법을 시도해 본 경험 자체에 의미가 있다고 생각합니다 :)