SnowGlow Move to Infra (AWS) 계획

김기수·2026년 4월 26일
aws

1) 현재 통신/데이터 구조 요약

  • Client → Server: job 생성 → 상태 폴링(percent/stage) → 완료 후 오디오 재생
  • Server
    • job 상태: 메모리 Map
    • 변환 결과: server/temp/<jobId>.mp3
    • /youtube/jobs/:jobId/audio는 HTTP Range(206) 지원
    • temp mp3 TTL: 24시간 (seek/Range 요청으로 TTL 갱신 없음)

2) 배포 목표 옵션(우리가 논의한 것)

목표 A — “최소 비용 + 빠른 배포”

  • 프론트: Netlify(또는 S3 정적)
  • 백엔드: EC2 단일(도커/PM2/Nginx)

목표 B — “AWS로 통일 + 운영 안정 + 도메인 1개”

  • 프론트: S3 + CloudFront
  • 백엔드: EC2(+선택적으로 ALB)
  • 도메인 1개에서 /api/* 경로로 백엔드 라우팅

목표 C — “오토스케일/운영 자동화”

  • 백엔드: ECS Fargate (+ALB)
  • 단, 스케일아웃하려면 상태/파일 외부화 필요

목표 D — “서버리스 워크플로(확장/안정)”

  • API: API Gateway + Lambda
  • 변환: Step Functions가 오케스트레이션, 실제 변환은 (대부분) Fargate RunTask/Batch
  • 상태: DynamoDB/Redis
  • 파일/서빙: S3 + CloudFront

3) 옵션별 장단점

3-1) Netlify(프론트) + EC2(백)

  • 장점
    • 프론트 배포가 매우 쉬움(자동 HTTPS/CI/CD)
    • 초기 비용이 낮고 구성 단순
  • 단점
    • 프론트/백 도메인이 분리될 가능성 큼 → CORS 설정 필요
    • 프론트가 https인데 백이 http면 Mixed Content로 막힐 수 있음 → 백도 https 권장

3-2) S3 + CloudFront(프론트) + EC2(백)

  • 장점
    • AWS로 통일(운영/권한/로그/도메인 관리 일원화)
    • 도메인 1개 구성이 깔끔함: example.com + /api/*
    • CloudFront 캐싱/전송이 강력(프론트에 최적)
  • 단점
    • Netlify 대비 설정 요소가 많음(S3 업로드, 캐시 무효화, CF 설정)

3-3) ALB를 붙이는 가치(ASG가 없어도?)

ASG(오토스케일 그룹)가 없어도 ALB는 의미가 있음.

  • ALB의 실익
    • TLS(HTTPS) 종료를 ALB에서 처리(ACM 인증서)
    • 헬스체크/리버스 프록시 구조가 깔끔
    • EC2를 외부에서 직접 노출하지 않고 ALB만 공개 가능(보안 단순화)
  • 하지만
    • 단일 인스턴스면 “부하 분산” 이점은 제한적
    • 비용/구성 복잡도가 증가

3-4) ECS Fargate(백엔드)

  • 장점
    • 배포/롤링업데이트/스케일이 편함
    • 운영 자동화/표준화에 유리
  • 단점(현재 코드 그대로는)
    • job 상태가 메모리 Map이라 태스크 여러 개로 늘리면 jobId가 깨질 수 있음
    • 파일이 로컬 temp라 태스크마다 분리됨
    • “항상 켜두는” 패턴이면 EC2 단일보다 비용이 높아질 수 있음

3-5) Step Functions + Serverless로 가능한가?

  • 가능은 하지만 구조가 바뀜
    • Lambda만으로 yt-dlp 변환을 끝내기는 제약(시간/디스크/실행환경) 때문에 어렵고,
    • 실무에선 Step Functions가 오케스트레이션하고 변환은 Fargate RunTask/Batch로 돌리는 형태가 많음.
  • 장점
    • 실패 재시도/타임아웃/상태 관리/모니터링이 매우 체계적
    • 확장성/내구성(서버 재시작 영향 최소)
  • 단점
    • 초기 구현/운영 복잡도가 크게 증가

4) “job 상태”와 “파일”을 어디에 둘 것인가?

단일 서버(EC2 1대)일 때

  • job 상태: 메모리(Map)로도 일단 가능(단, 재시작 시 유실)
  • 파일: 로컬 temp + TTL(현재 24시간)로 충분

스케일아웃(멀티 인스턴스/멀티 태스크)로 갈 때(정석)

  • job 상태
    • NFS(EFS)로 해결하는 문제가 아님 (NFS는 파일 공유)
    • Redis(ElastiCache) / DynamoDB 같은 키-값 저장소로 외부화
  • 파일
    • 추천: S3 저장 + CloudFront로 서빙
    • 대안: EFS(공유 디스크)도 가능하지만 운영/비용/지연 고려 필요

5) 오디오 서빙을 S3(+CloudFront)로 빼는 이유(확장/비용)

변환량이 늘면 mp3 트래픽(egress)이 비용과 서버 부하를 지배할 수 있음.

  • 서버가 직접 mp3를 스트리밍하면:
    • 서버 네트워크/CPU/IO 부하 증가
    • 스케일링/캐싱이 어려움
  • S3 + CloudFront로 빼면:
    • 서버는 “변환 + job 관리”만 담당
    • Range/seek는 CDN이 처리
    • TTL은 S3 Lifecycle(예: 1일 삭제)로 관리 가능

6) 최소 비용 추천(요약)

“진짜 최소 비용 + 단순” (추천 1순위)

  • 프론트: Netlify
  • 백엔드: EC2 단일(도커/PM2) + https 처리(Nginx + Let’s Encrypt 또는 ALB)

“AWS로 통일 + 도메인 1개 + 운영 깔끔” (추천 2순위)

  • 프론트: S3 + CloudFront
  • 백엔드: EC2(필요시 ALB)
  • 라우팅: example.com 기본은 S3, /api/*는 백엔드

7) 도메인/HTTPS 관련 결론

  • 프론트가 https면 백엔드가 http인 상태로 브라우저에서 직접 호출하면 Mixed Content로 막힐 가능성이 높음.
  • 운영 배포에서는 백엔드도 https를 맞추는 것을 권장.
  • 도메인 하나로 합치려면 CloudFront의 path routing(/api/*) 구조가 깔끔.

8) 실행 체크리스트(“AWS로 통일”을 목표로 할 때)

  • S3 버킷 생성 + 정적 파일 업로드 + CloudFront 연결
  • CloudFront 배포에서 /api/*를 백엔드 오리진으로 라우팅
  • 백엔드(EC2) 보안그룹: 80/443(또는 ALB만 공개) + 내부 3000 포트 정책 정리
  • 클라이언트 API Base URL 정책
    • 배포에서 기본 /api 사용(권장) 또는 VITE_API_BASE_URL=https://example.com/api
  • 서버 CORS ALLOWED_ORIGINS 설정(필요한 경우)

9) 저장소

profile
김기수
엄청난 클라우드 고수
이전 포스트

SnowGrow 프로젝트) Client ↔ Server Job Polling ↔ Audio Range Streaming + TTL 운영

다음 포스트

SnowGlow 배포 기록: YouTube → MP3 변환을 CloudFront/S3로 안정화하기

0개의 댓글