DynamoDB 완전 정복 | AWS DynamoDB로 NoSQL 마스터하기

AWS DynamoDB는 완전 관리형 NoSQL 데이터베이스로, 무제한 확장성과 단일 자릿수 밀리초 대기 시간을 제공하며 Single Table Design과 Global Secondary Index를 활용한 최적화된 설계 패턴으로 서버리스 애플리케이션 구축에 필수적인 서비스입니다.

---

DynamoDB란 무엇인가

Amazon DynamoDB는 AWS에서 제공하는 완전 관리형 NoSQL 데이터베이스 서비스입니다.

기존 관계형 데이터베이스(RDBMS)와 달리 스키마가 자유로우며, 키-값(Key-Value) 및 문서(Document) 데이터 모델을 지원합니다.

2025년 1월, DynamoDB는 글로벌 테이블에 대한 다중 리전 강력한 일관성 기능을 제공하기 시작했으며, 이를 통해 최고 수준의 애플리케이션 복원력과 가용성을 보장합니다.

DynamoDB NoSQL 데이터베이스는 서버 관리가 전혀 필요 없는 서버리스 아키텍처를 제공하며, 자동으로 확장되어 초당 수백만 건의 요청을 처리할 수 있습니다.

AWS DynamoDB는 Amazon의 실제 프로덕션 환경에서 검증된 기술로, 2004년 홀리데이 시즌의 대규모 트래픽 장애를 극복하기 위해 개발되었습니다.

DynamoDB의 핵심 특징은 다음과 같습니다.

완전 관리형 서비스: 서버 프로비저닝, 패치, 백업 등 인프라 관리가 필요 없습니다.

예측 가능한 성능: 데이터 크기에 관계없이 일관된 단일 자릿수 밀리초 응답 시간을 제공합니다.

무제한 확장성: 테이블당 저장할 수 있는 데이터 양에 제한이 없으며, 트래픽에 따라 자동으로 확장됩니다.

고가용성: 다중 가용 영역(AZ)에 데이터를 자동으로 복제하여 99.99%의 가용성을 보장합니다.

---

DynamoDB의 핵심 구성 요소

테이블 구조의 이해

DynamoDB의 테이블 구조는 관계형 데이터베이스와 근본적으로 다릅니다.

각 테이블은 아이템(Item)의 모음으로 구성되며, 각 아이템은 속성(Attribute)을 가집니다.

테이블을 생성할 때 반드시 지정해야 하는 것은 파티션 키(Partition Key)입니다.

선택적으로 정렬 키(Sort Key)를 추가하여 복합 기본 키(Composite Primary Key)를 만들 수 있습니다.

파티션 키와 정렬 키

파티션 키는 DynamoDB가 데이터를 여러 파티션에 분산 저장하기 위해 사용하는 해시 키입니다.

DynamoDB는 해싱과 B-트리를 사용하여 데이터를 관리하며, 데이터 입력 시 파티션 키를 해싱하여 다양한 파티션에 분산시킵니다.

파티션 키를 선택할 때는 데이터가 고르게 분산되도록 카디널리티가 높은 값을 선택해야 합니다.

예를 들어, 사용자 ID, 주문 ID, 디바이스 ID 등이 좋은 파티션 키가 될 수 있습니다.

정렬 키는 같은 파티션 키를 가진 아이템들을 정렬하는 데 사용됩니다.

정렬 키를 사용하면 특정 파티션 내에서 범위 쿼리(Range Query)를 수행할 수 있습니다.

예를 들어, 파티션 키가 사용자 ID이고 정렬 키가 타임스탬프인 경우, 특정 사용자의 특정 기간 데이터를 효율적으로 조회할 수 있습니다.

구분	파티션 키	정렬 키
필수 여부	필수	선택
역할	데이터 분산	파티션 내 정렬
쿼리	정확한 값 일치	범위 검색 가능
사용 예	UserID, OrderID	Timestamp, Version

보조 인덱스

DynamoDB는 두 가지 유형의 보조 인덱스를 제공합니다.

로컬 보조 인덱스(Local Secondary Index, LSI)는 테이블 생성 시에만 정의할 수 있으며, 기본 테이블과 동일한 파티션 키를 사용하되 다른 정렬 키를 지정합니다.

LSI는 강력한 일관성(Strong Consistency) 읽기를 지원하며, 테이블당 최대 5개까지 생성할 수 있습니다.

