엘라스틱 캐시를 위한 Redis VS Memcached

[AWS][ElastiCache] #1.  엘라스틱 캐시의 클러스터 고르기

 

상황

마지막 프로젝트를 진행하면서 제작한 서비스의 메인 ec2 상의 api 서버는 기본적으로 mysql 기반의 rds 로 엔드포인트가 향해있었다. 어플리케이션을 통해 들어온 사용자의 예약 정보를 저장하기 위한 데이터베이스가 필요했기 때문.

솔직히 여기까지만 해도 토이프로젝트로는 충분하다고 생각했다. 실제 우리가 많은 양의 데이터를 처리하거나, 처리 속도에 대한 제한까지 신경쓸 것 같진 않았다. 사실 작은 규모의 데이터 입출력을 다룰 땐 캐싱이 필요하지 않다. 오히려 비용적 측면에서 캐싱을 함으로써 발생하는 추가 비용이 rds를 직접 다녀오는 비용보다 클 수 있다. 

단, 요구사항 명세에서 클라이언트로 부터 다음과 같은 요구를 받게되었다.

 

데이터 내구성을 보장하기 위해 RDS는 복제본이 만들어져야 하며, 빠른 예약 정보 검색을 위해 쿼리결과는 ElastiCache를 통해 캐싱이 되어야 합니다.

이 프로젝트가 실제 사용될 기업용 서비스임을 감안하고 만들어져야한다면, 우리가 아는 웹사이트들이 초당 몇천번의 I/O가 발생함을 상기해야한다. 이때 발생하는 모든 입출력을 메인 디비가 감당해야한다면 가장 큰 이슈인 속도부터 비용까지 문제가 커진다. 이를 해결하기 위해 캐싱을 해야했다. 

 

캐싱에 대해서는 단순 출처를 밝힌다.

캐싱이란 무엇입니까?

컴퓨팅에서 캐시는 일반적으로 일시적인 특징이 있는 데이터 하위 집합을 저장하는 고속 데이터 스토리지 계층입니다. 따라서 이후에 해당 데이터에 대한 요청이 있을 경우 데이터의 기본 스토리지 위치에 액세스할 때보다 더 빠르게 요청을 처리할 수 있습니다. 캐싱을 사용하면 이전에 검색하거나 계산한 데이터를 효율적으로 재사용할 수 있습니다.

캐싱은 어떻게 작동합니까?

캐시의 데이터는 일반적으로 RAM(Random Access Memory)과 같이 빠르게 액세스할 수 있는 하드웨어에 저장되며, 소프트웨어 구성 요소와 함께 사용될 수도 있습니다. 캐시의 주요 목적은 더 느린 기본 스토리지 계층에 액세스해야 하는 필요를 줄임으로써 데이터 검색 성능을 높이는 것입니다. 속도를 위해 용량을 절충하는 캐시는 일반적으로 데이터의 하위 집합을 일시적으로 저장합니다. 보통 완전하고 영구적인 데이터가 있는 데이터베이스와는 대조적입니다.

- 출처 : aws

https://aws.amazon.com/ko/caching/

캐싱이란 무엇이고 어떻게 작동합니까 | AWS

 

ElastiCache란?

쿼리 결과에 대한 캐싱은 여러 방법이 있겠지만, 우선 클라이언트가 직접적으로 언급해서 사용하길 바라는 것이기 때문에 가장 먼저 도입을 고려해야했다. 엘라스틱 캐시는 aws에서 제공하는 완전 관리형 캐시로 인메모리 NoSQL 시스템을 제공하는 서비스다. 전반적으로 aws의 리소스들을 사용하여 관리 할 예정이기 때문에 aws에서 관리하는 캐싱이 다른 리소스들과 연동이 쉬워보였다. 

 

In-memory ​cache란?

모든 데이터를 메모리(RAM)에만 올려 놓고 사용하는 데이터베이스.

일반적인 데이터베이스(RDBMS)는 디스크(HDD,SSD)에 데이터를 영구적으로 저장해 놓고, 필요한 데이터만 메모리에 읽어서 사용한다.

인 메모리 캐시는 디스크에 접근하지 않고 메모리로만 모든 처리를 하기 떄문에 데이터 저장 및 검색 속도가 매우 빠르지만, 데이터는 딱 메모리 크기까지만 저장 가능하다. 또한, 메모리에만 저장되어 있기 때문에 서버의 전원 공급이 중단되면 데이터는 소멸된다.

 

