Amazon SAA-C03: 데이터베이스 및 캐싱 — 학습 가이드

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

다음의 일부입니다: AWS SAA-C03 — 완벽 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

Amazon RDS: 관리형 관계형 엔진

Amazon RDS는 MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Amazon Aurora(MySQL 및 PostgreSQL 호환)의 6가지 관리형 엔진을 제공하며, 패치, 백업, 복제 토폴로지, 장애 조치를 추상화합니다. 어떤 엔진을 선택하는지에 따라 라이선스, 백업 방식, 사용 가능한 기능이 달라집니다. 예를 들어 Oracle과 SQL Server는 BYOL(Bring-Your-Own-License)과 라이선스 포함(License Included) 옵션이 있으며, SQL Server는 네이티브 복제를 통해 최대 5개의 읽기 전용 복제본을 지원하고, Oracle 읽기 전용 복제본은 Active Data Guard 기능이 포함된 Enterprise Edition이 필요합니다.

가용성과 확장을 위해 가장 많이 활용되면서도 가장 자주 혼동되는 두 가지 RDS 기능은 다중 AZ(Multi-AZ) 배포와 **읽기 전용 복제본(read replicas)**입니다. 이 둘은 서로 독립적이며 상호 보완적이지만, 서로 대체할 수는 없습니다.

**다중 AZ(Multi-AZ)**는 두 번째 가용 영역(Availability Zone)에 동기식 대기 복제본(standby replica)을 프로비저닝합니다. 모든 쓰기 작업은 응답을 반환하기 전에 기본(primary) 인스턴스와 대기 인스턴스 양쪽에 모두 커밋되므로, RPO는 실질적으로 0에 가깝고 자동 장애 조치 시 RTO는 60~120초입니다. 대기 인스턴스는 트래픽을 받지 않으며 오직 장애 조치만을 위해 존재합니다. 기본 인스턴스에 장애가 발생하거나, AZ가 손상되거나, 유지 관리로 인해 재시작이 필요한 경우, RDS는 DNS CNAME을 대기 인스턴스로 전환하고 애플리케이션은 동일한 엔드포인트를 통해 투명하게 다시 연결됩니다. 다중 AZ는 단일 AZ의 단일 장애점(single point of failure)을 해결하는 가장 손쉬운 방법입니다. 구성 토글만으로 활성화할 수 있고, 스키마나 애플리케이션 변경이 필요 없으며, 엔드포인트도 그대로 유지됩니다. 더 새로운 다중 AZ 클러스터 배포는 3개 노드(쓰기 노드 1개, 읽기 가능한 대기 노드 2개) 토폴로지이며, 약 1초의 커밋 지연 시간을 갖는 반동기식(semi-synchronous) 복제를 사용하여 고가용성(HA)과 함께 제한적인 읽기 부하 분산을 제공합니다.

**읽기 전용 복제본(Read replicas)**은 엔진의 네이티브 비동기식 복제(MySQL의 binlog, PostgreSQL의 WAL 스트리밍)를 사용합니다. 이는 분석 쿼리, 리포팅 대시보드, 임시 SELECT 문과 같이 기본 인스턴스의 OLTP 성능을 저하시킬 수 있는 읽기 작업을 확장하는 데 적합한 도구입니다. 대표적인 시나리오는 직원들이 월말 보고서를 장시간 실행하여 주문 처리 데이터베이스에 타임아웃이 발생하는 경우입니다. 읽기 전용 복제본을 추가하고 리포팅 도구가 그 엔드포인트를 가리키도록 하면, 기본 인스턴스의 사양을 높이지 않고도 분석 부하를 격리할 수 있습니다. 읽기 전용 복제본은 리전 간(cross-region)에 생성할 수 있고 독립적인 데이터베이스로 수동 승격할 수 있지만, 승격은 절대 자동으로 이루어지지 않으며 장애 발생 시점에 아직 복제되지 않은 트랜잭션은 손실됩니다.

이 영역에서 자주 발생하는 두 가지 함정이 있습니다. 첫째, 읽기 전용 복제본을 고가용성(HA) 솔루션으로 취급하는 것은 여러 가지 이유로 잘못된 생각입니다. 복제본은 비동기식이므로 데이터 손실 가능성이 있고, 자동 승격 기능이 없으며, 승격 시 엔드포인트가 변경되고, 진행 중이던 트랜잭션은 사라집니다. 만약 어떤 설계가 “데이터 손실 제로"를 약속하면서 장애 조치 대상으로 읽기 전용 복제본을 지목한다면, 그 약속은 거짓입니다. 둘째, 읽기 트래픽을 처리하기 위해 다중 AZ를 프로비저닝하는 것은 비용 낭비입니다. 표준 토폴로지에서 대기 인스턴스는 읽기가 불가능하기 때문입니다. 다중 AZ는 가용성을 해결하고, 읽기 전용 복제본은 읽기 확장성을 해결합니다. 종종 두 가지 모두가 필요합니다.

