Gidhub BE Developer

Redis 개념과 특징

2018-10-28
goodGid
Redis

Redis란?

  • REmote DIctionary Server의 약자이다.

  • 대용량 처리 관련 기술이다.

Redis의 특징

  1. 오픈 소스 소프트웨어이다.

  2. 디스크가 아닌 메모리 기반의 데이터 저장소이다.
    (In-Memory data structure store)

  3. NoSQL & Cache 솔루션이며 메모리 기반으로 구성된다.

  4. 명시적으로 삭제, Expire를 설정하지 않으면 데이터는 삭제되지 않는다.
    (= 영구적 보존)

  5. 여러대의 서버 구성 가능하다.

  6. 데이터베이스로 사용될 수 있으며 Cache로도 사용될 수 있는 기술이다.

  7. 성능은 서버에 따라 다르나 초당 2만 ~ 10만회 수행한다.


  • 메모리 위에서 동작하는 Key/value 저장소(Store)인 Redis는

  • NoSQL DBMS로 분류되며

  • 동시에 Memcached와 같은

  • 인메모리(In-memory) 솔루션으로 분리된다.

인메모리 캐시(In-memory Cache)란?

  • 서비스 요청이 증가하여

  • DB요청이 많아지면

  • DB서버 부하가 증가하게 된다.

  • 이 때 메모리 캐시가 적용되면

  • 성능 및 처리 속도가 향상된다.

  • 즉 캐시 방식을 통해

  • DB Read의 부하를 감소시킬 수 있게 된다.


  • 성능은 Memcached이 갖고 있는 좋은점을 기반으로 만들어졌기 때문에

  • Memcached보다 우수하지만 더욱 복잡하다.

  • 그렇지만 다양한

  • 데이터 구조체를 지원한다.

  • (Message Queue, Shared memory, Remote Dictionary)


  • 그리고 안전한 데이터의 보관과 백업을 위해 두 가지 방법을 제공한다.

  1. 다른 서버의 메모리에 실시간으로 복사본을 저장하는 방법

  2. 디스크에 직접 저장하는 방법


  • NoSQL 중에서도 Redis가 주목을 받는 이유는 다음과 같다.

    • 데이터 저장소로 입력/출력이 가장 빠른 메모리를 채택

    • 단순한 구조의 데이터 모델인 Key-Value 방식을 통한 빠른 속도

    • 캐시 및 데이터 스토어에 유리

    • 다양한 API 지원


  • Redis는 대형 서비스 업체들이

  • (페이스북, 인스타그램, 네이버 LINE 서비스, StackOverflow, 블리자드 등)

  • 사용자들의 대규모 메세지를

  • 실시간으로 처리하기 위하여 사용하고 있다.

사용가능한 데이터형

  • 대표적으로 5가지의 데이터형 사용이 가능하다.

  1. String

  2. Lists

  3. Sets

  4. Sorted sets

  5. Hashs

Redis의 장점

  • 리스트, 배열과 같은 데이터를 처리하는데 유용하다.

    • value 값으로 여러 데이터 형식을 지원한다.

    • ( String, List, Set, Sorted set, Hash 등 )

    • 따라서 다양한 방식으로 데이터를 활용할 수 있다.

    • 리스트형 데이터 입력과 삭제는

    • MySQL에 비해서 10배 정도 빠르다고 한다.


  • 메모리를 활용하면서 영속적인 데이터 보존이 가능하다.

    • 명령어로 명시적으로 삭제(Expires)를 설정하지 않으면

    • 데이터가 삭제되지 않는다.

    • 디스크에 데이터를 기록하고 있기 때문에

    • Redis 메모리가 날라가도 데이터를 복구할 수 있다.

    • 스냅샷(기억장치) 기능을 제공하여

    • 메모리의 내용을 *.rdb 파일로 저장하여 해당 시점으로 복구 할 수 있다.

주의할 점 : *.rdb

  • 스냅샷을 남기는 확장자가 rdb이기 때문에

  • DB의 모든 기능 역시 지원되지 않을까 생각할 수 있다.

  • 하지만 단순히 이름만 rdb일 뿐

  • 메모리 내용을 저장하는 기능 이외는 아무것도 지원하지 않는다.

  • 이렇게 덤프한 내용은

  • 다시 메모리에 올려 사용할 수 있다.

  • (= 해당 시점으로 복구 할 수 있다.)


  • Redis Server는 1개의 싱글 쓰레드로 수행되며

  • 따라서 서버 하나에 여러개의 서버를 띄우는 것이 가능하다.

    • Master - Slave 형식으로 구성이 가능하다.

    • 데이터 분실 위험을 없애주는 것이 바로 위 Master - Slave 방식이다.

    • 위 기능을 이용하여

    • 실시간으로 데이터를 다른 서버에 복제한다.

    • Master Sserver가 Down 되어도

    • Slave Server로 접속하면 바로 서비스를 계속할 수 있다.


  • Memcached 보다 다양한 API를 지원한다.

    • 아래의 경우에는 Redis API가 Memcached API보다 유용하다.

    • 여러개의 캐시를 한번에 업데이트해야하는 경우

    • Redis에서는 mset 이라는 함수를 사용하면 된다.

    • 그런데 Memcached에서는 여러개의 캐시 데이터를 가져오는건 가능하지만

    • 여러개의 캐시 데이터를 업데이트하는 API는 지원하지 않는다.

    • 많은 양의 캐시를 업데이트를 해줘야하는 상황에서

    • Memcached를 사용하면

    • 업데이트 해야하는 데이터 양만큼 set API를 호출해야 한다.

    • 반면 Redis에서는

    • 데이터의 크기를 쪼개서 mset을 호출하면

    • Memcached로 동작할 때 보다 빠른 시간안에 작업할 수 있다.

