DynamoDB 테이블 사용 패턴 평가

이 섹션에서는 DynamoDB 테이블을 효율적으로 사용하고 있는지 평가하는 방법을 간략히 살펴봅니다. DynamoDB에 최적화되지 않은 특정 사용 패턴이 있으며, 이러한 패턴은 성능 및 비용 측면에서 모두 최적화될 수 있는 여지가 있습니다.

강력히 일관된 읽기 작업 줄이기

DynamoDB를 사용하면 요청별로 읽기 일관성을 구성할 수 있습니다. 기본적으로 읽기 요청은 최종적으로 일관됩니다. 최종 읽기 일관성은 최대 4KB의 데이터에 대해 0.5RCU의 요금이 부과됩니다.

분산 워크로드의 대부분은 유연하며 최종 일관성을 허용합니다. 하지만 강력히 일관된 읽기가 필요한 액세스 패턴이 있을 수 있습니다. 강력히 일관된 읽기는 최대 4KB의 데이터에 대해 1RCU의 요금이 부과되므로 읽기 비용이 두 배로 늘어납니다. DynamoDB는 동일한 테이블에서 두 일관성 모델을 모두 사용할 수 있는 유연성을 제공합니다.

워크로드와 애플리케이션 코드를 평가하여 강력히 일관된 읽기가 필요한 경우에만 사용되는지 확인할 수 있습니다.

읽기 작업을 위한 트랜잭션 횟수 줄이기

DynamoDB를 사용하면 특정 작업을 전부 또는 전무 방식으로 그룹화할 수 있습니다. 즉, DynamoDB를 사용하여 ACID 트랜잭션을 실행할 수 있습니다. 그러나 관계형 데이터베이스의 경우처럼 모든 작업에 대해 이 접근 방식을 따를 필요는 없습니다.

최대 4KB의 트랜잭션 읽기 작업은 동일한 양의 데이터를 최종 일관성 방식으로 읽는 데 소비되는 기본 0.5RCU와 달리 2RCU를 소비합니다. 쓰기 작업의 경우 비용이 두 배로 늘어납니다. 즉, 최대 1KB의 트랜잭션 쓰기에 2WCU가 소비됩니다.

테이블의 모든 작업이 트랜잭션인지 확인하려면 테이블의 CloudWatch 지표를 트랜잭션 API로 필터링할 수 있습니다. 트랜잭션 API가 테이블의 SuccessfulRequestLatency 지표에서 사용할 수 있는 유일한 그래프인 경우 모든 작업이 이 테이블의 트랜잭션임을 확인할 수 있습니다. 또는 전체 용량 사용률 추세가 트랜잭션 API 추세와 일치한다면 트랜잭션 API가 주를 이루는 것처럼 보이는 애플리케이션 설계를 다시 살펴보는 것도 좋습니다.

스캔 줄이기

Scan 작업이 광범위하게 사용되는 이유는 일반적으로 DynamoDB 데이터에 대한 분석 쿼리를 실행해야 하기 때문입니다. 대형 테이블에서 Scan 작업을 자주 실행하면 비효율적이고 비용이 많이 들 수 있습니다.

더 나은 대안은 S3로 내보내기 기능을 사용하고 특정 시점을 선택하여 테이블 상태를 S3로 내보내는 것입니다. AWS가 제공하는 Athena와 같은 서비스를 통해 테이블의 용량을 전혀 소비하지 않고도 데이터에 대한 분석 쿼리를 실행할 수 있습니다.

Scan 작업 빈도는 Scan에 대한 SuccessfulRequestLatency 지표 아래의 SampleCount 통계를 사용하여 확인할 수 있습니다. Scan 작업이 실제로 매우 빈번하다면 액세스 패턴과 데이터 모델을 재평가해야 합니다.

속성 이름 줄이기

DynamoDB에 있는 항목의 총 크기는 속성 이름 길이와 값을 더하여 결정됩니다. 속성 이름이 길면 스토리지 비용이 증가할 뿐만 아니라 RCU/WCU 소비량도 증가할 수 있습니다. 속성 이름은 긴 것보다 짧은 것이 좋습니다. 속성 이름을 짧게 지정하면 다음 4KB/1KB 경계 내에서 항목 크기를 제한하는 데 도움이 될 수 있으며, 이후에는 데이터에 액세스하기 위해 추가 RCU/WCU를 소비하게 됩니다.

유지 시간(TTL) 활성화

유지 시간(TTL)은 사용자가 항목에 설정한 만료 시간보다 오래된 항목을 식별하여 테이블에서 제거합니다. 시간이 지남에 따라 데이터가 늘어나고 오래된 데이터는 무용지물이 되는 경우 테이블에서 TTL을 활성화하면 데이터를 줄이고 스토리지 비용을 절감하는 데 도움이 될 수 있습니다.

TTL의 또 다른 유용한 측면은 만료된 항목이 DynamoDB 스트림에서 발생한다는 점입니다. 따라서 데이터에서 데이터를 제거하는 대신 스트림에서 해당 항목을 소비하여 더 저렴한 스토리지 계층에 보관할 수 있습니다. 또한 TTL을 통해 항목을 삭제하면 추가 비용이 들지 않으므로 용량을 소비하지 않으며 정리 애플리케이션을 설계하는 데 드는 오버헤드도 없습니다.

글로벌 테이블을 리전 간 백업으로 대체

글로벌 테이블을 사용하면 서로 다른 리전에서 여러 개의 활성 복제본 테이블을 유지 관리할 수 있습니다. 이러한 테이블은 모두 쓰기 작업을 허용하고 서로 간에 데이터를 복제할 수 있습니다. 복제본을 쉽게 설정할 수 있으며 동기화가 자동으로 관리됩니다. 복제본은 최종 쓰기 우선 전략을 사용하여 일관된 상태로 수렴합니다.

글로벌 테이블을 순전히 장애 조치 또는 재해 복구(DR) 전략의 일부로만 사용하는 경우 복구 시점 목표와 복구 시간 목표 요구 사항이 상대적으로 관대한 리전 간 백업 복사본으로 대체할 수 있습니다. 빠른 로컬 액세스와 99.999%의 고가용성이 필요하지 않은 경우 글로벌 테이블 복제본을 유지 관리하는 것이 장애 조치를 위한 최선의 방법이 아닐 수 있습니다.

대안으로 AWS Backup을 사용하여 DynamoDB 백업을 관리하는 것을 고려해 보세요. 정기적인 백업을 예약하고 리전 간에 복사하여 글로벌 테이블을 사용하는 것보다 더 비용 효과적인 접근 방식으로 DR 요구 사항을 충족할 수 있습니다.