또한 읽기 전용 복제본은 쓰기 확장성에는 아무런 도움이 되지 않습니다. 모든 쓰기 작업은 여전히 기본 인스턴스로 향하고, 복제본은 이를 재현해야 합니다. 쓰기 확장성을 위해서는 샤딩(sharding)을 하거나, 스토리지와 컴퓨팅이 분리된 Aurora로 마이그레이션하거나, DynamoDB를 사용하도록 재설계해야 합니다.

읽기 전용 복제본의 적정 규모 산정

복제본의 인스턴스 클래스는 기본 인스턴스와 일치할 필요가 없습니다. 기본 인스턴스는 전체 쓰기 부하와 읽기 부하를 처리하지만, 복제본은 자신에게 들어오는 읽기 부하만 처리합니다. 야간 리포팅 작업을 위해 db.r6i.4xlarge 기본 인스턴스와 db.r6i.large 복제본을 함께 사용하는 것은 전적으로 합리적입니다. 단, 복제본이 복제 I/O를 따라갈 수 있어야 합니다. 방법론은 다음과 같습니다. 복제본의 실제 CPU, 메모리 사용량 및 복제 지연(replica lag)을 측정한 다음, 해당 워크로드에 맞게 규모를 조정합니다. 한 가지 주의할 점은, 재해 복구(DR) 시 복제본을 기본 인스턴스로 승격할 계획이라면, 쓰기 부하를 처리할 수 있는 규모로 설정해야 한다는 것입니다. 사양이 낮은 복제본은 승격 대상이 될 수 없습니다.

블루/그린 배포와 스토리지

**RDS 블루/그린 배포(Blue/Green Deployments)**는 논리적 복제를 통해 프로덕션 환경(그린)과 완벽하게 동기화되는 스테이징 사본을 생성합니다. 그린 환경에서 엔진 버전을 업그레이드하거나, 파라미터 그룹을 변경하거나, 스키마를 수정한 후 테스트하고, 1분 이내에 자동 엔드포인트 이름 변경을 통해 전환을 완료할 수 있습니다. 이를 통해 메이저 버전 업그레이드 실패 시 스냅샷 롤백을 해야 했던 기존의 인플레이스(in-place) 업그레이드 방식이 가진 위험을 제거합니다.

쓰기 중심의 OLTP 환경에서는 인스턴스 클래스만큼 스토리지 선택도 중요합니다. gp3/io2의 분류는 다음과 같습니다.

gp3가 gp2보다 개선된 점은 IOPS가 크기와 분리되었다는 것입니다. 따라서 더 이상 성능을 위해 용량을 초과 프로비저닝할 필요가 없습니다. 지속적인 IOPS가 gp3의 상한을 초과하거나 99.999%의 내구성이 필요한 경우 io2를 선택합니다. Multi-Attach를 사용하면 단일 io2 볼륨을 최대 16개의 Nitro 인스턴스에 연결할 수 있지만, 파일 시스템이나 애플리케이션이 클러스터를 인식해야 합니다. 이는 복제를 대체하는 기능이 아닙니다. 잠재적인 장애 유발 요인으로는 **스토리지 자동 조정(storage autoscaling)**을 활성화하지 않거나 FreeStorageSpace에 대한 CloudWatch 경보를 설정하지 않고 고정된 스토리지를 프로비저닝하는 경우가 있습니다. 사용 가능한 공간이 0이 되면 RDS는 storage-full 상태가 되어 쓰기 작업을 거부합니다.

Amazon Aurora: 아키텍처와 엔드포인트

Aurora는 MySQL 및 PostgreSQL의 스토리지 계층을 3개의 AZ에 걸쳐 분산된 로그 구조의 6-way 복제 볼륨으로 재구현합니다. 컴퓨팅 노드는 스토리지에 대해 상태 비저장(stateless)이므로, Aurora 복제본은 로그를 재실행하는 대신 쓰기(writer) 인스턴스와 동일한 기본 볼륨에서 읽습니다. 복제 지연 시간은 일반적으로 10-20ms로, 표준 RDS 복제본의 수 초에 비해 매우 짧습니다. 클러스터는 최대 15개의 복제본을 지원하며, 약 30초 만에 쓰기 인스턴스로 승격될 수 있습니다.

