데이터베이스 서비스 RDS와 DynamoDB

데이터베이스는 애플리케이션의 기억장치다

웹 서비스는 데이터를 기억해야 한다. 회원 정보, 주문 내역, 게시글, 댓글, 장바구니, 로그인 기록이 모두 데이터베이스에 저장된다. EC2 서버가 애플리케이션을 실행하는 몸이라면, 데이터베이스는 서비스의 기억장치다.

그래서 데이터베이스 선택은 단순히 "어떤 서비스를 쓸까?"의 문제가 아니다. 나중에 데이터를 어떻게 조회할지, 장애가 났을 때 얼마나 빨리 복구할지, 사용자가 늘어날 때 어떤 방식으로 확장할지까지 함께 결정한다. 처음부터 완벽한 선택을 할 필요는 없지만, 관계형 데이터베이스와 NoSQL 데이터베이스의 차이는 알고 시작해야 한다.

AWS에서 가장 자주 만나는 선택지는 두 가지다. 하나는 RDS이고, 다른 하나는 DynamoDB다. RDS는 MySQL, PostgreSQL 같은 관계형 데이터베이스를 관리형으로 제공한다. DynamoDB는 AWS가 제공하는 NoSQL 데이터베이스로, 정해진 조회 방식에 맞춰 매우 빠르고 크게 확장할 수 있다.

AI 생성 이미지

EC2에 직접 설치할까, RDS를 사용할까

데이터베이스도 프로그램이므로 EC2에 직접 설치할 수 있다. 예를 들어 EC2 인스턴스에 PostgreSQL을 설치하고, EBS 볼륨에 데이터 파일을 저장하면 직접 운영하는 데이터베이스가 된다.

이 방식의 장점은 통제권이다. 운영체제 설정, 데이터베이스 버전, 확장 프로그램, 파일 위치, 백업 스크립트까지 세밀하게 조정할 수 있다. 특수한 설정이 필요하거나 기존 운영 방식을 그대로 가져와야 할 때는 직접 설치가 필요할 수 있다.

하지만 책임도 커진다. 운영체제 보안 패치, 데이터베이스 패치, 백업, 복구 테스트, 장애 조치, 디스크 용량 관리, 모니터링을 모두 직접 챙겨야 한다. 작은 실습에서는 쉬워 보이지만, 실제 서비스에서는 이 운영 부담이 빠르게 커진다.

RDS(Relational Database Service)는 이 부담을 줄여 주는 관리형 관계형 데이터베이스 서비스다. 사용자는 데이터베이스 엔진, 크기, 저장소, 네트워크, 백업 정책을 선택한다. AWS는 데이터베이스 서버 생성, 자동 백업, 스냅샷, 패치 적용을 위한 유지 관리 기능, 장애 조치 기능 같은 운영 요소를 서비스로 제공한다.

단, RDS를 쓴다고 데이터베이스 설계 책임이 사라지지는 않는다. 어떤 테이블을 만들지, 인덱스를 어떻게 잡을지, 어떤 쿼리가 느린지, 누가 접근할 수 있는지는 여전히 사용자가 판단해야 한다. 관리형 서비스는 "운영의 일부를 맡긴다"는 뜻이지, "아무렇게나 써도 된다"는 뜻이 아니다.

RDS는 관계형 데이터베이스를 관리형으로 쓰는 방법이다

관계형 데이터베이스는 데이터를 표처럼 저장한다. 회원 테이블, 주문 테이블, 상품 테이블을 만들고, 서로의 관계를 연결한다. SQL이라는 언어로 데이터를 조회하고 수정한다. "이 사용자의 최근 주문 10개", "이번 달 결제 금액 합계", "상품별 판매량"처럼 조건을 걸고 조합해서 조회하기 좋다.

RDS를 만들 때 먼저 고르는 것은 엔진이다. MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2, Amazon Aurora 같은 선택지가 있다. 초보자라면 애플리케이션 프레임워크와 팀 경험을 기준으로 고르는 것이 좋다. 예를 들어 많은 웹 예제는 MySQL이나 PostgreSQL을 기준으로 설명한다. 특별한 이유가 없다면 익숙하고 자료가 많은 엔진을 선택하는 편이 안전하다.

