Redis
Redis란?
메모리에 저장하는 Key-Value 기반의 NoSQL DBMS
Redis 는 Remote Dictionary Server의 약자로 "key-value" 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 데이터베이스 관리 시스템 입니다.
Redis는 데이터베이스, 캐시, 메세지 브로커로 사용되며 인메모리 데이터 구조를 가진 저장소입니다.
Redis는 왜 사용할까?
데이터 베이스가 있는데도 Redis라는 인메모리 데이터 구조 저장소를 사용하는 이유는 무엇일까요?
데이터 베이스는 물리적 디스크에 데이터를 저장하기 때문에 서버가 꺼지더라도 데이터를 보존할 수 있습니다. 그러나 매번 디스크에 접근해야 하기 때문에 사용자가 많아진다면 그만큼 부하도 많아져 부담이 될 수밖에 없습니다. 사용자가 적은 서비스의 경우 크게 영향이 없겠지만, 사용자가 많아질수록 데이터베이스에 가해지는 부담이 많아져 이를 해소하기 위해 캐시 서버를 사용하게 됩니다. 이 때 캐시서버로 사용할 수 있는것이 Redis 입니다.
캐시는 임의의 공간에 데이터를 저장해두고 이후에 같은 데이터를 여러번 조회할 때마다 DB를 거치지 않고 해당 공간에 저장된 데이터를 바로 건내줌으로써 DB에 부하를 줄여주고 DB에 접근하는데 소요되는 시간도 줄여줍니다.
Redis의 특징
- key-value - 형식이기에 쿼리문이 따로 필요 없다.
- In-Memory - 모든 데이터를 디스크가 아닌 Ram에 저장(백업/ 스냅샷 제외)하기때문에 속도가 빠르다.
- DataStructure - 다양한 자료구조를 제공하여 개발의 편의성을 높여줌.
- Single Threaded - 단일 thread에서 모든 task를 처리하기 때문에 Race Condition이 거의 발생하지 않는다.
- Race Condition이란 두개의 프로세스가 하나의 데이터에 접근하려고 서로 경쟁하는 상태
- Persistence - 레디스는 메모리 저장소라 당연히 메모리가 유실될 것이라고 알고있지만, Redis는 RDB, AOF 등의 영속화 기능을 지원해 복구가 가능하도록 도와줍니다.
RDB (Redis Database Backup)
- 특정한 간격으로 현재 Redis에 저장된 데이터의 스냅샷을 남기는 방식
장점
압축하여 저장하기 때문에 AOF보다 크기가 작고, 데이터 자체를 저장하기 때문에 로딩, 복구 속도가 빠름
단점
특정한 간격을 두고 스냅샷을 남기기 때문에 백업 중 서버가 다운된다면 그 사이에 저장된 데이터는 유실될 가능성이 있음
AOF (Append Only File)
입력/수정/삭제 명령이 실행될 때 마다 Log파일에 기록하는 방식
장점
저장속도가 빠르고, 명령마다 바로바로 저장하기 때문에 중간에 서버가 장애가 발생하더라도 데이터 유실이 거의 일어나지 않음
단점
명령의 실행을 모두 기록하기 때문에 파일의 크기가 큼,
기록을 로그로 남기고, 데이터를 직접 저장한게 아니기에 데이터 복원 속도도 그만큼 느림
Redis 사용시 주의할 점
- 디스크의 내용이 변경될 경우 Redis와 데이터가 불일치 할 수 있습니다.
- 서버에 장애가 발생했을 경우 그에 대한 운영 플랜이 꼭 필요합니다.
- 인메모리 데이터 저장소의 특성상, 서버에 장애가 발생했을 경우 데이터 유실이 발생할 수 있기 때문입니다.
- 메모리 관리가 중요합니다.
- 메모리 내/외부 단편화에 의해 실제 가용가능한 메모리가 다를 수 있어, 사용중인 메모리의 모니터링이 필요합니다.
- O(N) 명령어 주의 (Keys,FlushAll,FlushDB)
- 싱글 스레드의 특성상, 한 번에 하나의 명령만 처리할 수 있습니다. 처리하는데 시간이 오래 걸리는 요청, 명령은 피해야 합니다.
캐시 서버의 패턴
캐시 서버는 여러가지 읽기, 쓰기 패턴이 존재합니다. Redis를 캐시용으로 사용하게 된다면 어떠한 방식으로 사용할지 고려해서 사용해야 합니다.
읽기 패턴
Look aside cache
데이터를 요청하기전에 캐시서버에 존재하는지 체크하는 패턴
1. 클라이언트가 데이터를 요청
2. 웹서버는 데이터가 존재하는지 Cache 서버에 먼저 확인
3. Cache 서버에 데이터가 있으면 DB에 데이터를 조회하지 않고 Cache 서버에 있는 결과값을 클라이언트에게 바로 반환 (Cache Hit)
4. Cache 서버에 데이터가 없으면 DB에 데이터를 조회하여 Cache 서버에 저장하고 결과값을 클라이언트에게 반환 (Cache Miss)
❗️ 이 패턴의 문제점은 DB의 데이터가 변경된다면 캐시 서버와 데이터 불일치 문제가 발생할 수 있습니다.
Read Through
데이터의 요청을 레디스가 대신 해주는 패턴
1. 클라이언트가 데이터를 요청
2. 웹서버는 데이터가 존재하는지 Cache 서버에 먼저 확인
3. Cache 서버에 데이터가 있으면 DB에 데이터를 조회하지 않고 Cache 서버에 있는 결과값을 클라이언트에게 바로 반환 (Cache Hit)
4. Cache 서버에 데이터가 없으면 Cache 서버에서 DB로부터 데이터를 조회하여 Cache 서버에 저장하고 결과 값을 클라이언트에게 반환(Cache Miss)
❗️ 이 패턴은 캐시와 DB사이 데이터의 정합성은 보장되지만, 문제점은 Cache서버에 장애가 발생한다면 어플리케이션 전체에 문제가 발생할 것입니다.
쓰기 패턴
Write Arround
1. 웹서버는 Cahce서버를 거치지 않고 DB에 바로 데이터를 저장
❗️ 이 패턴은 Cache서버를 거치지 않고 DB에 바로 쓰기 때문에 성능상으로는 이점이 매우 큽니다. 그러나 문제점은 DB와 Cache사이의 접점이 없어 데이터의 정합성을 유지하기가 어렵습니다.
Write Back
JPA에서 쓰기지연 저장소에 쿼리를 모아뒀다가 한번에 쿼리를 날리는 것과 같이 Cache서버에 데이터를 모아뒀다가(마치 버퍼처럼) 일정 시간마다 한번에 DB에 쓰기 요청을 보내는 패턴
1. 웹서버는 모든 데이터를 Cache 서버에 저장
2. Cache 서버에 특정 시간 동안 데이터가 저장됨
3. Cache 서버에 있는 데이터를 DB에 저장
4. DB에 저장된 Cache 서버의 데이터를 삭제
❗️ 이 패턴은 데이터가 많을 경우 insert문을 하나하나 날리지 않아도 된다는 장점이 있지만, 데이터가 아직 DB로 요청을 보내지 않았는데 Cache서버에 장애가 생기면 데이터가 유실될 수 있다는 단점이 있습니다.
Write Through
쓰기 작업을 캐시를 거쳐 DB에 저장하는 패턴
1. 웹서버는 데이터를 Cache 서버에 저장
2. Cache 서버에서 저장된 데이터를 DB에 저장
❗️ 이 패턴은 캐시를 항상 거치기 때문에 데이터의 정합성을 보장받지만, 문제점은 쓰기를 두번씩 진행해야해서 성능을 고려해서 도입하는것이 좋습니다.
캐시 사용시 주의할 점
- 자주 사용되면서 변경이 일어나지 않는 데이터에 사용
- 유실되어도 크게 상관없는 데이터에 사용
- 캐시 특성상 메모리에 저장되기 때문에 메모리가 죽어버린다면 데이터가 유실되는 문제가 존재합니다.
- DB와 함께 사용할때 DB와의 데이터 정합성 문제를 잘 고려해서 사용
