DynamoDB Accelerator (DAX) 를 정리하고 ElastiCache 와의 차이점에 대해 알아봤다.

LimChaejeong

2022.02.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

아젠다

1. 정의

DynamoDB와 호환되는 풀 관리형 인메모리 캐시 서비스
초당 요청 수가 몇 백만 개인 경우에도 몇 밀리초부터 몇 마이크로초까지 최대 10배의 성능을 제공
기존 DynamoDB의 API와 호환성이 있기 때문에 이미 DynamoDB를 사용하더라도 쉽게 이행이 가능
사용하기 적합한 경우
- 응답 시간을 최대한 짧게 해야 하는 경우
- 데이터를 많이 읽는 애플리케이션
- 대규모 데이터에서 자주 읽는 애플리케이션
사용하기 적합하지 않은 경우
- 데이터 읽기의 일관성을 유지해야하는 애플리케이션
  - 캐시 서비스이기 때문에 일관성 있게 읽기에는 적합하지 않다
- 쓰기가 많고 읽기가 적은 애플리케이션
  - 읽기가 많이 필요없는 애플리케이션에서는 추천하지 않는다

2. DynamoDB DAX VS ElastiCache

그럼 DynamoDB DAX도 ElastiCache도 같은 캐시 서비스인데 둘 중에 뭐를 사용하면 좋을까요? 두 서비스의 차이 점은 뭘까요?
두 서비스의 공통점은 캐시 서비스라는 것입니다. 캐시 서비스란 나중에 사용할 수 있도록 데이터를 보관하는 임시 저장 위치입니다.

또한, 차이점은 다음과 같습니다.

(1) DynamoDB DAX

DynamoDB 를 위한 인-메모리 캐시 서비스
DB 테이블의 각각의 개체나 쿼리 또는 스캔을 위한 캐시
- 스캔을 하고 쿼리를 해서 데이터를 걸러내는 것과 같다 (결과값을 캐싱)
ElastiCache에 비해 내구성과 계산 비용이 높다
사용하면 좋은 경우
- 읽기를 많이 하는 어플리케이션의 경우 캐시 적중률이 개선
- 동시 요청 수가 몇 백만 개의 환경에서 마이크로초의 성능의 응답이 필요한 경우
- 애플리케이션의 구조변화를 최소화하면서 DynamoDB의 응답 성능을 개선하고 싶을 경우

(2) ElastiCache

애플리케이션이 방금 수행한 작업의 결과를 저장하는 캐시 서비스
캐싱, 세션 스토어, 지리 공간 서비스, 실시간 분석 및 실시간 데이터에 사용
DAX에서 다시 쿼리하고 집계 클라이언트 측을 다시 수행하는 대신 ElastiCache에서 직접 데이터를 검색 가능
- 집약된 결과를 캐싱
사용하면 좋은 경우
- 애플리케이션에서 사용하여는 DB가 DynamoDB가 아닌 경우
- 온프레미스 환경에서 Redis, Memcached 서비스를 마이그레이션 하는 경우
- 요금 최적화를 고려해서 단순히 DB 캐싱 레이어를 추가하는 경우