Aurora는 네 가지 유형의 엔드포인트를 제공합니다:

사용자 지정 엔드포인트는 복제본들이 이기종(heterogeneous)일 때 중요합니다. 6개의 복제본 중 3개가 분석 리포팅을 위해 db.r6g.8xlarge이고 나머지가 OLTP 읽기를 처리하는 경우, 일반 읽기 엔드포인트는 때때로 리포팅 작업을 더 작은 노드로 라우팅하여 예측 가능성을 해칠 수 있습니다. 대규모 복제본에만 범위가 지정된 사용자 지정 엔드포인트는 결정론적인 워크로드 격리를 제공합니다:

aws rds create-db-cluster-endpoint \
  --db-cluster-identifier prod-aurora \
  --db-cluster-endpoint-identifier reporting \
  --endpoint-type READER \
  --static-members reporting-node-1 reporting-node-2 reporting-node-3

Aurora 엔드포인트의 DNS TTL은 5초입니다. 연결 문자열을 이보다 길게 캐싱하면 장애 조치(failover) 동작이 제대로 작동하지 않습니다.

Aurora Auto Scaling은 대상 CPU 또는 연결 지표에 따라 읽기 전용 복제본을 추가 및 제거하며, 이는 예측 불가능하고 읽기 중심의 워크로드에 대해 고가용성을 유지해야 할 때 표준적인 해답입니다:

TargetTrackingScalingPolicyConfiguration:
  PredefinedMetricSpecification:
    PredefinedMetricType: RDSReaderAverageCPUUtilization
  TargetValue: 60.0
  ScaleInCooldown: 300
  ScaleOutCooldown: 60

RDS MySQL 읽기 전용 복제본이 피크 타임에 복제 지연을 1초 미만으로 유지할 수 없을 때, 코드 변경을 최소화하는 해답은 Aurora MySQL로 마이그레이션하는 것입니다. 연결 문자열은 거의 변경되지 않으며, 스토리지 수준 복제를 통해 지연 시간이 사라집니다.

Aurora Serverless v2와 클로닝

Aurora Serverless v2는 세분화된 Aurora 용량 단위(ACU, 각 2GiB 메모리)로 약 0.5초 만에 컴퓨팅을 수직 확장하며, 세션을 끊지 않습니다. 이는 알려진 기준 메모리 사용량이 있는 가변적인 워크로드에 적합합니다. 예를 들어, 항상 최소 2GiB를 소비하는 온프레미스 MySQL 마이그레이션 같은 경우입니다. 최소 1 ACU, 최대 32 ACU로 설정하면 클러스터는 관리 없이 유연하게 확장됩니다. Serverless v2는 ACU당 프리미엄이 붙기 때문에, 부하가 안정적이고 예측 가능할 때는 프로비저닝된 Aurora가 여전히 더 좋습니다.

Aurora 클로닝은 copy-on-write를 통해 원본의 스토리지 페이지를 공유하는 새로운 클러스터를 생성합니다. 클론은 몇 초 만에 생성되며 데이터가 달라지기 전까지는 비용이 발생하지 않아, 스테이징 환경, 위험 부담이 큰 마이그레이션 또는 분석가들이 프로덕션 복사본을 마음껏 사용할 수 있도록 하는 데 이상적입니다. 스냅샷 복원은 데이터를 물리적으로 재구성하여 몇 시간이 걸릴 수 있지만, 속도가 중요할 때는 클로닝이 더 유리합니다.

Aurora Global Database

Aurora Global Database는 binlog 전송 방식이 아닌, 전용 스토리지 계층 복제 인프라를 사용하여 클러스터를 최대 5개의 보조 리전으로 확장합니다. 일반적인 복제 지연은 1초 미만, RPO도 1초 미만이며, 관리형 장애 조치를 통해 1분 이내에 보조 리전을 승격시킬 수 있습니다.

두 가지 중요한 의미가 있습니다: 보조 리전은 정상 작동 시 읽기 전용이며, Global Database는 액티브-액티브 다중 마스터가 아닌 낮은 RPO의 DR과 짧은 지연 시간의 원격 읽기를 위해 설계되었습니다. 글로벌 DB가 “보조 리전에서 쓰기를 자동으로 처리한다"고 가정하는 것은 잘못된 생각입니다. 보조 리전에서의 쓰기는 명시적인 관리형 장애 조치 또는 분리 후 승격(detach-and-promote)이 필요합니다. 리전 간 5분의 RPO / 20분의 RTO와 최소한의 운영 오버헤드라는 명시된 요구사항에 대해, Global Database가 표준적인 해답입니다.

