결론적으로 말하자면, Cache 서버로 조회성능을 높이고, Session 서버를 만들어 모든 세션이 하나의 DB를 바라보게 하기 위해서입니다.
또, 불필요한 복제(Session-Clustering)가 일어나지 않고, 서버를 계속 추가시켜도 성능의 저하 우려(Sticky Session)를 해결할 수 있습니다.
In-memory Database란?
Disk(HDD, SSD)에 저장되는 데이터베이스와는 다르게 Memory에 데이터 저장 목적으로 사용되는 데이터베이스를 말합니다. 보통 디스크에 저장이 되면 읽고/쓰기가 느리기 때문에 시간이 걸리게 되는데 이러한 응답 시간을 줄이고자 설계된 것이 In-memory Database 입니다.
하지만 메모리에 저장되기 때문에 서버가 다운되거나 동작 과정 중에 데이터가 유실될 수 있는 가능성이 큽니다. 그래서 Redis의 경우 이럴 때를 대비하여 동작 중에 로그나 스냅샷(snapshots)를 이용하여 디스크에 데이터를 저장합니다.
In-memory Database의 사용이 적합한 경우는 microsecond 단위의 응답시간을 요구하는 애플리케이션이나 실시간 분석, 세션 저장, 게임 순위 선정 등 트래픽이 비교적 많이 몰리는 상황에 적절하다고 합니다.
제 프로젝트(ward-study-reservation)에는 분산 처리 환경을 도입하였습니다. 그래서 여러 Session이 하나의 DB를 바라보게 설계가 필요하기에 Session-clustering에서 단점으로 꼽히던 데이터의 복사로 인한 성능 저하 가 해결할 수있는 In-memory Database 중 Redis를 사용하였습니다.
in-memory Database에도 종류가 다양합니다.
Redis를 선택한 이유
그중에서도 Redis를 선택한 이유는 아래와 같습니다.
- 무료 오픈소스 데이터베이스 이기 때문에 라이센스 비용이 대폭 절약된다.
- sub-milisecond 단위의 높은 응답 속도를 보여주기 때문에 대용량 트래픽을 고려하는 우리 프로젝트에 적절하다.
- Key-Value 형태로 저장되기 때문에 같은 Key-Value 로 저장되는 세션 데이터를 다루는데 적합하다.
- master-slave 관계의 replication(복제)을 지원한다.
- Spring 도 위와 같은 장점을 바탕으로 Redis를 사용할 때 편하게 개발할 수 있도록 Dependecy를 제공한다.
Redis는 master-slave 관계의 replication을 사용한다면, master 인스턴스에 모든 데이터를 저장하고 slave 인스턴스에 같은 데이터를 복제해 저장할 수 있습니다. 만약 master가 다운이 되어버리면 자동으로 다른 slave가 master로 지정되기 때문에 사용자들은 서비스의 중단 없이 이용할 수 있습니다.
그러나 Redis의 경우 Master-Slave 복사과정이 모두 비동기 방식으로 이루어져 높은 퍼포먼스를 보여줄 수 있지만, Master는 Slave로 복사하는 시간을 기다려주지 않기 때문에 데이터가 완벽히 복사되지 않을 수도 있습니다. 그래서 WAIT 이란 명령어를 통해 필요하다면 동기방식으로 복사를 진행할 수 있지만 성능이 떨어질 수 있으며 완벽한 일관성을 유지하지는 못한다고 합니다.
간단 정리 : https://velog.io/@mooh2jj/Redis-란
참고
