[DynamoDB] DynamoDB를 사용할 때 알아둬야 할 제한사항과 그 철학

목차

• DynamoDB와 같은 Wide Columns DB는 RDB에 비해서 더 확장성(scalability)을 가지는가 ?
• 그거 알아요 ? DynamoDB는 HTTP로 통신한다는거 (RDB 운영 이슈, Transaction, Conflict)
• DynamoDB에서 사용하는 용어 정리
• DynamoDB는 사용한 만큼 비용을 냅니다
• http API 실습히가 - Write 편
• http API 실습히가 - Read 편
• 제약사항과 그 철학
• 아키텍처 구조 이해하기
• Schema Modeling 하는 과정

개요

안녕하세요. 시스템을 사용할 때 그 시스템의 제한 사항을 이해하는 것은 중요합니다. 제한 사항을 알아두어야 시스템을 사용해서 원하는 목표를 원활하게 달성할 수 있기 때문입니다. 가령 예를 들어 dynamoDB의 item의 최대 사이즈는 400KB 입니다. 이러한 제한 사항을 알아야 DynamoDB를 사용하여 올바른 설계를 할 수 있습니다.

오늘은 DynamoDB를 사용하면서 알아야할 제한사항을 알아보도록 하겠습니다.

Item Size 제한 사항

Item은 DynamoDB에서 하나의 row를 가리키는 용어입니다. DyamoDB에서 하나의 Item은 400KB를 넘을 수 없습니다. 넘게 되면 데이터가 저장되지 않고 Exception을 뱉게 됩니다.

이러한 Item Size의 제한은 타 database에 비해서 많이 낮은 수치임은 틀림 없습니다.

• MongoDB 16MB
• Cassandra의 blobs 2GB
• Postgres 1 컬럼당 1 1GB

Query와 Scan Operation의 제한 사항

DynamoDB에서 사용하는 용어 정리에서 우리 Query와 Scan에 대해서 배웠습니다. 다시 이야기해보면 Query는 Partition Key를 기반으로 조회하고 Scan은 Table Full Search를 기반으로 합니다.

두 오퍼레이션 모두 각 요청에 1MB의 사이즈 제한이 걸려있습니다. 만약 1MB 보다 더많은 데이터가 있다면 DynamoDB는 1MB 이하의 데이터를 반환하면서 LastEvaluatedKey property를 함께 반환합니다.

예제

{
  "Items": [
    {
      "UserId": {"S": "user1"},
      "OrderId": {"N": "1001"},
      "OrderDate": {"S": "2024-11-15"}
    },
    {
      "UserId": {"S": "user2"},
      "OrderId": {"N": "1002"},
      "OrderDate": {"S": "2024-11-16"}
    }
    // ... (총 데이터 크기가 1MB에 근접한 수준까지만 반환)
  ],
  "Count": 25,
  "ScannedCount": 25,
  "LastEvaluatedKey": {
    "UserId": {"S": "user25"},
    "OrderId": {"N": "1025"}
  }
}

그리고 다음 요청에는 아래와 같이 보내면 됩니다.

{
  "TableName": "Orders",
  "ExclusiveStartKey": {
    "UserId": {"S": "user25"},
    "OrderId": {"N": "1025"}
  }
}

Partition Limit

DynamoDB 에서 데이터는 Partition Key를 기반으로하여 여러 Partition에 나눠서 저장됩니다. 하나의 Partition은 최대 10GB 까지의 데이터를 수용하며 그 이상은 저장되지 않습니다.

또한 Partition을 기준으로 최대 3000RCU, 1000WCU의 Throughput을 지원합니다. API에 따라 다를 수 있지만 이것은 Eventually Consistency 기준으로 최대 Partition 당 초당 24MB 읽기, 1MB의 쓰기를 지원한다는 말입니다.

Partition Limit를 넘는 비지니스라면 ?

이러한 제약 사항이 넘는 경우를 분산 DB에서는 Hot Partition의 경우라고 합니다. 초기에 설계할 때 하며 이를 넘지 않게 하기 위해서 설계가 필요합니다. 서비스를 운영하다 보면 피치 못하게 이러한 제한 사항을 넘을 수 있습니다. 이 경우 우리는 2가지 방향으로 이를 개선할 수 있습니다.

첫 번째, 만약 Read가 너무 많이 발생하는 케이스라 특정 RCU가 오버하고 있다면 앞단에 캐시를 장착해서 이를 완화할 수 있습니다. AWS에서는 DAX라고 DynamoDB에 연결하는 SaaS 차원의 서비스도 있기 때문에 고려해봄직 합니다.

두 번째, Write가 너무 많이 발생하는 케이스라고 한다면 Partition Key의 분할을 고려해볼만합니다. 일반적으로 Partition Key를 분할하는 방법은 아래와 같습니다. 장단을 잘 따져서 비지니스에 맞게 설계해야합니다.

• Write Sharding
  • Partition Key에 shard suffix를 붙여 파티션 분산.
    • 장점: Hot partition 완화, 병렬 확장 가능
    • 단점: 읽기 로직이 다소 복잡 (shard 전부 조회 후 병합 필요)
