들어가며
안녕하세요
Redis를 공부하고 있는 프로미입니다!
- Redis는 왜 빠른가?
- Redis를 메인 데이터베이스로 사용할 수는 없을까?
궁금증을 가지고 생각을 정리해 보았어요!
저와 비슷한 궁금증을 가졌던 분들에게 도움이 되길 바랍니다.
1. Redis란?
For developers, who are building real-time data-driven applications, Redis is the preferred, fastest, and most feature-rich cache, data structure server, and document and vector query engine. - redis github
Redis는 ‘매우 빠른 인메모리 데이터 저장소’이다.
Redis 하면 ‘빠르다’는 특징이 가장 먼저 생각난다.
하지만 싱글스레드라는 이야기를 들었을 때,
CPU 연산이 많아지면 느려지는 거 아닌가? 하는 생각이 가장 먼저 들었다.
(feat. Node로 치여온 인생)
Redis는 이러한 단점을 감수하는 대신, 다양한 전략을 통해 성능을 극대화했다.
이글에서는 여러 전략 중 중요하다고 생각한 전략들을 살펴보려고 한다.
2. Redis 가 빠른 이유
싱글스레드, I/O 멀티플렉싱, 메모리 기반 처리, 최적화된 자료구조, 파이프라이닝
싱글스레드 기반 설계
락 관리와 스케줄링 오버헤드를 줄인다
Redis는 전략적으로 싱글스레드 방식을 선택했다
1. 락을 관리하지 않아도 된다
Redis는 하나의 이벤트 루프에서 명령을 순차적으로 처리한다.
멀티스레드 환경이 아니기 때문에 필수적인 락 관리가 필요 없고,
락으로 인한 성능 오버헤드를 근본적으로 제거할 수 있다.
2. 컨텍스트 스위칭 비용을 줄일 수 있다
멀티스레드 환경에서는 스레드 전환 비용이 발생한다.
Redis는 단일 스레드에서 명령을 처리함으로써 스케줄링 비용을 최소화한다.
3. 짧고 단순한 명령어 설계
Redis의 대부분의 명령은 자료구조를 빠르게 조작하도록 설계되어 있다.
참고로 명령 실행은 싱글 스레드지만, 일부 I/O 처리는 멀티 스레드다.
Redis 6부터는 선택적으로 네트워크 I/O를 별도의 I/O 스레드에서 처리할 수 있다.
(데이터 접근과 명령 실행의 단일 스레드 특성은 유지된다.)
I/O 멀티플렉싱 적용
논블로킹 방식으로 다수의 연결을 처리한다
Redis는 I/O 멀티플렉싱을 활용해 하나의 이벤트 루프에서 여러 클라이언트 소켓을 동시에 감시한다.
공정함보다 빠른 처리를 중요시하기 때문에 먼저 ready 상태가 된 소켓부터 처리한다.
(먼저 요청 온 소켓 X )
메모리(RAM) 기반 데이터 저장
디스크가 아닌 메모리에서 데이터를 읽는다
메모리에 접근해서 가져오는 것은 디스크에서 가져오는 것보다 빠르다.
메모리 계층 사진은 컴공과라면 지겹게 봤을 것이다.
register→cache→RAM→SSD→HDD 순으로 접근 속도가 느려진다.
Redis는 RAM에 데이터를 저장해서 빠르게 데이터를 가져온다.
최적화된 자료 구조
낮은 시간 복잡도를 제공하도록 설계되었다
Redis는 다양한 자료구조(String, List, Set, Hash, ZSet 등)를 제공한다.
그중 Redis의 List는 내부적으로 압축 구조(quicklist / listpack)를 활용해
빠르게 데이터를 삽입/삭제/조회하도록 구현되어 있다.
더 많은 자료구조 참고 https://redis.io/technology/data-structures/
Data Structures - Redis
Designed with developers in mind and unlike simplistic key-value data stores, Redis data structures deliver flexible ways to model your data for many use cases in modern applications.
redis.io
파이프라이닝
네트워크 왕복 비용과 시스템 콜 오버헤드를 줄인다
응답을 기다리지 않고 서버에 여러 명령을 전송한 후 한 번에 응답을 읽을 수 있다.
$ (printf "PING\\r\\nPING\\r\\nPING\\r\\n"; sleep 1) | nc localhost 6379
+PONG
+PONG
+PONG
예시 코드를 보면 PING 명령어를 한번에 전송하고, 한번에 응답을 읽을 수 있다.
RTT(왕복 시간) 비용을 여러 번 지불하지 않아도 되고, 소켓 I/O에 사용되는 시스템 콜 오버헤드를 줄일 수 있다.
소켓 I/O에는 read(), write() 시스템 호출이 포함되는데, 이는 사용자 영역에서 커널 영역으로의 컨텍스트 전환을 의미합니다. 이러한 컨텍스트 전환은 속도 저하의 주요 원인입니다. - redis docs
요약하자면
Redis는 다양한 전략을 통해 빠른 데이터 연산을 지원한다.
이렇게만 보면 Redis는 만능인가? 하는 생각이 든다.
이렇게 빠르고 좋은 Redis를 메인 데이터베이스로는 사용하지 않는 걸까?
3. 메인 데이터베이스로 사용할 수 있을까?
Yes! 근데 할 수 있다고 다 하는 건 아니잔하요
Redis를 메인 데이터베이스를 사용하는 것은 이론적으로 가능하다.
하지만, 실제로 잘 사용하진 않는다.
Redis를 메인 데이터베이스로 사용하지 않는 이유
Redis를 메인 데이터베이스로 사용하지 않는 주된 이유는 크게 2가지였다.
- RAM은 휘발성이고 비싸다.
- 구조화되어있지 않다. (RDB 같은 스키마 형태를 지원하지 않는다.)
RAM은 휘발성이고 비싸다
Redis는 컴퓨터가 꺼졌을 때도 데이터를 복구할 수 있도록 AOF, RDB(스냅샷) 기법을 지원한다.
휘발성이라고는 하지만, 이런 보조적인 기법을 통해 영구적 저장을 흉내 낼 수 있다.
하지만, AOF, RDB는 데이터 복구를 위한 기법이고 결국 모든 데이터는 메모리에 올라가야 한다.
메모리는 금방 차게 되고, Eviction 정책에 따라 데이터는 삭제되거나 오류가 발생할 것이다.
이 과정에서 불필요한 CPU 소모도 발생한다.
또한, 더 많은 메모리를 사용하기 위해 디스크를 사용할 때보다 더 많은 비용을 지불해야 한다.
구조화되어있지 않다
RDB는 스키마를 설정하고, 조인 연산을 활용해 복잡한 데이터를 관리할 수 있게 해 준다.
Redis는 key:value의 형태로 데이터를 저장하기 때문에 제약 조건 안에서 강한 정합성을 보장하기 어렵다.
또한, seat:hold:1처럼 데이터 표현 방식은 길어지고 데이터를 쉽게 확인하기도 어렵다.
정리하자면,
데이터 유실 가능성이 있는 공간에 영속성이 중요한 데이터를 저장하는 것은 추천하지 않는다.
느낀 점
Redis를 공부할수록 영구적인 저장소와는 철학적으로 맞지 않는다는 생각이 들었다.
또한, 굉장히 많은 분야에 쓰이고 있다는 게 놀랍기도 했다.
(이 내용을 다 공부한다면 80살쯤 되려나?)
그럼에도 Redis를 활용해서 다양한 작업을 할 수 있는 만큼
다양한 유즈케이스를 공부해 보고 직접 구현해보려고 한다.
(다음에는 캐싱, 분산락, Rate limit, Pub/sub 도 블로그에서 다뤄보겠습니다!)
Ref
https://www.youtube.com/watch?v=VLTPqImLapM
https://github.com/redis/redis
https://redisgate.kr/redis/configuration/internal_quicklist.php
https://redis.io/docs/latest/develop/using-commands/pipelining/
https://redis.io/technology/data-structures/
*잘못된 내용은 댓글로 알려주시면 글에 반영하도록 하겠습니다. 감사합니다.
'Server > Infra' 카테고리의 다른 글
| [Redis] 대용량 트래픽에도 동작하는 좌석 예매 시스템 구축 (Lua, Zset) (0) | 2026.02.04 |
|---|---|
| [CICD] 도커 이미지 경량화하기 (CICD 구축기 2탄) (0) | 2025.10.03 |
| [CICD] 블루그린 배포로 변경하기 (spring + nginx + github action) (0) | 2025.03.13 |
