[AWS SAA] 데이터베이스

RDS

핵심 개념

• RDS는 AWS에서 제공하는 관리형 관계형 데이터베이스 서비스
• 전통적인 관계형 데이터, 트랜잭션 처리, SQL 기반 애플리케이션에 적합
• MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2 등을 지원
• Aurora는 RDS 계열에서 사용할 수 있는 AWS 클라우드 최적화 관계형 데이터베이스 엔진
• 운영체제 패치, DB 백업, 장애 조치, 모니터링 등 관리 작업을 AWS가 일부 자동화
• 사용자는 스키마 설계, 쿼리 튜닝, 파라미터 설정, 애플리케이션 연결 관리에 집중 가능
• EC2에 직접 DB를 설치하는 방식보다 운영 부담을 줄일 수 있음

RDS 자동 백업과 복구

• RDS 자동 백업은 1~35일 보관 가능
• 자동 백업은 S3에 저장되지만, 사용자가 직접 S3 버킷의 객체처럼 관리하는 구조는 아님
• RDS는 자동 백업과 트랜잭션 로그를 사용하여 특정 시점 복구, 즉 PITR을 지원
• 트랜잭션 로그는 일반적으로 5분마다 S3로 업로드됨
• 특정 시점 복구가 필요하면 백업 보관 기간 내 원하는 시점으로 복원 가능
• 수동 스냅샷은 사용자가 직접 생성하고 삭제 전까지 유지 가능
• 자동 백업은 삭제 시 함께 제거될 수 있으므로 장기 보관이 필요하면 수동 스냅샷을 고려

RDS Multi-AZ vs Read Replica

항목	Multi-AZ DB Instance	Read Replica
목적	고가용성 / 장애 조치	읽기 성능 확장
복제 방식	동기식 복제	비동기식 복제
Standby 읽기	불가	가능
장애 조치	자동 페일오버	기본 목적은 읽기 확장, 필요 시 승격 가능
리전 간 구성	일반적으로 같은 리전 내 고가용성 구성	리전 간 Read Replica 구성 가능
주요 용도	장애 대비, 가용성 향상	읽기 트래픽 분산, 보고서, 분석성 조회

• 일반적인 RDS Multi-AZ DB Instance의 Standby는 읽기 트래픽을 처리하지 않음
• Standby를 보고서 트래픽에 연결하는 용도로 사용할 수 없음
• 읽기 트래픽 분산이 필요하면 Read Replica를 사용
• 단, RDS Multi-AZ DB Cluster는 일반 Multi-AZ DB Instance와 다르게 읽기 가능한 DB 인스턴스를 포함할 수 있음
• 반복 조회가 많고 매우 낮은 지연 시간이 필요하면 RDS Read Replica보다 ElastiCache가 더 적합한 경우가 있음
• Read Replica는 비동기 복제이므로 원본과 복제본 사이에 지연이 발생할 수 있음
• 읽기 복제본 지연은 Replica Lag 지표로 확인 가능

RDS 주요 기능

기능	설명
RDS Proxy	DB 연결 수 제어와 연결 풀링을 지원. Lambda처럼 연결이 많이 생기는 환경에서 유용
RDS Custom	OS와 DB 환경에 대한 더 많은 제어가 필요한 워크로드에 사용
RDS Custom for Oracle	OS 접근이나 특정 DB 설정이 필요한 Oracle 워크로드에 적합
스토리지 자동 확장	스토리지 용량 부족이 예상될 때 자동으로 스토리지 확장
Performance Insights	DB 성능 병목 분석에 사용
Enhanced Monitoring	OS 수준의 세부 모니터링 제공

• RDS Proxy는 스토리지 확장 서비스가 아니라 DB 연결 관리 서비스
• RDS 스토리지 자동 확장은 스토리지 용량 부족이 예상될 때 활성화
• RDS 인스턴스를 중지해도 스토리지 비용은 계속 발생
• 더 이상 필요 없는 RDS 인스턴스라면 스냅샷 보관 여부를 결정한 뒤 삭제 고려
• Oracle 워크로드에서 OS 접근이 필요하면 RDS Custom for Oracle 고려

RDS 암호화

• RDS 저장 데이터 암호화에는 KMS를 사용
• RDS 인스턴스 생성 시 암호화를 활성화할 수 있음
• 이미 생성된 비암호화 RDS 인스턴스를 직접 암호화 상태로 변경할 수는 없음
• 기존 비암호화 RDS를 암호화하려면 스냅샷 생성 → 암호화된 스냅샷으로 복사 → 복사본에서 새 RDS 인스턴스 복원 순서로 처리
• 전송 중 암호화가 필요하면 SSL/TLS 연결 사용
• 암호화된 스냅샷을 다른 계정과 공유하려면 스냅샷 공유뿐 아니라 KMS 키 권한도 대상 계정에 허용해야 함

