06/07

사실 Redis 는 분류를 DB 로 해야 하나 말아야 하나.. 좀 애매하다고 생각했는데, 의외로 데이터베이스라고 불러도 정확한 표현이라고. 공식 홈페이지에서도 스스로를 데이터 구조 스토어 이자 데이터베이스로 정의하고 있다.
Redis 란
Remote Dictionary Server 의 약자로, 디스크가 아닌 메모리에 데이터를 저장하여 고속으로 읽고 쓸 수 있는, 인메모리 기반의 비관계형(NoSQL) Key-Value 데이터 구조 스토어이다.
주요 사용처는,
- 원본 DB의 부하를 줄이기 위해 자주 조회되는 읽기 데이터를 캐싱하는 용도.
- 웹 서비스 로그인 유저의 세션 상태를 빠르게 공유하고 관리.
- 실시간 순위나 점수를 자동으로 정렬하고 계산.
- 애플리케이션 간에 이벤트를 발행/구독하거나 리스트를 통해 메시지 중계.
처럼 실시간 조회/수정/상호작용이 필요한 곳에 많이 쓰인다.
특징
디스크가 아니라 RAM을 사용하는 것에서부터 유추할 수 있지만, 1ms 미만의 빠른 응답속도를 보장한다.
단순한 String 외에도, List, Set, Sorted Set, Hash, Bitmaps, JSON 등 데이터 타입을 기본 지원한다.
싱글 스레드에서 이벤트 루프 방식을 사용하여 순차적으로 명령어를 처리해, race condition 을 방지하고 Atomicity 를 보장한다.
RAM 의 단점인 휘발성을 극복했는데, 데이터를 주기적으로 디스크에 저장(RDB) 하거나, 로그로 기록(AOF) 하여 서버가 꺼져도 데이터를 복구할 수 있다.
RDB (Redis Database Snapshot)
특정 시점의 메모리 데이터 전체를 그대로 복사해서, 하나의 압축 파일(.rdb) 로 저장하는 스냅샷 방식. 파일 크기가 작아서 서버가 다운되었을 때 복구가 빠르고, 복제 서버를 만들기도 편하지만..
백업 주기 사이에 꺼지면 마지막 백업 이후의 데이터는 모두 유실된다.
AOF (Append Only File)
데이터 변경(쓰기, 수정, 삭제) 명령이 들어올 때 마다, 그 명령어 실행 로그를 텍스트 파일(.aof) 에 순차적으로 기록하는 방식. 거의 실시간으로 디스크에 기록하므로 데이터 유실이 거의 없으나..
파일 크기가 RDB에 비해 매우 커지고, 재시작 시 로그를 처음부터 끝까지 다시 실행해서 데이터를 복구하기 때문에 복구 시간이 오래 걸린다.
보통은 안정성을 극대화하기 위해 RDB와 AOF를 동시에 사용하는 것이 권장된다고.
데이터는 평소에 AOF로 꼼꼼하게 기록해 두어 유실을 방지하고, 서버를 재시작할 때는 속도가 빠른 RDB 파일로 뼈대를 먼저 올린 뒤 나머지 빈틈을 AOF 로그로 채워 넣는 방식으로 하이브리드하게 운영하는 식.
단순히 캐시용 데이터라 유실되어도 전혀 상관없다면, 두 기능을 모두 끄고 순수 인메모리로만 사용해도 된다고 한다.
DB 와 비교
MySQL 이나 Oracle 같은 전통적인 관계형 데이터베이스(RDBMS) 와는 작동 방식과 목적이 많이 다르긴 하지만..
공통점
- 데이터 저장 및 관리 : 데이터를 구조화하여 저장하고, 필요할 때 고유한 Key 를 통해 언제든 조회, 수정, 삭제할 수 있다.
- 데이터 영속성 : 메모리에만 상주하는 캐시와는 달리, 위에서 알아본 RDB, AOF 가 있어 데이터를 복구할 수 있다.
차이점
- 디스크(SSD/HDD) 에 데이터를 저장하는 DB 와 달리, Redis 는 RAM 에 저장하기 때문에 속도가 비교가 안 될 정도로 빠르다.
- 관계형 DB 는 Table 형태로 데이터가 얽혀 있는데, Redis 는 Key-Value 형태로 데이터를 단순하게 저장하는 NoSQL DB.
- 그렇기 때문에 일반DB 처럼 복잡한 쿼리를 통한 정밀한 검색은 어렵다. 오직 Key 기반으로 빠르게 데이터를 가져오는 데 특화됨.
그래서 보통은,
메인 DB 앞에 Redis 를 두고, 자주 조회되는 데이터는 Redis 에 임시로 넣어서 빠르게 보여주고, 중요하고 복잡한 전체 데이터는 메인 DB에 안전하게 보관하는, 상호보완적인 형태로 가장 많이 사용한다고.
데이터 유실 리스크가 적고, 실시간 연산이 중요한 일부 서비스에서는 Redis 하나만으로도 메인DB로 써도 된다고 한다.
한계와 극복 방법
기본적으로 Redis 를 구성하면, Standalone 으로 구성하게 될 것이다. 하지만, Cluster 모드 라는 것을 지원하는데..
Standalone 모드
레디스 서버 1대(마스터) 만 띄워놓고, 모든 읽기/쓰기 요청을 처리하는 가장 단순한 구조.
- Redis 는 인메모리 DB이므로, 데이터 전체 크기가 해당 서버 1대의 RAM 용량을 넘을 수 없다. 서버 RAM이 16GB 라면, 데이터도 최대 16GB 미만만 저장 가능하다는 의미. 용량에 한계가 있다.
- 서버가 설치된 컴퓨터가 고장 나거나 다운되면, 서비스 전체가 마비된다.
- 데이터 양이 많지 않은 소규모 프로젝트, 로컬 개발 환경, 테스트 환경에 적합
- 장애 취약성을 보완하기 위해, Replica 서버를 두고 자동 전환해주는 Sentinel 모드를 함께 쓸 수 있지만.. 데이터 용량 한계는 극복하지 못한다.
Cluster 모드
여러 대의 Redis 서버를 연결하여, 하나의 거대한 데이터 저장소를 만드는 방식. 데이터를 16,384개의 Hash slot 으로 쪼개어, 여러 서버에 Sharding(나누어 저장) 한다.
- 데이터가 늘어나면 서버를 추가하기만 하면 된다. 16GB 서버 3대를 묶으면 이론상 약 48GB 의 데이터를 저장할 수 있는 식.
- cluster 를 구성할 때, 각 master 서버마다 Replica 서버를 한 대씩 붙여 놓는다. 특정 master 서버가 다운되면, 그 서버의 replica 가 자동으로 승격되어, 서비스 중단 없이 유지할 수 있다.
- 읽기와 쓰기 트래픽이 여러 서버로 분산되므로, 대규모 트래픽 처리에도 유리
- 대용량 트래픽이 몰리는 큰 서비스, 게임 등 대규모 프로덕션 환경에서는 필수적
하지만 당연하게도, 설정 및 관리가 복잡하며... 제일 중요한 비용 문제가 있다