Elasticache
•
완전관리형 In-Memory Cache 서비스
•
Elasticache for Redis
•
Elasticache for Memcached
•
고가용성 캐시 서비스 구성
•
관리 부담 감소 사용 편의성
•
빠른 응답이 필요한 애플리케이션에 사용
•
기존의 DB와 연결하여 DB 응답 성능을 개선하기 위해 사용
•
ElasticCache를 사용하기 위해서는 애플리케이션의 코드 변경이 필요
•
세션 스토어, 게임 리더보드, 스트리밍 및 분석과 같이 내구성이 필요하지 않는 기본 데이터 스토어로 사용
•
Memcached는 멀티스레드 지원
•
Redis는 싱글스레드만 지원
Vs RDS Read Replica
•
RDS Read Replica
◦
영구적인 데이터 저장
◦
데이터가 계속 변경되는 쿼리의 읽기 성능 향상에 적합
•
ElasticCache
◦
RAM과 같이 빠른 하드웨어에 일시적으로 저장
◦
지연시간을 줄이는 목적으로 주로 사용
◦
속도는 빠르지만 저장할 수 있는 공간에 제약이 있음
◦
변경이 없는 동일한 데이터를 계속 읽는 경우의 성능 향상에 적합
Elasticache for Redis의 3가지 클러스터 형태
•
싱글 클러스터
•
Replication 
•
Data Partitioning
•
Scaling Up / Down
•
Multi-AZ
•
클러스터 모드 비활성
•
Replication (최대 5개)
(최대 5개)•
Data Partitioning
•
Scaling Up / Down
•
Multi-AZ 최소 1개 Replica 필요
•
클러스터 모드
•
Replication
•
Data Partitioning
•
Scaling In / Out
•
Multi-AZ
Memcached
•
Memcached는 심플한 캐싱 활용에 적합하다.
•
Multi Thread로 작동한다. 즉, 여러 스레드가 동시에 요청을 처리할 수 있다.
•
Redis와 달리 Memcached는 데이터의 영구 보존이나 백업 기능이 없다.
•
그렇기 때문에 장애나 재부팅이 발생하면 캐시 데이터가 남지 않고 사라진다.
•
계속 유지해야 하는 데이터는 스토리지나 다른 DB 서비스에 저장해두고, 애플리케이션의 속도를 높이기 위한 캐시로 사용하는 경우에 적합하다.
Redis
•
Redis는 Memcached보다 고기능의 데이터베이스 엔진이다.
•
Single Thread로 작동한다. 즉, 한 번에 하나의 작업만 처리한다.
•
Snapshot (Amazon S3에 저장) 기능을 통한 백업 및 복원이 가능하며, 데이터를 영구적으로 보존할 수 있다.
•
"자동 페일오버"와 "Multi AZ"가 있다. (장애 대책 기능])
◦
자동 페일오버 : 프라이머리 노드에 장애가 발생하면 자동으로 레플리카 노드가 프라이머리 노드로 승격된다.
◦
Multi AZ : AZ를 넘나드는 복제가 가능하므로, 프라이머리 노드가 있는 AZ에 장애가 발생해도 다른 레플리카 노드를 승격시켜 운영을 지속할 수 있다.
•
[보안 기능]: Redis는 Memcached에는 없는 보안 기능을 제공한다.
◦
저장된 데이터의 암호화나 SSL/TLS를 통한 통신 암호화
◦
클라이언트를 비밀번호로 인증하는 Redis 인증 등을 지원한다.
◦
이러한 기능을 사용하려면, ElastiCache 데이터베이스를 생성할 때 Redis를 선택하고 암호화를 활성화해야 한다
Redis와 Memcached 공통점
•
in-memory DB로써 속도가 빠르다.
•
key-value 형태로 데이터를 저장
•
캐시나 새션, 상태 정보 저장에 최적화 되어 있다.
캐싱 전략
•
ElastiCache는 애플리케이션 성능 향상을 위해 주로 사용된다.
•
데이터를 어떻게 저장할 것인가는 데이터의 일관성과 가용성을 유지하면서 성능을 최대화하는 데 중요하다.
•
이를 캐싱 전략이라고 하며 대표적인 2 가지 캐시 전략이 있다.
Write-Through - 바로 바로 업데이트
•
DB에 데이터를 업데이트(write)할 때마다, 동시에 캐시에도 데이터를 업데이트한다.
•
이 전략에서는 캐시의 데이터가 항상 최신 상태로 유지되므로, 데이터 일관성이 유지된다.
•
그러나 쓰기 성능이 약간 저하될 수 있으며, 액세스되지 않는 데이터가 캐시에 쌓이는 단점이 있다
Cache-Aside (Lazy loading) - 살짝 지연 but 효율적
•
DB에 데이터를 업데이트(write) 우선시하고, 필요할 때만 캐시에 데이터를 업데이트한다.
•
요청 발생 : 애플리케이션이 데이터를 DB 요청할 때 먼저 캐시(ElastiCache)를 확인한다.
◦
만약 캐시에 그 데이터가 있다면, 애플리케이션에 보낸다.
◦
만약 캐시에 그 데이터가 없다면, 데이터베이스(DB)에서 해당 데이터를 가져온다.
▪
캐시에 저장: 가져온 데이터를 캐시(ElastiCache)에 저장해 둔다.
▪
이후에 동일한 데이터 요청이 들어오면 캐시에서 빠르게 가져올 수 있게 됩니다.
•
이 방법에서는 요청된 데이터만 캐시되므로 리소스 낭비를 줄일 수 있지만, 캐시와 데이터베이스 간에 일시적인 데이터 불일치가 발생할 수 있는 가능성이 있다.
•
또한, cache miss(캐시 미스 : 캐시에서 데이터를 가져올 수 없는 경우)가 발생하면 데이터 가져오는 데 시간이 걸릴 수 있다.