영화 추천 시스템 - (2) React + Django CI/CD 파이프라인 및 AWS 아키텍처 설계하기

https://antraxmin.tistory.com/102

 

앞선 글에서 TMDB 영화 데이터를 가져오는 과정이 상당히 오래 걸렸다. 그래서 우선 웹 애플리케이션 세팅 먼저 해놓는게 좋을 것 같았다. 영화 추천 시스템의 프론트엔드는 React로, 백엔드는 Django로 구축할 계획이고, AWS 리소스와 통합하여 CI/CD 자동화 파이프라인을 먼저 만들어놓고자 한다. 

 

기술적 의사결정 - 왜 리액트와 장고인가? 

우선 프로젝트 요구사항에 반드시 웹서비스 형태로 만들어야 한다는 조건은 없었다. 그러나 개인 맞춤형 영화 추천 기능을 구현하려면 어떻게든 사용자와 상호작용하는 부분이 있어야 하는데, 아무리 생각해도 웹 인터페이스와 통합하는 방법밖에 떠오르지 않았다. 일단 웹서비스 형태로 만든다는 것을 가정하고 기술 스택을 선택하는 과정에 있어서 또 고민과 마주했다. 

1. AWS Glue + SageMaker로 데이터 분석과 모델 개발/서빙 과정을 완전 자동화
2. AWS Lambda + API Gateway 기반의 서버리스 모델 서빙 
3. Spring Boot또는 Nest.js로 메인 API 구축 + FastAPI로 모델 서빙 
4. Django로 백엔드 + 모델 서빙 통합 

등등.. 여러 가지 조합으로 시스템을 구축할 수 있다. 그러나 간과하고 있었던 가장 중요한 요소는 개발 속도와 남은 시간이었다. 이번 기말 프로젝트 진행 여부가 시험 2주 전에 처음 공지되었고, 당시 졸업논문과 타 과목 프로젝트 제작을 동시에 하고 있던 상황으로서 시험기간이 끝나고 남은 일주일간 개발을 진행해야 하는 하는 상황이었다. 어떻게 보면 이것저것 따질 때가 아니라 생산성을 가장 높일 수 있는 기술 조합으로 가야만 했다. 

 

물론 전체적인 아키텍처로 봤을 때 가장 이상적인 조합은 메인 API 서버 + 모델 서빙용 API 서버로 구성하는 것이긴 하다. 데이터 ETL 파이프라인은 AWS Glue, 모델 개발과 학습은 Sagemaker, 비용 최적화를 위해 Lambda를 통한 서버리스 아키텍처를 구성하면 AWS 환경 안에서 완전 자동화 파이프라인을 구축할 수도 있다. 다만 반드시 팀이 아닌 개인으로 진행해야 했고, 이 글을 쓰는 시점으로부터 약 5일 정도가 남아있었기 때문에 프로젝트에 투입할 수 있는 시간이 너무 제한적이었다. 또한 AWS Glue + Sagemaker 사용 시 비용 최적화를 위한 학습과 설정 시간이 필요했다. 하지만 이 방식은 당장 실현 가능성이 떨어졌고, 대신 빠르게 웹서비스를 구축할 수 있는 리액트와 장고라는 조합이 가장 적합하다고 판단했다. 리액트와 장고 모두 나에겐 익숙한 기술이기에 웹 구현의 부담을 덜고 프로젝트의 핵심 기능인 개인화된 영화 추천 기능에 집중할 수 있겠다는 생각이 들었다. 

 

요즘 핫한 FastAPI 대신에 장고를 선택한 이유 중 하나는 데이터베이스와의 연동 때문이다. 모델 서빙 자체는 FastAPI와 장고 모두 가능하지만, 개인 맞춤형 영화 추천을 위한 사용자 데이터 관리도 중요했기 때문에 ORM 및 어드민 연동 측면에서 장고를 선택하였다. 속도는 FastAPI가 더 빠르겠지만 추가적인 설정에 들어가는 시간을 무시할 수 없었다. 

 

AWS 기반 시스템 아키텍처 설계 

해당 과목은 실질적으로 AWS에 대해 배우는 과목이기 때문에 AWS 리소스 활용도가 중요한 평가 대상 중 하나이다. 따라서 어떤 리소스를 어떻게 구성하였는지가 핵심이다. 과제 평가 때문이 아니더라도 안정적인 서비스 운영을 위해 AWS 아키텍처는 정말 중요하기 때문에 이번 프로젝트를 통해 제대로 된 시스템 아키텍처를 설계해보고자 했다. 

CI/CD 파이프라인 구축 단계에서는 'Django 애플리케이션 Docker 컨테이너화 - ECR 푸시 - ECS/Fargate를 이용한 배포' 이렇게만 설계했지만, 실제로 안정적이고 효율적인 서비스 운영을 위해서는 완전한 AWS 기반 시스템 아키텍처가 필요하다. 따라서 네트워크 구성, 보안, 모니터링, 오토스케일링, 백업 등을 모두 고려해야 한다. 

VPC (Virtual Private Cloud)

기본적으로는 VPC를 중심으로 ECS, RDS, S3, CloudFront, Route 53, CloudWatch 등을 활용하여 서비스를 구성하고자 했다. 먼저 장고 애플리케이션과 데이터베이스를 안전하게 배포하기 위해 다음과 같이 VPC 내에서 여러 리소스를 구성해 보았다. 

