Redis
Remote Dictionary Server.
— 살바토레 산필리포(Salvatore Sanfilippo)가 개발한 인메모리 데이터 구조 저장소.
메모리 위에서 빛의 속도로 쿼리를 처리하는 캐시계의 절대 존엄. 그러나 메모리 관리 잘못해서 OOM(Out of Memory) 터지면 캐시와 함께 서버 멘탈도 같이 휘발됨
1. 개요
Redis(Remote Dictionary Server)는 메모리 기반의 데이터 스트럭처 저장소로, 데이터베이스, 캐시, 메시지 브로커 등으로 광범위하게 사용된다.
디스크가 아닌 RAM(메모리)에 데이터를 직접 쓰기 때문에, 디스크 I/O 병목이 없어 그야말로 눈이 번쩍 뜨이는 속도를 보여준다. 대형 포털 사이트의 실시간 검색어 순위, 대규모 수강신청 대기열, 로그인 세션 보관소 등 "속도가 생명인 곳"에는 어김없이 이 Redis가 버티고 서 있다.
2. 핵심 특징
2.1. 인메모리 (In-memory) 기반의 압도적 속도
평균적으로 읽기 및 쓰기 성능이 1ms 이하로 떨어진다. 일반적인 관계형 데이터베이스가 아무리 빨라야 수십 ms인 것과 대조된다.
2.2. 다양한 자료구조 지원
단순히 Key-Value 문자열만 저장하는 게 아니라 List, Set, Sorted Set, Hash, Bitmaps 등 개발자가 입맛대로 골라 쓸 수 있는 호화로운 자료구조 세트를 제공한다.
2.3. 싱글 스레드 (Single Thread) 아키텍처
레디스는 한 번에 딱 하나의 명령만 순차적으로 처리한다. 복잡한 멀티스레드 락(Lock) 걱정 없이 동시성 이슈를 깔끔하게 피해 가지만, 시간이 아주 오래 걸리는 명령어 하나가 들어오면 그 뒤의 모든 요청이 대기 줄에 묶여 서버가 마비되는 치명적인 단점이 있다.1
3. 관련 밈 및 드립
3.1. Redis가 죽었어요 (로그인 풀림 & DB 폭발 콤보)
속도가 빠른 레디스에 의존해 모든 캐시와 임시 데이터를 몰아주었다가 레디스가 뻗어버릴 때 일어나는 대재앙이다. 캐시가 사라지자마자 모든 사용자의 요청이 원본 RDBMS로 한꺼번에 몰려가게 된다(Cache Stampede 현상). 결국 RDBMS까지 연쇄적으로 뻗어버리며 사이트 전체가 오프라인이 되는 마법을 목격할 수 있다.2
3.2. Keys * 명령어로 실서버 터뜨리기
싱글 스레드인 Redis의 특성을 잊고 실서버 터미널에서 전체 키 목록을 조회하는 쿼리를 날릴 때 일어나는 참사다.
keys *3 데이터가 수천만 개 쌓인 실서버에서 이 명령어를 치는 순간, 레디스는 모든 키를 찾기 위해 연산을 독점하게 되고 그 시간 동안 모든 사용자의 로그인과 조회 요청이 멈춘다. 결국 타임아웃 에러가 뿜어지며 서버가 터지게 된다. (실무에서는SCAN명령어를 써야 한다)
4. 여담
- 메모리 폭탄 OOM의 대참사: 레디스는 RAM을 사용하기 때문에 용량 대비 비용이 엄청나게 비싸다. 아무 생각 없이 데이터를 무제한으로 쌓다 보면 어느 순간 메모리가 가득 차서
Out of Memory에러를 뱉으며 장렬히 전사한다. 반드시 데이터 만료 시간(TTL)을 명시해 주어야 안전하다. - 휘발 방지를 위한 RDB와 AOF: 인메모리 DB의 한계(서버가 꺼지면 데이터 유실)를 방지하기 위해 스냅샷을 남기는 RDB(Redis Database) 방식과, 모든 쓰기 명령을 로그 파일로 기록하는 AOF(Append Only File) 방식을 지원한다.
물론 이거 세팅 잘못하면 저장하는 속도 때문에 캐시 성능이 나락으로 간다. - 2024 라이선스 변경 사태: 2024년 3월, Redis는 기존 BSD 오픈소스 라이선스에서 클라우드 기업들이 무단으로 서비스화하는 것을 막기 위해 상용 성격의 라이선스로 변경을 선언했다. 이로 인해 리눅스 재단 등을 중심으로 오픈소스 포크 버전인 Valkey가 만들어져 치열한 경쟁을 벌이고 있다.