[AWS] ElastiCache를 이해하고 캐싱 전략을 정해보자

aws - Aurora

 

AWS(Amazon Web Services)

 

 

AWS(Amazon Web Services)는 아마존이 제공하는 클라우드 컴퓨팅 서비스로, 서버, 스토리지, 네트워크 등을 클라우드를 통해 이용할 수 있습니다. 높은 안정성과 확장성을 갖춘 AWS는 클라우드 분야에서 높은 점유율을 차지하고 있습니다. 스파게티처럼 많은 기술이 존재하여 올바른 사용을 위해서는 꼭 학습이 필요합니다. 반대로 배워두면 많은 클라우드 기술을 사용할 수 있게 됩니다.

 

---

ElastiCache

What is ElastiCache?

 

ElastiCache란 캐시 기술인 Redis 혹은 Memcached를 사용할 수 있도록 해주는 서비스입니다. 이를 통해 최적화와 모니터링 등 여러 관리 이점을 가질 수 있습니다.

 

Cache(캐시)란 무엇일까요? 한마디로 높은 성능과 짧은 대기시간을 가지는 인메모리 데이터베이스라고 할 수 있습니다. 캐시를 사용하면 읽기 워크로드에 대한 데이터베이스의 트래픽을 줄일 수 있습니다.

 

ElastiCache를 사용하기 위해서는 애플리케이션 코드의 변경이 필요합니다. 다른 서비스와 달리 활성화를 한다고 해서 즉시 캐시를 얻을 수는 없다는 이야기입니다.

 

해당 포스트에서는 ElastiCache에 대한 설명과 어떠한 캐싱 전략을 선택할지에 대한 내용을 정리해 보겠습니다.

 

---

 

 

ElastiCache Solution Architecture

How ElastiCache Works

 

가장 먼저 애플리케이션이 ElastiCache를 쿼리 하여 쿼리 오류가 발생했는지 혹은 이미 발생하여 ElastiCache에 저장되어 있는지 확인합니다.

 

이때, 응답할 데이터가 캐시에 존재하면 Cache hit이 발생하고 그렇지 않은 경우 Cache miss가 발생합니다. 만약 Cache miss가 발생하는 경우 데이터베이스로 다시 요청을 보내야 합니다.

 

이후, 동일한 쿼리를 수행하는 애플리케이션을 위해 캐시에 write 작업을 수행합니다. 이러한 캐시 기술은 데이터베이스의 트래픽을 줄이는 데에 매우 유용합니다. 다만, 캐시에 데이터를 저장하고 있기 때문에 최신 데이터가 사용될 수 있도록 캐시 무효화 전략을 잘 세워야 합니다.

 

캐시를 사용하여 유저의 세션 정보를 저장하는 것 또한 가능합니다.
1. 사용자가 로그인을 하면 애플리케이션이 ElastiCache로 세션 데이터를 보냅니다.
2. 사용자가 애플리케이션의 또 다른 인스턴스로 리다이렉트 되면 애플리케이션은 ElastiCache에서 세션 캐시를 검색합니다.
3. 이전에 세션 캐시를 작성했으므로 로그인 상태가 유지됩니다.
즉, 사용자의 세션을 저장하여 애플리케이션을 무상태로 만들 수 있습니다.

 

---

 

Redis vs Memcached

 

What is the difference between Redis and Memcached?

 

ElastiCache를 사용할 때 두 가지의 선택지가 존재합니다. 바로 Redis와 Memcached입니다. 둘의 차이점이 무엇인지 간단한 게 알아보고 넘어가겠습니다.

 

Redis
- Auto failover를 가진 multi-az가 존재합니다.
- read replica가 있어서 read를 스케일 하고 고가용성을 가집니다.
- AOF 지속성을 사용하는 데이터 내구성이 있습니다.
- 백업과 복원 기능이 있습니다.
- 세트와 정렬세트를 지원합니다.

 

Memcached
- 데이터 파티셔닝을 위한 멀티 노드를 사용합니다.(샤딩)
- 고가용성이 없고 복제도 없습니다.
- 지속 캐시가 아닙니다.
- 백업과 복원도 없습니다.
- 다중 스레드 아키텍처입니다. 따라서 샤딩을 통해 여러 인스턴스를 보유하고 있습니다.

 

간단히 정리하자면, Redis는 High Availability(고가용성), 백업, 읽기 전용 복제본 등의 기능을 가집니다. 이에 반해 Memcached는 오직 순수한 캐시 기능만 가집니다.

 

---

Caching Patterns

 

 

What are the Criteria for Choosing a Caching Pattern?

 

 

데이터 캐싱을 통해 많은 이점을 얻을 수 있습니다. 하지만 항상 캐싱을 해야 하는 것은 아닙니다. 예를 들어 데이터가 빠르게 바뀌고 데이터셋의 모든 키가 필요한 경우 캐싱은 비효율적일 수 있습니다.(anti-patterns)

 

