ElastiCache에 대해 알아보기

 

먼저 짧게 정리해뒀던 ElastiCache 개념에 대해 잡아가고 싶으면

이 글을 먼저 읽고 오면 좋을 것이다.

https://670811.tistory.com/50#3-elasti-cashe%EC%9D%BC%EB%9D%BC%EC%8A%A4%ED%8B%B0-%EC%BA%90%EC%8B%9C%EB%9E%80?

AWS Database에 관해

 

#0 ElastiCache란?

ElastiCache는 앞서 살펴본 RDS가 관계형 데이터베이스를 관리하는 것과 같은 방식인데

ElastiCache는 캐싱 기술인 Redis나 Memcached를 관리할 수 있도록 도와주는 서비스이다.

...

여기서 캐시는 무엇일까?🤷‍♀️

캐시는 성능이 매우 높고 짧은 지연 시간을 가진 in-memory(인메모리) 데이터베이스이다.

캐시는 읽기가 주로 이루는 워크로드에서 데이터베이스의 로드를 줄여주고 일반적인 쿼리들은 캐시에 저장돼서 매번 데이터베이스를 쿼리하지 않아도 되고 캐시만 사용해서 쿼리의 결과를 검색할 수 있다.

 

근데 ElastiCache를 사용할 경우, 애플리케이션의 코드를 많이 바꿔야 하는데 캐시를 껐다 켰다 하면 되는게 아니라 캐시를 쿼리하도록 애플리케이션을 변경해야 한다. 

 

< ElastiCache를 사용하기 위한 아키텍처 살펴보기 > 📦

1. DB Cache

ElastiCache, RDS, 애플리케이션이 있다고 가정했을 때, 애플리케이션은 쿼리가 이미 발생했는지 확인하려고 ElastiCache를 쿼리한다. 이미 쿼리가 발생해서 ElastiCache에 저장되어 있는게 '캐시 히트' 라고 하는데 바로 ElastiCache에서 답을 가져오는 것이고 이 과정에서 쿼리를 수행하기 위해 데이터베이스로 이동하는 시간이 절약된다.

'캐시 미스' 가 발생하면, 데이터베이스에서 읽을 수 있도록 데이터를 가져와야 하는데 다른 애플리케이션이나 다른 인스턴스에서 같은 쿼리가 발생하면 데이터를 캐시에 다시 쓸 수 있고 다음에 동일한 쿼리가 일어나면 '캐시 히트' 가 되는 것이다.

 

=> 이렇게 하면 RDS 데이터베이스의 로드를 줄이는 데 도움이 된다.

그리고 데이터를 캐시에 저장하고 사용하는 과정에서 가장 최신 데이터만 사용되도록 캐시 무효화 전략이 있어야 한다.

(캐싱 기술을 사용하는 데 있어 가장 어려운 점이다.)

 

2. User Session Store

이 아키텍처는 애플리케이션을 상태 비저장으로 만드려고 사용자 세션을 저장하는 건데

쉽게 말해 사용자가 어떤 애플리케이션에 로그인하면, 애플리케이션이 세션 데이터를 Amazon Elasticache에 쓰는 것이다. 사용자가 애플리케이션의 다른 인스턴스로 리디렉션되면 애플리케이션은 그 세션의 세션 캐시를 Elasticache에서 직접 검색할 수 있으니 사용자는 여전히 로그인 상태.(다시 한 번 더 로그인할 필요 X)

=> 사용자의 세션 데이터를 Elasticache에 기록해서 애플리케이션을 상태 비저장형으로 만드는 것

 

+) Redis나 Memcached와 비교해보기

Redis의 '내구성'의 경우, 자동 장애조치 기능이 있는 다중 AZ와 읽기 복제본이 있어 RDS와 매우 유사하다.

(기능 면에서는 캐시로서 Supports Sets와 Sorted Set를 지원한다.)

 

반면에 Memcached는 데이터 분할을 위해 멀티 노드를 사용한다. => 이를 샤딩이라고 한다.