RDS Proxy와 연결 관리

서버리스 및 고도로 동시적인 워크로드는 연결 폭풍(connection storm)이라는 고전적인 문제를 악화시킵니다. 3,000개의 동시 실행으로 확장되는 Lambda 함수는 3,000개의 소켓을 열어 max_connections를 초과하고, 시스템에 부하가 걸렸을 때 연쇄적인 장애를 일으킵니다. 각 동시 실행 환경은 격리되어 있으므로 함수 내 풀링은 도움이 되지 않습니다.

RDS Proxy는 클라이언트와 데이터베이스 사이에 위치하여 준비된 연결 풀(warm pool)을 유지하고 클라이언트 세션을 이 풀에 멀티플렉싱합니다. 이는 두 가지 문제를 해결합니다:

1. 연결 폭풍. 수천 개의 클라이언트 세션이 소규모 백엔드 풀에 멀티플렉싱됩니다.
2. 장애 조치 시간. 프록시는 백엔드 링크를 다시 설정하는 동안 클라이언트 연결을 열린 상태로 유지하여, 체감 장애 조치 시간을 최대 66%까지 단축하고 클라이언트 측의 TCP/TLS 재설정 및 DNS 재확인을 제거합니다.

IAM 및 Secrets Manager와 통합되어 자격 증명을 처리하므로 애플리케이션 코드에서 하드코딩된 보안 암호를 제거할 수 있습니다.

DBProxy:
  Type: AWS::RDS::DBProxy
  Properties:
    EngineFamily: POSTGRESQL
    RequireTLS: true
    IdleClientTimeout: 1800
    Auth:
      - AuthScheme: SECRETS
        SecretArn: !Ref DBSecret
        IAMAuth: REQUIRED

애플리케이션은 클러스터 엔드포인트가 아닌 프록시 엔드포인트에 연결합니다. 특별한 이유가 없는 한, 모든 Lambda-to-RDS 또는 높은 팬아웃(high-fan-out) 아키텍처는 RDS Proxy를 사용해야 합니다. EC2에서 자체 풀러(PgBouncer, ProxySQL)를 실행하는 것도 가능하지만, 이는 프록시가 제거하려는 바로 그 운영 오버헤드를 추가하는 셈입니다.

DynamoDB: 용량 모드

DynamoDB는 해시 키로 수평 분할되며, 어떤 규모에서든 한 자릿수 밀리초의 지연 시간을 제공하는 관리형 키-값/문서 스토어입니다. 두 가지 용량 모드를 제공합니다:

온디맨드는 훨씬 간단하지만, 잘 활용된 프로비저닝 용량에 비해 요청당 비용이 약 6–7배 더 비쌉니다. 매일 밤 4시간 동안 500 WCU를 사용하는 배치 작업의 경우, 온디맨드는 과도한 비용이 발생합니다. 예약된 스케일링이나 예약 용량을 사용하는 프로비저닝 모드가 훨씬 저렴합니다. 반대로, 예측 불가능한 공개 론칭 워크로드에 프로비저닝 모드를 사용하면 스로틀링이 발생할 수 있습니다. 변동성이 중간 정도인 꾸준한 워크로드의 경우, 약 70% 사용률을 목표로 추적하는 오토 스케일링을 설정한 프로비저닝 모드가 온디맨드보다 50–70%까지 의미 있게 저렴합니다:

TargetTrackingScalingPolicyConfiguration:
  TargetValue: 70.0
  PredefinedMetricSpecification:
    PredefinedMetricType: DynamoDBReadCapacityUtilization
  ScaleInCooldown: 60
  ScaleOutCooldown: 60

용량 모드는 24시간에 한 번씩 전환할 수 있습니다. 온디맨드가 항상 더 저렴하다고 가정하거나, 프로비저닝이 급증하는 트래픽에 항상 적합하다고 가정하는 것은 비용이 많이 드는 실수입니다.

DynamoDB: 일관성, 스트림, 글로벌 테이블

읽기는 기본적으로 **최종적 일관성(eventually consistent)**을 가집니다 (약 1초 이내의 오래된 데이터를 반환할 수 있으며, 0.5 RCU 비용). ConsistentRead=true를 설정하면 두 배의 비용으로 가장 최근에 커밋된 값을 반환합니다. 강력한 일관성 읽기(Strongly consistent read)는 글로벌 보조 인덱스(GSI)나 DAX를 통해서는 지원되지 않으며, 이 경로들은 항상 최종적 일관성 데이터를 반환합니다.