Global Secondary Index(GSI)는 언제든지 생성하거나 삭제할 수 있으며, 기본 테이블과 완전히 다른 파티션 키와 정렬 키를 사용할 수 있습니다.

GSI는 언제든지 생성하고 삭제할 수 있으며, 기본 테이블과 다른 파티션 키를 선택적으로 사용할 수 있습니다.

GSI는 최종 일관성(Eventual Consistency)만 지원하며, 테이블당 최대 20개까지 생성 가능합니다.

GSI는 Single Table Design 패턴의 핵심 구성 요소로, 다양한 액세스 패턴을 지원하는 데 필수적입니다.

인덱스 설계 시 주의할 점은 모든 인덱스가 쓰기 작업에 성능 영향을 준다는 것입니다.

인덱스 시스템과 마찬가지로 DynamoDB는 테이블에 대한 모든 업데이트가 각 인덱스에 반영되어야 하며, 이를 위해 로그 전파자(log propagator) 서비스를 사용합니다.

---

DynamoDB 용량 모드

프로비저닝 용량 모드

프로비저닝 용량(Provisioned Capacity) 모드는 애플리케이션에 필요한 읽기/쓰기 용량 단위를 사전에 지정하는 방식입니다.

읽기 용량 단위(RCU)는 최대 4KB 크기의 아이템에 대해 초당 강력한 일관성 읽기 1회 또는 최종 일관성 읽기 2회를 의미합니다.

쓰기 용량 단위(WCU)는 최대 1KB 크기의 아이템에 대해 초당 쓰기 1회를 의미합니다.

프로비저닝 모드는 예측 가능한 트래픽 패턴을 가진 애플리케이션에 적합하며, 비용 효율적입니다.

Auto Scaling을 활성화하면 트래픽 변화에 따라 용량이 자동으로 조정됩니다.

최소 및 최대 용량 한도를 설정하면, DynamoDB가 그 범위 내에서 자동으로 용량을 조절합니다.

온디맨드 스케일링 모드

온디맨드(On-Demand) 모드는 용량 계획 없이 사용한 만큼만 비용을 지불하는 방식입니다.

2025년 8월부터 DynamoDB는 24시간 내 프로비저닝에서 온디맨드 모드로 최대 4회까지 전환할 수 있는 기능을 제공하여, 대용량 데이터 로드 작업이나 워크로드 요구사항 관리에 더 큰 유연성을 제공합니다.

온디맨드 스케일링은 트래픽이 예측 불가능하거나 급격하게 변동하는 애플리케이션에 이상적입니다.

서버리스 애플리케이션을 구축할 때 온디맨드 모드를 사용하면 소규모로 시작하여 초당 수백만 건의 요청까지 자동으로 확장할 수 있습니다.

용량 모드 전환에는 비용이 들지 않으며, 필요에 따라 모드를 변경할 수 있습니다.

DynamoDB 실전 가이드에서 권장하는 것은 초기 개발 단계에서는 온디맨드 모드를 사용하고, 트래픽 패턴이 안정화되면 프로비저닝 모드로 전환하여 비용을 최적화하는 것입니다.

AWS DynamoDB 요금 정보를 참고하면 각 모드의 비용 구조를 상세히 확인할 수 있습니다.

---

Single Table Design 패턴

Single Table Design이란

Single Table Design은 AWS DynamoDB 설계 패턴 중 가장 중요하고 강력한 개념입니다.

AWS는 전체 애플리케이션에 단일 DynamoDB 테이블만 사용할 것을 권장하며, 이는 성능과 비용 효율성을 극대화하는 방법입니다.

전통적인 관계형 데이터베이스에서는 엔티티마다 별도의 테이블을 생성하고 JOIN을 통해 데이터를 조합합니다.

하지만 DynamoDB에서는 JOIN 연산을 지원하지 않기 때문에, 모든 관련 데이터를 하나의 테이블에 저장하고 사전에 조인된 형태로 설계합니다.

Single Table Design의 핵심 원칙은 다음과 같습니다.

액세스 패턴 우선: 데이터 구조가 아닌 애플리케이션의 쿼리 패턴을 기반으로 설계합니다.

비정규화: 관련 데이터를 함께 저장하여 단일 쿼리로 필요한 모든 정보를 조회합니다.

복합 키 활용: 파티션 키와 정렬 키에 접두사를 사용하여 여러 엔티티 타입을 구분합니다.

