Amazon ElasticCache

 

성능을 높이기 위해 사용하는 서비스 Amazon ElasticCache는 DynamoDB Accelerators(DAX)와 다르게 어플리케이션에서 처리를 해 줘야하는 부분이 있다. DynamoDB는 어플리케이션이 작업을 할때마다 항상 캐싱쪽으로 모든 요청을 보낸다. 하지만 ElasticCache는 어플리케이션이 케시쪽에 읽어달라고 요청을 하게 된다면, RAM과 같은 메모리를 이용헤 데이터를 처리하게된다. 그렇기에 캐싱 환경으로 사용을 하게 되지만, 데이터가 없을때 어딘가로 찾아가서 원본데이터를 가져와서 응답을 해 주는 그런 경우는 없는것이다.

선택할 수 있는 DB는 Redis와 Memcached가 있으며, 개발자의 선택에 따라 DB를 선택할 수 있다. 

	Memcached	Redis
DB부하를 오프로드 하는 단순 캐시	예	예
쓰기/저장을 위해 수평적으로 확장할 수 있는 기능	예	아니요
다중 스레드 성능	예	아니요
고급 데이터 유형	아니요	예
pub/sub기능	아니요	예
자동 장애 조치가 있는 다중 가용 영역	아니요	예
지속성	아니요	예

DB를 선택하고 나서는 크게 연속 쓰기, 레이지 로딩 이라는 2가지 전략중 하나를 택해서 수립할 수 있어야 한다.  

원본(DB)에 가서 데이터를 가지고 와서 캐싱을 하고, 응답을 하는 행동을 하지않는 - 즉  어플리케이션에 구현을 해야하는- 캐싱을 관리하는 전략이다.

 

연속쓰기

수정작업을 할 때 무엇인가 새로 생기는(레코드 생성, 삭제, 업데이트 등) 정보를 원본에 해당하는 데이터베이스에만 쓰는것이 아니라 캐싱쪽에도 쓰는 작업을 동시에 하겠다는 의미를 가진다. 즉 "오리진과 캐싱 두 군데에 동시에 업데이트를 하겠다" 라는 전략이다.

장점 : 항상 최신데이터를 캐싱한다

           사용빈도를 확인하여 데이터를 관리하기 용이하다.

단점 : 어플리케이션이 쓰기 작업을 2회 해야한다. 즉 쓰기작업이 2배로 늘어난다.

            캐싱되어있는 데이터가 자주 수정되어야하는 환경에 놓여져있다.

            최근자료이지만, 근시일내에 사용이 안 될 수 도 있다.

 

레이지 로딩(lazy)

말 그대로 읽기작업을 게으르게 하겠다 라는 의미를 가지고 있다. 캐싱을 사용하면 읽기작업은 1차적으로 캐싱쪽에서 작동하게된다. 데이터가 있으면 응답을 하겠지만, 데이터가 없다면 캐시미스(miss)가 발생하게 되어서, 원본에 가서 데이터를 가지고 오는 작업을 해야한다. 이때 어플리케이션이 ElastiCache에 쓰기작업을 하도록 하게 한다. 

즉 최근에 읽기 작업을 했으니 근시일내에 사용을 할 것이다 라고 가정하고 캐싱을 하는 개념이다. 

단 이것만 사용하게 된다면 오래된 데이터가 응답으로 가게 될 수 도 있다. 즉 수정은 원본과 캐싱된 데이터간의 차이가 있을 수 있게 된다. 

 

정책들의 단점을 개선하기 위해서 새로 도입된것이 TTL 이다. 데이터를 어느정도까지, 얼마나 보관을 할 것인지를 각 애플리케이션 쓰기에 추가를 시킨 후, TTL이 만료되면 애플리케이션은 데이터를 DB에서 쿼리하도록 한다.