Amazon DVA-C02: 데이터베이스 및 캐싱 (RDS, Aurora, ElastiCache, Timestream, 프록시) — 학습 가이드

By Laurynas Brazys · 28 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

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

RDS와 Aurora: 설계, 확장 및 암호화

RDS 또는 Aurora에서 관계형 데이터베이스를 설계하는 것은 단일 노드 프로비저닝된 RDS와 Aurora의 분산 스토리지 간의 워크로드 트레이드오프를 고려하는 것에서 시작됩니다. 높은 읽기 확장성과 빠른 장애 조치가 필요할 때는 Aurora를 선택하세요. Aurora 복제본은 클러스터 볼륨을 공유하므로 승격이 빠른 반면, RDS MySQL/Postgres 읽기 전용 복제본은 비동기식 binlog 기반 복제를 사용하므로 지연이 발생할 수 있습니다. 읽기 확장을 위해서는 읽기 전용 복제본을 추가하고 애플리케이션의 읽기 트래픽을 해당 복제본으로 보내야 합니다. Aurora에서는 리더 엔드포인트를 사용하여 복제본 간에 자동으로 부하를 분산할 수 있습니다. 쓰기의 경우, 수직 확장(인스턴스 클래스)과 신중한 스키마/인덱스 설계가 중요합니다. 생성 시 항상 KMS CMK로 저장 데이터 암호화를 활성화해야 합니다. 나중에 암호화를 활성화하려면 스냅샷을 생성한 후 암호화된 새 인스턴스로 복원해야 하므로 이는 흔히 빠지는 함정입니다. 전송 중 데이터 보호를 위해서는 TLS/SSL 연결을 강제해야 합니다(RDS는 CA 번들을 제공합니다). 자격 증명의 경우, 내장된 RDS 순환 Lambda 템플릿을 사용하여 자동 순환 기능이 있는 AWS Secrets Manager를 사용하는 것이 좋습니다. SDK에서는

undefined

를 사용하여 프로그래밍 방식으로 보안 암호를 가져옵니다. 정적 암호를 제거하기 위해 IAM DB 인증을 고려해 보세요. SDK의 RDS.Signer 또는 rds.generate-db-auth-token을 통해 토큰을 생성한 다음, 수명이 짧은 토큰으로 연결합니다. Performance Insights, Enhanced Monitoring, CloudWatch를 사용하여 계측하고, 핫스팟을 찾기 위해 느린 쿼리 로그와 EXPLAIN을 사용하세요.

커넥션 풀링, RDS Proxy 및 서버리스 패턴

서버리스 함수와 커넥션 사용량이 많은 앱은 종종 DB 커넥션 한도를 소진합니다. Node.js에서 간단한 패턴은 Lambda 전역 스코프에 mysql2/promise 풀을 배치하고 여러 호출에 걸쳐 재사용하는 것이지만, 이는 대규모 동시성 확장 문제를 해결하지는 못합니다. RDS Proxy가 관리형 해결책입니다. create_db_proxy로 프록시를 생성하고, Secrets Manager 보안 암호 및 대상 RDS/Aurora 인스턴스와 연결한 다음, 앱에서 프록시 엔드포인트를 사용합니다. RDS Proxy는 커넥션 멀티플렉싱, IAM 인증 통합 및 장애 조치를 처리합니다. 서버리스인 Aurora Serverless를 사용하거나 HTTP 스타일 호출을 선호하는 경우 RDS Data API를 사용하세요.

undefined

를 사용하면 Lambda가 영구적인 TCP 연결 없이 SQL을 실행할 수 있습니다. 흔한 함정 중 하나는 Data API를 프로비저닝된 클러스터와 혼용하는 것입니다. Data API는 서버리스 클러스터용으로 설계되었으며 지연 시간/트랜잭션 의미 체계가 다릅니다. 또한 RDS Proxy에는 커넥션 풀 타임아웃과 max_connections가 있다는 점에 유의해야 합니다. Lambda의 급증하는 트래픽에 대비하여 유휴 클라이언트 타임아웃과 커넥션 대여 설정을 조정하세요. 자격 증명에는

undefined

를 사용하고, rotateSecret으로 순환하거나 콘솔/SDK에서 자동 순환을 활성화하세요.

캐싱 전략: ElastiCache, DAX 및 캐시 설계

캐싱 선택은 데이터 스토어와 액세스 패턴에 따라 달라집니다. DynamoDB의 경우, DAX는 마이크로초 단위의 읽기 지연 시간과 DynamoDB.DocumentClient를 래핑하는 AmazonDaxClient를 통한 투명한 SDK 통합을 제공합니다. 이는 읽기 중심의 최종적 일관성 워크로드에 이상적입니다. 관계형 또는 임의의 키-값 캐싱을 위해서는 고급 데이터 구조, 영속성(AOF/RDB 스냅샷), 복제, 클러스터 모드 샤딩을 지원하는 ElastiCache Redis를 사용하거나, 간단하고 수평적으로 확장 가능한 캐싱을 위해 Memcached를 사용하세요. 읽기에는 cache-aside 패턴을 구현하고, 일관성과 복잡성 측면에서 허용 가능한 경우에만 write-through/write-behind를 구현하세요. 키 설계는 매우 중요합니다. 애플리케이션과 버전으로 키 접두사를 지정하고, 합리적인 TTL을 사용하며, 무한한 카디널리티를 피해야 합니다. 캐시 스탬피드는 lock-and-refresh 패턴(SETNX 또는 Redlock)이나 확률적 조기 TTL 갱신으로 처리하세요. Redis를 다중 AZ 및 자동 장애 조치로 구성하고, CreateReplicationGroup을 통해 자동 장애 조치 및 스냅샷 기능이 있는 복제 그룹을 생성하세요. 흔한 함정으로는 쓰기 후 오래된 캐시 데이터(stale cache), 스키마 변경 시 캐시 무효화 누락, 절대적인 일관성 기대 등이 있습니다. CloudWatch에서 캐시 적중률과 제거(eviction) 지표를 모니터링하고, 메모리나 CPU가 병목 현상을 일으킬 때 노드 유형이나 클러스터 샤드를 확장하세요.

