레디스는 왜 쓰고 어디에 써야 하는 걸까? - 레디스를 사용하는 이유와 활용 사례

레디스를 쓰면 좋다, 빠르다 하는 말을 수없이 들었지만 어떤 점 때문에 그런건지나 어떤 식으로 활용되는지는 알지 못했다. 왜 쓰는지는 알아두고 시용하기 위해 레디스의 이점과 활용 사례를 알아보았다.

레디스의 특징

레디스는 키-값 저장소 방식의 No-SQL 데이터베이스이다. 즉 쿼리를 사용하지 않고, 키를 기반으로 데이터를 가져온다.

  • MySQL에서 데이터를 저장 : INSERT INTO users (id, name) VALUES (1, 'Alice');
  • Redis에서 데이터를 저장 : SET key valueSET user:1 “Alice”
  • MySQL에서 데이터를 조회 : SELECT name FROM users WHERE id = 1;
  • Redis에서 데이터를 조회 : GET keyGET user:1

레디스의 이점

  • 레디스는 RDBMS에 비해 속도가 빠르다 데이터를 메모리(RAM)에 저장해서 조회 속도가 매우 빠르다. RDBMS는 디스크를 주로 사용하기 때문에 레디스만큼 빠르지 않다.
  • 레디스는 기본 키-값 외에도 다양한 데이터 구조를 지원한다.
    • String: 기본적인 텍스트나 숫자 값을 저장.예: SET key "value"
    • Hash: 필드와 값을 가진 데이터.예: HSET user:1 name "Alice" age 25
    • List: 순서가 있는 리스트.예: LPUSH tasks "task1"
    • Set: 중복 없는 집합.예: SADD tags "tag1"
    • Sorted Set: 순위와 값을 가진 집합.예: ZADD scores 100 "Alice"
  • 캐시로 사용하기 좋다 데이터가 메모리에 올라가 있기 때문에 캐시로 사용하기 좋다. 자주 조회되는 데이터를 캐싱해두면 RDBMS에서 데이터를 매번 읽어오는 비용을 줄일 수 있다.
  • 만료 시간을 설정할 수 있다

    데이터에 만료 시간을 설정할 수 있다. 예: SETEX session:1234 3600 "data" → 3600초(1시간) 후 자동 삭제.

  • 분산 시스템에 유리하다

    분산 환경에서 쉽게 확장이 가능해서, 대규모 트래픽을 처리할 때 유용하다. (이 부분은 아직 실제로 경험해보지 못해서 추후 프로젝트에 적용하며 확인해야 할 것 같다. ) 레

레디스 활용 사례

빠르고, 캐싱 처리도 가능해서 좋다는 건 알겠는데 주로 언제 사용하면 될 지 와닿지 않아서 활용 사례(출처 : https://meetup.nhncloud.com/posts/225 )를 찾아보았다.

  • 사례 1 : 좋아요 처리하기 RDBMS에서 특정 게시물의 댓글에 사용자가 좋아요 처리를 하거나, 취소하게 구현한다고 생각해보자. 구현을 할 수는 있지만 insert와 update가 매우 빈번하게 발생하므로 규모가 큰 SNS라면 성능 저하가 발생할 수 있다. 이 때 레디스의 Set을 이용하면 간단하고 빠르게 처리가 가능하다. ⇒ Key : 댓글의 번호, Value : 좋아요를 누른 회원 ID
  • 사례 2 : 일일 방문자 수 구하기 사용자가 서비스에 방문할 때, 사용자 ID에 해당하는 bit를 1로 설정한다. 1개의 bit가 1명을 의미하므로 천만 명의 유저는 천만 개의 bit로 표현 할 수 있고, 이는 곧 1.2MB 정도의 크기이다(레디스 string의 최대 길이는 512MB. 레디스 4.0.7 이후로는 최대 크기를 변경 할 수 있게 되었다). 즉, 천만 명의 회원이 있는 서비스라면 비트 천만개를 준비해놓고 각각의 회원이 방문할 때 비트를 0→1로 변경한 후, 이 문자열에서 1로 설정된 bit의 개수를 구하는 BitCount 연산을 하면 간단하게 방문자 수를 구할 수 있다.
  • 사례 3 : 최근 검색한 키워드 5개 보여주기 이런 기능이 있다면, RDBMS에서는 이런 식으로 쿼리를 날려야 한다.

    1
      select * from KEYWORD where ID = 123 order by reg_date desc limit 5;
    

    그리고 사용자 별로 저장된 데이터 개수를 확인하고, 중복된 데이터는 제거하고, 오래된 검색어는 삭제하고… 같은 부수적인 작업들이 필요하다. 이 때, 애초에 중복을 허용하지 않고 자동으로 정렬 되는 레디스의 sorted set을 사용하면 간단하게 구현할 수 있다.

  • 사례 4 : Twitter 타임라인에서 레디스를 활용한 방식

2012년 트위터는 15만명 이상의 실시간 사용자와, 초당 30만건 이상의 타임라인 조회가 발생했다고 한다. 이 규모의 타임라인 요청을 DB에서 직접 처리하면 속도가 현저히 떨어진다. Twitter에서는 Redis Cluster를 통해 각 사용자의 타임라인에 노출될 트윗의 정보(Tweet ID, 작성자 ID)를 List 형태로 약 800개 정도 캐싱했다. 새로 발생한 타임라인 요청은 DB에 바로 접근하지 않고, Redis에 캐싱되어 있는 타임라인 정보를 먼저 가져와서 이를 토대로 DB에 접근하여 처리했다고 한다.

기존방식vs레디스

1
단, 모든 사용자의 타임라인을 캐싱하면 메모리가 부족해 질 수 있으므로, 로그인을 안 한 지 30일이 지난 사용자의 타임라인은 Redis Cluster에서 삭제한다. 해당 사용자가 다시 로그인을 하면 Redis Cluster에 사용자의 타임라인 정보가 재생성된다.