GSI 활용: 여러 액세스 패턴을 지원하기 위해 Global Secondary Index를 전략적으로 사용합니다.

Single Table Design의 장점

Single Table Design을 사용하면 여러 관련 아이템을 단일 효율적인 요청으로 가져올 수 있어, 애플리케이션과 DynamoDB 간의 I/O 비용을 최소화할 수 있습니다.

멀티 테이블 설계에서는 고객 정보를 조회한 후 관련 주문 정보를 별도로 조회해야 하지만, Single Table Design에서는 한 번의 Query 작업으로 모두 가져올 수 있습니다.

운영 관리 측면에서도 하나의 테이블만 모니터링하고 백업하면 되므로 관리 부담이 크게 줄어듭니다.

비용 측면에서도 요청 횟수가 줄어들어 DynamoDB 비용을 절감할 수 있습니다.

예를 들어, 전자상거래 애플리케이션에서 고객, 주문, 제품 정보를 모두 하나의 테이블에 저장할 수 있습니다.

PK: CUSTOMER#12345    SK: METADATA
PK: CUSTOMER#12345    SK: ORDER#2024-001
PK: CUSTOMER#12345    SK: ORDER#2024-002
PK: PRODUCT#PROD-456  SK: METADATA

이런 구조에서 CUSTOMER#12345로 시작하는 모든 아이템을 조회하면 고객 정보와 해당 고객의 모든 주문을 한 번에 가져올 수 있습니다.

Single Table Design의 단점과 고려사항

Single Table Design의 주요 단점은 새로운 액세스 패턴을 수용하기 어렵다는 것이며, 처음 설계 시 모든 액세스 패턴을 신중하게 고려해야 합니다.

테이블 구조가 복잡해져 새로운 개발자가 이해하기 어려울 수 있습니다.

분석 작업이 복잡해질 수 있으며, ETL 프로세스를 통해 데이터를 별도의 분석 스토어로 이동해야 할 수 있습니다.

Single Table Design이 적합하지 않은 경우도 있습니다.

빠르게 진화하는 신규 애플리케이션에서 개발 민첩성이 성능보다 중요한 경우, 멀티 테이블 설계가 더 나을 수 있습니다.

GraphQL을 사용하는 경우에도 실행 흐름의 특성상 Single Table Design의 이점이 제한적일 수 있습니다.

AWS 공식 DynamoDB Best Practices에서 자세한 가이드라인을 확인할 수 있습니다.

---

DynamoDB 설계 패턴

인접 리스트 패턴

인접 리스트(Adjacency List) 패턴은 일대다 관계를 모델링하는 핵심 DynamoDB 설계 패턴입니다.

인접 리스트 패턴을 사용하면 다양한 SQL 타입의 테이블들을 단일 NoSQL 테이블로 결합할 수 있으며, 특히 다대다 관계 모델링에 유용합니다.

이 패턴에서는 파티션 키에 두 가지 타입의 아이템을 모두 포함시키고, 정렬 키로 구분합니다.

예를 들어, 레이스와 레이서 관계를 모델링할 때

PK: RACE#001      SK: METADATA
PK: RACE#001      SK: RACER#101
PK: RACE#001      SK: RACER#102
PK: RACER#101     SK: METADATA

이런 구조로 RACE#001로 쿼리하면 해당 레이스의 모든 참가자를 한 번에 조회할 수 있습니다.

역방향 GSI 패턴

역방향 GSI(Reverse GSI) 패턴은 다대다 관계에서 양방향 조회를 가능하게 합니다.

기본 테이블의 파티션 키와 정렬 키를 GSI에서는 반대로 구성합니다.

예를 들어, 학생과 강좌의 다대다 관계에서

기본 테이블

PK: STUDENT#001    SK: COURSE#CS101
PK: STUDENT#001    SK: COURSE#CS102

GSI1

GSI1PK: COURSE#CS101    GSI1SK: STUDENT#001
GSI1PK: COURSE#CS102    GSI1SK: STUDENT#001

이렇게 하면 특정 학생이 수강하는 모든 강좌와 특정 강좌를 수강하는 모든 학생을 효율적으로 조회할 수 있습니다.

시계열 데이터 패턴

시계열 데이터는 로깅, 메트릭, IoT 센서 데이터 등에 많이 사용되는 패턴입니다.

