새로운 DB Redis 도입
새로운 아키텍처에서 채널리스트들을 빠르게 주고 받음과 동시에 중복을 제거하기 위해 redis를 도입하기로 했다. aws 상에서 redis를 사용하기 위해서는 몇 가지 생각해볼 수 있는 안들이 있었다.
- Redis용 서버(ec2)를 띄우기
- Elasticache에서 Redis 엔진 사용하기
- Amazon MemoryDB for Redis 사용하기
우선 1번은 굳이 그럴 필요가 없어서 제외했다. 남은 건 2번과 3번이었는데 이 포스팅과 이 포스팅을 번역해본 결과, 아래와 같았다.
Amazon ElastiCache는 메모리 작업을 수행하는 캐시 관리 역할을 데이터베이스 앞에 위치시킵니다. 즉, 데이터를 참조할 때 캐시에 먼저 접근하여 캐시 히트가 발생하면 데이터를 읽고, 캐시 미스가 발생하면 데이터베이스에서 데이터를 읽어 캐시를 업데이트합니다. 쓰기 작업은 데이터베이스에서 직접 수행되며, ElastiCache에서도 캐시 업데이트가 동시에 이루어집니다. 오래된 캐시 접근을 방지하기 위해 데이터베이스에서 데이터 변경이 발생할 때마다 캐시 서비스와의 백엔드 동기화를 통해 ElastiCache를 업데이트합니다. 이러한 캐시 자동 업데이트를 위해 갱신 속도를 구성할 수 있습니다.
반면에, Amazon MemoryDB for Redis는 데이터베이스와 캐시를 결합한 내구성이 뛰어난 완전히 관리되는 인메모리 데이터베이스로서 애플리케이션에 대한 데이터 액세스를 위한 마이크로초 읽기 지연 시간을 제공합니다. 인메모리 데이터베이스이므로 MemoryDB에서 쿼리를 수행하는 속도는 ElastiCache보다 훨씬 빠를 것입니다. 또한 다중 가용 영역(Availability Zone)에서 읽기 복제본에 대해 강력한 일관성을 가지므로 장애 조치 시나리오에서 더 신뢰할 수 있습니다. 데이터 내구성을 위해 분산 트랜잭션 로그를 사용합니다.
즉, Elasticache는 캐시와 DB의 조합이지만, 읽기 작업의 경우 우선 캐시를 탐색하고 뭔가 미스가 나면 DB로 넘어가서 탐색한다. 이에 반해, MemoryDB는 비슷한 캐시와DB 조합이지만, 통합되어있기 때문에 Elasticache보다 빠르다.
또한, Elasticache는 기본적으로 DB나 다른 저장소의 데이터를 캐싱해두거나 내구성이 크게 중요하지 않은 데이터를 위하기 때문에 노드가 다운되면 데이터가 날아간다. 하지만, MemoryDB는 멀티 AZ간의 복제를 통해 일관성을 항상 유지한다.
요약하자면 아래와 같다.
Elasticache
- memoryDB와 비슷하나 쓰기가 좀 더 빠름(공식 테스트 없음)
- 스케일링 자유
- 내구성 안 좋음(노드 손상시 데이터 날아감)
- 멀티 AZ(replica) 구성시 최대 5개까지 읽기 복제본 가능. 노드 승격은 비동기 처리.
- primary node 죽으면 데이터 일관성 깨짐
- r6g.2xlarge (8 vCPU, 52GB mem) = $0.916/h.
MemoryDB
- 1초당 읽기 39만개, 쓰기 10만개, 노드 당 읽기 최대 1.3GB/s 쓰기 최대 100MB/s
- 스케일링 자유
- 내구성 좋음
- 멀티 AZ 구성시 최대 5개까지 읽기 복제본 가능. 노드들이 애초에 일관성을 가져 승격에 시간 얼마 안 걸림(길어야 10초).
- 항상 primary node랑 replica node들이 일관성 유지
- r6g.2xlarge (8 vCPU, 52GB mem) = $1.374/h.
나는 2번과 3번을 고민했지만, 백엔드의 "비싼데..." 에 결국 남는 ec2에 redis를 올리기로 하였다. 물론 ec2에 올리는 것이 가장 저렴은 하나, 가용성이랑 스케일링을 할 때는 직접 클러스터를 구성해야 하고, 그 때는 또 비용이 들 수도 있다. 게다가, 백엔드 ec2에 올리기로 했는데, 만약 다른 이유로 백엔드 서버에 장애가 생기면 우리 redis에도 트러블이 나기 때문에 우선 진행하면서 조정을 해나가야겠다.
