Amazon DVA-C02: Amazon DynamoDB 및 NoSQL 설계 — 학습 가이드

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

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

데이터 모델링 및 액세스 패턴

DynamoDB 설계는 액세스 패턴에서 시작합니다. 모든 쿼리는 기본 키, 글로벌 보조 인덱스(GSI) 또는 로컬 보조 인덱스(LSI)에 매핑되어야 합니다. 테이블 설계는 관계형 스키마 구조가 아닌, 애플리케이션이 항목을 읽고 쓰는 방식에 따라 결정됩니다. ‘핫 파티션’을 피하기 위해 카디널리티가 높은 파티션 키를 선택하고, 범위 쿼리가 필요할 때는 복합 기본 키(파티션 키 + 정렬 키)를 사용하세요. Query 작업은 파티션 키에 대한 동등성 조건과 정렬 키에 대한 선택적 KeyConditionExpression을 요구합니다. SDK의 경우 DynamoDB Document 추상화를 사용하는 것이 좋습니다. AWS SDK for JavaScript v3에서는 DynamoDBDocumentClient를 사용하거나(marshall/unmarshall이 자동으로 처리됨), Java에서는 DynamoDB Enhanced Client를 사용하여 객체를 속성에 매핑하세요. 단일 테이블 패턴은 읽기 패턴이 키를 공유하고 type 속성을 통해 항목 유형을 인코딩할 수 있을 때만 구현하세요. 필요한 항목에만 속성을 작성하여 보조 액세스 경로를 노출하려면 희소(sparse) GSI를 사용하세요. 흔한 함정은 Scan을 남용하는 것입니다. 대용량 테이블을 스캔하는 것은 비용이 많이 들고 페이지네이션됩니다(LastEvaluatedKey). RCU 사용량을 줄이려면 ProjectionExpression과 함께 Query를 사용하는 것이 좋습니다. 조건부 쓰기의 경우 ConditionExpression과 함께 UpdateItem을 사용하거나, 여러 항목의 원자성을 위해 TransactWriteItems를 사용하세요. ConditionalCheckFailedException을 처리하고 지터(jitter)를 사용한 백오프를 적용하세요.

인덱스, 쿼리 및 트랜잭션 패턴

로컬 보조 인덱스는 테이블 생성 시에만 만들 수 있고, 기본 테이블과 동일한 파티션 키를 공유하며, 쿼리 시 테이블의 읽기 용량을 소비합니다. 반면 GSI는 테이블 생성 후에도 추가할 수 있고, 독립적인 용량 또는 온디맨드 결제 방식을 가지며, 다른 파티션 키를 허용합니다. Query 호출은 KeyConditionExpression과 ExpressionAttributeNames/Values를 사용하며, 프로젝션 표현식(projection expression)은 데이터 전송량을 줄입니다. GSI는 기본적으로 최종적 일관성을 가지며, 인덱싱된 속성을 프로젝션하는 모든 기본 테이블 쓰기가 해당하는 GSI 쓰기를 생성하기 때문에 추가 쓰기 비용이 발생합니다. 이에 맞춰 WCU를 계획하고 인덱스의 ConsumedWriteCapacityUnits를 모니터링하세요. 강력한 일관성을 위해서는 기본 테이블에서 GetItem 또는 ConsistentRead=true를 사용한 Query를 사용하세요(GSI는 강력한 일관성 읽기를 지원하지 않습니다). 트랜잭션(TransactWriteItems 및 TransactGetItems)은 최대 25개 항목 또는 4MB 페이로드에 걸쳐 원자성을 보장합니다. 실패를 검사하려면 ReturnValuesOnConditionCheckFailure를 사용하세요. BatchWriteItem과 BatchGetItem은 각각 25개와 100개 항목으로 제한되며 트랜잭션 방식이 아닙니다. 코드는 지수 백오프를 사용하여 재시도함으로써 UnprocessedItems를 처리해야 합니다. 관계형 조인을 인덱스로 마이그레이션할 때 GSI의 비용과 최종적 일관성 영향을 잊는 것은 흔한 실수입니다.

용량 모드, 성능 튜닝 및 문제 해결

예측 가능성에 따라 프로비저닝 용량과 온디맨드 용량 중에서 결정하세요. Auto Scaling(DynamoDB용 Application Auto Scaling)을 사용하는 프로비저닝 모드는 안정적인 워크로드에 대해 RCU/WCU 및 비용 제어를 제공하는 반면, 온디맨드 모드는 용량 계획 없이 폭증하는 트래픽을 단순화하지만 요청당 가격이 더 높습니다. 목표 사용률과 여러 스케일링 정책으로 Auto Scaling을 활성화하세요. ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits, ThrottledRequests, SuccessfulRequestLatency, SystemErrors, ConditionalCheckFailedRequests와 같은 CloudWatch 지표를 모니터링하여 핫스팟과 스로틀링을 탐지하세요. 단일 키 스로틀링을 완화하기 위해 적응형 용량(adaptive capacity)을 사용하되, 이에 의존하지 말고 균일한 키 분산을 위해 설계하세요. 읽기 중심 워크로드의 경우 마이크로초 단위 읽기를 위해 DAX를 고려하거나 Amazon ElastiCache로 캐시하세요. 쓰기 중심 워크로드의 경우 쓰기 샤딩(접두사 또는 버킷)을 사용하여 여러 파티션에 쓰기를 분산하세요. ProvisionedThroughputExceededException을 검사하고 SDK 클라이언트에 지터를 사용한 지수 백오프를 구현하여 문제를 해결하세요. 핫 키를 찾기 위해 CloudWatch Contributor Insights를 활성화하고, 세그먼트화된 워커를 사용하여 대규모 일회성 분석을 위해 Parallel Scan을 사용하세요. 항목 크기 제한(400KB)과 큰 항목이 RCU/WCU를 증가시킨다는 점을 기억하세요. 필요한 경우 큰 블롭(blob)은 S3로 분할하고 메타데이터는 DynamoDB에 저장하세요.