파티션 키로 엔티티 ID를 사용하고, 정렬 키로 타임스탬프를 사용하여 시간 기반 쿼리를 최적화합니다.

PK: SENSOR#DEVICE001    SK: 2025-01-15T14:30:00Z
PK: SENSOR#DEVICE001    SK: 2025-01-15T14:31:00Z
PK: SENSOR#DEVICE001    SK: 2025-01-15T14:32:00Z

이 패턴으로 특정 디바이스의 특정 시간 범위 데이터를 효율적으로 조회할 수 있습니다.

정렬 키에서 범위 조건(begins_with, between)을 사용하여 필요한 기간의 데이터만 가져올 수 있습니다.

시계열 데이터가 계속 증가하는 경우, Time-to-Live(TTL)을 설정하여 오래된 데이터를 자동으로 삭제할 수 있습니다.

---

DynamoDB 스트림

DynamoDB Streams란

DynamoDB 스트림(DynamoDB Streams)은 테이블의 아이템 수준 변경 사항을 시간 순서대로 캡처하는 기능입니다.

DynamoDB Stream은 테이블의 변경 로그와 같으며, 아이템이 생성, 업데이트 또는 삭제될 때마다 레코드가 스트림에 기록됩니다.

스트림은 최근 24시간 동안의 변경 사항을 보관하며, 이는 SNS와 같은 일시적인 pub-sub 메커니즘과 달리 지속성을 제공합니다.

스트림의 주요 특징

시간 순서 보장: 변경 사항이 발생한 순서대로 기록됩니다.

거의 실시간: 변경 발생 후 1초 이내에 스트림에서 사용할 수 있습니다.

중복 제거: 각 수정 사항은 스트림에서 정확히 하나의 레코드에 해당합니다.

No-op 무시: 실제로 데이터를 변경하지 않는 작업은 무시됩니다.

스트림 뷰 타입을 선택할 수 있습니다
- KEYS_ONLY: 수정된 아이템의 키만 포함
- NEW_IMAGE: 수정 후 아이템 전체
- OLD_IMAGE: 수정 전 아이템 전체
- NEW_AND_OLD_IMAGES: 수정 전후 아이템 모두

서버리스 애플리케이션과의 통합

DynamoDB Streams는 ElasticSearch 및 Lambda와 같은 다른 AWS 서비스와 결합되어 실시간 응답 및 검색 기능을 제공할 수 있습니다.

DynamoDB 스트림과 AWS Lambda의 조합은 이벤트 주도 아키텍처 구축의 핵심입니다.

서버리스 애플리케이션에서 DynamoDB Streams의 활용 사례:

실시간 데이터 동기화: 테이블 변경 사항을 Elasticsearch나 다른 데이터베이스에 실시간으로 반영합니다.

알림 및 이메일 발송: 새로운 주문이나 사용자 등록 시 자동으로 알림을 전송합니다.

데이터 검증 및 처리: 비즈니스 로직에서 데이터 무결성을 검증하거나 추가 처리를 수행합니다.

감사 로그: 모든 데이터 변경 사항을 별도의 감사 테이블이나 S3에 저장합니다.

캐시 무효화: DynamoDB 데이터가 변경될 때 관련 캐시를 자동으로 갱신합니다.

Lambda 함수를 DynamoDB Stream에 연결하는 방법

functions:
  streamProcessor:
    handler: handler.process
    events:
      - stream:
          type: dynamodb
          arn:
            Fn::GetAtt:
              - MyTable
              - StreamArn
          batchSize: 100
          startingPosition: LATEST

DynamoDB Streams는 AWS Lambda와 특히 잘 작동하는데, 이는 이벤트 주도 특성 덕분이며 스트림을 통해 푸시되는 데이터 양에 따라 자동으로 확장됩니다.

실시간 분석을 위해 DynamoDB Streams를 Amazon Kinesis Data Streams에 연결할 수도 있습니다.

AWS Lambda와 DynamoDB Streams 통합 가이드에서 상세한 설정 방법을 확인할 수 있습니다.

---

DynamoDB 고급 기능

트랜잭션

DynamoDB는 단일 AWS 계정 및 리전 내에서 하나 이상의 테이블에 걸쳐 ACID(원자성, 일관성, 격리성, 내구성) 트랜잭션을 지원합니다.