고가용성이 없고 복제도 일어나지 않고 영구 캐시도 아니고 백업도 없다.🤨

멀티스레드 아키텍처고 모두 샤딩(sharding)을 통해 작동한다.

 

=> 결론적으로 Redis는 고가용성이나 백업, 읽기 복제본 등을 위해 존재하고 Memcached는 분산되어 잇는 순수한 캐시라 데이터가 손실되어도 괜찮은 경우만 사용하면 된다.

이런 식으로 redis를 선택할건지 Memcached를 설택할건지 표시된다.

서버리스가 아닌 자체 캐시 설계에 들어가면 위에 설명했던 설정 개념들이 나온다.

 

 

#1 ElastiCache의 보안적 측면

ElastiCache는 Redis에서만 IAM 인증을 지원하고 나머지 경우엔 사용자 이름과 비밀번호를 사용하면 되는데

ElastiCache에서는 IAM 정책을 정의하면 AWS API 수준 보안에서만 사용이 된다.

그래서 Redis AUTH라는 Redis 내 보안을 통해서(Redis 클러스터를 만들 때) 비밀번호와 토큰을 설정할 수 있다.

=> 캐시에 추가 보안 수준을 만드는 것

그리고 SSL 전송 중 암호화도 지원한다.

 

아래의 그림을 빌려 더 설명을 하자면

예를 들어 EC2 인스턴스와 클라이언트가 있는 경우, Redis AUTH를 사용해서 Redis 클러스터에 연결할 수 있다. redis의  security group에 의해 보호가 되며 in-filght 암호화를 사용하거나 redis에서 IAM 인증을 활용할 수 있다.

 

#2 ElastiCache에 데이터를 로드하는 패턴 3가지

 

✅ <1. Lazy Loading - 지연 로딩>

모든 데이터가 캐시되고 데이터가 캐시에서 지체될 수 있다.

✅ <2. Write Through>

데이터베이스에 데이터가 기록될 때마다 캐시에 데이터를 추가하거나 업데이트하는 것

=> 데이터가 지체되지 않는다.

✅ <3. Session Store>

ElastiCache를 앞서 살펴본 세션 스토어로 사용할 수 있는데 유지 시간 기능(TTL)을 사용해서 세션을 만료할 수 있는 것

 

+) 위의 1. 지연로딩 전략 조금 더 살펴보기

윗쪽 챕터에서 비슷하게 설명하고 내려왔지만 첨언을 조금 더 해보겠다.

일단 애플리케이션에 '캐시 히트' 가 있는 경우, ElastiCache는 캐시에서 데이터를 가져오게 되는데

'캐시 미스'의 경우에는 데이터베이스에서 읽고 캐시에 쓰게 된다.

지연 로딩이라고 불리는 이유는 '캐시 히트' 가 없는 경우에만 데이터를 ElastiCache에서 로드하기 때문이다.

 

#3 ElastiCache - Redis의 사용 사례 살펴보기

게이밍 리더보드 만들기에 관한 내용으로 사용 사례를 조금 더 설명해보려고 한다.

게임하는 동안 어떤 순간에라도 누가 1등이고 2등이고 3등인지를 알고 싶을 때, Redis에서는 'Sorted Sets' 이라고 고유성과 요소 순서를 모두 보장하는 세트가 존재한다.

요소가 추가될 때마다 실시간으로 순위를 매긴 다음 올바른 순서로 추가가 되는데 Redis 클러스터가 있는 경우, 실시간 리더보드를 만들 수 있다.

=> 즉, 클라이언트가 Redis를 사용해서 Amazon ElastiCache와 대화할 때 이 실시간 리더보드에 액세스할 수 있고 애플리케이션 측에서 이 기능을 프로그래밍할 필요가 없다.

Sorted Sets와 같이 Redis를 활용해서 리더보드에 액세스 할 수 있다는 점을 기억하면 좋을 것이다.