RDS 와 Aurora, Aurora DSQL (관계형 데이터베이스 고르기와 운영)

무엇을 고르나

RDS 의 고가용성 두 방식

Multi-AZ 는 고가용성용이고, 읽기 확장은 읽기 복제본(비동기)으로 합니다. 둘을 헷갈리면 "Multi-AZ 인데 왜 읽기가 안 분산되지?" 하는 질문이 나옵니다.

Aurora 의 구조

Aurora 는 컴퓨트와 스토리지를 나눕니다. 스토리지는 세 AZ 에 걸쳐 6 개 사본을 두고 자동으로 늘어나며, 쓰기 인스턴스와 읽기 복제본이 같은 스토리지를 함께 봅니다. 그래서 복제본 지연이 보통 수십 ms 수준이고, 장애가 나면 복제본 하나가 쓰기 인스턴스로 승격됩니다.

• 엔드포인트: 클러스터(쓰기), 리더(읽기 분산), 사용자 지정, 인스턴스 엔드포인트. 애플리케이션은 인스턴스 주소가 아니라 클러스터, 리더 엔드포인트를 씁니다.
• 스토리지 구성: Standard(I/O 요청마다 과금)와 I/O-Optimized(I/O 요금 없음, 인스턴스와 스토리지 단가가 높음). I/O 비용이 전체 Aurora 비용의 25% 를 넘으면 I/O-Optimized 가 대개 유리합니다.
• 빠른 복제(clone): 쓰기 시 복사 방식이라 큰 DB 도 몇 분 만에 테스트용 사본을 만듭니다.
• 역추적(Backtrack, MySQL): 실수로 지운 데이터를 클러스터째 과거 시점으로 되돌립니다.

Aurora Serverless v2

용량을 ACU(Aurora Capacity Unit, 약 2 GiB 메모리) 단위로 0.5 씩 자동 조절합니다. 2024-11 부터 최소 0 ACU 까지 내려가 일정 시간 접속이 없으면 자동 일시 정지할 수 있어서, 개발과 스테이징 DB 비용이 크게 줄었습니다. 다시 깨어날 때는 몇 초가 걸리니 운영의 첫 요청 지연에 민감하면 최소값을 0.5 이상으로 둡니다. 프로비저닝 인스턴스와 한 클러스터에 섞어 쓸 수 있습니다.

Global Database

한 리전의 Aurora 클러스터를 다른 리전(최대 여러 개)으로 스토리지 수준에서 복제합니다. 보통 1 초 미만의 복제 지연이고, 리전 장애 때 보조 리전을 승격합니다. 계획된 전환(switchover)은 데이터 손실 없이, 장애 조치(failover)는 약간의 손실 가능성을 감수하고 빠르게 합니다. 서울을 주 리전으로, 도쿄나 오사카를 보조로 두는 구성이 흔합니다.

Aurora DSQL

Aurora DSQL 은 2024-12 에 Preview 로 공개되어 2025-05 에 GA 된 서버리스 분산 SQL 데이터베이스입니다. PostgreSQL 호환이고, 인스턴스나 용량을 정하지 않습니다.

• 단일 리전 클러스터는 여러 AZ 에 걸쳐 액티브-액티브로 돌고, 다중 리전 클러스터는 두 리전이 모두 읽고 쓰며 세 번째 리전이 감시(witness) 역할을 합니다. 서울은 2025-07 부터 단일, 다중 리전 클러스터 모두 지원하고, 다중 리전 조합에 도쿄, 오사카를 쓸 수 있습니다. 2026-07 기준 다중 리전 클러스터는 16 개 리전에서 지원합니다.
• 낙관적 동시성 제어를 씁니다. 잠금을 기다리지 않고 커밋 때 충돌을 검사하므로, 같은 행을 동시에 고치면 한쪽 트랜잭션이 실패합니다. 애플리케이션에 재시도 로직이 꼭 있어야 합니다.
• 트랜잭션 하나가 바꿀 수 있는 행 수, 크기, 시간에 한도가 있고, 외래 키 제약, 트리거 같은 일부 PostgreSQL 기능은 지원하지 않거나 다르게 동작합니다. 이전 전에 Aurora DSQL 사용 설명서의 PostgreSQL 호환성 항목를 꼭 확인합니다.
• 인증은 비밀번호 대신 IAM 으로 만든 토큰을 씁니다.

aws dsql generate-db-connect-admin-auth-token --hostname abc123.dsql.ap-northeast-2.on.aws --region ap-northeast-2

DSQL 은 "리전 장애에도 쓰기가 멈추면 안 되는" 결제, 재고, 세션 같은 시스템에 맞고, 복잡한 조인과 긴 배치 트랜잭션이 많은 기존 OLTP 를 그대로 옮기는 용도로는 맞지 않을 수 있습니다.

연결 관리

• Lambda 처럼 연결을 많이 여닫는 클라이언트는 RDS Proxy 로 연결을 풀링합니다. 장애 조치 시간도 줄어듭니다.
• 비밀번호는 Secrets Manager 로 관리하고 자동 교체(rotation)를 켭니다. RDS 는 마스터 비밀번호를 Secrets Manager 에 맡기는 통합 기능이 있습니다.
• IAM 데이터베이스 인증을 쓰면 비밀번호 없이 토큰으로 접속할 수 있습니다(초당 새 연결 수 한도에 주의).

업그레이드와 연장 지원

엔진 메이저 버전의 표준 지원이 끝나면 RDS 와 Aurora 는 RDS 연장 지원으로 자동 등록되고 vCPU 시간당 추가 요금이 붙습니다. 연장 지원 요금은 기간이 지날수록 오르니, 표준 지원 종료일을 캘린더에 넣고 미리 올립니다.

• 블루/그린 배포: 운영 DB 를 복제한 그린 환경에서 메이저 업그레이드와 파라미터 변경을 미리 해 두고, 보통 1 분 안팎의 전환으로 바꿉니다.
• 업그레이드 전에 스냅숏을 뜨고, 파라미터 그룹을 새 버전용으로 준비합니다.

비용 팁

• Database Savings Plans(2025-12): Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS 에 1 년 시간당 약정으로 할인을 받습니다. 서버리스는 최대 35%, 프로비저닝 인스턴스는 최대 20% 입니다. 엔진과 인스턴스 패밀리를 바꿔도 적용되는 것이 예약 인스턴스와의 차이입니다.
• 개발 DB 는 Serverless v2 의 0 ACU 나 야간 중지(RDS 는 최대 7 일 중지 후 자동 시작)를 씁니다.
• 스냅숏 보존 기간과 수동 스냅숏을 정리합니다. 수동 스냅숏은 DB 를 지워도 남습니다.
• Graviton 인스턴스(db.r8g, db.m7g 등)는 같은 크기의 x86 보다 단가가 낮습니다.

자주 하는 실수

• 퍼블릭 액세스 가능 옵션을 켬: 데이터 서브넷에 두고 퍼블릭 접근을 끕니다.
• 기본 파라미터 그룹 사용: 기본 그룹은 고칠 수 없습니다. 처음부터 사용자 지정 그룹을 만듭니다.
• 스토리지 자동 확장 없이 가득 참: RDS 는 스토리지가 가득 차면 쓰기가 멈춥니다. 자동 확장과 FreeStorageSpace 경보를 겁니다.
• 장애 조치 후 DNS 캐시: JVM 의 DNS 캐시 TTL 이 길면 옛 쓰기 인스턴스로 계속 붙습니다. TTL 을 짧게(예: 5 초) 둡니다.