Aurora

핵심 개념

• Aurora는 AWS에서 제공하는 클라우드 최적화 관계형 데이터베이스
• MySQL 및 PostgreSQL과 호환
• 일반 RDS MySQL/PostgreSQL보다 높은 성능과 가용성을 목표로 설계됨
• Aurora 스토리지는 여러 AZ에 걸쳐 자동 복제됨
• Aurora는 최대 15개의 Aurora Replica를 구성할 수 있음
• 읽기 확장, 고가용성, 빠른 장애 조치가 필요한 관계형 DB 워크로드에 적합
• PostgreSQL 호환 관계형 DB를 AWS 관리형으로 이전하려면 Aurora PostgreSQL을 고려
• MySQL 호환 고성능 관계형 DB가 필요하면 Aurora MySQL을 고려

Aurora 주요 기능

항목	내용
Aurora Replica	읽기 성능 확장 및 장애 조치 대상
Aurora Global Database	보조 리전으로 복제하여 글로벌 읽기 및 재해 복구 구성
Aurora Serverless v2	사용량에 따라 ACU 단위로 세밀하게 자동 확장
Babelfish	Aurora PostgreSQL에서 SQL Server 호환 쿼리 일부 지원
Aurora I/O-Optimized	I/O 사용량이 많은 워크로드에서 I/O 비용 구조 최적화
Aurora 클로닝	운영 클러스터에 큰 영향 없이 테스트/스테이징 환경 생성
사용자 지정 엔드포인트	특정 Aurora Replica 그룹으로 트래픽 라우팅
Aurora 병렬 쿼리	분석성 쿼리 성능 개선에 사용

Aurora Global Database

• Aurora Global Database는 하나의 기본 리전과 여러 보조 리전으로 구성
• 쓰기는 기본 리전에서 수행
• 보조 리전은 읽기 전용으로 사용 가능
• 매우 낮은 RPO와 다중 리전 읽기 복제가 필요한 경우 적합
• 리전 장애 시 보조 리전의 클러스터를 승격하여 복구 가능
• 글로벌 서비스의 읽기 지연 시간을 줄이거나 재해 복구 구성을 강화할 때 사용

Aurora Serverless

• Aurora Serverless는 트래픽이 불규칙하거나 예측이 어려운 워크로드에 적합
• Aurora Serverless v2는 최소/최대 ACU 범위 내에서 용량을 자동 조정
• 사용량이 들쑥날쑥한 워크로드에 적합
• 개발/테스트 환경, 간헐적으로 사용하는 애플리케이션, 예측하기 어려운 트래픽에 고려 가능
• Aurora Serverless v2는 기존 Provisioned 인스턴스와 같은 클러스터 내에서 함께 사용할 수 있음

DynamoDB

핵심 개념

• DynamoDB는 AWS에서 제공하는 서버리스 NoSQL 데이터베이스 서비스
• 키-값 및 문서 데이터 모델을 지원
• 초당 수백만 요청과 밀리초 단위 응답이 필요한 워크로드에 적합
• 대규모 확장성, 빠른 응답, 서버 관리 없는 운영이 핵심
• 세션 저장소, 장바구니, 사용자 프로필, 게임 데이터, IoT 이벤트 저장 등에 사용
• 관계형 조인이나 복잡한 SQL 분석보다는 키 기반 조회와 대규모 트래픽 처리에 적합
• DynamoDB는 RDS 안에서 사용하는 서비스가 아니라 별도의 NoSQL 데이터베이스 서비스

DynamoDB 주요 기능

 

항목	내용
TTL	만료 시간이 지난 데이터를 자동 삭제하여 비용 절감
PITR	특정 시점으로 테이블 복구
GSI	기본 키 외 다른 속성으로 쿼리하기 위한 글로벌 보조 인덱스
LSI	같은 파티션 키 내에서 다른 정렬 키로 조회하기 위한 로컬 보조 인덱스
DAX	DynamoDB 앞단의 인메모리 캐시
Streams	테이블 변경 이벤트 기반 후속 처리
온디맨드 백업	사용자가 특정 시점에 직접 생성하는 백업
Global Tables	다중 리전 복제 및 글로벌 애플리케이션 구성