• 프라이빗 서브넷과 퍼블릭 서브넷을 분리하여 배치한다. 프라이빗 서브넷에서는 ECS Fargate를 사용해 장고 애플리케이션을 실행하고, 퍼블릭 서브넷에서는 ALB를 배치하여 외부 트래픽을 받도록 한다. 
• IGW(인터넷 게이트웨이)는 퍼블릭 서브넷에 인터넷 접속을 제공하기 위해 사용되며, 프라이빗 서브넷에 배치된 ECS Fargate가 인터넷에 접근할 수 있도록 NAT Gateway를 설정한다. 
• Auto-Scaling을 사용하여 트래픽에 맞춰 ECS 서비스를 자동으로 확장하고 축소할 수 있도록 구성한다. (실사용 목적이 아니라 과제 프로젝트이기 때문에 트래픽은 거의 없을 것으로 예상하지만.. 실습을 위해 설계해보았다.)
• 장고 애플리케이션과 연동할 데이터베이스는 RDS(PostgreSQL)을 사용한다. RDS는 VPC 내부 프라이빗 서브넷에 배치하여 보안을 강화하고, ECS Fargate에서 접근할 수 있도록 보안 그룹을 설정한다.
• S3는 리액트 정적 파일과 장고 애플리케이션의 리소스 등을 저장하는데 사용한다. 프론트엔드 배포 시 Cloudfront와 통합하여 CDN 형태로 빠르게 배포한다. 
• CloudWatch를 통해 컨테이너 로그와 메트릭을 실시간으로 확인하고, 문제가 발생했을 때 알림받을 수 있도록 설정한다. 
• 시간이 된다면 Route 53을 통해 DNS 관리까지 통합해보려고 한다. 

전체 아키텍처 구성도

나름 설계한대로 그려봤는데 뭔가 허접한 것 같다. 프로젝트 끝나면 AWS 아이콘으로 제대로 다시 그려봐야겠다. 

 

CI/CD 파이프라인 설계 

본격적으로 웹서비스 개발을 시작하기 전에 모노레포로 리액트와 장고 프로젝트를 세팅하고, Github Actions와 AWS 리소스를 통합하여 main 브랜치에 변경 사항이 반영될 때마다 자동으로 CI/CD 파이프라인이 작동하게 하는 프로세스를 먼저 설계해보고자 한다. GitOps 기반 CI/CD 파이프라인을 위해서는 다양한 기술을 활용할 수 있다. ArgoCD와 같이 요즘 핫한 자동화 도구들도 많지만, 오버엔지니어링을 줄이고 프로젝트 필수 요구사항인 AWS 리소스를 최대한 활용하려고 한다. 

왜 모노레포인가? 

모노레포(Monorepo)는 여러 프로젝트나 서비스를 하나의 저장소에서 관리하는 방식이다. 여러 개의 독립적인 프로젝트들이 하나의 코드베이스에 위치해 있으며, 각 프로젝트가 서로 의존할 수 있도록 구성된다. 사실 모노레포를 선택한 이유는 모노레포로 하지 않아야 할 이유가 없기 때문이라고 생각했기 때문이다. today-movie-frontend, today-movie-backend라는 두 개의 레포를 각각 만들어서 관리할 경우 통합된 CI/CD 파이프라인 구축이 번거로워지기 때문에 각각의 파이프라인을 별도로 관리해야 한다. 따라서 이번 프로젝트와 같이 개발 속도가 중요한 경우 하나의 파이프라인을 통해 여러 프로젝트를 동시에 빌드하고 배포할 수 있는 모노레포로 가는 것이 압도적으로 좋을 것이라고 판단했다. 

 

우선 장고 백엔드 애플리케이션은 AWS 아키텍처 설계대로 EC2가 아닌 Docker 컨테이너 기반으로 빌드하고 배포할 예정이다. 지금같이 비상식적인 수준의 환율을 자랑하는 상황에서는 EC2 구동으로 인해 발생할 수 있는 요금을 조금이라도 줄이는게 맞다고 생각했기 때문이다. EC2 인스턴스를 계속해서 실행시키는 것보다 ECS - ECR - Fargate로 통합되는 서버리스 컨테이너 배포 환경을 구축하는게 훨씬 나은 것 같다. 따라서 이상적인 백엔드 애플리케이션 배포 파이프라인은 아래와 같다. 

 

간단하게 시각화한 CI/CD 파이프라인

 

1. Github에 변경사항을 push하면 Github Actions가 자동으로 트리거

2. 빌드된 React 정적 파일을 S3 버킷에 업로드하고, CloudFront로 배포

3. Django 애플리케이션의 Docker 이미지를 ECR에 푸시 

4. ECS를 사용하여 Fargate로 컨테이너 배포 

 

요약하자면 리액트 프론트엔드는 S3 + CloudFront로, 장고 백엔드는 ECS와 Fargate로 서버리스 컨테이너 환경에서 배포하게 되는 것이다. 

---

 

다음 포스팅에서는 본격적으로 리액트와 장고 애플리케이션 모노레포를 세팅하고 CI/CD 자동화 파이프라인을 구축해볼 것이다. 

To be continued...