스트림, 통합, 백업 및 운영 모범 사례

DynamoDB Streams는 파티션 키별로 순서대로 항목 수준 변경(INSERT, MODIFY, REMOVE)을 캡처하고 이벤트 소스 매핑을 통해 Lambda와 직접 통합됩니다(startingPosition을 TRIM_HORIZON 또는 LATEST로 구성하고, batchSize와 maximumBatchingWindowInSeconds를 설정하며, bisectBatchOnError와 maximumRetryAttempts를 조정합니다). 안정적인 처리를 위해 Dead-Letter Queue(SQS 또는 SNS)를 사용하는 Lambda를 이용하거나, 분석을 위해 스트림 레코드를 Kinesis 또는 Kinesis Data Firehose로 라우팅합니다. 항목의 자동 만료를 위해 Time To Live(TTL)를 활성화합니다. TTL 삭제는 최종적으로 처리되므로 즉각적인 일관성을 위해 의존해서는 안 됩니다. 재해 복구를 위해 Point-in-Time Recovery(PITR) 및 온디맨드 백업을 사용하고, 다중 리전 가용성을 위해 Global Tables를 사용하여 리전 간 변경 사항을 복제합니다. 서비스에 최소 권한 IAM 역할을 적용하고 Lambda에는 dynamodb:Query, dynamodb:PutItem, dynamodb:UpdateItem, dynamodb:GetItem, dynamodb:DescribeStream, dynamodb:ListStreams 작업만 부여합니다. 일반적인 운영상의 함정으로는 소비자(consumer)의 재시도/백오프 로직 누락, 부적절한 GSI 용량 계획, 지연 감지를 위한 Streams IteratorAge 모니터링 실패 등이 있습니다. CloudWatch Logs와 X-Ray를 사용하여 엔드투엔드 지연 시간을 추적하세요.

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

시나리오: AcmeMedia는 us-east-1의 단일 DynamoDB 테이블에서 수천만 개의 항목을 포함하는 메타데이터 카탈로그를 운영하고 있습니다. 새로 출시된 이미지 처리 파이프라인은 photographerId와 uploadTimestamp 범위에 대한 낮은 지연 시간의 쿼리가 필요하며, 다운스트림 Lambda 소비자는 변경 사항을 안정적으로 처리해야 합니다.

과제: 테이블 재설계 없이 photographerId + 타임스탬프 범위에 대한 효율적인 쿼리 경로를 추가하고, 다운스트림 Lambda가 최소 한 번(at-least-once) 시맨틱으로 스트림 레코드를 처리하도록 보장하며, 활동이 많은 사진 작가로 인한 핫 파티션을 방지해야 합니다.

권장 접근 방식:

파티션 키가 photographerId이고 정렬 키가 uploadTimestamp인 photographer-gsi라는 이름의 GSI를 생성합니다. UpdateTable API 또는 콘솔을 사용하여 GSI를 추가하고, UpdateTable을 통해 ProvisionedThroughput 또는 On-Demand 결제 방식을 지정하며, IndexStatus 모니터링을 설정합니다.
항목을 쓸 때 photographerId와 uploadTimestamp 속성을 포함하여 인덱스 프로젝션이 희소(sparse)하도록 합니다. 스토리지 및 쓰기 비용을 줄이기 위해 쿼리에 필요한 비-키(non-key) 속성을 포함하는 ProjectionType=INCLUDE를 선택합니다.
테이블에서 DynamoDB Streams를 ENABLED로 구성하고, startingPosition=TRIM_HORIZON, 조정된 batchSize(예: 100), bisectBatchOnError=true, maximumRetryAttempts=2로 Lambda 이벤트 소스 매핑을 생성합니다. 그리고 Lambda 함수 구성에서 SQS 큐를 Dead-Letter Destination으로 설정합니다.
지터(jitter)를 포함한 SDK 클라이언트 재시도를 구현하고(AWS SDK 내장 재시도 전략 사용), 단일 photographerId가 여전히 스로틀링을 유발하는 경우 쓰기 샤딩(write sharding)을 적용합니다(쓰기 시 photographerId에 N개의 버킷으로 접두사를 붙이고, 읽기 시 클라이언트 측에서 접두사를 제거).

근거: GSI를 추가하면 기본 기본 키를 변경하지 않고도 필요한 액세스 패턴을 노출할 수 있습니다. 필요한 속성만 프로젝션하면 GSI 쓰기 비용이 절감됩니다. DLQ 및 재시도 제어 기능이 있는 Streams + Lambda는 안정적인 최소 한 번(at-least-once) 처리를 제공하며, 샤딩은 카디널리티가 높은 트래픽으로 인한 핫 파티션을 방지합니다.

← Amazon API Gateway 및 앱 통합 · 모든 도메인 · CloudFormation 및 코드형 인프라 (SAM →

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