TransactWriteItems와 TransactGetItems API를 사용하여 여러 아이템을 원자적으로 처리할 수 있습니다.

트랜잭션 제약 사항
- 한 트랜잭션에서 최대 100개의 고유 아이템 처리 가능
- 트랜잭션은 최대 4MB의 데이터를 포함할 수 있음
- 같은 테이블의 동일 아이템에 대해 두 개의 작업을 수행할 수 없음
- 여러 AWS 계정이나 리전에 걸친 작업 불가

트랜잭션은 프로비저닝 용량의 두 배를 소비하므로, 비용과 성능을 고려하여 신중하게 사용해야 합니다.

TTL (Time to Live)

TTL은 만료된 데이터를 자동으로 삭제하는 기능으로, 추가 비용 없이 사용할 수 있습니다.

타임스탬프 속성을 지정하면, 지정된 시간이 지난 후 DynamoDB가 자동으로 아이템을 삭제합니다.

세션 데이터, 임시 데이터, 이벤트 로그 등에 유용하게 사용할 수 있습니다.

TTL 삭제는 백그라운드에서 처리되며 용량 단위를 소비하지 않습니다.

Point-in-Time Recovery

DynamoDB는 이제 사용자 정의 가능한 특정 시점 복구(PITR) 기간을 제공하여, 고객이 복구 기간을 지정할 수 있어 비즈니스 요구사항 및 규제 의무에 맞춰 백업 정책을 조정할 수 있습니다.

PITR을 활성화하면 최근 35일 이내의 어느 시점으로든 테이블을 복원할 수 있습니다.

실수로 데이터를 삭제하거나 손상시킨 경우에도 신속하게 복구할 수 있습니다.

Global Tables

Global Tables는 다중 리전 배포를 위한 완전 관리형 솔루션입니다.

2024년의 주요 발전 중 하나는 다중 리전 강력한 일관성 기능으로, 글로벌 테이블에 대한 최고 수준의 애플리케이션 복원력을 제공합니다.

여러 AWS 리전에 테이블 복제본을 자동으로 복제하고 동기화하여, 전 세계 사용자에게 낮은 지연 시간을 제공합니다.

한 리전에서 발생한 변경 사항은 다른 모든 리전에 자동으로 전파됩니다.

---

DynamoDB 모범 사례

파티션 키 설계

파티션 키 선택은 DynamoDB 성능의 가장 중요한 요소입니다.

고른 분산: 파티션 키는 데이터를 균등하게 분산시켜야 합니다.

핫 파티션(Hot Partition)을 피하기 위해 높은 카디널리티를 가진 속성을 선택하세요.

나쁜 예: status (값이 "active", "inactive" 두 개뿐)
좋은 예: userId (수천~수백만 개의 고유 값)

날짜를 파티션 키로 사용하면 특정 날짜에 트래픽이 집중되어 핫 파티션이 발생할 수 있습니다.

이런 경우 날짜에 해시값을 추가하거나, userId와 날짜를 조합하는 것이 좋습니다.

쿼리 최적화

스캔 작업 최소화: 스캔은 전체 테이블을 읽으므로 비효율적입니다.

가능한 한 쿼리(Query) 작업을 사용하고, 액세스 패턴에 맞는 인덱스를 설계하세요.

프로젝션 표현식 사용: 필요한 속성만 조회하여 네트워크 대역폭과 비용을 절감합니다.

response = table.query(
    KeyConditionExpression=Key('userId').eq('12345'),
    ProjectionExpression='userName,email,createdAt'
)

페이지네이션 구현: 대량의 데이터를 조회할 때는 반드시 페이지네이션을 구현하세요.

DynamoDB 쿼리는 최대 1MB의 결과를 반환할 수 있으며, LastEvaluatedKey 속성을 지정하여 페이지네이션으로 추가 레코드를 검색할 수 있습니다.

비용 최적화

적절한 용량 모드 선택: 트래픽 패턴에 따라 프로비저닝 또는 온디맨드 모드를 선택하세요.

2024년 DynamoDB는 온디맨드 처리량에 대한 요금을 인하하여 고객이 더 비용 효율적이고 복원력 있는 애플리케이션을 구축할 수 있도록 했습니다.

아이템 크기 관리: 큰 속성은 Amazon S3에 저장하고 DynamoDB에는 참조만 저장하세요.

불필요한 인덱스 제거: 사용하지 않는 GSI는 비용을 발생시키므로 정기적으로 검토하세요.

