DataBase/DynamoDB

☁️ AWS DynamoDB 기본 개념 공부

민돌v 2025. 9. 16. 00:46
AWS DynamoDB 를 처음 접하는 작성자의 공부용 기록 페이지입니다.

아마도 연초에?  감사하게도 회사에서 AWS DynamoDB 교육을 지원해주었습니다.

해당 교육을 들었을 때는, NoSQL 도 익숙하지 않은 상황이었고 DDB가 가지는 특징들 또한 이해가 잘 가지않아 제대로 소화하지 못하고있었는데, 사내에서 DDB 를 주력 테이블로 하는 작은 서비스의 테이블 설계를 맡게 되어 AWS 공식문서 내용과 제 생각을 글로 정리해 보았습니다.
 
[목차]

  1. AWS DynamoDB 란
  2. DynamoDB 스키마 구조
  3. DynamoDB 테이블 디자인 시 주의해야할 점
    1. RDMBS 와의 차이점
    2. DynamoDB Access Pattern
    3. DynamoDB 성능을 제어하는 일반 원칙
  4. DynamoDB 파티션 키 설계 (DynamoDB PK, SK Design)
  5. 개인적인 생각

 

✔️  AWS DynamoDB 란

DynamoDB는 AWS에서 제공하는 서버리스 기반 Key-Value 형식의 NoSQL 데이터베이스입니다.
AWS 에서 2004년 아마존 닷컴의 대용량 트랙픽으로 인한 전체 서버다운 문제를 개선하기 위해 만들어진 DB 입니다.
  • AWS 에서 관리하는 Serverless DataBase
  • Key - Value 형식으로 이루어진 비정형 NoSQL
    • Key-Value DataBase 특장점 (링크 - AWS)
      1. 테이블 조인 불필요
        • 키-값 데이터베이스는 리소스를 많이 사용하는 테이블 조인을 수행할 필요가 없습니다. 유연성이 뛰어나기 때문에 필요한 모든 정보를 단일 테이블에 저장할 수 있습니다. 이것이 키-값 스토어가 성능이 높은 이유 중 하나입니다.
      2. ACID 트랜잭션 지원

 

📃 DynamoDB History 의 목적 (생성 원인)

NoSQL journey

  • 2004 : 아마존 닷컴의 전체 서버가 다운 됨 (DB 트래픽 급증)
    • 전체 쿼리의 70% 가 단일 테이블에서 단일 쿼리를 조회하고 있음 → 70% 데이터는 RDBMS 가 아니어도 되겠네? 에서 다이나모디비의 시작점
  • 2007 : DynamoDB 논문이 나왔지만, 현재 다이나모 디비와는 매우 상이함
  • 2012.1 : AWS 서비스 사용화
  • Today : Tier 0 service (AWS 의 사용 서비스 중 근간이 되는 서비스 중 하나가 되었다)
    • Tier 0 Service 대부분 버전이 없다. (근간이 되는 서비스가 버전 up 되면 전체가 업데이트 되어야하기 때문에, 정책으로 가져가고 있다고 합니다.)

 

✔️ DynamDB 의 스키마 구조

필수 요소

  • 테이블 이름 (table name)
  • 파티션 키 (PK, Primary Key) → Hash
  • 정렬 키 (SK, Primary Key) → Range

선택 요소

  1. Data-Item Attributes
    • key-value 형태의 데이터 필드
  2. Secondary Indexes
    • GSI (Global Secondary Index): 별도의 Partition Key / Sort Key 구조 정의 가능
    • LSI (Local Secondary Index): 테이블의 PK는 공유, Sort Key만 다른 구조 사용
  3. Provisioned / On-Demand Capacity
    • 읽기/쓰기 성능 모델 선택
  4. TTL (Time To Live)
    • 특정 속성을 만료 시각으로 지정해 자동 삭제 가능
  5. Streams
    • 변경 이벤트 캡처 → Lambda, Kinesis 등과 연동

스키마 예시 - 출처: https://www.alexdebrie.com/posts/dynamodb-single-table/

 

✔️  NoSQL DynomoDB 테이블 디자인 시 유의 사항

