← 프로젝트 목록
EVERY WEAR · AI 가상 피팅
AWS 인프라 설계·구축 · 크롤링 서버 · 배포 자동화
쇼핑몰 상품 링크를 붙여 넣으면 4개 쇼핑몰(무신사·지그재그·29CM·W컨셉)의 상품·리뷰를 수집하고, AI로 사용자 사진에 옷을 합성해 보여주는 서비스입니다.
Spring BootFastAPISeleniumECS FargateSQSRDSCloudWatchTerraformGitHub Actions
2개ECS 서비스로 분리
20여 개Terraform 관리 리소스
최대 3분응답에서 떼어낸 크롤링
1,012MB한도 직전 OOM 원인 규명
프로젝트 목적
옷을 사기 전에 내 사진으로 입어 본 모습과 리뷰 요약을 함께 보여주는 서비스입니다. 상품 수집은 브라우저를 띄워야 하는 무거운 작업이라, 이를 사용자 요청과 어떻게 분리하느냐가 인프라의 핵심이었습니다.
| 기간 | 2025.12 — 2026.02 |
|---|---|
| 링크 | GitHub ↗ |
담당 역할
- AWS 인프라 설계·구축 (VPC 2개 가용 영역, ALB, ECS Fargate, RDS, S3, SQS)
- 리뷰 크롤링 서버(FastAPI + Selenium)와 비동기 처리
- Terraform 코드화, GitHub Actions → ECR → ECS 무중단 배포
- CloudWatch 지표·로그 기반 장애 분석
시스템 구조
주요 구현
1. 요청 접수→2. PENDING 선점→3. SQS 전달→4. 크롤링→5. 상태 조회
- 요청에는 먼저 응답하고, 진행 상태를 DB에 기록해 클라이언트가 5초마다 완료 여부를 확인합니다.
- 크롤링 전에 PENDING 행을 먼저 넣고 Unique 제약을 걸어, 같은 상품을 두 번 크롤링하지 않게 했습니다.
- 블로킹 Selenium 작업은 별도 스레드로 넘기고, 단계별 타임아웃으로 쇼핑몰 지연이 서버 전체로 번지지 않게 했습니다.
- Terraform으로 AWS 리소스 20여 개를 관리하고, GitHub Actions에서 이미지를 빌드해 ECR·ECS로 배포했습니다.
해결 과제
1. 최대 3분 걸리는 크롤링
- 과제
- 리뷰 크롤링이 최대 3분까지 HTTP 응답을 붙잡았고, 크롤러가 백엔드와 같은 서버에 있으면 다른 요청까지 느려졌습니다.
- 접근
- 크롤러를 별도 ECS 서비스로 떼어 자원을 따로 할당하고, 수집 작업은 SQS로 넘겼습니다. 요청에는 바로 응답하고 진행 상태는 DB로 추적합니다.
크롤러 장애가 백엔드로 번지지 않고, 응답 시간이 쇼핑몰 지연과 분리됨
2. 재현되지 않던 OOM
- 과제
- 크롤러 태스크가 반복적으로 메모리 부족으로 종료됐습니다. 로컬에서는 재현되지 않았고, 메모리를 늘려도 같은 현상이 반복됐습니다.
- 원인
- 메모리 그래프에서 요청이 끝나도 내려오지 않고 1,024MB 한도 직전(1,012MB)까지 계단식으로 오르는 패턴을 찾았습니다. 오르는 시점을 타임아웃 로그와 맞춰 보니, 타임아웃 뒤에도 크롤링 스레드가 Selenium 드라이버를 잡고 남아 있었습니다.
- 접근
- 종료 플래그와 페이지 로드 타임아웃으로 스레드와 드라이버를 확실히 회수하게 했습니다.
재현 없이 원인을 찾아 메모리 계단식 누적 해소
남은 한계
- 완료 여부를 클라이언트가 5초마다 물어보는 방식이라, 완료 시점에 알려주는 방식으로 바꿀 여지가 있습니다.