DynamoDB Streams는 항목 수준의 변경 사항을 순서가 보장되는 로그로 캡처하여 24시간 동안 보관하며, 폴링 없이 Lambda를 트리거하여 다운스트림 처리(검색 인덱싱, 알림, 테이블 간 비정규화)를 수행합니다.

Global Tables는 Streams를 기반으로 구축되며, ‘최종 쓰기자 우선(last-writer-wins)’ 충돌 해결 방식을 사용하는 다중 활성(multi-active), 다중 리전(multi-Region) 복제를 제공합니다. 여러 리전에서 읽기 및 쓰기가 로컬로 이루어져야 할 때 적합한 솔루션입니다. 하지만 스토리지 및 쓰기 비용이 거의 두 배가 되고(모든 쓰기는 각 복제 리전에서 WCU를 소모함), 리전 간 일관성이 약화됩니다. 단일 리전으로도 가용성 요구 사항을 충족할 수 있는데 Global Tables를 활성화하는 것은 함정입니다. 단일 리전의 DynamoDB는 이미 3개의 AZ에 걸쳐 복제되어 99.99%의 가용성을 제공합니다. 비용 효율적인 단일 리전 고가용성(HA) 구성은 PITR을 활성화하고, 필요에 따라 오토 스케일링이 적용된 프로비저닝 용량을 갖춘 단일 리전 테이블입니다.

**Point-in-Time Recovery (PITR)**는 지난 35일간의 데이터를 초 단위의 세분화된 복구 지점으로 지속적인 백업을 제공하며, 오버헤드는 거의 없습니다. 모든 프로덕션 테이블에 활성화해야 합니다. 이는 시간 단위가 아닌 분 단위의 일반적인 RPO 요구 사항을 충족시킵니다. 더 긴 보존 기간(규제 준수 등)이 필요한 경우, AWS Backup을 통합하여 예약되고 수명 주기가 관리되며 리전 간 복사가 가능한 백업을 사용하세요.

TTL을 사용하면 Unix epoch 만료 시간을 포함하는 속성을 지정할 수 있습니다. DynamoDB는 만료된 항목을 비용 없이 비동기적으로 삭제하므로 세션 스토어, 임시 토큰 또는 이벤트 캐시에 이상적입니다. TTL 삭제는 다운스트림 아카이빙을 위해 Streams를 통해 전달됩니다:

TTLSpecification:
  AttributeName: expireAt
  Enabled: true

분석을 위해서는 S3로 내보내기 기능을 사용하세요. 이 기능은 테이블 용량을 소비하지 않고 Athena, Redshift Spectrum 또는 EMR에서 읽을 수 있는 특정 시점 스냅샷을 생성하며, 테이블을 스캔하는 것보다 훨씬 나은 패턴입니다.

DAX: DynamoDB Accelerator

DAX는 DynamoDB를 위해 특별히 설계된 완전 관리형 인메모리, write-through 캐시로, DynamoDB의 한 자릿수 밀리초 기준 지연 시간 대비 마이크로초 단위의 읽기 지연 시간을 제공합니다. 가장 큰 특징은 API 호환성입니다. DAX 클라이언트는 DynamoDB SDK 클라이언트를 바로 대체할 수 있으므로, 애플리케이션은 쿼리 로직을 재작성하는 대신 엔드포인트 구성만 변경하여 DAX를 도입할 수 있습니다:

import amazondax
dax = amazondax.AmazonDaxClient(
    endpoint_url='dax://cluster.abc.dax-clusters.us-east-1.amazonaws.com')
table = dax.Table('Products')
resp = table.get_item(Key={'sku': '1234'})  # microsecond hit path

DAX는 두 가지 캐시를 유지합니다: GetItem/BatchGetItem 결과를 위한 **항목 캐시(item cache)**와 Query/Scan 결과를 위한 **쿼리 캐시(query cache)**입니다. 쓰기는 write-through 방식입니다. 즉, DAX가 DynamoDB로 쓰기 요청을 프록시하고 성공 시 항목 캐시를 업데이트합니다. 하지만 쿼리 캐시는 TTL에 의존하므로, 새로 작성된 항목에 대해서도 쿼리 결과가 오래된 데이터일 수 있습니다.