따라서 올바른 캐시 사용을 위해 적절한 캐싱 설계 패턴을 선택할 필요가 있습니다. 패턴은 크게 세 가지 종류로 나눌 수 있습니다.

 

Lazy Loading / Cache-Aside / Lazy Population

How does Lazy Loading work?

 

Lazy Loading 혹은 Cache-Aside, Lazy Population이라고도 불리며 앞서 ElastiCache Solution Architecture에서 설명했던 방법과 동일하게 작동합니다.

 

read 작업 수행 시 캐시를 확인하고 만약 데이터가 존재하지 않는다면 데이터베이스에서 읽어옵니다. 이후, 캐시에 해당 데이터를 작성합니다.

 

장점은 오직 요청받은 데이터만 캐싱된다는 점이 있습니다. 또한 캐시가 삭제되거나 노드 실패가 발생해도 치명적이지 않습니다. 물론 캐시를 한 번 warm-up 해야 하므로 시간 지연은 발생합니다. (warm-up이란 예열한다고도 하며 캐시 데이터를 가지기 위해서는 모든 읽기가 RDS로 가야 한다는 뜻입니다.)

 

단점으로 캐시 미스인 경우 애플리케이션에서 3번의 네트워크 호출이 필요합니다. ElastiCache로 한 번, 데이터베이스로 한 번, 캐시를 쓰면서 한 번 발생합니다. 이는 지연 발생으로 이어지게 됩니다. 또한 오래된 데이터가 존재할 수 있습니다. 데이터가 RDS에서 업데이트되어도 캐시는 업데이트되지 않을 수 있기 때문입니다.

 

따라서 최신 데이터가 아니어도 일관성을 유지하는 것이 중요한지 고민할 필요가 있습니다.

 

Write Through

How does Write Through work?

 

Write Through는 데이터베이스가 업데이트될 때 케시를 추가하는 방식으로 작동합니다. 즉, 앱이 RDS 데이터베이스를 수정하는 경우 캐시를 작성합니다.

 

장점은 캐시 데이터가 항상 최신화되어 있다는 점입니다. 사용자는 캐시 데이터에 접근할 때 오래된 데이터를 가져오지 않을 수 있습니다.

 

단점으로 업데이트가 추가될 때까지 데이터 누락이 발생할 수 있습니다. 이를 해결하기 위해 Lazy Loading 전략과 결합하여 캐시 데이터가 없는 경우 가져오도록 할 수 있습니다. 또한 캐시 이탈률이 존재하여, 많은 캐시에 많은 데이터가 있지만 절대 읽히지 않는 경우가 존재합니다.

 

Lazy Loading과 비교하였을 때 가장 큰 차이점으로 wirte penalty가 생긴다는 점입니다. Lazy Loading은 cache miss가 발생하였을 때 read latency이 발생합니다. 반대로 Write Through의 경우 write 과정에서 무조건 캐시를 작성하기 때문에 write latency가 발생합니다.

 

사용자 관점에 따라 read latency 최적화를 더 중요하게 생각한다면 Write Through 방식이 더 적합하다고 볼 수 있습니다.

 

 

 

---

Cache Evictions and Time-to-live(TTL)

 

Cache Evictions?

 

캐시에는 제한된 크기가 있습니다. 따라서 캐시를 제거할 필요가 있는데 이때 Cache Eviction이 일어납니다. 가장 간단한 방법으로 캐시를 명시하여 삭제할 수 있습니다. 혹은 캐시 메모리가 가득 찬 경우 가장 오랫동안 사용하지 않은 데이터를 삭제하는 방법도 존재합니다. (LRU)

 

Cache Eviction의 또 다른 방법으로 TTL(Time-to-live)를 사용할 수 있습니다. 이는 쉽게 말해 캐시에 수명을 부여하고 시간이 지나면 삭제되도록 하는 것입니다.

 

TTL은 짧으면 몇 초에서 길면 며칠까지 갈 수도 있습니다. 매우 작은 TTL이라도 데이터가 자주 요청되는 경우에는 효과적일 수 있습니다.

 

다만, 메모리가 가득 차서 너무 많이 제거되는 상황이라면, 캐시 크기 자체를 늘릴 것을 고려할 필요가 있습니다.

---

There are only two hard things in Computer Science: cache invalidation and naming things.

 

 

컴퓨터 과학에서 가장 힘든 일은 캐시 무효화와 이름을 짓는 것이라는 명언이 있습니다. 그만큼 캐싱이라는 기술을 적용하기 매우 어려운 기술입니다.

 

해당 포스트에서도 정말 기초적인 내용만이 설명되고 있습니다. 캐시에 관해서는 AWS 학습이 끝이난 뒤 다시 한번 깊게 공부해 볼 필요가 있겠다는 생각이 듭니다.

 

이제 RDS, Aurora, ElastiCache까지 관계형 데이터베이스 서비스와 연관된 모든 내용 정리가 끝났습니다. 다음 포스트는 Route 53에 대한 내용으로 돌아오겠습니다.