종류

엘라스틱 캐시를 사용하기 위해서 NoSQL 시스템은 Memcached와 Redis 둘중 하나를 선택할 수 있었다. 

 

Redis

• Redis는 문자열, 해시, 리스트, 정렬 심지어 위치데이터 와 같은 다양한 데이터 구조를 지원하는 오픈 소스 인 메모리 캐시.
• Redis는 Memcached와 달리 노드들끼리 클러스터를 구성할 수 없다. 따라서 노드를 추가한다고 해서 저장할 수 있는 전체 메모리 용량이 늘어나지 않는다 => 수평 확장 불가. Aws에서 제공하는 기능의 수직확장만 가능.
• ElastiCache Redis는  마스터/슬레이브 복제 및 다중 AZ 기능을 사용할 수 있고 스냅샷 생성과 Read Replica를 지원. Read Replica는 마스터 캐시 노드에 장애가 발생하면 자동으로 Read Replica가 마스터 캐시 노드로 승격되는 Failover 기능을 지원. => 안정성과 고가용성
• Redis 캐시 노드가 제공하는 메모리 용량을 넘어서는 데이터를 저장하기 위해서는 애플리케이션 레벨에서 데이터를 여러 캐시 노드에 분산하여 저장하는 샤딩(Shading)을 구현해야 함.
• 싱글스레드 지원 => 한번에 명령어 하나
• 동일 vpc 내의 ec2 인스턴스로만 접근 가능, 엔드포인트를 통한 퍼블릭한 접근 x

 

샤딩이란?

 Nosql 장르 디비에서 주로 쓰이는 수평적 파티셔닝의 한 종류. 수평적 파티셔닝은 디비 하나를 여러 파트로 분할 하는 정책에따라 관리하는 것이고 샤딩은 클라이언트가 직접 나눠진 여러 레디스 서버에 데이터를 나눔으로써 관리하는 것이다.

 

 레디스는 복제를 통해 Master의 데이터를 Replica에 모두 저장하여 가용성과 읽기 작업의 성능을 높인다. 대체로 디비들의 핵심 이슈인, 데이터 양이 갑자기 늘 경우 어떻게 대처하는가-를 위해 샤딩을 알아봐야한다. Replica는 모든 데이터를 복제해야하기 때문에 단일 서버에서 저장 가능한 Memory를 초과하면 이를 복제할 수 없다. 마스터 노드의 성능에 따라 최종적으로 저장 할 수 있는 양이 정해지는 것이다. 따라서 메모리 증설등을 통한 Scale-Up(수직확장) 만으로 데이터 저장 공간을 확보할 수 없을때, Redis에서는 샤딩을 활용한다.

 또한, 기본적으로 복제를 통해 마스터와 노드를 동기화 하는데 샤드가 나뉘면 쓰기 연산을 실행했을 때, 해당 부분을 한 샤드에서만 할 수 있으니까 연산 양이 줄어든다.

 

샤딩 전략을 어떻게 취하는지가 결국 데이터베이스의 성능에 직접적 영향을 끼치게 된다.

 

샤딩 전략에 대해서는 다음 블로그에 자세히 설명되어 있다.

https://cla9.tistory.com/102

2. Redis 샤딩

 

Memcached

• 멀티스레드 아키텍처를 지원한다
• HTML 같은 단순한 코드를 캐싱할 때, 비교적 작은 메모리를 사용한다.
• String 타입만 지원하고 오로지 읽기 전용이기 때문에 다른 작업을 처리하지 않아서 데이터 저장하기에 좋다.
• Redis에 비해 수평적 확장의 이점

 

개인적 결론

• 사실 토이프로젝트라고 생각하고 단순하게만 진행하려면 memcached로도 충분해 보였다.
• 실제 시도 해 보니 지원하는 자료구조가 레디스가 훨씬 다양했다. String, List, Set, Sorted sets, Hash 등을 지원하기 때문에 api와 커스텀하기 좋았다.
• 데이터 변경이 잦은 경우, 메모리 파편화가 발생하기 쉽다는 이슈로 memcached는 한 번 입력후, 변경되지 않는 정보를 저장할 때 권장된다. 하지만 우리가 하고자하는 서비스를 생각하면 같은 사용자도 배송을 위해 도착지, 출발지, 화물의 용량, 날짜 등 모든 데이터가 예약할 때 마다 변경될 것이기 때문에 레디스가 더 적절하다고 생각했다.