[AWS Infra - Airflow] 자취를 시작하는 분들을 위한 원룸 추천 웹 서비스 제작

석형원·2024년 8월 25일

Infra airflow aws 프로젝트

project

목록 보기

9/11

데브코스3기 데이터 엔지니어링 과정에서 진행한 최종 프로젝트로,
AWS IAM 계정 및 여러 리소스를 지원받아서 프로젝트를 진행할 수 있었습니다.

저는 프로젝트 내에서 Infra 역할을 맡았기에 제가 다뤘던 AWS 각종 리소스 및 CI/CD 등에 대해 기록을 해두고자 합니다.

주제 : 자취를 시작하는 분들을 위한 원룸 추천 웹 서비스 제작
프로젝트 작업 기간 : 2024.07.15 ~ 2024.08.16
맡은 역할 : Infra 설계 및 구성
팀 인원 : 4명

프로젝트 소개

여러 부동산 플랫폼의 데이터(다방, 직방)를 통합하여 더 많은 선택지 제공 및 최적의 매물을 추천해주는 웹 서비스입니다.
사용자의 요구와 조건을 반영하여 매물 추천 알고리즘을 설계하여 맞춤형 매물 추천 시스템을 구축하였습니다.
매물을 쉽고 빠르게 찾을 수 있게 직관적인 웹 서비스의 형태로 제작했습니다.
인공지능을 활용한 매물 추천 시스템을 도입하여 신뢰성 높은 추천 결과도 제공합니다.

Github : https://github.com/lv1turtle/Studio-Recommendation-Service

Data Pipeline

전체적인 데이터의 흐름은 다음과 같습니다.

먼저, 직방, 다방에서 부동산 매물 데이터와 VWORLD의 부동산 중개업자 데이터를 크롤링하여 S3에 적재합니다.
S3에 적재된 데이터는 AWS Glue와 Redshift Spectrum을 이용해 읽어와 Redshift의 테이블들을 업데이트합니다.
이후, Redshift 내에서 ELT 작업( 전처리 및 테이블 병합 ) 및 머신러닝 학습을 진행하여 해당 목적에 맞는 테이블들을 생성합니다.
분석용 테이블은 시각화 툴인 Metabase로 데이터를 넘겨 대시보드로 표현하고,
머신러닝 결과가 포함된 Production용 테이블은 S3를 거쳐 Production DB 목적으로 개설된 RDS에 데이터를 전송합니다.
마지막으로, 웹 서버에서 해당 Production DB의 데이터를 읽어와 웹 서비스를 제공합니다.

그럼 이제 제가 한 작업들을 살펴보겠습니다.

AWS Architecture 설명

Airflow 시스템을 Celery Executor와 Auto Scaling이 가능한 Worker로 구성하여 분산 처리 환경을 구축

Bastion Host와 Session Manager 접속

Private subnet에 위치한 Airflow 서버에는 보안을 위해 Bastion Host를 통하여 SSH 접속이 가능하게 하였습니다.

또한, AWS Session Manager를 사용하여 서버에 보안 키 없이 쉽게 접속할 수 있도록 하였습니다.

이는 AWS 에서 제공하는 관리 서비스로, EC2 인스턴스에 대한 안전한 접속을 제공할 뿐 아니라 Lambda 함수를 통해 인스턴스에 명령을 내리기 용이합니다.
Airflow Webserver와 Flower

Airflow Webserver는 웹 기반 사용자 인터페이스를 제공하여 DAGs의 workflow와 Metadata를 관리하고 모니터링할 수 있게 해줍니다.
Airflow Flower는 Celery용 웹 기반 모니터링 도구로, Airflow에서 사용되는 워커의 상태와 작업을 모니터링할 수 있게 해줍니다.

이 Webserver와 Flower를 Applicatin Load Balancer(ALB)로 배포하여, 허용된 사용자에 한하여 SSH, SSM 없이 쉽게 접속할 수 있게 하였습니다.
Airflow Worker (Auto Scaling Group)

Celery Executor를 사용하면 다수의 Worker를 통해 Task를 분산 처리할 수 있습니다.

또한, Celery Executor는 worker가 다른 EC2 인스턴스에서 위치해도 동작하므로 Scale out에 용이합니다.

