Amazon RDS

주문이나 결제 데이터를 다루는데 데이터베이스를 직접 설치해 두면 새벽 장애 대응, 백업 확인, 패치 일정이 모두 팀 일감이 됩니다. 트랜잭션이 많아질수록 데이터 자체보다 운영 부담이 더 빠르게 커집니다.

예전에는 MySQL이나 PostgreSQL을 VM에 직접 설치하고 복제와 백업을 스크립트로 관리해야 했습니다. 이 반복적인 운영 부담을 줄이기 위해 데이터베이스 엔진 운영을 서비스가 대신 맡아주는 RDS 같은 모델이 등장했습니다.

RDS의 핵심은 장애와 부하를 자동으로 흡수하는 이중화 메커니즘입니다. Multi-AZ 배포를 켜면 RDS는 프라이머리 인스턴스의 쓰기를 다른 가용 영역의 스탠바이에 동기 복제합니다. 프라이머리에 장애가 발생하면 RDS가 수십 초 안에 이를 감지하고, 스탠바이를 새 프라이머리로 승격시킨 뒤 DNS 엔드포인트를 전환합니다. 애플리케이션은 같은 엔드포인트를 바라보고 있으므로 연결만 재시도하면 됩니다. Read Replica(읽기 전용 복제본)는 다른 경로로 부하를 분산합니다. 원본의 변경 사항을 비동기로 복제본에 흘려보내고, 읽기 요청은 복제본이 처리합니다. 원본 인스턴스는 쓰기 처리에 집중할 수 있고, 복제본을 여러 개 붙이면 읽기 트래픽이 늘어도 원본에 병목이 생기지 않습니다. 결국 애플리케이션 팀은 엔드포인트만 바라보고, 장애 전환·복제·백업 검증은 서비스가 계속 맡습니다.

RDS와 DynamoDB는 둘 다 데이터를 저장하지만 데이터 모델과 운영 방식이 다릅니다. RDS는 조인, 트랜잭션, 스키마가 중요한 관계형 워크로드에 맞고, DynamoDB는 키 기반의 대규모 저지연 접근에 더 적합합니다. ElastiCache와의 경계도 자주 헷갈립니다. 둘 다 데이터를 다루지만 RDS는 영구 저장소이고 ElastiCache는 휘발성 캐시입니다. RDS에 저장된 데이터는 디스크에 기록되고 백업·복구가 가능하지만, ElastiCache는 메모리에만 두기 때문에 노드가 내려가면 데이터가 사라질 수 있습니다. 원본 데이터 정합성이 필요하면 RDS를 보고, 반복 조회의 응답 시간과 DB 부하를 줄이는 게 목적이면 ElastiCache를 앞에 두는 구조를 봅니다.

주문이나 결제처럼 정합성과 SQL이 중요한 시스템에서 원본 저장소 역할을 맡습니다. 트래픽이 늘어 읽기 병목이 보이기 시작하면 Read Replica를 붙여 리포트 쿼리나 대시보드 조회를 복제본으로 돌릴 수 있습니다. 원본은 트랜잭션 쓰기에 집중하고, 분석이나 조회 부하는 복제본이 맡는 구조입니다. 자동 스냅샷은 매일 지정한 시간에 백업을 만들고, 장애 시 특정 시점으로 복원할 수 있어 실수로 데이터를 날려도 되돌릴 여지가 생깁니다. 스키마 없이 키 기반으로 대규모 저지연 조회가 필요하거나, 읽기 병목을 캐시로 해결해야 하는 경우에는 맞지 않습니다.