두 가지 제약 사항이 중요합니다. 첫째, DAX는 최종적 일관성 읽기만 가속화하며, 강력한 일관성 읽기는 캐시를 우회합니다. 둘째, DAX를 우회하는 다른 쓰기 작업은 데이터 부실(staleness)을 유발합니다. 매일 수백만 번 조회되는 제품 상세 페이지의 경우, DAX는 운영 오버헤드가 가장 적은 가속기입니다. 캐시 무효화 코드가 필요 없고, 별도의 클러스터 관리도 필요 없습니다. DynamoDB 앞에 ElastiCache를 두는 것도 가능하지만, 이 경우 DAX가 불필요하게 만드는 cache-aside 로직이 필요합니다.

ElastiCache: Redis와 Memcached

ElastiCache는 Redis 또는 Memcached를 실행하는 관리형 서비스로서, 밀리초 미만의 인메모리 데이터 액세스를 제공합니다. 엔진 선택은 기능에 따라 결정됩니다:

• Memcached — 수평적 샤딩을 지원하는 순수 다중 스레드 키/값 캐시로, 영속성, 복제, pub/sub 기능이 없습니다. 전체 캐시 손실이 허용되는 임시 캐싱 용도로만 사용합니다.
• Redis — 복제, 자동 장애 조치를 지원하는 다중 AZ, 샤딩을 위한 클러스터 모드, 영속성, pub/sub, 정렬된 집합(sorted sets), 트랜잭션, 전송 중 및 저장 시 암호화를 지원합니다. 내구성이 필요하거나 복잡한 데이터 유형이 필요한 모든 작업에 필수적입니다.

두 가지 대표적인 패턴이 주로 사용됩니다.

중앙 집중식 세션 스토어. ALB가 상태 비저장(stateless) EC2 또는 ECS 인스턴스로 트래픽을 분산할 때, 로컬 세션 스토리지를 사용하면 고정 세션(sticky session)이 강제되어 로드 불균형을 초래하고 스케일인, 배포, AZ 장애 시 문제가 발생합니다. 세션을 Redis로 외부화하면 모든 인스턴스가 어떤 요청이든 처리할 수 있으며, 호스트 장애 시에도 세션이 유지됩니다:

import redis, json
r = redis.Redis(host='sessions.abc123.ng.0001.use1.cache.amazonaws.com',
                port=6379, ssl=True)

def save_session(sid, data, ttl=1800):
    r.setex(f"sess:{sid}", ttl, json.dumps(data))

비용이 많이 드는 쿼리의 읽기 부하 분산 — 순위표(Redis의 정렬된 집합을 ZADD/ZREVRANGE로 구현), 카탈로그 조회, 집계 등이 해당됩니다. 캐싱 전략은 일관성 요구 사항에 맞춰야 합니다:

• Lazy loading (cache-aside): 애플리케이션이 캐시를 읽고, 캐시에 데이터가 없으면(miss) DB를 읽어 TTL과 함께 캐시에 저장합니다. 간단하지만, 초기 캐시 미스(cold miss)는 성능에 영향을 주고 데이터가 오래될(stale) 수 있습니다.
• Write-through: 애플리케이션이 캐시와 DB에 동시에 데이터를 씁니다. 캐시는 항상 최신 상태를 유지하지만, 쓰기 속도가 느려지고 사용되지 않는 데이터가 메모리를 차지할 수 있습니다.
• Write-back (write-behind): 데이터를 먼저 캐시에 쓰고, 비동기적으로 DB에 기록(flush)합니다. 쓰기 속도가 가장 빠르지만, 캐시 장애 시 데이터가 유실될 수 있습니다.

data = r.get(f"product:{sku}")
if data is None:
    data = db.query("SELECT * FROM products WHERE sku=%s", sku)
    r.setex(f"product:{sku}", 300, serialize(data))

TTL, 업데이트 시 명시적인 DEL 호출, 또는 write-through 같은 무효화 전략 없이 캐싱 계층에 의존하면 오래된 데이터(stale read)를 읽게 됩니다. 이 장애 모드는 조용히 발생합니다. 즉, 사용자가 데이터 불일치를 알아차리기 전까지 애플리케이션은 정상적으로 보이는 것입니다. 또한 캐싱은 읽기 전용 복제본(read replica)이 감당할 수 있는 수준을 넘어 읽기 성능을 확장하고, 트래픽 급증 시 기본 데이터베이스를 보호하는 가장 저렴한 방법이기도 합니다.

DAX와 달리 ElastiCache는 엔진에 구애받지 않으므로(engine-agnostic) 무효화 로직을 직접 관리해야 합니다. 이것이 바로 백업 스토어가 DynamoDB일 때 운영 단순성 측면에서 DAX가 더 유리한 이유입니다.

