Phantom File
SNS 파일 공유 시 서버 영구 기록 및 만료 누락 문제를 해결하는 휘발성 보안 파일 공유 서비스
$5 미만
월 운영비
671ms
P99 응답 속도
100%
장애 재처리 성공률
0건
요청 유실
DynamoDB 선택 - 설계 문서
1회성 파일 공유 서비스의 데이터 접근 패턴 분석과 DB 의사결정 과정
Problem
→ 키-값 단건 조회만 필요한 휘발성 파일 공유 서비스에서 RDS는 오버스펙이었습니다.
파일을 업로드하면 만료 시간이 지나면 자동 삭제되는 1회성 공유 서비스입니다. 데이터 접근 패턴은 파일 ID로 단건 조회, 상태 갱신(업로드 완료·만료·삭제)이 전부이며, 여러 파일을 조건으로 묶거나 집계하는 쿼리는 없습니다.
- ▸단순 키-값 조회만 필요한데 RDS의 복잡한 JOIN·집계 기능이 불필요
- ▸Lambda 동시 실행 수 × 커넥션 = 풀 초과 — 서버리스 환경에서 RDS 커넥션 풀 고갈 문제 발생
- ▸TTL 기반 자동 만료가 핵심인데 RDS는 별도 스케줄러/크론잡이 필요
- ▸인스턴스 유지 비용·패치 등 운영 부담이 개인 프로젝트에 과도함
Trade-off
→ 키-값 접근 패턴, 서버리스 친화성, TTL 네이티브 지원을 근거로 DynamoDB를 선택했습니다.
장점
- 복잡한 JOIN 쿼리와 집계 분석에 유리
- 트랜잭션 처리가 강력함
- 익숙한 SQL 기반 데이터 모델링
단점
- 이 서비스에선 복잡한 쿼리가 필요한 시나리오가 없어 오버스펙
- Lambda 동시 실행마다 커넥션을 점유해 풀 고갈 위험 (동시 실행 수 × 커넥션 = 풀 초과)
- TTL 만료 처리를 위해 별도 스케줄러/크론잡 구성 필요
- 인스턴스 고정 비용 발생 및 패치·운영 부담
장점
- 파일 ID 기반 키-값 단건 조회에 최적
- 네이티브 서버리스 연동 — 커넥션 풀 관리 불필요
- TTL 네이티브 지원 + Streams 연동으로 만료 파이프라인 자연스럽게 구성
- 완전 관리형으로 운영 부담 없음
- 요청량 비례 과금으로 유휴 비용 제로
단점
- 복잡한 쿼리 불가능 — 이 서비스에서 필요한 통계가 없으므로 현재는 허용 가능
- 비용 예측이 어려움 — 개인 서비스 규모에서 실제 측정 필요
- 향후 관리자 대시보드 등 추가 시 DynamoDB 한계에 부딪힐 수 있음
의사결정
이 서비스에서 복잡한 쿼리가 필요한 시나리오가 없고, 서버리스 아키텍처에서 RDS 커넥션 풀 고갈 문제(Lambda 동시 실행 수 × 커넥션 = 풀 초과)가 발생하며, TTL → Streams 연동이 이 서비스의 핵심 파이프라인 시작점이기 때문에 DynamoDB를 선택해야 자연스러운 흐름이 만들어진다고 판단했습니다.
Trade-off: 복잡한 통계 쿼리가 불가능하지만 현재 필요한 통계가 없으므로 허용 가능합니다. 향후 관리 기능(관리자 대시보드 등) 추가 시 DynamoDB 한계에 부딪힐 수 있으며, 이 시점이 오면 설계를 재검토할 것입니다.
Architecture
→ 파일 ID 기반 단건 조회 + TTL 자동 만료 + Streams 연동으로 서비스 핵심 파이프라인을 구성했습니다.
DynamoDB 테이블에 파일 메타데이터(파일 ID, 링크, 만료 시각, 상태)를 저장하고, TTL 속성으로 만료 시각을 설정합니다. TTL 만료 시 Streams에 REMOVE 이벤트가 기록되어 후속 삭제 파이프라인의 시작점이 됩니다. 파일 자체는 S3 Pre-signed URL을 통해 클라이언트가 직접 업로드/다운로드하며, Lambda는 메타데이터 처리와 URL 발급만 담당합니다.
구현 흐름
- 1DynamoDB 테이블 설계: 파일 ID를 파티션 키로, 만료 시각을 TTL 속성으로 설정
- 2파일 업로드 시 메타데이터(링크, 만료 시각, 상태) 저장 및 TTL 자동 설정
- 3TTL 만료 → DynamoDB Streams REMOVE 이벤트 → 후속 삭제 파이프라인 트리거
- 4S3 Pre-signed URL 발급으로 Lambda 파일 중계 제거 → API Gateway 10MB 제한 회피
- 5Terraform IaC로 DynamoDB 테이블 및 전체 인프라 코드화
Verification
→ 월 운영비 $5 이하 달성, 파일 조회 P99 671ms의 안정적인 응답 성능을 확보했습니다.
DynamoDB 도입으로 RDS 대비 운영 비용과 관리 부담을 대폭 절감하고, 키-값 조회 성능을 검증했습니다.
$5 이하
월 운영비
DynamoDB 요청량 비례 과금 + Lambda 사용량 과금으로 유휴 비용 제로
671ms
파일 조회 P99 응답 시간
DynamoDB 단건 조회 기반, K6 부하테스트 10분간 약 9,800건 처리 기준
불필요
커넥션 풀 관리
DynamoDB HTTP API 기반으로 Lambda 동시 실행 시에도 커넥션 고갈 없음
Retrospective
→ 관리자 대시보드 등 복잡한 쿼리가 필요한 시점이 오면 설계를 재검토할 것입니다.
한계점
DynamoDB는 복잡한 통계 쿼리(다중 조건 필터, 집계, JOIN)를 지원하지 않아, 향후 관리자 대시보드나 분석 기능 추가 시 한계에 부딪힐 수 있습니다.
보완 방향
현재는 필요한 통계가 없으므로 허용 가능하며, 관리 기능이 필요한 시점에 DynamoDB Streams → S3 → Athena 파이프라인으로 분석 레이어를 분리하거나, 해당 기능만 RDS로 이관하는 방식을 검토할 수 있습니다.
한계점
요청량 비례 과금 구조로 트래픽이 급증하면 비용 예측이 어렵습니다.
보완 방향
DynamoDB Auto Scaling의 최대 용량 제한 설정과 CloudWatch 비용 알람을 구성하여 예상치 못한 비용 급증을 사전에 감지할 수 있습니다. 현재 개인 서비스 규모에서 실제 월 $5 이하로 운영 중입니다.