AWS Certified Solutions Architect - Associate (SAA-C03) #12 Domain 3-4 고성능 아키텍처: DB 선택

인프라 AWS 자격증
5 분 소요

#11 스토리지에 이어, 고성능 도메인의 마지막으로 데이터베이스 선택을 다룹니다. SAA의 DB 문항에서 가장 자주, 가장 결정적으로 갈리는 지점은 RDS의 Multi-AZ와 읽기 복제본 차이입니다. 여기서부터 정리합니다.

RDS: 관리형 관계형 데이터베이스 #

RDS는 MySQL,PostgreSQL,MariaDB,Oracle,SQL Server를 관리형으로 제공합니다. 백업,패치,복구를 AWS가 맡습니다. 핵심은 두 가지 확장/가용성 메커니즘이고, 목적이 완전히 다릅니다.

항목Multi-AZ읽기 복제본(Read Replica)
목적고가용성/장애 전환읽기 부하 분산
복제 방식동기(synchronous)비동기(asynchronous)
대기 인스턴스평소엔 트래픽 안 받음(standby)읽기 트래픽을 받음
장애 시자동 failover수동 승격(promote) 필요
교차 리전보통 같은 리전교차 리전 가능
  • Multi-AZ. 다른 AZ에 동기 복제된 standby를 두고, 주 인스턴스 장애 시 자동으로 전환합니다. 고가용성을 위한 것이지 읽기 성능을 위한 것이 아닙니다. standby는 평소 트래픽을 받지 않습니다.
  • 읽기 복제본. 비동기 복제본을 두어 읽기 쿼리를 분산합니다. 읽기 부하가 큰 워크로드의 확장 수단이며, 교차 리전에도 둘 수 있어 DR과 글로벌 읽기에도 활용됩니다. 단, 자동 failover는 아닙니다.

이 구분이 시험 단골입니다. “읽기 부하 분산“은 읽기 복제본, “고가용성/자동 failover“는 Multi-AZ입니다. 둘을 함께 써서 가용성과 읽기 확장을 동시에 잡기도 합니다.

Aurora: 클라우드 네이티브 관계형 #

Aurora는 AWS가 클라우드에 맞춰 다시 만든 관계형 DB로, MySQL,PostgreSQL과 호환됩니다. 특징은 다음과 같습니다.

  • 스토리지 자동 확장. 데이터가 늘면 스토리지가 자동으로 커집니다.
  • 6개 복제본을 3개 AZ에 분산 저장해 높은 내구성과 가용성.
  • 최대 15개 읽기 복제본으로 읽기 확장.
  • Aurora Global Database. 여러 리전에 1초 미만 지연으로 복제(#7 DR 활용).
  • Aurora Serverless v2. 부하에 따라 용량을 자동 조절(변동,간헐 워크로드).

“MySQL/PostgreSQL 호환이면서 더 높은 성능과 자동 스토리지 확장"이 단서면 Aurora입니다.

DynamoDB: 관리형 NoSQL #

DynamoDB는 완전관리형 NoSQL key-value/document 데이터베이스입니다. 서버리스이며 사실상 무제한으로 확장되고, 한 자릿수 밀리초(DAX로 마이크로초) 응답을 냅니다.

  • 용량 모드. On-Demand(트래픽 예측 불가,관리 불필요) vs Provisioned(예측 가능,비용 효율).
  • 글로벌 테이블. 다중 리전 active/active 복제.
  • DynamoDB Streams. 데이터 변경 이벤트를 캡처(예: Lambda 트리거).
  • TTL. 항목 자동 만료.
  • DAX. #10의 마이크로초 캐시.

“key-value, 밀리초 응답, 무제한 확장, 서버 관리 없음"이면 DynamoDB입니다. 다만 복잡한 조인이나 트랜잭션 중심 관계형 모델에는 부적합합니다. 그런 워크로드는 RDS/Aurora입니다.

목적별 데이터베이스 #

관계형,NoSQL 외에도 워크로드 전용 DB가 있습니다. 시험에 등장하는 것들입니다.

워크로드서비스
분석/데이터 웨어하우스(OLAP)Redshift
인메모리 캐시ElastiCache(#10)
그래프(관계 데이터)Neptune
MongoDB 호환 문서 DBDocumentDB
시계열Timestream

“대규모 데이터 분석/집계 쿼리(OLAP)“는 트랜잭션용 RDS가 아니라 Redshift입니다. 이 구분(OLTP vs OLAP)이 자주 나옵니다.

시험 출제 패턴 #

  • “관계형 DB 읽기 부하 분산.” → 읽기 복제본(Read Replica)
  • “관계형 DB 고가용성/자동 failover.” → Multi-AZ
  • “MySQL 호환 + 고성능 + 스토리지 자동 확장.” → Aurora
  • “다중 리전 active/active 관계형.” → Aurora Global Database
  • “key-value, 밀리초, 무제한 확장, 서버리스.” → DynamoDB
  • “트래픽 예측 불가 NoSQL, 용량 관리 회피.” → DynamoDB On-Demand
  • “대규모 분석/데이터 웨어하우스.” → Redshift

자주 만나는 함정 #

1) Multi-AZ로 읽기를 확장하려 한다 #

Multi-AZ의 standby는 트래픽을 받지 않습니다. 읽기 확장은 읽기 복제본입니다.

2) 읽기 복제본으로 자동 failover를 기대 #

읽기 복제본은 비동기이며 자동 전환이 아닙니다. 자동 failover는 Multi-AZ입니다.

3) DynamoDB로 복잡한 조인을 처리 #

DynamoDB는 NoSQL입니다. 복잡한 관계형 조인,트랜잭션은 RDS/Aurora가 맞습니다.

4) 분석 쿼리를 RDS로 처리 #

대규모 분석(OLAP)은 RDS가 아니라 Redshift입니다. RDS는 트랜잭션(OLTP)용입니다.

정리 #

이번 글에서 잡은 것:

  • RDS. Multi-AZ(고가용성,자동 failover) vs 읽기 복제본(읽기 확장,비동기,교차 리전 가능). 목적이 다름
  • Aurora. MySQL/PostgreSQL 호환, 스토리지 자동 확장, Global, Serverless v2
  • DynamoDB. NoSQL key-value, 서버리스,무제한 확장, On-Demand/Provisioned, 글로벌 테이블. 복잡한 조인엔 부적합
  • 목적별: 분석은 Redshift(OLAP), 그래프는 Neptune, 문서는 DocumentDB

이것으로 **고성능 도메인(24%, #9~12)**을 마칩니다. 컴퓨팅 → 캐싱 → 스토리지 → 데이터베이스로 성능을 끌어올리는 선택지를 정리했습니다.

다음: Domain 4-1 비용 최적화 #

마지막 도메인은 **비용 최적화(20%)**입니다. 같은 결과를 더 싸게 내는 설계로 넘어갑니다.

#13 Domain 4-1 가격 모델에서는 EC2 구매 옵션의 비용 관점 재정리(Reserved,Savings Plans,Spot), S3,스토리지 비용 구조, 데이터 전송 비용, 그리고 비용을 줄이는 아키텍처 선택을 정리하겠습니다.

X