• Time-Based Partitioning
  • • 시간 단위로 파티션을 나누면, 트래픽이 자연스럽게 분산됨
      • 장점: 정렬, 필터링에 유리
      • 단점: 시간 단위 선택을 잘 해야 함 (하루 단위? 시간 단위?)

사실 Partition Limit의 경우 타 분산 DB 에서도 성능 이슈로 직결되는 문제로 인지되고 있고 가이드를 하고 있습니다. 추가로 찾아보았으나 Hot Partition을 판단하여 이를 다시 쪼개는 DB는 아직 제한적인것으로 보았습니다. 이에대해서 좀 더 궁금하신 분들은 TiDB, Google Bigtable, CockroachDB를 찾아보시면 좋을것 같습니다.

기타 알아두면 좋을 Limit

기타 추가로 알아두면 좋을 제한 사항은 아래와 같습니다.

종류	제한
Table 별 Throughput Limit	40,000 RCU, 40,000 WCU
Account 별 Throughput Limit	80,000 RCU, 80,000 WCU
Partition key length	2048 bytes.
Sort key length	1024 bytes.

이러한 제한 사항으로 DynamoDB에서 달성하고자 하는 바

DynamoDB는 타 DB 보다 제한이 더 빡빡하게 잡혀있습니다. 이러한 제한 조건을 통해서 DynamoDB는 OLTP database에 맞는 적절한 모델링을 사용자에게 강제하는 것입니다. OLTP 시스템은 적은 로드의 많은 요청이 데이터베이스로 들어오게 됩니다.

DynamoDB는 강력한 제약 조건을 통해서 아래의 경우를 원천적으로 차단해버립니다.

이미지 파일, 사용자가 제출한 산문 또는 JSON의 거대한 덩어리와 같이 레코드와 관련된 큰 데이터가 있는 경우 데이터베이스에 직접 저장하는 것이 좋지 않을 수 있습니다. 해당 data를 읽고 쓸 때 RAM이 막히고 디스크 I/O가 발생합니다. 이는 퍼포먼스 이슈로 발전될 수 있습니다.

Query와 Scan Operation의 1MB 제약사항도 이와 맥을 함께합니다. 이러한 제약 사항은 다건을 조회할 때 Cursoring을 통한 Pagenation을 강제합니다. 이러한 강제로 DB 퍼포먼스의 저하를 막는것입니다.

The DynamoDB philosophy of limits​

아래는 DynamoDB의 limits가 가지는 철학이라는 부분을 그대로 가져와서 번역한 부분입니다. 해당 철학에 대한 이야기를 이해한다면 왜 DynamoDB가 이렇게 제한 사항이 큰지 이해하는데 도움이 될 것 같습니다.

아래가 전문 번역 글입니다.

전통적인 databae 들을 사용하면 성능이 다양한 변수에 의해서 바뀝니다. 같은 Query라고해도 이에 대한 응답시간은 dataset의 크기, 하드웨어의 성능 (CPU, RAM, disk, network bandwidth) 등의 변수에 의존하게 됩니다.

이러한 가변성으로 인해 어플리케이션이 확장될 때 어떤 성능을 보일지 계획하기가 매우 어렵습니다. Load Test를 하더라도 실제 트래픽이 들어올 때의 하드웨어 상태를 맞춰놓아야하는 등의 제대로된 테스트를 하기가 어려울 수 있습니다.

DynamoDB의 성능은 광범위한 변수에 의해서 좌지우지되지 않습니다. 정확한 limits가 정해져있고 이를 기반으로 작성해야하기 때문에 hot key에 대해서도 어느정도 예상가능한 성능을 보여줄 수 있는것입니다.

당연히 item 당 400KB 사이즈를 오버하면 안된다는 제약 사양 등을 포함해서 이것이 dynamoDB의 물리적인 제약사항은 아닙니다. 우리는 훨씬 더 많이 처리할 수 있습니다. DynamoDB는 파티션 당 3000RCU, 1000WCU의 제약사항을 넘게 처리할 수 있다고 확신합니다.

하지만 DynamoDB가 중요하게 생각한것은 어떠한 경우라도 동일한 퍼포먼스를 유지하는 것입니다.

데이터베이스에는 물리적 limit가 있습니다. limit가 무엇인지 모른다면 위험에 처해질 수 있습니다.

DynamoDB는 한계를 명확하게 명시하고 제한함으로써 언제나 동일한 성능을 낼 수 있는 DB 인것입니다.

마무리

오늘은 DynamoDB의 사용에 있어서 제한 사항과 이러한 제한 사항으로 DynamoDB 에서 달성할 수 있는것에 대해서 알아보는 시간을 가져보았습니다.

개인적으로 DynamoDB의 철학이 마음에 들었고 타 DB에도 적용할 수 있다고 생각했습니다. 감사합니다.

참조

[1] https://www.alexdebrie.com/posts/dynamodb-limits/

[2] https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ServiceQuotas.html

[3] https://www.youtube.com/watch?v=OhKVFQBYnYY&t=48s

[4] https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Constraints.html

[5] https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/LSI.html

[6] https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html

[7] https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ServiceQuotas.html#default-limits-throughput