실전 프로젝트에서 아직 코딩으로 기능을 구현하기 전, 팀원들과 함께 데이터 모델링을 할 때였다. User 테이블에는 Refresh Token 필드값을 넣어뒀었고, 채팅 기능을 구현하기 위해 Chatroom과 Chat 테이블까지 만들어뒀었는데 한 팀원이 이런 질문을 던졌다.
"실시간으로 채팅을 주고 받을 때마다 MySQL에 값을 다 넣으면 DB가 아마 터지고 말껄요?"
맞는 말이었다. MySQL을 채팅 메세지 보관용으로 바로 쓰기에는 속도, 응답성 2가지의 측면에서 문제가 있었다. 일정 시간이 지난 데이터들을 MySQL과 같은 RDBMS에 저장하는 것은 검색 등의 기능을 구현하기 위해 더 나은 선택이겠지만, 즉각적인 채팅 데이터들을 바로 데이터베이스에 접근하게 하는 것은 비효율적이었다.
그래서 우리는 Redis를 프로젝트에 도입했다.
Redis
Redis는 고성능 key-value 저장소로서 문자열, 리스트, 해시, 셋, 정렬된 셋 형식의 데이터를 지원하는 NoSQL이다. Redis는 In-Memory 저장소로서 기본적으로 빠른 데이터 입출력을 제공하며 키 등록, 조회에 있어서는 O(1)의 성능을 보장한다.
하지만 이후, 단순히 입출력이 잦은 기능 구현에 필요하다고 해서 Redis를 도입하고 나서 우리 팀은 또다시 위기에 직면했다. 서버가 내려갈 때마다 Redis는 저장된 데이터를 모두 지웠던 것이다. 다른 것은 몰라도 채팅 같은 경우에는 불시에 이전 내역이 다 날라가있으면, 유저들이 큰 불편함을 느낄 수 있는 부분이었다. 그제서야 우리 팀은 이 문제를 해결하고자 'Redis의 데이터 백업 방식' 등을 검색하기 시작했고, Redis가 데이터 영속이라는 기능도 지원하는 오픈 소스라는 것을 알게 되었다.
Redis를 통한 데이터 영속화
Redis는 데이터 관리 방법으로 3가지가 있는데,
첫번째는 메모리에서 데이터를 관리하는 방식(휘발성 기반),
두번째는 특정 시간에 데이터를 디스크에 저장하는 방식(RDB 기반),
세번째는 수시로 데이터를 디스크에 저장하는 방식(AOF 기반)이 있다.
종류에 따라 성능저하를 유발할 수 있으므로 상황에 맞게 선택해야 하는데, 채팅 같은 경우에는 데이터 분실률을 0%로 가져가고 싶었기 때문에 우리는 AOF 기반의 데이터 저장방식을 선택했고, 유실되는 데이터 없이 채팅, 알림 서비스 기능을 구축할 수 있었다.
Redis를 처음 접했을 때는 Cache 저장소로 자주 사용된다는 것만 알았는데, 우리 서비스의 경우에는 Cache 보다는 Refresh Token 관리, 채팅, 알림 데이터 저장소로 활용을 했다. 프로젝트를 끝내고 이제 Redis를 생각하면 떠오르는 키워드는 다음과 같다.
Redis 의 핵심 Keywords
- message broker기능을 수행하는 pubsub 구조
- key-value 값 데이터 저장소
- 싱글 쓰레드로 실행되기 때문에 keys * 등의 명령어 쓸 때 주의할 것
- 영속화 기능(RDB, AOF)
- 연속적으로 발생하는 데이터를 보관하고 처리하는 Streams
이번 프로젝트를 통해 처음 접한 Redis 였지만, 상당히 많은 기능 사용에 도전을 해보고 공부를 해본 것 같다. 다음 번에는 Cache Memory로도 제대로 사용을 해보고 싶고 무엇보다 우리 서비스에 적합한 Redis 성능을 측정하기 위한 테스트도 수행해보고 싶다.
이상, 끝!