마이그레이션: DMS와 SCT

**AWS Database Migration Service (DMS)**는 동종 엔진(Oracle→Oracle, MySQL→Aurora MySQL) 간 또는 이기종 엔진(Oracle→Aurora PostgreSQL, SQL Server→RDS MySQL, 온프레미스→DynamoDB) 간에 데이터를 복제합니다. DMS 작업은 세 단계로 구성됩니다:

1. 전체 로드(Full load) — 기존 행을 대량으로 복사합니다.
2. CDC (변경 데이터 캡처) — 원본의 트랜잭션 로그를 추적하여 지속적인 변경 사항을 적용합니다.
3. 전체 로드 + CDC — 일반적인 최소 다운타임 패턴입니다. 원본은 온라인 상태를 유지하고, DMS가 대상(target)을 동기화하며, 최종 전환(cutover)은 짧은 DNS 스위치로 이루어집니다.

aws dms create-replication-task \
  --replication-task-identifier ora-to-aurora \
  --source-endpoint-arn $SRC --target-endpoint-arn $TGT \
  --migration-type full-load-and-cdc \
  --table-mappings file://mappings.json \
  --replication-instance-arn $RI

DMS Serverless는 복제 인스턴스의 크기를 조정하고 관리할 필요를 없애줍니다. 워크로드에 따라 용량이 자동으로 프로비저닝되므로, 변동이 심하거나 장기간 실행되는 CDC에 적합합니다. 원본 엔진은 보조 로깅(supplemental logging, Oracle) 또는 ROW 형식 바이너리 로깅(MySQL)이 활성화되어 있어야 합니다. 매우 큰 초기 데이터 로드의 경우, DMS는 오프라인 로드를 위해 Snowball Edge와 통합될 수 있습니다.

DMS는 스키마가 아닌 데이터를 이전합니다. 이기종 마이그레이션의 경우 **AWS Schema Conversion Tool (SCT)**와 함께 사용해야 합니다. SCT는 저장 프로시저, 뷰, 트리거, 시퀀스 및 특정 방언(dialect)에 맞는 타입(예: Oracle PL/SQL을 PostgreSQL PL/pgSQL로, 또는 T-SQL을 Aurora MySQL로)을 변환합니다. SCT는 수동 수정이 필요한 객체를 표시하는 평가 보고서를 생성합니다(복잡한 코드베이스의 경우 일반적으로 5–20%). 엔진 간 마이그레이션에서 DMS만 단독으로 실행하는 것은 흔한 실수입니다. DMS가 기본적인 대상 테이블을 생성할 수는 있지만, 프로시저나 독점적인 타입을 올바르게 변환하지는 못하기 때문입니다. 동종 마이그레이션의 경우 SCT는 필요 없으며, 네이티브 도구(mysqldump, pg_dump, RMAN)와 DMS CDC만으로 충분합니다.

전체 엔진 간 마이그레이션 패턴은 다음과 같습니다:

1. SCT: convert schema, apply to target RDS/Aurora
2. DMS full-load task: bulk copy existing data
3. DMS CDC task: capture ongoing changes from source
4. Cutover: stop writes at source, wait for CDC lag = 0, redirect app

백업 및 지정 시간 복구(PITR)

RDS 자동 백업은 일일 스냅샷과 5분 간격의 트랜잭션 로그 백업을 결합하여 보존 기간(1~35일, 기본값 7일) 내의 어느 시점으로든 PITR(지정 시간 복구)을 가능하게 합니다. 복원 시에는 새 인스턴스가 생성되므로(기존 인스턴스에 덮어쓸 수 없음), 애플리케이션 엔드포인트나 CNAME을 업데이트해야 합니다. 수동 스냅샷은 보존 기간이 지나도 유지되며 인스턴스 삭제 시에도 살아남고(최종 스냅샷 설정에 따라 다름), DR을 위해 다른 리전으로 복사하거나 다른 계정과 공유할 수 있습니다.

EBS 기반 스냅샷을 위한 **Fast Snapshot Restore (FSR)**는 지연 로딩(lazy-load) 페널티를 제거하여 복원된 볼륨이 즉시 최대 성능을 발휘하도록 합니다. 이는 시간적 압박 속에서 하나의 스냅샷으로 여러 환경을 구성할 때 유용합니다. Aurora 클로닝은 동일 리전 내 복사 시 스냅샷 과정을 완전히 생략합니다. DynamoDB PITR은 테이블별로 활성화해야 하는 유사한 기능으로, 복원 시 새 테이블을 생성합니다.