그다음은 크기와 저장소다. EC2에서 인스턴스 타입을 골랐던 것처럼 RDS도 CPU와 메모리 규모를 고른다. 저장소는 데이터가 쌓이는 공간이다. 처음부터 크게 잡기보다 작은 크기로 시작하고, 증가 추세를 보며 조정하는 것이 비용 면에서 낫다.

RDS에서 꼭 알아야 할 운영 옵션은 네 가지다.

첫째, 자동 백업이다. 자동 백업을 켜면 정해진 보관 기간 안에서 특정 시점으로 복구할 수 있다. 실수로 데이터를 삭제했거나 애플리케이션 배포 후 데이터가 잘못 변경되었을 때 중요하다. 백업은 "켜 두었다"에서 끝나지 않는다. 실제로 복구가 되는지 테스트해야 의미가 있다.

둘째, 수동 스냅샷이다. 스냅샷은 사용자가 원하는 시점에 남기는 백업본이다. 큰 변경 전, 마이그레이션 전, 실습 종료 전 상태를 보관할 때 유용하다. 자동 백업은 보관 기간이 지나면 사라질 수 있지만, 수동 스냅샷은 사용자가 삭제하기 전까지 남길 수 있다. 그래서 비용도 함께 확인해야 한다.

셋째, Multi-AZ다. AZ는 가용 영역이며, 같은 리전 안의 서로 분리된 데이터센터 묶음으로 이해하면 된다. 일반적인 RDS Multi-AZ DB 인스턴스 배포를 사용하면 RDS가 다른 AZ에 대기용 데이터베이스를 만들고, 기본 데이터베이스의 변경 내용을 동기식으로 복제한다. 장애가 나면 RDS가 대기 인스턴스로 자동 전환할 수 있다. 핵심 목적은 성능 향상이 아니라 고가용성이다. 특히 일반적인 Multi-AZ 대기 인스턴스는 읽기 트래픽을 나눠 받기 위한 용도가 아니다. 읽기 성능을 늘리고 싶다면 별도의 읽기 전용 복제본을 검토해야 한다.¹

넷째, 읽기 전용 복제본(Read Replica)이다. 읽기 요청이 많을 때 원본 데이터베이스의 복제본을 만들어 조회 부하를 나눌 수 있다. 예를 들어 쇼핑몰에서 주문 생성은 원본 DB에 쓰고, 상품 조회나 리포트 조회는 읽기 복제본으로 보낼 수 있다. 다만 복제는 보통 비동기 방식이므로 원본과 복제본 사이에 짧은 지연이 생길 수 있다. 읽기 복제본은 읽기 확장을 위한 도구이지, 일반적인 Multi-AZ 대기 인스턴스와 같은 자동 장애 조치 기능으로 이해하면 안 된다.²

DynamoDB는 조회 방식부터 설계한다

DynamoDB는 관계형 데이터베이스와 다르게 생각해야 한다. 테이블이 있고 항목(item)이 있으며 각 항목은 여러 속성(attribute)을 가진다. 겉으로 보면 표처럼 보이지만, SQL로 자유롭게 조인하고 조건을 조합하는 방식과는 다르다.

DynamoDB에서 가장 중요한 것은 기본 키다. 기본 키는 데이터를 저장하고 찾는 기준이다. 기본 키는 두 방식 중 하나로 만든다.

첫 번째는 파티션 키만 사용하는 방식이다. 파티션 키는 데이터를 나누어 저장하는 기준이다. 예를 들어 UserId를 파티션 키로 쓰면 사용자 ID를 기준으로 데이터를 찾는다. DynamoDB에서 효율적인 조회는 보통 파티션 키를 정확히 알고 있을 때 가능하다.

두 번째는 파티션 키 + 정렬 키를 함께 사용하는 방식이다. 정렬 키는 같은 파티션 키 안에서 데이터를 정렬하고 범위 조회를 할 때 쓴다. 예를 들어 주문 테이블을 다음처럼 설계할 수 있다.