예약 용량 활용: 장기적으로 안정적인 워크로드가 있다면 예약 용량을 구매하여 비용을 절감할 수 있습니다.

---

DynamoDB vs 다른 NoSQL 데이터베이스

MongoDB와 비교

항목	DynamoDB	MongoDB
관리	완전 관리형	자체 호스팅 또는 Atlas(관리형)
확장성	자동, 무제한	수동 샤딩 필요
쿼리 유연성	제한적 (액세스 패턴 필요)	풍부한 쿼리 언어
일관성	최종 일관성 기본	강력한 일관성 기본
비용	사용량 기반	인스턴스 기반

MongoDB는 더 유연한 쿼리를 제공하지만, DynamoDB는 예측 가능한 성능과 완전 자동화된 관리를 제공합니다.

Cassandra와 비교

DynamoDB와 Cassandra는 모두 분산 NoSQL 데이터베이스입니다.

Cassandra는 오픈소스로 더 많은 제어권을 제공하지만, 운영 복잡도가 높습니다.

DynamoDB는 관리 오버헤드가 없고 AWS 생태계와 완벽하게 통합되는 장점이 있습니다.

---

실전 예제: 전자상거래 애플리케이션

요구사항 분석

전자상거래 애플리케이션의 주요 액세스 패턴
1. 사용자 ID로 사용자 정보 조회
2. 사용자 ID로 모든 주문 조회
3. 주문 ID로 주문 상세 조회
4. 제품 ID로 제품 정보 조회
5. 카테고리별 제품 목록 조회
6. 사용자의 장바구니 조회 및 업데이트

테이블 설계

기본 테이블

PK                    SK                    entity_type    attributes...
USER#12345           METADATA              User           name, email...
USER#12345           ORDER#2024-001        Order          total, status...
USER#12345           CART                  Cart           items...
PRODUCT#PROD-001     METADATA              Product        name, price...
ORDER#2024-001       METADATA              Order          userId, date...
ORDER#2024-001       ITEM#PROD-001         OrderItem      quantity, price...

GSI1 (제품 카테고리별 조회)

GSI1PK               GSI1SK
CATEGORY#Electronics PRODUCT#PROD-001
CATEGORY#Books       PRODUCT#PROD-002

GSI2 (주문 상태별 조회)

GSI2PK               GSI2SK
STATUS#Pending       ORDER#2024-001
STATUS#Shipped       ORDER#2024-002

이 설계로 모든 주요 액세스 패턴을 효율적으로 처리할 수 있습니다.

구현 코드 예제

Python boto3를 사용한 쿼리 예제:

import boto3
from boto3.dynamodb.conditions import Key, Attr

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('EcommerceTable')

# 사용자의 모든 주문 조회
response = table.query(
    KeyConditionExpression=Key('PK').eq('USER#12345') &
                          Key('SK').begins_with('ORDER#')
)
orders = response['Items']

# 카테고리별 제품 조회 (GSI1 사용)
response = table.query(
    IndexName='GSI1',
    KeyConditionExpression=Key('GSI1PK').eq('CATEGORY#Electronics')
)
products = response['Items']

# 주문 생성 (트랜잭션 사용)
response = dynamodb.meta.client.transact_write_items(
    TransactItems=[
        {
            'Put': {
                'TableName': 'EcommerceTable',
                'Item': {
                    'PK': 'ORDER#2024-NEW',
                    'SK': 'METADATA',
                    'entity_type': 'Order',
                    'userId': 'USER#12345',
                    'total': 150.00,
                    'status': 'Pending'
                }
            }
        },
        {
            'Update': {
                'TableName': 'EcommerceTable',
                'Key': {
                    'PK': 'USER#12345',
                    'SK': 'CART'
                },
                'UpdateExpression': 'REMOVE items'
            }
        }
    ]
)

AWS SDK for Python (Boto3) 문서에서 더 많은 API 사용법을 확인할 수 있습니다.

---

마이그레이션 전략

RDBMS에서 DynamoDB로 마이그레이션

관계형 데이터베이스에서 DynamoDB로 마이그레이션할 때는 단순 테이블 복사가 아닌 재설계가 필요합니다.

1단계: 액세스 패턴 파악
현재 애플리케이션의 모든 쿼리를 문서화하고 사용 빈도를 분석합니다.

