스타트업이 RDBMS 대신 선택한 조합: 디프로모션의 AWS 아키텍처 도입기
스타트업에게 있어 기술 스택 선택은 곧 서비스의 속도, 확장성, 그리고 생존력에 직결되는 중요한 문제입니다. 특히 데이터베이스 아키텍처는 초기 개발 속도와 향후 확장 가능성을 동시에 고려해야 하는 까다로운 결정이죠.
오늘은 프로모션 기반 사용자 참여 플랫폼인 디프로모션이 어떻게 DynamoDB, OpenSearch, ElastiCache Serverless의 조합을 통해 기존 RDBMS 기반 구조의 한계를 극복했는지 소개해드리겠습니다.
왜 RDBMS만으로는 부족했는가?
디프로모션의 초기 구조는 전통적인 RDBMS에 기반하고 있었지만, 몇 가지 한계에 직면했습니다:
- 복잡하고 유동적인 데이터 구조: 프로모션별로 다양한 형태의 데이터를 처리해야 하는데, 고정된 스키마 구조를 가진 RDBMS는 자주 변경되는 요구사항에 빠르게 대응하기 어렵습니다.
- 예측 불가능한 트래픽: 특정 프로모션이나 이벤트 시점에는 급격한 트래픽 증가가 발생하는데, 이를 위해 항상 고성능 인프라를 유지하는 것은 비효율적입니다.
- 검색과 집계 성능의 한계: SQL 기반 복잡한 쿼리로는 사용자 행동 집계나 다양한 조건 검색이 성능 문제를 일으킬 수 있습니다.
디프로모션의 선택: 관리형 NoSQL 조합
1. 쓰기 성능을 책임지는 DynamoDB
- DynamoDB 온디맨드 모드를 활용하여 예측할 수 없는 쓰기 트래픽에도 유연하게 대응.
- *Global Secondary Index(GSI)**로 다양한 조회 패턴을 일부 커버하되, 비용을 감안해 주요 패턴만 선택적으로 적용.
- Zero-ETL 파이프라인: **DynamoDB Streams + PITR(Point-in-Time Recovery)**를 활용하여 데이터 변경을 OpenSearch로 실시간 전송.
2. 검색과 집계를 담당하는 OpenSearch
- DynamoDB의 한계를 보완하기 위해 도입.
- 다양한 데이터 구조에 대한 유연한 검색과 복잡한 집계 연산 처리에 최적화.
- 실시간 사용자 참여 데이터를 기반으로 한 랭킹, 통계, 조건 검색 등을 빠르게 수행 가능.
3. 읽기 성능 향상용 ElastiCache Serverless
- 자주 조회되는 데이터는 ElastiCache Serverless에 캐싱하여 DynamoDB 읽기 비용을 절감.
- 평균 응답 시간이 최대 87% 이상 단축, 피크 타임에도 안정적인 성능 유지.
- 필요할 때만 비용이 발생하는 서버리스 캐싱 계층으로 높은 비용 효율성 확보.
전통적인 RDBMS와의 비교
✅ 비용 측면
항목 디프로모션 구조 전통 RDBMS
| 쓰기 처리 비용 | 온디맨드 기반, 탄력적 | 고정 인프라로 유휴 자원 발생 가능 |
| 읽기 비용 | 캐시로 오프로드 | 읽기 부하 증가 시 리소스 증설 필요 |
| 관리 비용 | 완전 관리형, 낮음 | 백업, 스케일링, 운영 부담 큼 |
✅ 성능 측면
항목 디프로모션 구조 전통 RDBMS
| 쓰기 처리 | 대규모 트래픽도 일관된 성능 | 고트래픽 대응 위해 사전 확장 필요 |
| 검색/집계 | OpenSearch로 고성능 대응 | 조인, 필터 쿼리는 가능하나 성능 저하 가능 |
| 읽기 응답 속도 | 캐시로 극적 개선 | 캐시 없는 구조는 응답 지연 가능 |
✅ 운영/관리 측면
항목 디프로모션 구조 전통 RDBMS
| 인프라 관리 | 자동 스케일링, 콘솔 기반 관리 | 수동 튜닝, 샤딩 등 고난도 작업 요구 |
| 시스템 복잡도 | 다중 서비스 운영 필요 | 단일 스택으로 비교적 단순 |
| 데이터 일관성 | eventual consistency 고려 필요 | ACID 트랜잭션으로 높은 일관성 |
결론: 왜 이 조합이 더 나은 선택이었는가?
디프로모션은 다음과 같은 이유로 전통적인 RDBMS 단일 구조 대신, 복합적인 AWS 관리형 서비스 조합을 선택했습니다:
- 비정형 데이터와 유연한 구조 요구
- 예측하기 어려운 트래픽에 대응 가능한 확장성
- 빠른 개발과 낮은 인프라 운영 부담
- 특정 역할에 특화된 데이터 서비스 선택으로 최적 성능 확보
물론 Zero-ETL 파이프라인의 관리, 다중 서비스 운영에 따른 복잡도는 단점으로 남지만, 스타트업의 민첩성과 성장을 고려하면 더 적합한 선택이었음을 확인할 수 있습니다.
마치며
NoSQL과 서버리스 기술은 단순히 “최신 기술”이라서 선택하는 것이 아닙니다. 디프로모션의 사례는 비즈니스 요구사항과 기술적 제약을 균형 있게 고려한 결과물입니다. 동일한 고민을 하고 있다면, 전통적인 RDBMS 구조 외에도 다양한 대안을 실험해보는 것도 좋은 전략이 될 수 있습니다.
디프로모션의 DynamoDB, zero-ETL, ElastiCache Serverless 도입기 | Amazon Web Services