Amazon RDS

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

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

RDS가 운영 부담을 줄여주는 방식은 단순한 기능 제공이 아니라 실제 작업을 대신 처리해주는 구조에서 나옵니다. 직접 운영하면 스스로 해야 하는 일련의 과정, 즉 매일 백업 스크립트가 돌았는지 확인하고, 엔진 패치를 테스트 환경에서 먼저 적용해보고, 장애가 나면 대기 서버로 수동 전환하는 일들을 RDS가 맡습니다. Multi-AZ 배포를 켜두면 RDS가 다른 가용 영역에 대기 인스턴스를 유지하다가 장애 감지 시 자동으로 전환하므로, 팀이 새벽에 수동 개입할 일이 없어집니다. 읽기 복제본은 원본에 쌓이는 읽기 트래픽을 분산시켜 원본 인스턴스가 쓰기 처리에 집중할 수 있게 합니다. 결국 애플리케이션 팀은 SQL 접속 엔드포인트만 바라보고, 그 아래의 이중화·패치·백업 검증은 서비스가 계속 돌봅니다.

RDS와 DynamoDB는 둘 다 데이터를 저장하지만 데이터 모델과 운영 방식이 다릅니다. RDS는 조인, 트랜잭션, 스키마가 중요한 관계형 워크로드에 맞고, DynamoDB는 키 기반의 대규모 저지연 접근에 더 적합합니다.

주문, 결제, 회원, ERP처럼 정합성과 SQL이 중요한 업무 시스템에 적합합니다. 스키마 없이 키 기반으로 대규모 저지연 조회가 필요하거나, 읽기 병목을 캐시로 해결해야 하는 경우에는 맞지 않습니다.