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
- 파티션 키를 무작위 값 또는 시간/랜덤 접두사로 샤딩하면 Hot partition을 방지할 수 있음
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 발생