1. RDMBS 와는 다른 관점이 필요

  • RDBMS
    • NoSQL 설계는 RDBMS 설계와는 다른 사고방식을 요구합니다.
    • RDBMS의 경우, 접근 패턴을 고려하지 않고도 정규화된 데이터 모델을 생성할 수 있습니다.
    • 이후 새로운 질문이나 쿼리 요구 사항이 발생할 때 이를 확장할 수 있습니다.
    • 각 데이터 유형을 별도의 테이블에 정리할 수 있습니다.
  • NoSQL (DynomoDB Schema)
    • DynamoDB 애플리케이션에서는 가능한 한 적은 수의 테이블을 유지해야 한다고 합니다.
      • 테이블 수가 적을 수록 확장성이 높아지고
      • 권한 관리의 필요성 낮아지고 (AWS Serverless이기 때문에 명시된 문장 같음)
      • 오버헤드가 줄어든다.
      • 백업 비용도 절감
    • DynomoDB 가 해결해야 할 질문을 파악하기 전까지는 시작해서는 안된다.. !(공식문서 명시)
      • 비즈니스 문제
      • 애플리케이션 사용 사례

2. DynamoDB Access Pattern

다이나모 디비는, AWS 서버를 통해 조회해야하기 때문에 관리하는 Access Pattern 이 존재하고 권장하는 걸로 보임
  1. 데이터 크기
    • 저장 및 조회 (Write & Read) 가 얼마나 많은 데이터로 한번에 요청되는지 먼저 파악하는게 스키마를 분할하는데 도움이 된다.
  2. 데이터 형태
    • RDBMS는 조회할 때 조인하고 선택하여, 조회할 데이터 포맷을 구성한다.
    • NoSQL은 저장할 때 조회 포맷을 염두에 두고 저장해야한다. (그대로 조회 - 데이터 포맷을 정형화하지 않는 이유)
    • ❗️NoSQL의 속도와 확장성을 높이는 핵심 요소..!!
  3. 데이터 속도
    1. 논리적 파티션(PK)을 통해 어떻게 I/O 요청을 분산할지에 대한 고민이 필요.
    2. DynamoDB는 쿼리 처리에 사용 가능한 물리적 파티션 수를 늘리고 이러한 파티션에 데이터를 효율적으로 분산함으로써 확장합니다.
    3. 최대 쿼리 부하가 어느 정도일지 미리 파악하면 I/O 용량을 최대한 활용하기 위한 데이터 분할 방법을 결정하는 데 도움될 수 있습니다.
📌 3. 데이터 속도에 대하여
분할 파티션을 위한 설명인데, 물리적인 분할 (샤딩)은 한번 진행하면 되돌릴 수 없으므로 가능한 하지 않는게 좋다는 내부 직원의 설명을 들은 적이 있습니다.
물리적인 분할 (샤딩)은 데이터가 분할되어 저장되기 시작하면, 특정 샤딩 키(?) 지점에 데이터가 몰리거나 트래픽이 몰리지 않도록 샤딩 키를 설계하는 부분부터, 설계 복잡도 및 관리의 복잡도가 급격하게 늘어나기 때문에 되도록이면 샤딩을 하지 않는 방향으로 설계하는게 좋다고 합니다.

3. DynamoDB 성능을 제어하는 일반 원칙

  1. 관련 데이터를 함께 보관해라 (참조 지역성)
    • 일반적으로 DynamoDB 애플리케이션에서는 가능한 한 적은 수의 테이블을 유지
      • 대용량 시계열 데이터나 액세스 패턴이 매우 다른 데이터세트가 있는 경우는 예외
    • 역인덱스가 있는 단일 테이블은 일반적으로 간단한 쿼리를 통해 애플리케이션에 필요한 복잡한 계층적 데이터 구조를 생성하고 검색할 수 있도록 지원
  2. 정렬 순서를 사용해라 (SK 를 의미 ?)
    • 정렬이 가능하다면 관련 항목을 그룹화(파티션) 하여 효율적으로 쿼리할 수 있다.
  3. 쿼리를 분산해라
    • 트래픽이 파티션에 잘 분산되도록 데이터 키를 설계하고, 핫 스팟을 피해라
    • (생각) 참조 지역성에 있는 데이터만 같은 파티션 키를 사용하도록 하라는 말로 해석됩니다.
  4. 글로벌 보조 인덱스를 사용해라
    • 글로벌 보조 인덱스를 생성하면, 기본 테이블 조회 쿼리보다 다양하게 쓸 수 있다고 합니다.
    • 테이블 스키마의 속성(attribute) 로 조회 필터링을 걸기 위해서는 GSI 설정이 필요합니다.
