레디스를 왜 쓸까요?

정말 많은 백엔드 엔지니어 공고를 보면 레디스 사용 유무에 대한 우대를 확인할 수 있습니다. 그렇다면 현업에서는 레디스를 적극적으로 도입하고, 사용하고 있다는 것인데요. 레디스가 도대체 무엇이길래 현업에서 이를 하나의 솔루션으로써 활용하는지를 알아보려고 합니다.

 

Redis란 무엇인가?

레디스(Redis; REmote Dictionary Server)는 시스템 메모리를 활용하여 Key-Value 형식으로 비관계형 데이터를 저장하는 데이터베이스(NoSQL)인 데이터 관리 시스템입니다. 모든 데이터를 메모리에 저장하기 때문에 Relational DB (ex. RDS) 또는 Document DB (ex. MongoDB) 와 같은 데이터베이스를 활용하여 데이터를 처리하는 것보다 훨씬 빠르고 가볍게 데이터를 조회할 수 있습니다.

 

하지만 레디스는 우리가 아는 RDB가 아니라 비 관계형 데이터베이스이므로, varchar나 int, datetime과 같은 자료형을 지원하지 않습니다. 하지만, List, Set, Sorted Set, Hash 와 같은 Collection을 지원합니다.

1. 문자열 : 숫자나 날짜, 시간 등 거의 모든 정보는 문자열로 처리하여 캐싱합니다.

2. 해시 : 해시는 필드를 가질 수 있습니다. 가령, 사용자 정보라는 해시는 이메일과 닉네임을 가질 수 있게 됩니다.

3. 연결 리스트 : 문자열을 element로 갖는 연결 리스트를 저장할 수 있습니다. 마치 deque처럼 양쪽에 element를 추가할수도 있습니다.

4. 셋 : 중복을 제거하는 자료구조인 set을 활용하여 고유 값을 저장하도록 사용합니다. 이는 sorted set을 지원하며, 정렬을 통해 특정 기준 값에 들어온 데이터만 필터링하는 것도 가능합니다.

 

왜 사용하는가?

위에서 서술한 것과 같이, 레디스는 데이터를 메모리에 저장하므로 MySQL과 같은 데이터베이스와 비교했을 때 데이터 조회 성능이 훨씬 빠르며, 비록 메모리에 저장한다 하여도 저장된 데이터가 volatile하지 않고 영속적으로 보관됩니다. 즉, 서버를 재부팅하여도 레디스에 저장되어있는 데이터는 유지가 되어있게 됩니다. 말만 들어서는 무조건 적용하는 것이 좋아 보이지만, 레디스는 어느 서비스에나 무조건 적용할 만능 솔루션은 아니라고 합니다.

 

그렇지만 만약에 어떤 웹 서버가 key-value 형식의 데이터 타입을 빈번하게 처리해야 하고, 그 데이터의 I/O이 자주 발생하여 이를 RDB등을 사용하여 매번 처리하기엔 오버헤드가 너무 강할 경우 적용해볼만한 솔루션입니다. 이러한 것의 대표적인 예시는 조회수입니다. 유튜브 서비스 내에서는 유명 유튜버가 영상을 공개하면 실시간으로 정말 많은 조회수를 기록하는 서비스입니다. 이 조회 count를 매번 RDS에 쿼리를 쏘며 update한다면 아무리 좋은 컴퓨터라도 버티지 못할 것입니다. 이러한 경우에 해당 데이터를 레디스로 캐싱하고, 일정 주기에 따라 DB를 업데이트하는 방법을 사용할 수 있습니다. (물론 스케줄러 코드가 같이 병행되어야 합니다.)

 

그리고 레디스의 대표적인 사용처는 역시 사용자의 세션 관리입니다. 사용자의 세션을 유지하고, 불러오고, 여러 활동들을 추적하는 데에 레디스는 매우 효과적인 성능을 보여줄 수 있습니다. 또한 메시지 큐잉에도 사용할 수 있습니다.

 

그 밖에도 API 캐싱에 활용하여 라우터로 들어오는 요청에 대하여 요청 값을 캐싱하여 동일 요청에 대한 캐싱 데이터를 리턴하는 방식으로도 활용할 수 있습니다.

 

API 캐싱  방법 참고  링크:

redis 캐시 활용해서 express API 속도 높이기

 

활용 방법

우리가 MySQL을 사용할 때 보통 워크벤치를 설치하듯이, 레디스는 레디스 데이터베이스를 설치하여 사용해야 합니다. 이렇게 레디스를 활용할 수 있는 방법은 아래 두 가지 정도로 요약할 수 있습니다.

 

1. 서버 컴퓨터에 직접 설치하여 레디스를 사용할 수 있습니다. 예를 들어, AWS EC2에서 서버가 실행되고 있다면, 그 EC2에 레디스를 설치하여 EC2의 메모리를 레디스로 활용하면 됩니다. 이는 EC2 인스턴스의 메모리 성능에 의존적이기 때문에, 인스턴스의 메모리가 여유있다면 좋은 선택일 수 있지만, 만약 비루한 EC2에 레디스를 조합하여 사용한다면 좋지 않을 수 있겠네요.

 

2. 클라우스 서비스를 사용하여 레디스를 사용할 수 있습니다. 레디스 랩(https://redis.com) 등의 서드파티 서비스를 활용하거나, aws에서 제공하는 elastic cache를 대표적인 선택지로 볼 수 있습니다. 이는 협업할 때 편리하게 사용할 수 있어 대개의 경우 이러한 방식을 많이 적용하게 되는 것 같습니다. redisblabs는 1개의 레디스 DB를 30MB 무료로 제공해주고, aws elastic cache는 유료이므로 트레이드오프를 고려하여 선택하면 됩니다.

레디스랩 활용 방법에 대하여 자세히 다루고 있는 블로그 링크 : (인파님 추앙합니다.)

[Redislabs] 📚 Redis를 클라우드로 사용하자

 

레디스 스키마

RDB 구조에 뇌가 절여진 우리는 '스키마'라는 말에 테이블 형식부터 떠올리게 됩니다. 하지만 레디스는 key-value 형식의 데이터 스토리지이므로 스키마 형태가 우리가 익숙한 형태와 사뭇 다릅니다.

 

아래는 사용자의 이메일, 닉네임, 최근 로그인 시간을 레디스에 저장할 때 사용되는 스키마입니다.

• user:userId:email:문자열
• user:userId:nickname:문자열
• user:userId:lastLogin:문자열

위 구조는 직감적으로 알 수 있듯이, key:key:key:value 구조로 되어 있고 " : "를 활용하여 데이터에 접근하면서 사용합니다. 위 스키마를 활용하면 userId만 알고 있어도 그 유저의 email, nickname, lastLogin 정보를 알 수 있게 되는 겁니다.

 

위 구조를 봤을 때, key의 깊이가 너무 깊어지거나 넓어지면 성능에 영향이 있을까 하는 우려가 발생할 수 있는데, 많은 key-value 자료구조의 성능을 보면 알겠지만, 그 연산속도가 O(1)에 불과하여, 키가 아무리 많아봤자 인간이 느낄 수 있는 유의미한 차이를 보이지 않습니다. 즉, key의 깊이나 넓이는 성능을 고려하였을 때에는 크게 문제되지 않습니다.

 

유의사항

레디스는 개발자가 인위적으로 삭제하는 이벤트를 설정하지 않으면 키가 영원히 쌓이는 방식입니다. 이는 심지어 volatile하지 않아서 그 상태가 계속 유지됩니다. 따라서 인위적인 조치를 취해야 합니다.

 

1. 일괄 삭제 : FLUSHDB 명령어를 통해 모든 키를 삭제합니다. 복구 불능이기 때문에 일반적으로 개발 단계에서 활용합니다.

 

2. 일정 시간 이후 삭제 : 각각의 키를 저장할 때, Set에 저장하여 특정 시간이나 조건에 따라 삭제하는 방법입니다. set이 활용되므로 교집합, 차집합, 합집합 같은 기능을 제공합니다.

 

3. 기간 만료 후 삭제 : 가장 주로 사용되는 방법입니다. key를 추적할 필요 없이 SETEX(Set + expire) 커맨드를 이용하여 일정 시간이 지나면 key가 자동으로 삭제되도록 관리할 수 있습니다.

 

 

참고:

레디스(Redis)는 언제 어떻게 사용하는 게 좋을까