목적별 데이터베이스

액세스 패턴에 맞는 목적별(purpose-built) 엔진을 선택하면 나중에 비용이 많이 드는 아키텍처 재설계를 방지할 수 있습니다. Amazon Neptune은 Gremlin, openCypher, SPARQL을 지원하는 관리형 그래프 데이터베이스로, 관계형 엔진에서는 재귀적 조인 비용이 엄청나게 비싼 관계 탐색 쿼리(사기 탐지망, 소셜 그래프, 지식 그래프 등)에 적합합니다. Amazon QLDB는 추가만 가능한(append-only) 저널을 갖춘 불변의 암호화 검증 가능 원장 데이터베이스로, 공급망 출처, 금융 거래, 차량 등록 기록 등 위변조 방지 감사가 필요한 기록 시스템에 적합합니다. DynamoDB는 단일 테이블 설계, 계층적 액세스를 위한 복합 정렬 키, 대체 액세스 경로를 위한 GSI와 같은 패턴을 사용하여 모든 규모에서 한 자릿수 밀리초의 키-값 또는 문서 액세스를 제공하는 기본 선택지입니다. 이러한 워크로드를 억지로 RDS에 맞추면 잠금 경합(원장 쓰기), 쿼리 복잡성(그래프 순회), 확장성 한계(높은 처리량의 키-값) 등의 문제가 발생하며, 각 문제 모두 설계 시 올바른 선택을 하는 것보다 나중에 해결하는 데 훨씬 더 많은 비용이 듭니다.

함정 요약

• 읽기 전용 복제본을 HA(고가용성)로 사용. 비동기식, 자동 승격 없음, 승격 시 엔드포인트 변경, 진행 중인 트랜잭션 손실. Multi-AZ가 HA를 위한 해답입니다.
• 읽기 확장(read scaling)을 위해 Multi-AZ 사용. 표준 RDS Multi-AZ에서 대기(Standby) 인스턴스는 읽을 수 없습니다. 읽기 전용 복제본이나 Aurora 복제본을 사용해야 합니다.
• 프로덕션 환경에서 Single-AZ 사용. 장애 조치(failover) 대상이 없으며, AZ 이벤트나 인스턴스 재시작 시 가용성을 잃게 됩니다. Multi-AZ는 약 2배의 비용으로 가용성을 질적으로 크게 향상시킵니다.
• 기본적으로 복제본을 프라이머리와 동일한 크기로 설정. 복제본은 훨씬 작은 사양이 필요한 경우가 많습니다. 승격 대상이 아니라면 측정된 워크로드에 맞게 크기를 조정해야 합니다.
• 온디맨드 DynamoDB가 항상 더 저렴하다고 생각. 요청당 비용이 약 6~7배 더 비쌉니다. 안정적인 워크로드에서는 프로비저닝 + 오토 스케일링 방식이 더 유리합니다.
• 단일 리전(single-region) 요구사항에 Global Tables 사용. 다중 리전 사용자 근접성이나 DR이 필요하지 않다면, 이점 없이 비용만 두 배로 늘고 일관성만 약화됩니다.
• Aurora Global Database의 보조(secondary) 데이터베이스가 쓰기를 처리한다고 생각. 관리형 장애 조치(managed failover)로 승격되기 전까지는 읽기 전용입니다.
• RDS Proxy 없이 Lambda에서 RDS로 직접 연결. 커넥션 폭증(Connection storm)으로 max_connections가 소진됩니다. 함수 내 커넥션 풀은 동시 실행 환경 전반에 걸쳐 도움이 되지 않습니다.
• 이기종(heterogeneous) 마이그레이션에 DMS만 단독으로 사용. 데이터만 이동하며 스키마는 이동하지 않습니다. SCT와 함께 사용해야 합니다.
• 오토 스케일링이나 FreeStorageSpace 경보 없이 고정된 RDS 스토리지 사용. 잠재적인 장애 원인입니다. storage-full 상태가 되면 쓰기 요청이 거부됩니다.
• 무효화(invalidation) 전략 없이 캐싱 사용. 조용한 데이터 불일치(Silent staleness)를 유발합니다. TTL, 완전 сквозная запись(write-through), 또는 명시적 무효화는 필수적입니다.
• DAX나 GSI를 통해 강력한 일관성(strongly consistent) 읽기 시도. 두 경로 모두 최종적 일관성(eventually consistent) 데이터만 제공합니다.

← 콘텐츠 전송 · 모든 도메인 · 분석 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Amazon 찾아보기 →