Redis (REmote DIctionary Server)

 

Redis란

  • 대용량 처리 관련 기술

  • 메모리 기반 데이터 저장소 : 입출력이 빠르다는 장점이 있다

    • NoSQL DB로 분류되기도 하고 memcached와 같은 인메모리(in-memory) 솔루션으로 분류되기도 한다 (DB로도 사용될 수 있고 Cache로도 사용될 수 있다)
      • in-memory cache
        캐시 방식을 통해 DB Read 부하 감소 가능
    • Expire 명시하지 않는 한 데이터 영구 보존
    • key/value 저장소(store) : 단순한 구조의 데이터모델을 통한 빠른 속도

  • 다양한 API지원

    • 여러개의 캐시를 한 번에 업데이트 해야하는 경우 데이터릐 크기를 쪼개서 mset함수를 호출하면 Memcached로 동작할 때 보다 빠른 시간안에 작업할 수 있다 (Memcached는 여러개의 캐시 데이터를 가져오는건 가능해도 업데이트하는 API는 제공하지 않는다. > 업데이트 데이터 양만큼 set API를 호출해야한다)

  • 여러대 구성 가능

  • 초당 2만 ~ 10만회 수행 (서버에 따라 다름)

    • memcached보다 우수하지만 더욱 복잡하다.
    • 다양한 데이터 구조체를 지원한다.
      • ex. message queue, shared memory, remote dictionary

  • 데이터 보관과 백업은 두 가지 방식이 있다.

    1. 다른 서버의 메모리에 실시간으로 복사본을 저장
    2. 디스크에 직접 저장
    • 디스크에 데이터를 기록하기 때문에 Redis메모리가 날라가도 데이터를 복구할 수 있다
    • 스냅샷(기억장치) 기능을 제공하여 메모리의 내용을 *.rdb파일로 저장해 해당 시점으로 복구할 수 있다 (rdb로 덤프된 내용을 다시 메모리에 올려 사용할 수 있다.)
    • 메모리 내용을 저장하는 기능 이외에는 아무것도 지원하지 않는다

  • 대형 서비스 업체들이 사용자들의 대규모 메시지를 실시간으로 처리하기 위해 사용한다.

  • redis server는 1개의 싱글 쓰레드로 수행

    • 따라서 서버 하나에 여러개의 서버를 띄우는 것이 가능하다
    • Master - Slave형식으로 구성 가능 (실시간으로 데이터를 다른 서버에 복제하여 분실 위험을 줄여준다)
    • Master Server가 다운되어도 Slave Server로 접속하여 서비스를 지속할 수 있다

 

지원되는 데이터형

  1. String
  2. Lists
  3. Sets
  4. Sorted sets
  5. Hashs

 

단점

  • 메모리 파편화 발생 가능성

    • 메모리를 2배로 사용한다. 싱글 쓰레드기 때문에 스냅샷을 뜰 때 자식 프로세스를 하나 만들어낸 후 새로 변경된 메모리 페이지를 복사해서 사용한다.
    • copy-on-write방식을 사용한다. 데이터 변경이 잦기 떄문에 실제 메모리 크기만큼 자식 프로세스를 복사하게 된다.
    • 그래서 더 많은 메모리를 사용하게 되는 것이다

  • 대규모 데이터에 대한 응답 속도의 불안정성

    • 대규모 트래픽으로 인해 많은 데이터가 업데이트되면 memcached에 비해 속도가 불안정하다.
    • Redis :
      • jemalloc 사용
      • malloc과 free를 통해 메모리 할당이 이루어진다
      • 할당 비용 때문에 응답속도가 느려진다 (but 극단적인 케이스이다)
    • memcached :
      • slab할당자를 이용
      • 내부적으로는 메모리 재할당을 하지 않고 관리하는 형태

 

 

Redis 데이터 처리

client에서 read요청이 들어온 경우 메인 서버로부터 값을 가져와 저장한다. 이 떄 메인 서버와 싱크된 데이터 외 추가로 데이터 만료 시점을 처리하기 위해서 현재시간이나 만료시간을 함께 저장해야한다. 상황에 따라 기존 캐싱 데이터를 삭제하는 과정이 요구된다.

  • READ (R)

    • redis서버에서 사용자가 요청한 데이터 유무 확인
    • 존재하는 경우
      • 만료 여부 확인 후 해당 정보 반환
      • 정보 반환한 시간을 현재로 업데이트 후 종료
    • 없거나 데이터가 만료된 경우
      • 삭제 후 메인 서버에 요청
      • 메인 서버로부터 받은 데이터를 캐싱 및 DB에 저장
      • 해당 값을 사용자에게 반환 후 종료

  • CREATE, UPDATE, DELETE (CUD)

    • 데이터에 변화가 생기기 때문에 해당 값의 데이터는 캐싱 값이 아닌 현재 실시간 정보를 보내줘야 한다.
    • 사용자의 CUD를 메인 서버에 요청
    • 메인서버에서 요청받은 CUD 작업 반영 및 업데이트
    • 변경 전 데이터값을 Redis에서 찾아 삭제 후 종료

 

 

  • memcached를 활용하는 경우

    • 메모리가 날라가도 원본데이터로 즉시 복구 할 수 있는 경우
    • 통신 속도를 향상 시키기 위한 목적

  • redis를 활용하는 경우

    • 메모리가 날아갔을 시 서비스 장애가 발생할 수 있는 상황
    • 서비스의 특정 기능을 위한 목적으로 캐시 데이터를 사용하는 경우

 

 

reference