EC2 - Auto Scaling Group을 통해 자동으로 Worker가 Scale out되도록 설정하였습니다.
Metadata DB

Airflow에는 두 가지 종류의 Relational Metadata DB가 있습니다.

airflow.config를 기준으로 봤을 때, SQL_ALCHEMY_CONN과 RESULT_BACKEND인데요.

SQL_ALCHEMY_CONN는 Airflow webserver에서 지정한 variables, connections 등과 같은 기본적인 Airflow 시스템에 꼭 필요한 메타데이터들을 저장하는 데이터베이스입니다,

RESULT_BACKEND는 Celery Executor에서 사용하는 Metadata DB로 Task들의 상태 정보를 기록하여 다수의 Worker 간의 충돌 없이 분산 처리를 가능하게 합니다.

저의 경우, SQL_ALCHEMY_CONN과 RESULT_BACKEND 모두 동일하게 외부 DB인 Amazon RDS - PostgresSQL로 설정하여 관리해주었습니다.
Message Queue (Broker)
다수의 Worker에게 Task를 할당하기 위한 Message Queue (Broker)로써 Amazon Elasticache - Redis를 사용하였습니다.
중앙 집중형 파일 관리

Airflow의 DAGs 파일, Log 파일은 중앙 집중형으로 Amazon S3에 저장하여 관리합니다.

DAGs 파일은 Github Repo가 변경될 시마다 배포되는 방식으로 진행되며,

Log 파일은 원격으로 S3와 연결하여 인스턴스가 달라도 동일한 Log 파일에 접근할 수 있도록 해주었습니다.

AWS EC2 Auto Scaling Group 동작 방식

Airflow Worker 세팅이 완료된 EC2 인스턴스에서 AMI 이미지를 추출
해당 AMI를 기반으로 시작 템플릿을 만들어 Auto Scaling Group에 등록
CloudWatch에서 CPU 점유율을 감시하다가 수행해야 할 Task가 많아져 CPU 점유율이 40퍼 이상이 되면 알람을 보냄
( t3.small 기준, 메모리 점유율이 task 3개가 한계(1.8GB/2GB), 이때, CPU 점유율이 40퍼 초반 )
Auto Scaling Group에서 새로운 인스턴스를 생성
인스턴스가 새로 생성될 때 Amazon SNS에 Topic을 전송
SNS에 Topic이 도착하면 Lambda가 Trigger됨
Lambda 함수가 S3의 DAGs를 새로 생성되는 인스턴스에 업데이트 시킨 후 Docker 기반 Airflow worker를 실행시킴
수행해야 할 Task가 사라져 CPU 점유율이 5퍼 미만이 되면 해당 인스턴스를 종료

웹 서버와 MetaBase를 Airflow 시스템과 동일한 VPC에 구현

Production DB

Production DB로 Amazon RDS - MySQL를 생성하였고 보안을 위해 Private Subnet에 위치시켰습니다.

또한, Airflow 시스템에서 DAG를 통해 해당 DB에 데이터를 적재할 것이기 때문에,

Airflow 시스템이 접근할 수 있도록 동일한 VPC에 위치하도록 설정하였습니다.
웹 서버와 MetaBase

Production DB가 Private Subnet에 위치하므로,

웹 서버와 MetaBase도 이에 접근하기 위해선 동일한 VPC 내에 있어야 합니다.

따라서, Airflow 시스템과 동일한 VPC에 EC2 인스턴스를 생성하여 웹 서버와 MetaBase를 구축하였습니다.

CD : GitHub Actions

Deploy DAGs
- develop 브랜치의 dags 폴더에 변화가 생기면 Trigger
- build : repository에서 dags 폴더에 변화가 생기면 AWS CLI를 통해 S3에 배포
- deploy : S3에 배포 완료 후에 EC2 인스턴스에 DAGs를 업데이트하는 Lambda 함수를 호출

Deploy Front & Server (Backend)
- Front 혹은 Server 브랜치에 변화가 생기면 Trigger
- Github Actions의 IP를 보안 그룹에 등록 후 SSH로 접근하여 배포 및 서버 실행,
  이후 보안 그룹에서 IP 등록 해제