사용 사례에 대한 DAX의 적합성 평가 - Amazon DynamoDB
DAX를 선택해야 하는 시기와 이유DAX를 사용하지 말아야 할 경우

사용 사례에 대한 DAX의 적합성 평가

이 섹션에서는 DAX를 사용해야 하는 시기와 이유를 설명합니다. 이 지침을 바탕으로 DAX를 DynamoDB와 통합하는 것이 애플리케이션의 워크로드 패턴, 성능 요건, 데이터 일관성 요구 사항에 유리한지 판단할 수 있습니다. 나아가 쓰기 작업이 많은 워크로드, 자주 액세스하지 않는 데이터 등 DAX가 적합하지 않을 수 있는 시나리오도 다룹니다.

DAX를 선택해야 하는 시기와 이유

여러 시나리오에서 애플리케이션 스택에 DAX를 추가하는 것을 고려해 볼 수 있습니다. 예를 들어, DAX를 사용하여 DynamoDB에 대한 읽기 요청의 전체 지연 시간을 줄이거나 테이블에서 동일한 데이터를 반복적으로 읽는 상황을 최소화할 수 있습니다. 다음 목록은 DAX와 DynamoDB의 통합을 활용할 수 있는 시나리오의 예를 보여줍니다.

  • 고성능 요구 사항

    • 지연 시간이 짧은 읽기 - 애플리케이션에서 최종적으로 일관된 읽기를 보장하는 데 마이크로초 단위의 응답 시간이 필요한 경우 DAX 사용을 고려해야 합니다. 또한, DAX는 자주 읽는 데이터에 액세스하는 데 필요한 응답 시간을 크게 단축할 수 있습니다.

  • 읽기 집약적인 워크로드

    • 읽기 중심의 애플리케이션 - 예를 들어, 읽기-쓰기 비율이 10:1 이상과 같이 높은 애플리케이션의 경우 DAX를 사용하면 캐시 적중률이 증가하고 오래된 데이터가 줄어듭니다. 이렇게 하면 테이블에 대한 읽기 횟수가 줄어듭니다. 애플리케이션에 쓰기 작업량이 많은 경우 캐시에서 오래된 데이터를 읽지 않으려면 캐시의 DynamoDB에서 TTL(Time To Live) 사용을 더 낮게 설정해야 합니다.

    • 일반 쿼리 캐싱 - 애플리케이션이 동일한 데이터(예: 전자 상거래 플랫폼의 인기 제품)를 자주 읽는 경우 DAX는 캐시에서 직접 이러한 요청을 처리할 수 있습니다.

  • 급증하는 트래픽 패턴

    • 원활한 테이블 규모 조정 - DAX를 사용하면 갑작스러운 트래픽 급증으로 인한 영향을 완화할 수 있습니다. DAX는 DynamoDB 테이블 용량을 단계적으로 스케일 업할 수 있는 버퍼를 제공하므로, 읽기 제한의 위험이 줄어듭니다.

    • 각 항목에 대한 더 높은 읽기 처리량 - DynamoDB는 각 항목에 개별 파티션을 할당합니다. 하지만 파티션은 항목 수가 3,000RCU(읽기 용량 단위)에 도달하면 읽기 제한을 시작합니다. DAX를 사용하면 단일 항목의 읽기를 3,000RCU 이상으로 규모를 조정할 수 있습니다.

  • 비용 최적화

    • DynamoDB 비용 절감 - DAX에서 읽으면 DynamoDB 테이블로 전송되는 읽기를 줄일 수 있으며, 이는 비용에 직접적인 영향을 미칠 수 있습니다. 캐시 적중률이 높으면 감소된 테이블 읽기 비용이 DAX 클러스터 비용을 초과하여 순 비용이 절감될 수 있습니다.

  • 데이터 일관성 요구 사항

    • 최종 일관성 - DAX는 최종적으로 일관된 읽기를 지원합니다. 따라서 DAX는 즉각적인 일관성이 중요하지 않은 사용 사례에 적합합니다.

    • 라이트-스루 캐싱 - DAX에 대한 쓰기는 라이트-스루입니다. DAX가 항목이 DynamoDB에 기록되었음을 확인하면 항목 캐시에 해당 항목 버전을 유지합니다. 이 라이트-스루 메커니즘은 캐시와 데이터베이스 간의 데이터 일관성을 더 엄격하게 유지하는 데 도움이 되지만, 추가 DAX 클러스터 리소스를 사용합니다.

DAX를 사용하지 말아야 할 경우

DAX는 강력하지만, 모든 시나리오에 적합하지는 않습니다. 다음 목록은 DAX와 DynamoDB를 통합하는 것이 적합하지 않은 시나리오의 예를 보여줍니다.

  • 쓰기 중심의 워크로드 - DAX의 주요 이점은 읽기 속도를 높이는 것이지만, 쓰기는 읽기보다 DAX 리소스를 더 많이 사용합니다. 애플리케이션에서 쓰기 작업이 주로 발생하는 경우 DAX가 주는 이점이 제한될 수 있습니다.

  • 데이터 읽기 빈도 낮음 - 애플리케이션이 데이터에 자주 액세스하지 않거나 거의 재사용되지 않는 데이터(콜드 데이터) 범위가 넓을 경우 cache hit ratio이 낮아질 가능성이 높습니다. 이 경우 캐시 유지 관리에 수반되는 오버헤드가 성능 향상을 정당화하는 데 걸림돌이 될 수 있습니다.

  • 대량 읽기 또는 쓰기 - 애플리케이션이 개별 쓰기보다 대량 쓰기를 더 많이 수행하는 경우 DAX를 중심으로 작성해야 합니다. 또한, 대량 읽기의 경우 DynamoDB 테이블에 대해 직접 전체 테이블 스캔을 실행해야 합니다.

  • 강력한 일관성 또는 트랜잭션 요구 사항 - DAX는 강력히 일관된 읽기 및 TransactGetItems 호출을 DynamoDB 테이블로 전달합니다. 클러스터 리소스를 사용하지 않으려면 DAX 클러스터를 대상으로 이러한 읽기 작업을 수행해야 합니다. 이렇게 읽은 항목은 캐시되지 않으므로, DAX를 통해 이러한 항목을 라우팅하는 것은 아무 소용이 없습니다.

  • 성능 요구 사항이 보통인 단순 애플리케이션 - 성능 요구 사항이 보통이고 직접적인 DynamoDB 지연 시간을 허용하는 애플리케이션의 경우 DAX를 추가하는 데 따르는 복잡성과 비용이 필요하지 않을 수 있습니다. DynamoDB는 자체적으로 높은 처리량을 처리하고 10밀리초 미만의 성능을 제공합니다.

  • 키-값 액세스를 넘어서는 복잡한 쿼리 요구 사항 - DAX는 키-값 액세스 패턴에 최적화되어 있습니다. 애플리케이션에 쿼리 및 스캔 작업과 같이 단순하지 않은 필터링 기능이 포함된 복잡한 쿼리 기능이 필요한 경우 DAX 캐싱이 주는 이점이 제한될 수 있습니다.

    이러한 상황에서는 Amazon ElastiCache(Redis OSS)를 대안으로 사용하세요. ElastiCache(Redis OSS)는 목록, 집합, 해시와 같은 고급 데이터 구조를 지원합니다. 나아가 게시/구독, 지리 공간 인덱스, 스크립팅과 같은 기능까지 제공합니다.

  • 규정 준수 요구 사항 - DAX는 현재 DynamoDB와 동일한 규정 준수 인증을 제공하지 않습니다. 예를 들어, DAX는 아직 SOC 인증을 획득하지 못했습니다.