2단계: 데이터 모델 설계
액세스 패턴을 기반으로 DynamoDB 테이블 구조를 설계합니다.

Single Table Design을 적용할지, 여러 테이블로 나눌지 결정합니다.

3단계: 파일럿 테스트
작은 규모로 마이그레이션을 시작하여 성능과 비용을 검증합니다.

4단계: 데이터 마이그레이션
AWS Database Migration Service(DMS)를 사용하거나 커스텀 ETL 파이프라인을 구축합니다.

5단계: 점진적 전환
읽기 트래픽부터 점진적으로 DynamoDB로 전환하고, 모니터링을 강화합니다.

데이터 동기화 전략

마이그레이션 기간 동안 두 데이터베이스를 동기화해야 합니다.

이중 쓰기 패턴: 애플리케이션이 두 데이터베이스에 동시에 쓰기 작업을 수행합니다.

CDC 기반 복제: Change Data Capture를 사용하여 RDBMS의 변경 사항을 DynamoDB로 실시간 복제합니다.

배치 동기화: 정기적으로 델타 데이터를 추출하여 동기화합니다.

AWS Database Migration Service를 활용하면 마이그레이션 프로세스를 크게 간소화할 수 있습니다.

---

모니터링과 운영

CloudWatch 메트릭

DynamoDB는 자동으로 CloudWatch에 다양한 메트릭을 전송합니다.

주요 모니터링 메트릭
- ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits: 실제 사용된 용량
- UserErrors: 400 에러 발생 횟수
- SystemErrors: 500 에러 발생 횟수
- ThrottledRequests: 제한된 요청 수
- SuccessfulRequestLatency: 요청 지연 시간

이러한 메트릭을 기반으로 알람을 설정하여 문제를 조기에 감지할 수 있습니다.

성능 튜닝

핫 파티션 감지: CloudWatch Contributor Insights를 사용하여 자주 액세스되는 파티션 키를 식별합니다.

Adaptive Capacity: DynamoDB는 자동으로 일시적인 핫 파티션을 처리하지만, 지속적인 문제는 설계 변경이 필요합니다.

DAX (DynamoDB Accelerator): 인메모리 캐시를 추가하여 읽기 성능을 마이크로초 단위로 향상시킬 수 있습니다.

2024년 DAX는 스페인 및 스톡홀름 리전을 포함한 추가 AWS 리전에서 사용 가능해졌습니다.

백업 및 재해 복구

온디맨드 백업: 언제든지 수동으로 전체 백업을 생성할 수 있습니다.

Point-in-Time Recovery: 지속적인 백업으로 35일 이내 어느 시점으로든 복구 가능합니다.

글로벌 테이블: 다중 리전 복제로 재해 복구 대비와 낮은 지연 시간을 동시에 달성합니다.

정기적으로 백업 복원 테스트를 수행하여 재해 복구 절차를 검증하는 것이 중요합니다.

---

최신 기능 및 업데이트

2025년 주요 업데이트

2025년 7월, DynamoDB Local의 주요 버전인 3.0.0이 출시되어 AWS SDK for Java 2.x로 마이그레이션했습니다.

이를 통해 로컬 개발 환경에서 최신 보안, 호환성 및 안정성을 유지할 수 있습니다.

2025년 1월, 새로운 아시아 태평양(태국) 리전이 출시되어 동남아시아 고객에게 향상된 서비스를 제공하기 시작했습니다.

2024년의 주요 발전 사항으로는 제로-ETL 통합이 Amazon Redshift 및 SageMaker Lakehouse와 같은 서비스와 이루어져, 더 효율적인 분석 워크플로우가 가능해졌습니다.

Zero-ETL 통합

Zero-ETL 통합은 DynamoDB 데이터를 다른 AWS 분석 서비스로 자동으로 복제합니다.

전통적인 ETL 파이프라인 없이 Amazon Redshift에서 DynamoDB 데이터를 직접 분석할 수 있습니다.

실시간에 가까운 분석이 가능하며, 운영 데이터베이스에 영향을 주지 않습니다.

이를 통해 비즈니스 인텔리전스 및 머신러닝 워크로드를 더 쉽게 구현할 수 있습니다.

---

보안 모범 사례

IAM 권한 관리

최소 권한 원칙을 적용하여 필요한 작업만 허용하는 IAM 정책을 구성합니다.

