AWS ElastiCache Redis

aws elasticache는 RDS와 같은 managed service로 OS부터 시작되는 패치, 모니터링, 장애 대응 등을 전부 관리한다.

 

elasticache는 read replica와 sharding을 통해 읽기/쓰기에 대한 scaling을 조절한다.

지원하는 엔진으로는 Redis와 Memcached이 있고, in-memory database로 빠른 성능이 필요할 때 사용한다. 주로 cache, session 관리에 사용한다.

 

memcached는 기본 redis와 달리 여러 개의 node로 구성되어 데이터를 샤딩해서 저장한다.

 

 

redis

replica node를 추가해서 읽기 성능을 높일 수 있고, multi az를 사용해서 failover를 관리할 수 있다.

in-memory 데이터베이스라서 노드에 문제가 생긴 경우 데이터는 손실되지만 AOF(Append Only File) 기능을 사용하면 데이터 유실을 막을 수 있다.

 

cluster

cluster 모드를 사용해서 견고성과 확장성을 더 높일 수 있다.

shard 수와 shard 당 node 수를 입력해서 cluster를 구성하면 shard는 적절히 slot별로 할당되어 나뉜다. 이때 key에 따라서 slot도 달라지는데 해당 slot을 범위로 가지는 shard로 보내주기 위해 클라이언트는 cluster의 configuration endpoint를 사용해야 한다.

 

freeable memory

운영에 필요한 거의 모든 metric을 수집한다. 오해하기 쉬운 metric이 있는데 freeableMemory 항목은 redis에서 앞으로 사용할 수 있는 메모리가 아니다.

 

redis는 전체 메모리를 key-value를 저장하는 데 사용하지 않고, reserved-memory라는 특수 공간을 할당한다. 이 공간은 백업, 장애 등의 조치에 필요한 공간이다. reserved-memory를 얼마나 할당할지는 parameter group에 정의되어 있는데 기본이 25%이다. 즉 10G 메모리의 인스턴스에서 redis를 운영한다면 freeableMemory가 2.5G가 남아 있어도 더 이상 데이터를 추가할 수 없다.

 

maxmemory policy

위의 예와 같이 더이상 데이터를 추가할 수 없을 때 행동하는 정책이다. set 명령이 들어왔는데 저장 공간이 부족한 경우 redis는 maxmemory-policy에 따라 행동한다.

redis는 key를 저장할 때 얼마 후에 expire 할지 기간도 같이 설정할 수 있는데, 정책에 이 ttl을 참조하기도 한다.

 

parameter group의 maxmemory-policy 기본값은 volatile-lru이다. volatile-lru 정책은 ttl이 설정된 key에 대해서 가장 오랫동안 참조되지 않은 key를 삭제한다. 이러면 캐시 용도로 redis를 사용할 때 문제 되지 않지만, ttl이 무한으로 설정된 key들로 데이터가 전부 찬다면 문제가 발생한다. volatile-lru 방식으로 삭제해야 하는데 ttl이 무한이면 대상 자체가 없기 때문에 OOM이 발생한다.