• TTL은 만료 데이터 자동 삭제에 사용
• PITR은 짧은 RPO가 필요한 복구 시나리오에 유용
• 온디맨드 백업은 특정 시점 복구, 즉 PITR과 구분
• GSI를 사용하면 기본 키 외 다양한 쿼리 패턴을 지원할 수 있음
• DAX는 읽기 지연 시간을 마이크로초 수준으로 낮추고 싶을 때 고려
• DAX는 쓰기 성능 개선보다는 읽기 캐시에 가까움
• Streams는 데이터 변경 이벤트를 Lambda 등과 연동하여 후속 처리할 때 사용
• 큰 객체는 DynamoDB에 직접 저장하기보다 S3에 저장하고 DynamoDB에는 S3 URL 또는 메타데이터를 저장하는 방식이 적합

DynamoDB 용량 모드

모드	특징	적합한 경우
온디맨드	요청량에 따라 자동으로 처리량 조정	트래픽 예측이 어렵거나 급격히 변하는 경우
프로비저닝	읽기/쓰기 처리량을 미리 지정	트래픽이 예측 가능하고 일정한 경우

• 트래픽이 일정하고 예측 가능하면 프로비저닝 모드가 온디맨드보다 비용 효율적일 수 있음
• 장기적으로 예측 가능한 처리량이 있으면 프로비저닝 모드 + 예약 용량을 고려
• 프로비저닝 모드에서는 DynamoDB Auto Scaling으로 읽기/쓰기 용량을 트래픽 변화에 맞춰 자동 조정 가능

DynamoDB VPC Endpoint

• 프라이빗 서브넷의 EC2에서 DynamoDB로 프라이빗하게 접근해야 하면 DynamoDB용 Gateway VPC Endpoint 사용
• 인터넷 게이트웨이나 NAT 게이트웨이를 거치지 않고 AWS 네트워크 내부에서 DynamoDB에 접근 가능
• Endpoint 정책을 통해 접근 가능한 테이블이나 작업 범위를 제한할 수 있음
• 참고로 SQS는 Gateway Endpoint가 아니라 Interface VPC Endpoint를 사용

DynamoDB Global Tables

• DynamoDB Global Tables는 DynamoDB 테이블을 여러 리전에 복제하는 기능
• 다중 리전 읽기/쓰기 애플리케이션에 적합
• 글로벌 사용자에게 낮은 지연 시간 제공 가능
• 리전 장애에 대한 복원성을 높일 수 있음
• Global Tables를 사용하면 99.999% 수준의 가용성 요구사항에 대응할 수 있음

ElastiCache

핵심 개념

• ElastiCache는 AWS의 관리형 인메모리 캐싱/데이터 저장소 서비스
• Redis OSS 또는 Memcached 기반 엔진을 지원
• 밀리초 이하 응답, 세션 저장소, 캐시, 실시간 랭킹, 빠른 데이터 조회에 적합
• 반복 조회 데이터를 캐싱해 DB 읽기 부하를 줄여야 하면 ElastiCache 우선 고려
• RDS 읽기 부하가 높으면 Read Replica를 고려할 수 있음
• 같은 데이터를 반복 조회하고 지연 시간을 더 줄여야 한다면 ElastiCache를 함께 고려
• 변경이 적은 데이터를 캐싱해 DB 읽기 부하를 줄이는 데 적합

Redis vs Memcached

항목	Redis OSS	Memcached
구조	다양한 자료구조 지원	단순 키-값 캐시
스냅샷	지원	미지원
데이터 지속성	지원	미지원
복제/고가용성	지원	제한적
자동 장애 조치	지원	미지원
Pub/Sub	지원	미지원
멀티스레드 단순 캐시	제한적	적합
주요 용도	세션, 랭킹, 큐, 복잡한 캐싱	단순 캐싱

• 고가용성 캐시 요구사항이 있으면 ElastiCache for Redis OSS의 복제와 자동 장애 조치 구성 고려
• 단순 캐시이고 데이터 지속성이 필요 없다면 Memcached도 적합
• 세션 상태 유지, 랭킹, 다양한 자료구조가 필요하면 Redis OSS가 더 적합

Redshift

핵심 개념

• Redshift는 AWS의 관리형 데이터 웨어하우스 서비스
• 대규모 분석 쿼리, BI, 리포팅 용도에 적합
• OLTP 트랜잭션 처리보다는 OLAP 분석 처리에 적합
• 컬럼 기반 저장과 MPP 구조를 사용하여 대규모 분석 쿼리를 처리
• 클릭스트림 데이터를 S3 데이터 레이크에 적재한 뒤 Redshift로 로드하여 분석 가능
• Kinesis Data Firehose를 통해 Redshift 또는 S3로 거의 실시간 적재 가능
• Redshift Spectrum을 사용하면 S3에 있는 데이터를 Redshift에서 외부 테이블처럼 조회 가능
• Redshift Serverless를 사용하면 클러스터 용량 관리를 줄이고 분석 워크로드를 실행할 수 있음