테이블 수준, 아이템 수준, 속성 수준의 세밀한 액세스 제어가 가능합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:region:account-id:table/MyTable",
      "Condition": {
        "ForAllValues:StringEquals": {
          "dynamodb:LeadingKeys": ["${aws:userid}"]
        }
      }
    }
  ]
}

데이터 암호화

저장 데이터 암호화: 기본적으로 AWS 관리형 키를 사용하여 암호화됩니다.

고객 관리형 KMS 키를 사용하여 더 세밀한 제어가 가능합니다.

전송 중 암호화: 모든 데이터 전송은 TLS를 통해 암호화됩니다.

VPC 엔드포인트

VPC 엔드포인트를 사용하면 인터넷을 거치지 않고 프라이빗하게 DynamoDB에 접근할 수 있습니다.

보안이 강화되고 데이터 전송 비용도 절감됩니다.

---

결론

DynamoDB는 현대적인 서버리스 애플리케이션과 마이크로서비스 아키텍처에 이상적인 NoSQL 데이터베이스입니다.

Single Table Design, 적절한 인덱스 설계, 그리고 DynamoDB 스트림 활용은 DynamoDB를 효과적으로 사용하는 핵심입니다.

프로비저닝 용량과 온디맨드 스케일링 중 워크로드에 맞는 모드를 선택하여 비용을 최적화할 수 있습니다.

액세스 패턴을 먼저 정의하고, 이에 맞춰 파티션 키와 정렬 키를 신중하게 설계하는 것이 성공의 열쇠입니다.

2024년과 2025년의 지속적인 혁신으로 DynamoDB는 보안, 비용 최적화, 통합 기능에서 큰 발전을 이루었으며, 고객들이 더 복원력 있고 비용 효율적인 애플리케이션을 구축할 수 있게 되었습니다.

DynamoDB 실전 가이드를 따라 실습하고, AWS 공식 문서와 커뮤니티 리소스를 활용하면 빠르게 전문성을 쌓을 수 있습니다.

지금 바로 DynamoDB를 시작하여 확장 가능하고 고성능의 애플리케이션을 구축해보세요.

AWS DynamoDB 시작하기에서 무료 티어로 DynamoDB를 체험할 수 있습니다.

---

참고 자료

• AWS DynamoDB 공식 문서
• DynamoDB Best Practices
• AWS re:Invent 2024 DynamoDB Sessions
• Alex DeBrie's DynamoDB Guide
• AWS Database Blog

---

클라우드 배포 생존 가이드 | 12팩터앱 원칙, Heroku 적용 팁

12팩터앱 방법론으로 Heroku 클라우드 배포를 마스터하세요. 단일 코드베이스부터 stateless 프로세스까지 실전 체크리스트와 코드 예제를 제공합니다. 환경 변수 설정, 마이그레이션 자동화 팁 포함

🌐 tech-in-depth-hub.blogspot.com

동기와 비동기 완전 정복 | 블로킹 / 논블로킹 & 언어별 예제 포함

동기 비동기 차이부터 블로킹/논블로킹 개념, async/await 패턴까지 실전 예제와 함께 완벽하게 정리한 프로그래밍 필수 가이드입니다.

🌐 tech-in-depth-hub.blogspot.com

API, 라이브러리, 프레임워크 | 개념부터 예시까지 한눈에 이해하기

API 라이브러리 프레임워크 차이를 명확히 이해하면 개발 효율이 2배 향상됩니다. Inversion of Control 개념부터 Java, Python, JavaScript 실전 예시까지 완벽 가이드

🌐 tech-in-depth-hub.blogspot.com

로드밸런싱 알고리즘 종류, 페일오버, 헬스 체크까지 완전 해설

로드밸런싱 알고리즘 종류부터 헬스 체크, 페일오버 전략까지 웹서버 로드밸런싱 구성의 모든 것을 다룬 완벽 가이드. 실무 예제와 클라우드 비교 포함.

🌐 tech-in-depth-hub.blogspot.com

RAG (Retrieval-Augmented Generation) | AI가 외부 지식을 끌어오는 방법 완전 해설

RAG(Retrieval Augmented Generation)는 LLM이 외부 지식 베이스를 참조하여 더욱 정확하고 최신의 정보를 생성할 수 있도록 하는 AI 기술로, 할루시네이션 감소와 도메인 특화 지식 통합에 효과적입니다.

🌐 tech-in-depth-hub.blogspot.com