Timestream을 사용한 시계열 및 읽기 전용 복제본 패턴

Amazon Timestream은 시계열 데이터 전용으로 설계되었습니다. SDK의 WriteRecords API를 사용하여 배치(batch) 형태의 WriteRecords 호출로 데이터를 수집하고, TimestreamQuery.query(sql)로 쿼리합니다. 레코드 스키마는 낮은 카디널리티(cardinality)의 차원(dimension)으로 설계하고, 쓰기 증폭(write amplification)을 줄이기 위해 다중 측정 레코드(multi-measure records)를 사용하세요. 테이블별로 메모리 및 마그네틱 스토리지 보존 규칙을 구성하여 최신 데이터는 ‘hot’ 상태로 유지하고 오래된 데이터는 저렴하게 저장하세요. 메모리 티어의 보존 크기가 비용과 쿼리 성능에 영향을 미치므로 보존 기간 조정은 매우 중요합니다. 분석 시에는 시계열 전용 쿼리(time_bin 또는 bin)를 사용하고, 차원에 필터를 푸시다운(push down)하여 스캔하는 데이터 양을 최소화하세요. 시계열 데이터를 관계형 스토어와 통합할 때는, 변경 불가능한 과거 데이터는 Timestream으로 오프로드하고, ‘hot’ 메타데이터는 ElastiCache와 함께 RDS/Aurora에서 제공하세요. 관계형 데이터베이스의 읽기 확장을 위해서는 읽기 전용 복제본(read replicas)을 추가하고 읽기 전용 트래픽을 라우팅하세요. Aurora의 경우, 리더 엔드포인트(reader endpoints)를 사용하고 중요한 읽기 요청을 라우팅하기 전에 복제 지연(CloudWatch ReplicaLag)을 확인해야 합니다. 개발자가 흔히 겪는 문제점은 Timestream의 높은 카디널리티나 요청별로 생성되는 캐싱 키로, 이는 스토리지 사용량을 급증시키고 성능을 저하시킵니다. 쓰기 작업에는 배치를 사용하고, 비동기 수집 파이프라인(Kinesis, Firehose)을 활용하여 피크 트래픽을 완화하고 스로틀링(throttling)을 방지하세요.

실용적인 문제: 사용 사례 시나리오

시나리오: NovaShop은 AWS에서 다중 리전 이커머스 플랫폼을 운영합니다. us-east-1 리전의 주문 데이터는 Aurora MySQL을 사용하고, API는 Lambda 기반이며, 글로벌 고객 카탈로그는 DynamoDB에 저장되어 있습니다. 개발자들은 단일 AWS 계정에서 CI/CD를 사용하며 DB 자격 증명은 Secrets Manager에 저장합니다.

과제: 판매 급증 시 Lambda 함수가 DB 커넥션을 모두 소진하고, 카탈로그는 마이크로초 단위의 읽기 성능이 필요합니다. 개발자들은 자격 증명을 교체하여 보안을 유지하면서 제품 정보 읽기 지연 시간을 최소화해야 합니다.

권장 접근 방식:

CreateDBProxy를 사용하여 Aurora 클러스터용 RDS Proxy를 생성하고, Secrets Manager 보안 암호의 ARN을 연결한 후 IAM 인증을 구성합니다. Lambda가 프록시 엔드포인트를 사용하고 SecretsManager.getSecretValue()를 통해 자격 증명을 가져오도록 업데이트합니다.
카탈로그를 위해 Amazon DAX 클러스터를 배포하고, DynamoDB 클라이언트를 마이크로초 단위 읽기를 위해 DynamoDB DocumentClient를 래핑하는 AmazonDaxClient({endpoints})로 전환합니다.
RDS 순환 Lambda 템플릿(rotate-secret 또는 콘솔에서 구성)을 사용하여 Aurora 보안 암호에 대한 Secrets Manager 자동 순환을 활성화하고, Lambda의 IAM 역할이 secretsmanager:GetSecretValue를 호출할 수 있도록 보장합니다.
세션 캐싱을 위해 ElastiCache Redis 클러스터(클러스터 모드)를 추가하고, TTL을 사용하는 캐시 어사이드(cache-aside) 패턴과 SETNX 새로 고침 잠금을 구현하여 캐시 스탬피드(stampede)를 방지합니다.

근거: RDS Proxy를 사용하면 Lambda 스케일링으로 인한 커넥션 폭증을 방지할 수 있으며, IAM/Secrets Manager는 자동 순환 기능으로 자격 증명을 보호합니다. DAX는 마이크로초 단위의 DynamoDB 읽기를 제공하고 ElastiCache는 일시적인 세션/읽기 캐싱을 처리하여, 서버리스 확장 및 보안 모범 사례에 부합합니다.

← 스토리지 · 모든 도메인 · 메시징 →

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