📌 글로벌 보조 인덱스 (GSI)
공식 문서에서는 GSI 를 권장하는 것 처럼 나와있는데, AWS 에 제시되어있는 GSI 의 가격을 보면 1개의 Item attribute(이하 필드) 에 GSI 를 설정할 때 마다 테이블 1개를 더 사용하는 것과 같다고 나와있습니다.
즉, GSI 는 PK(hash) 와 SK(range) 로 설정하지 않은 값에 대해서는 조회 쿼리의 조건으로 사용될 수 없는 특징으로 인해 어쩔수 없이 추가 조회 필터가 필요할 때만 사용하는게 맞다고 생각합니다.

이러한 부분때문에 처음 스키마 설계 시 실제 조회할 쿼리를 먼저 생각하고 스키마를 설계해야하는 부분이 다른 DB와의 매우 큰 차이점으로 느켜졌습니다.. (매우 어려움,,)

 

✔️ DynomoDB 파티션 키 설계 (DynomoDB PK, SK Design)

Amazon DynamoDB 테이블의 각 항목을 고유하게 식별하는 기본 키는 단순 키(파티션 키만)이거나 복합 키(파티션 키와 정렬 키 결합)일 수 있습니다.

테이블과 보조 인덱스의 모든 파티션 키에서 동일한 활동이 수행되도록 애플리케이션을 설계해야 합니다.

  • DynamoDB 테이블의 모든 파티션은 초당 최대 3,000개의 읽기 단위와 1,000개의 쓰기 단위를 제공하도록 설계되었습니다.
  • 최대 4KB 크기 초당 1개의 최종 일관성 (ACID 트랜잭션) 읽기 보장 (Write 는 1KB)

 

📌 파티션 키 (PK)

  • DynamoDB에서 작업 부하를 분산하기위한 파티션 키
  • 테이블 기본키의 파티션 키는, 데이터가 저장되는 논리적 파티션을 결정합니다.
    • 테이블의 싱글 테이블로 사용하더라도, 파티션 키를 이용하면 물리적 I/O는 분리되어 있지는 않지만 - I/O 요청 자체를 분산하여 요청할 수 있도록 하기 때문이라고 생각되어집니다.
    • 참고 - AWS Docs

📌 정렬 키 (SK)

  • DynamoDB에서 데이터를 구성하기 위한 정렬 키
  • 정렬 키를 신중하게 설계하면 begins_with, between, >, <등의 연산자를 사용한 범위 쿼리를 통해 자주 필요한 관련 항목 그룹을 검색할 수 있습니다.
  • 복합 정렬 키를 사용하면 계층 구조의 모든 수준에서 쿼리할 수 있는 데이터의 계층적(일대다) 관계를 정의할 수 있습니다.
    • ex ) [country]#[region]#[state]#[county]#[city]#[neighborhood]

 

✔️ DynomoDB 에 대한 생각 정리

AWS 다이나모 디비는 Serverless 시스템으로 굉장히 강력한 확장성과 편리성을 제공하지만, 그만큼 무척 비싸고 까다롭습니다.

AWS 자체에서 DDB를 싱글 테이블로 구성하는걸 권장하는 만큼 설계를 굉장히 조심스럽게 해야하며, 특히 PK 와 SK를 꼼꼼하게 설정하여야만 NoSQL로써 DDB의 장점을 살릴 수 있다는 생각이 들었습니다.

💡즉 DDB 의 스키마는 RDBMS 처럼 데이터의 정합성을 논리적으로 설계하는게 아닌,
실제 데이터가 어떻게 조회될 지, 실제 사용 시나리오와 필요한 데이터를 추출할 수 있는 쿼리를 먼저 고민해보아야 후회없는 테이블 스키마 설계가 가능할 것 같습니다.

 

끝!

 

 

☁️ AWS DynomoDB
기본 개념 공식문서로 톺아보기

 

 

 
참고