이 구조에서는 "1001번 사용자의 주문 목록"을 빠르게 조회할 수 있다. 정렬 키가 날짜를 포함하므로 "특정 기간의 주문"도 조회하기 쉽다. 반대로 "모든 사용자 중 오늘 주문한 목록"은 이 키 구조만으로는 효율적이지 않을 수 있다. 그래서 DynamoDB는 테이블을 만들기 전에 "어떤 질문을 자주 할 것인가?"를 먼저 정해야 한다.

관계형 데이터베이스에서는 데이터를 정규화하고 나중에 SQL로 다양한 질문을 던지는 방식이 자연스럽다. DynamoDB에서는 자주 사용할 조회 패턴에 맞춰 키를 설계한다. 이 차이를 모르고 시작하면, 데이터는 저장했는데 원하는 방식으로 빠르게 꺼내기 어려운 상황이 생긴다.

또 하나 주의할 점은 뜨거운 파티션(hot partition)이다. 특정 파티션 키에 요청이 몰리면 그 부분만 바빠져 성능 병목이 생길 수 있다. 예를 들어 모든 주문의 파티션 키를 TODAY 하나로 저장하면 오늘 주문이 모두 한곳에 몰린다. 파티션 키는 요청이 가능한 한 고르게 퍼지도록 선택해야 한다.³

온디맨드와 프로비저닝, 용량을 어떻게 계산할까

DynamoDB는 서버를 직접 고르지 않는다. 대신 읽기와 쓰기 요청을 처리할 용량 방식을 선택한다.

온디맨드 모드는 요청이 들어오는 만큼 자동으로 처리 용량을 맞추는 방식이다. 트래픽을 예측하기 어렵거나, 새 서비스를 빠르게 시작하거나, 사용량이 들쭉날쭉할 때 편하다. 초보자 실습에서도 단순하다. 다만 요청이 많아지면 사용량에 따라 비용이 커질 수 있으므로 모니터링이 필요하다.

프로비저닝 모드는 초당 읽기와 쓰기 용량을 미리 정하는 방식이다. 트래픽이 비교적 예측 가능하고 비용을 더 세밀하게 관리하고 싶을 때 적합하다. Auto Scaling을 함께 사용하면 사용량 변화에 따라 일정 범위 안에서 용량을 늘리거나 줄일 수 있다. 대신 너무 낮게 잡으면 요청이 제한될 수 있고, 너무 높게 잡으면 사용하지 않는 용량에도 비용을 낼 수 있다.³

간단히 정리하면, 처음 만들고 패턴을 모를 때는 온디맨드가 쉽다. 사용량이 안정되고 비용 최적화가 필요해지면 프로비저닝을 검토한다.

데이터베이스는 필요한 애플리케이션만 접근하게 한다

데이터베이스 보안의 기본은 간단하다. 인터넷에서 아무나 직접 접근할 수 없게 두는 것이다. 다만 여기서 RDS와 DynamoDB는 네트워크 구조가 조금 다르다.

RDS는 사용자의 VPC 안에 만든 서브넷 그룹을 통해 배치된다. 그래서 이전 장에서 배운 퍼블릭 서브넷과 프라이빗 서브넷 개념이 그대로 중요하다. RDS는 보통 프라이빗 서브넷에 둔다. 사용자는 인터넷을 통해 로드 밸런서나 웹 서버에 접근하고, 애플리케이션 서버만 데이터베이스에 연결한다.

기본 구조는 다음과 같다.

1. 로드 밸런서 또는 웹 서버는 퍼블릭 서브넷에 둔다.

2. 애플리케이션 서버는 프라이빗 서브넷에 두거나, 학습 단계에서는 제한적으로 퍼블릭 서브넷에 둘 수 있다.

3. RDS는 프라이빗 서브넷에 둔다.

4. RDS 보안 그룹은 애플리케이션 서버의 보안 그룹에서 오는 DB 포트만 허용한다.

5. 내 집 IP나 회사 IP에서 데이터베이스 포트를 직접 여는 방식은 피한다.

