ElastiCache는 주로 DB의 처리 결과를 메모리에 저장했다가 다음 요청시에 저장된 결과를 반환함으로써, 애플리케이션을 빠르게 구동할 수 있게 해줍니다.

 

앞에서 설명드린 CloudFront와 컨셉만 보면 매우 비슷하죠? 캐싱기능이라는 점에서 유사성이 있긴 합니다. 물론, 사용하는 곳은 전혀 다르지만요... 아키텍쳐 설계 시 두가지를 함께 써서 설계를 하는 문제가 나올 수도...나왔을 수도 있습니다.^^;;;

 

 

ElastiCache는 인 메모리 캐시를 간편하게 배포,운영할 수 있도록 도와주는 AWS의 서비스입니다.

인 메모리 캐시는 일반적인 데이터베이스와는 다르게 데이터를 메모리에 올려놓고 사용한다고 하네요.

따라서, 상대적으로 느린 디스크 기반의 데어터 베이스가 아닌 메모리 캐시에서 정보를 검색하고 분석하기

때문에 처리량을 개선할 수 있고, 그로 인해 더욱 고성능의 서비스를 제공할 수 있습니다.

 

그리고, ElastiCache는 우리가 일반적으로 생각하는 캐싱과 달리, 캐시에도 쓰고, DB에도 함께 쓰는 방식이며, 읽을때만 캐시에서 읽어오는 구조라고 합니다. (흐름도를 그려야 할 경우에 주의가 필요해 보입니다)

 

아래 그림의 7번,8번 흐름도를 참고하시면 될 것 같네요.

 

 

ElastiCache는 현재 Memcached와 Redis 캐싱 엔진을 지원하고 있습니다.

두 캐싱엔진은 특성이 다르기때문에, 사용할 때 특성을 잘 알고 사용해야 합니다.

 

1. Memcached

  > 클러스터 노드를 추가하여 용량을 증설할 수 있음

  > 간단하게 처리할 때 주로 사용

  > Memcached로 묶인 모든 서버는 동일한 가상 메모리 풀을 공유

  > 분산 메모리 캐시를 적용하게 되므로, 캐싱을 통해 DB나 API호출에 대한 횟수를 줄일 수 있고,

     이로 인해 부하를 줄일 수 있음.

 

 

2. Redis

  > 클러스터 구성이 불가하며, 노드 추가로 인한 용량증설 효과를 볼 수 없음

  > 스냅샷 생성과 Read  Replica 기능 사용 가능

  > Read Replica 마스터 캐시 노드의 Failover 기능(Read Replica 승격) 사용 가능

  > Key-Value 저장방식이며, Value에는 일반적인 string외에 set,list,hash와 같은 집합형 데이터 구조를 지원

  > 저장된 데이터에 대한 연산이나 추가 작업 가능

 

 

 

 내용이 조금 복잡해 보일 수 있는데, 찾아보니 대부분의 경우에 Redis를 사용하는 것이 더 좋다고 하네요.

 

이부분은 아래 사이트에 잘 정리가 되어 있습니다.

 

http://blog.leekyoungil.com/?p=200

 

+ Recent posts