이벤트 버퍼 저장소로서의 AWS 서비스 비교(DynamoDB vs RDS vs S3)
목적: WMS → 기간계 수불이벤트 배치 전송 시 임시 저장소 아키텍처 선정
📋 목차
1. 배경 및 요구사항
1.1 현재 상황
- 시스템 구성: WMS 서버와 기간계 서버 분리
- 데이터 전송: 배치 단위로 수불이벤트 전송
- 전송 규모: 최대 10만건/배치
- 처리 방식: 즉시 처리가 아닌 순차적 후처리 필요
1.2 기술 요구사항
| 항목 | 요구사항 |
|---|---|
| Write 성능 | 10만건을 빠르게 저장 |
| 내구성 | 데이터 유실 방지 |
| 순차 처리 | 이벤트 순서 보장 |
| 재처리 | 실패 시 재처리 가능 |
| 모니터링 | 처리 상태 추적 |
1.3 현재 기술 스택
- Database: PostgreSQL (RDS)
- ORM: MyBatis
- Infrastructure: AWS ECS, RDS, DynamoDB, SQS
- Language: Kotlin, Java
2. DynamoDB 개요
2.1 DynamoDB란?
AWS의 완전관리형 NoSQL 데이터베이스로, key-value 형태로 데이터를 저장합니다.
2.2 주요 장점
성능 & 확장성
- ✅ 10ms 이하의 빠른 읽기/쓰기 속도
- ✅ 수평적 확장 용이 (초당 수천 건 처리)
- ✅ 3개 가용 영역에 자동 복제
운영 편의성
- ✅ 완전 관리형 서비스 (서버 관리 불필요)
- ✅ Auto Scaling 지원
- ✅ 스키마 자유로움
2.3 주요 단점
기능적 제약
- ❌ 테이블 간 관계(JOIN) 미지원
- ❌ 트랜잭션 지원 제한적
- ❌ ORM 라이브러리 부족
- ❌ 복잡한 쿼리 제한
비용 문제 (가장 큰 약점)
- ❌ Hot Partition 처리 시 비용 폭증
- ❌ 데이터 증가 시 파티션당 처리량 감소 → 비용 증가
- ❌ Write 비용 높음, 강력한 일관성 읽기는 2배
- ❌ 테스트/개발 환경도 동일 비용
- ❌ 캐싱(DAX) 필요 시 추가 비용
2.4 적합한 사용 사례
✅ DynamoDB가 적합한 경우
- 단순한 key-value 조회가 주된 워크로드
- 빠른 읽기 성능이 중요
- 운영 부담을 줄이고 싶을 때
- 게임, 모바일 앱, 세션/로그 저장
❌ DynamoDB를 피해야 할 경우
- 복잡한 관계형 쿼리 필요
- 강력한 트랜잭션 필수
- 비용 최적화가 중요 (특히 빠르게 증가하는 데이터)
- 복잡한 집계 연산 필요
3. 아키텍처 옵션 비교
3.1 비교 대상
| 옵션 | 구조 | 특징 |
|---|---|---|
| A | DynamoDB + SQS FIFO | 서버리스, 고성능 |
| B | PostgreSQL + SQS FIFO | 기존 스택 활용 |
| C | SQS FIFO 단독 | 가장 단순 |
| D | S3 + SQS | 파일 기반, 저비용 |
3.2 아키텍처 흐름도
옵션 A: DynamoDB + SQS FIFO
WMS (10만건 배치)
↓
[1] API 수신 → DynamoDB 병렬 저장 (3-5초)
↓
[2] DynamoDB Query → SQS FIFO 전송
↓
[3] Worker가 순차 처리 → 상태 업데이트옵션 B: PostgreSQL + SQS FIFO
WMS (10만건 배치)
↓
[1] API 수신 → PostgreSQL Bulk Insert (10-20초)
↓
[2] PostgreSQL Query → SQS FIFO 전송
↓
[3] Worker가 순차 처리 → 상태 업데이트옵션 C: SQS FIFO 단독
WMS (10만건 배치)
↓
[1] API 수신 → SQS FIFO 직접 전송 (30-100초)
↓
[2] Worker가 순차 처리
※ 별도 저장소 없음, 14일 보관 제한옵션 D: S3 + SQS
WMS (10만건 배치)
↓
[1] API 수신 → S3 파일 업로드 (2-3초)
↓
[2] S3 Event → SQS 메시지
↓
[3] Worker가 파일 다운로드 → 순차 처리4. 상세 비교 분석
4.1 핵심 지표 비교
| 비교 항목 | DynamoDB | PostgreSQL | SQS FIFO 단독 | S3 |
|---|---|---|---|---|
| Write 성능 | ⭐⭐⭐⭐⭐ 병렬 처리 초당 수만건 | ⭐⭐⭐⭐ Bulk Insert 튜닝 필요 | ⭐⭐⭐ 초당 3천~1만 (제한적) | ⭐⭐⭐⭐⭐ 단일 파일 매우 빠름 |
| Read 성능 | ⭐⭐⭐⭐⭐ 10ms 이하 파티션별 병렬 | ⭐⭐⭐⭐ 인덱스 활용 안정적 | ⭐⭐⭐⭐ 큐에서 순차 읽기 | ⭐⭐⭐ 파일 다운로드 레이턴시 높음 |
| 10만건 저장 | 3-5초 | 10-20초 | 30-100초 | 2-3초 |
| 월 비용 (30회) | $7-10 | $5-15 | $3-5 | $1-2 |
| 운영 복잡도 | ⭐⭐⭐ 새로운 학습 | ⭐⭐⭐⭐⭐ 기존 스택 | ⭐⭐⭐⭐ 단순하지만 제약 많음 | ⭐⭐ 파일 관리 복잡 |
| 내구성 | ⭐⭐⭐⭐⭐ 3 AZ 복제 | ⭐⭐⭐⭐⭐ Multi-AZ | ⭐⭐⭐⭐ 14일 보관 | ⭐⭐⭐⭐⭐ 99.999999999% |
| 재처리 용이성 | ⭐⭐⭐⭐⭐ 상태별 조회 쉬움 | ⭐⭐⭐⭐⭐ SQL 조회 유연함 | ⭐⭐⭐ DLQ만 가능 | ⭐⭐⭐⭐ 파일 재처리 |
| 모니터링 | ⭐⭐⭐⭐ CloudWatch | ⭐⭐⭐⭐⭐ SQL 쿼리 | ⭐⭐⭐ 메시지 추적 | ⭐⭐ 파일 로그 |
4.2 비용 상세 분석 (월 30회, 회당 10만건 기준)
옵션 A: DynamoDB + SQS FIFO
DynamoDB Write: $0.125/회
DynamoDB Read: $0.025/회
DynamoDB Storage: $0.175/회 (7일 보관)
SQS FIFO: $0.10/회
월 비용: ($0.125 + $0.025 + $0.175 + $0.10) × 30 = $12.75옵션 B: PostgreSQL + SQS FIFO
RDS 추가 용량: 기존 RDS 사용 시 미미
RDS 추가 IOPS: $5-10 (일시적 증가)
SQS FIFO: $3
월 비용: $5-15 (기존 RDS 여유에 따라)옵션 C: SQS FIFO 단독
SQS FIFO 메시지: $0.05/회
메시지 보관: 무료 (14일)
월 비용: $0.05 × 30 = $1.5
※ 가장 저렴하지만 저장소 없음옵션 D: S3 + SQS
S3 PUT + Storage: 거의 무시 가능
SQS Standard: $0.10/회
월 비용: $0.10 × 30 = $3
※ 가장 저렴하고 용량 무제한4.3 성능 상세 비교 (10만건 기준)
| 작업 단계 | DynamoDB | PostgreSQL | SQS FIFO | S3 |
|---|---|---|---|---|
| 수신→저장 | 3-5초 | 10-20초 | 30-100초 | 2-3초 |
| 저장→조회 | 즉시 | 즉시 | N/A | 즉시 |
| 조회→SQS 전송 | 5-10초 | 5-10초 | 즉시 | 10-20초 |
| 전체 파이프라인 | 10-15초 | 15-30초 | 30-100초 | 15-25초 |
| 동시 배치 처리 | ✅ 가능 | ⚠️ 제한적 | ❌ 어려움 | ✅ 가능 |
4.4 운영 관점 비교
장애 대응
| 시나리오 | DynamoDB | PostgreSQL | SQS FIFO | S3 |
|---|---|---|---|---|
| 저장 실패 | 자동 재시도 부분 성공 처리 | 트랜잭션 롤백 전체 재시도 | N/A | 파일 재업로드 |
| 처리 중 장애 | 상태별 조회 재처리 쉬움 | SQL 조회 유연한 재처리 | DLQ 활용 제한적 | 파일 재처리 |
| 유실 위험 | 거의 없음 | 백업 시 안전 | 14일 제한 | 거의 없음 |
모니터링 & 디버깅
| 항목 | DynamoDB | PostgreSQL | SQS FIFO | S3 |
|---|---|---|---|---|
| 처리 상태 추적 | ✅ 항목별 상태 CloudWatch | ✅ SQL 조회 로그 테이블 | ⚠️ 메시지 속성 제한적 | ❌ 파일 단위만 |
| 배치 진행률 | ✅ Count 조회 실시간 | ✅ SQL 집계 실시간 | ⚠️ SQS 메트릭 근사치 | ❌ 외부 관리 필요 |
| 특정 이벤트 조회 | ✅ Key 조회 빠름 | ✅ 인덱스 조회 빠름 | ❌ 불가능 | ❌ 파일 파싱 |
| 장애 원인 분석 | 보통 | 매우 좋음 | 제한적 | 어려움 |
5. 의사결정 가이드
5.1 우선순위별 추천
| 최우선 요구사항 | 1순위 | 2순위 | 3순위 |
|---|---|---|---|
| 빠른 Write 성능 | DynamoDB | S3 | PostgreSQL |
| 비용 최소화 | S3 | SQS 단독 | PostgreSQL |
| 운영 안정성 | PostgreSQL | DynamoDB | S3 |
| 빠른 구현 | PostgreSQL | SQS 단독 | DynamoDB |
| 확장성 | DynamoDB | S3 | PostgreSQL |
| 디버깅 용이성 | PostgreSQL | DynamoDB | S3 |
| 기존 스택 활용 | PostgreSQL | - | - |
5.2 시나리오별 추천
📌 시나리오 1: 안정성 최우선, 빠른 구현
추천: PostgreSQL + SQS FIFO
이유:
✅ 기존 스택 활용으로 빠른 구현
✅ 팀 전체가 익숙한 기술
✅ 트랜잭션으로 안정성 보장
✅ SQL로 유연한 디버깅
단점:
⚠️ 성능 튜닝 필요
⚠️ RDS 용량 관리 필요📌 시나리오 2: 성능 최우선, 서버리스 선호
추천: DynamoDB + SQS FIFO
이유:
✅ 가장 빠른 Write 성능
✅ Auto Scaling으로 확장성
✅ 운영 부담 최소화
✅ 향후 트래픽 증가 대응
단점:
⚠️ 비용이 가장 높음 ($12/월)
⚠️ 새로운 기술 학습 필요
⚠️ 복잡한 쿼리 제한적📌 시나리오 3: 비용 최소화, 실시간성 덜 중요
추천: S3 + SQS Standard
이유:
✅ 가장 저렴한 비용 ($3/월)
✅ 대용량 처리 유리
✅ 파일 자체가 백업
✅ 무제한 용량
단점:
⚠️ 처리 복잡도 높음
⚠️ 레이턴시 증가
⚠️ 실시간 조회 어려움📌 시나리오 4: 단순함 추구
추천: SQS FIFO 단독 (조건부)
이유:
✅ 가장 단순한 구조
✅ 가장 저렴 ($1.5/월)
✅ 빠른 구현
단점:
⚠️ 저장소 없음 (14일 제한)
⚠️ 재처리 제한적
⚠️ 처리량 제약 (30-100초)
⚠️ 디버깅 어려움
※ 조건: 14일 보관으로 충분하고, 재처리 로직이 간단한 경우만5.3 장단점 종합 비교
옵션 A: DynamoDB + SQS FIFO
✅ 장점
• 빠른 성능 (3-5초 저장)
• 무제한 확장성
• 서버리스 운영
• 높은 내구성
• 상태 추적 용이
❌ 단점
• 새로운 기술 학습 필요
• 비용이 가장 높음 ($12/월)
• 복잡한 쿼리 제한적
• 기존 스택과 이질적옵션 B: PostgreSQL + SQS FIFO
✅ 장점
• 기존 스택 활용
• 팀 전체 익숙
• SQL로 유연한 조회
• 트랜잭션 보장
• 중간 비용 ($5-15/월)
• 디버깅 용이
❌ 단점
• RDS 용량 관리 필요
• 성능 튜닝 필요
• 확장성 한계
• 동시 배치 처리 제한적옵션 C: SQS FIFO 단독
✅ 장점
• 가장 단순한 구조
• 가장 저렴 ($1.5/월)
• 빠른 구현
❌ 단점
• 저장소 없음 (14일 제한)
• 재처리 제한적
• 처리량 제약 (30-100초)
• 디버깅 어려움
• 배치 진행률 추적 어려움옵션 D: S3 + SQS
✅ 장점
• 매우 저렴 ($3/월)
• 무제한 용량
• 파일 자체가 백업
• 대용량 처리 유리
❌ 단점
• 처리 복잡도 높음
• 레이턴시 증가
• 실시간 조회 어려움
• 파일 관리 부담
• 상태 추적 복잡5.4 의사결정 체크리스트
- 성능 요구사항: 10만건을 20초 내 저장 가능한가?
- 비용 예산: 월 예산이 $10 이하인가?
- 운영 리소스: 신규 기술 학습 시간이 있는가?
- 확장 계획: 향후 배치 크기/빈도 증가 예상되는가?
- 모니터링: 처리 상태 추적 및 디버깅 방안이 있는가?
- 재해 복구: 장애 시 재처리 방안이 명확한가?
📚 참고 자료
일하며 겪은 문제를 나눠요