예를 들어 PostgreSQL은 기본 포트가 5432이고 MySQL은 3306이다. RDS 보안 그룹의 인바운드 규칙에 0.0.0.0/0을 넣으면 전 세계에서 DB 접속 시도가 가능해진다. 실습 중 잠깐 열어 두었다가 잊는 경우가 가장 위험하다. 데이터베이스는 "필요한 애플리케이션만 접근"하게 만드는 것이 원칙이다.

DynamoDB는 RDS처럼 특정 프라이빗 서브넷 안에 데이터베이스 인스턴스를 배치하는 방식이 아니다. AWS가 운영하는 관리형 서비스 엔드포인트에 애플리케이션이 API로 접근한다. 따라서 DynamoDB 보안에서는 IAM 권한이 특히 중요하다. 어떤 역할이 어떤 테이블에 대해 GetItem, PutItem, Query 같은 작업을 할 수 있는지 최소 권한으로 제한해야 한다.

프라이빗 서브넷의 애플리케이션이 DynamoDB에 접근해야 한다면 VPC 엔드포인트를 사용할 수 있다. 특히 DynamoDB는 게이트웨이 VPC 엔드포인트를 지원하므로, VPC에서 DynamoDB로 가는 트래픽을 인터넷 게이트웨이나 NAT 게이트웨이에 의존하지 않고 AWS 네트워크 안에서 보낼 수 있다. 필요하면 엔드포인트 정책으로 특정 테이블 접근만 허용하는 식의 제한도 함께 걸 수 있다.⁴

비밀번호도 코드에 직접 쓰지 않는 편이 좋다. 운영 환경에서는 AWS Secrets Manager 같은 서비스를 사용해 데이터베이스 접속 정보를 관리한다. RDS라면 저장 데이터 암호화, 전송 중 TLS 암호화, 백업 보관 기간을 함께 확인한다. DynamoDB라면 IAM 정책, 테이블 암호화, VPC 엔드포인트 사용 여부, CloudTrail을 통한 접근 기록 확인을 함께 생각한다. 보안은 마지막에 붙이는 장식이 아니라 데이터베이스 생성 순간부터 정하는 기본값이다.

RDS와 DynamoDB 중 무엇을 고를까

선택 기준은 데이터 모양보다 애플리케이션의 질문 방식이다.

회원, 주문, 결제, 정산처럼 데이터 관계가 중요하고 SQL 조회가 필요하다면 RDS가 자연스럽다. 트랜잭션이 중요하거나, 여러 테이블을 연결해 보고서를 만들어야 하거나, 기존 MySQL·PostgreSQL 생태계를 사용한다면 RDS가 좋은 출발점이다.

반대로 조회 패턴이 명확하고, 키를 기준으로 매우 빠르게 읽고 쓰며, 트래픽 증가에 맞춰 크게 확장해야 한다면 DynamoDB가 잘 맞을 수 있다. 세션 저장소, 장바구니, 사용자별 이벤트 기록, 게임 상태, IoT 데이터처럼 특정 키로 읽고 쓰는 구조에 강하다.

둘 중 하나만 써야 하는 것은 아니다. 실제 서비스에서는 주문과 결제 데이터는 RDS에 두고, 사용자 세션이나 이벤트 로그는 DynamoDB에 두기도 한다. 중요한 것은 서비스 이름을 외우는 것이 아니라 "이 데이터는 어떤 방식으로 저장되고, 어떤 방식으로 조회되는가?"를 먼저 묻는 습관이다.

데이터베이스는 한 번 선택하면 바꾸기 어렵다. 그래서 처음에는 단순하게 시작하되, 백업·복구·보안·확장 방식을 함께 생각해야 한다. RDS는 관계형 데이터베이스 운영 부담을 줄여 주고, DynamoDB는 키 기반 조회와 확장성을 강하게 제공한다. 이 차이를 이해하면 AWS에서 데이터를 다루는 첫 번째 큰 갈림길을 지나온 것이다.

참고

¹Amazon RDS Multi-AZ Deployments

²Working with Multi-AZ DB cluster read replicas for Amazon RDS

³Best practices for designing and using partition keys effectively in DynamoDB

⁴Gateway endpoints for Amazon DynamoDB