AWS

DynamoDB 키 설계 개념 정리 및 성능 최적화 전략

heesoohi 2025. 6. 9. 01:11

DynamoDB 성능은 키 설계에 의해 좌우될 수 있다. 파티션 키는 높은 카디널리티, 정렬키는 조회 패턴에 맞춤 설계해야 Hot partition을 방지하고 액세스 패턴 기반 설계로 처리량을 고르게 유지하고 성능을 극대화할 수 있다. 해당 내용들을 정리해보겠다. 

 

1. 기본 개념 정리

1.1 파티션 키 (Partition Key)

  • DynamoDB에서 데이터를 물리적으로 분산 저장하기 위한 기준
  • 동일한 파티션 키 값을 가진 항목은 같은 파티션에 저장됨
  • 파티션 키는 고유하고, 다양한 값(높은 카디널리티) 을 갖는 것이 이상적임

1.2 정렬 키 (Sort Key)

  • 파티션 키와 함께 사용되는 두 번째 키
  • 같은 파티션 키를 가진 항목들을 정렬된 순서로 저장함
  • 쿼리 시 정렬 키를 통해 범위 조회(range query)도 가능하다

1.3 복합 기본 키 (Composite Primary Key)

  • 파티션 키 + 정렬 키로 구성된 기본 키
  • 하나의 파티션 키에 여러 항목을 넣고, 정렬 키로 구분할 수 있음

1.4 카디널리티 (Cardinality)

  • 속성 값이 가지는 고유한 값의 수를 의미한다. 예시는 아래와 같음
    • 높은 카디널리티: 사용자 ID (매 요청마다 다른 값)
    • 낮은 카디널리티: 성별 (남, 여)

2. 처리량 효율화 및 성능 개선 전략

2.1 파티션 키는 높은 카디널리티를 가지도록 설계

  • 이유: 다양한 파티션 키 값은 워크로드를 여러 파티션에 분산시켜 처리량 병목을 방지함.
  • 예를 들어 userId, orderId, deviceId 등 고유 식별자 사용하면 카디널리티를 높일 수 있다

2.2 Hot Partition 방지

  • 동일한 파티션 키에 트래픽이 집중되면 해당 파티션이 병목이 생길 수 있어 아래와 같은 전략을 취할 수 있다. 
    • 파티션 키를 무작위 값 또는 시간/랜덤 접두사로 샤딩하면 Hot partition을 방지할 수 있음
      예) user_1, user_2, ..., user_n

2.3 정렬 키를 활용한 범위 쿼리

  • 같은 파티션 내에서 시간순, 순서순으로 정렬된 데이터 조회 가능
  • 예) userId + timestamp 형태의 복합 키로 최근 활동 조회

2.4 액세스 패턴 기반 설계

  • DynamoDB는 스키마리스지만, 실제 액세스 패턴을 기준으로 키를 설계해야 성능 최적화 가능
  • 읽기/쓰기 쿼리 패턴이 명확하면, 파티션 키/정렬 키 조합을 최적화할 수 있음

 

3. 예시 설계

✅ 좋은 예시

  • 파티션 키: userId (수백만 개의 사용자 ID → 높은 카디널리티)
  • 정렬 키: createdAt (사용자별 활동 시간순 기록)
  • 장점:
    • 분산 저장 → 처리량 병목 방지
    • 시간 기준 쿼리 가능 (예: 최근 1주일 활동 조회)
{
  "userId": "user-123",
  "createdAt": "2025-06-04T14:00:00Z",
  "activity": "Login"
}

❌ 나쁜 예시

  • 파티션 키: status (예: "active", "inactive" → 낮은 카디널리티)
  • 문제점:
    • 모든 항목이 몇 개 안 되는 파티션에 몰림 → hot partition 발생