Redis의 단점

  • 메모리 파편화가 발생하기 쉽다.

    • 메모리를 2배로 사용한다.

    • Redis는 싱글 쓰레드이다.

    • 그래서 스냅샷을 뜰 때

    • 자식 프로세스를 하나 만들낸 후

    • 새로 변경된 메모리 페이지를 복사해서 사용한다.

    • Redis는 copy-on-write 방식을 사용한다.

    • 보통 Redis를 사용할 때는 데이터 변경이 잦기 때문에

    • 실제 메모리 크기만큼 자식 프로세스가 복사하게 된다.

    • 그래서 실제로 필요한 메모리 양보다

    • 더 많은 메모리를 사용하게 된다.


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

    • 대규모 트래픽으로 인해 많은 데이터가 업데이트되면

    • Redis는 Memcached에 비해서 속도가 불안정하다.

    • 이것은 Redis와 Memcached의 메모리 할당 구조가 다르기 때문에 발생하는 현상이다.

    • Redis는 jemalloc을 사용하기 때문에

    • 매번 malloc과 free를 통해서 메모리 할당이 이루어진다.

    • 반면 Memcached는

    • slab 할당자를 이용하여

    • 내부적으로는 메모리 재할당을 하지 않고 관리하는 형태를 취한다.

    • 이로 인해서 Redis는

    • 메모리 파편화가 발생하며

    • 이 할당 비용 때문에 응답 속도가 느려진다.

    • 다만 이는 극단적으로 봤을 때 발생하는 일이다.

    • 대규모 서비스에서도 Redis를 많이 도입하는 것을 보면

    • 일반적으로 스타트업 등에서 사용하여도 무방하다 볼 수 있다.

CRUD에 따른 Redis 데이터 처리

  • Redis 서버는

  • Client에서 Read 요청이 들어올 때

  • 메인 서버로부터 값을 가져와 저장한다.

  • 이 때 메인 서버와 싱크된 데이터 이 외에

  • 추가로 데이터 만료 시점을 처리하기 위해서

  • 현재 시간이나 만료 시간을 함께 저장해야한다.

Read 요청시

  • Redis 서버에서

  • 사용자가 요청한 데이터가 있는지 확인한다.

  • 데이터가 존재하는 경우

  • 만료 여부 확인 후 이 정보를 반환한다.

  • 정보를 반환한 시간을

  • 현재로 업데이트 후 종료한다.

  • 데이터가 만료되었거나 없는 경우는

  • 삭제 후 메인 서버에 요청한다.

  • 메인 서버로 부터 받은 데이터를 캐싱 및 DB에 저장 후

  • 이 값을 방문자에게 반환 후 종료한다.

CUD 요청시

  • 이 경우 앞의 과정과는 조금 다르다.

  • 그 이유는 데이터에 변화가 생겼으므로

  • 해당하는 값의 데이터는

  • 캐싱 값이 아닌 현재 실시간 정보를 보내줘야한다.

  • 그러기 위해 필요한 조치는 비교적 간단하다.


  • 방문자의 CUD를 메인 서버에 요청을 한다.

  • 메인 서버는 요청받은 CUD 작업을 반영 및 업데이트한다.

  • 변경되기 전 데이터 값을 Redis에서 찾아 삭제 후 종료한다.


  • 여기서 가장 중요한 점은

  • 캐싱을 제공하는 경우

  • 단순하게 정보를 제공하는 부분만 고려하는 것이 아니라

  • 다양한 상황에 대처해야 한다는 점이다.

  • 예를 들어

  • CUD처럼 데이터에 중요한 변경 사항이 있는 경우

  • 기존의 캐싱 데이터를 삭제하는 과정을 들 수 있다.

Redis vs Memcached

  • Memcached와 관련해선 Memcached 개념과 특징 글을 읽고 오자.

  • 아주 단순하게 비교하자면

  • Memcached는 캐시 솔루션이다.

  • 이러한 Memcached에

  • 저장소의 개념이 추가된 것이

  • Redis라고 할 수 있다.


  • 캐시는 빠른 속도를 위해서 어떤 결과를 저장해 두는 것을 의미하며

  • 또한 데이터가 사라지면 다시 만들 수 있다는 전제를 내포하고 있다.

  • 캐시 기능만을 고려한다면

  • 디스크에서 불러오기만 하면 된다.

  • (= Load 기능만 수행되면 된다.)

  • 그런데 저장소라는 개념이 추가되면

  • 데이터가 유지되어야 한다는 특성을 가지게 된다.

  • (= Save기능도 필요하다.)

정리

  • 메모리가 날라가도

  • 원본 데이터로 즉시 복구할 수 있는 데이터는

  • Memcached를 사용하는 편이 좋을 수 있다.


  • 메모리가 날아가면

  • 서비스 장애가 발생 할 수 있는 상황이라면

  • Redis를 사용하는 편이 좋을 수 있다.


  • 통신 속도를 향상 시키기 위한 목적이면

  • Memcached를 사용하는게 좋다.

  • 그러나 서비스의 특정 기능을 위한 목적으로

  • 캐시 데이터를 사용한다면

  • Redis를 사용하는게 좋다.

Reference

Index