Redshift 노드 타입

노드  타입	특징
RA3	컴퓨팅과 스토리지를 분리하여 확장 가능. 최신 Redshift 워크로드에서 우선 고려
DC2	로컬 SSD 기반 고성능 컴퓨팅 노드. 데이터 크기가 비교적 작고 고성능이 필요한 경우
DS2	이전 세대 대용량 스토리지 노드. 신규 워크로드에서는 일반적으로 RA3 우선 고려

• 기존 Dense Compute, Dense Storage만으로 외우기보다 RA3 중심으로 이해하는 것이 좋음
• 대규모 분석과 스토리지 확장성이 중요하면 RA3 고려
• 클러스터 관리 부담을 줄이고 싶다면 Redshift Serverless 고려

기타 데이터베이스

서비스	설명	사용 용도
DocumentDB	MongoDB 호환 관리형 문서 데이터베이스	MongoDB 호환 애플리케이션 이전
Neptune	그래프 데이터베이스	복잡한 관계 표현, 추천, 지식 그래프, IT 인프라맵
Timestream	시계열 데이터베이스	IoT, 모니터링, 시계열 데이터
QLDB	변경 불가능하고 암호화 검증 가능한 원장 데이터베이스	금융 거래 기록, 감사 로그
Keyspaces	Apache Cassandra 호환 관리형 데이터베이스	Cassandra 워크로드 이전
MemoryDB for Redis	Redis OSS 호환 내구성 있는 인메모리 데이터베이스	초고속 읽기/쓰기와 데이터 내구성이 모두 필요한 경우

DMS / SCT

DMS

• DMS는 Database Migration Service의 약자
• 데이터베이스 마이그레이션에 사용하는 서비스
• 동종 DB 간 이전과 이기종 DB 간 이전 모두 지원
• CDC, 즉 Change Data Capture 기반 지속적 복제 가능
• 마이그레이션 중 소스 DB의 변경 사항을 대상 DB에 지속적으로 반영할 수 있음
• 다운타임을 줄여야 하는 DB 이전에 적합
• DMS Serverless는 복제 워크로드 수요에 따라 컴퓨팅과 메모리 리소스를 자동 할당

SCT

• SCT는 Schema Conversion Tool의 약자
• 이기종 DB 간 스키마 변환에 사용
• 예를 들어 Oracle에서 Aurora PostgreSQL로 이전할 때 SCT로 스키마를 변환하고, DMS로 데이터를 이전할 수 있음
• 테이블, 뷰, 저장 프로시저, 함수 등 DB 객체 변환을 지원
• 자동 변환이 어려운 객체는 수동 수정이 필요할 수 있음

DMS / SCT 사용 예시

이전 시나리오	사용 서비스
MySQL → RDS MySQL	DMS
Oracle → Aurora PostgreSQL	SCT + DMS
SQL Server → Aurora PostgreSQL	SCT + DMS
온프레미스 DB → AWS로 지속 복제	DMS
마이그레이션 중 변경 데이터 동기화	DMS CDC

데이터베이스 서비스 선택 기준 요약

요구사항	적합한 서비스
일반적인 관계형 DB, SQL, 트랜잭션 처리	RDS
MySQL/PostgreSQL 호환 고성능 관계형 DB	Aurora
다중 리전 관계형 DB 읽기 복제 및 DR	Aurora Global Database
예측하기 어려운 Aurora 워크로드 자동 확장	Aurora Serverless v2
키-값 기반 대규모 NoSQL	DynamoDB
다중 리전 NoSQL 읽기/쓰기	DynamoDB Global Tables
DynamoDB 읽기 지연 시간 최소화	DAX
반복 조회 캐싱, 세션 저장소	ElastiCache
단순 캐싱	ElastiCache for Memcached
고가용성 캐시, 랭킹, 세션, 다양한 자료구조	ElastiCache for Redis OSS
대규모 분석, BI, 데이터 웨어하우스	Redshift
MongoDB 호환 문서 DB	DocumentDB
그래프 관계 데이터	Neptune
시계열 데이터	Timestream
변경 불가 원장 데이터	QLDB
Cassandra 호환 DB	Keyspaces
DB 마이그레이션	DMS
이기종 DB 스키마 변환	SCT