Redis의 작동 원리

드디어 '0.001초'의 찰나에서 승부가 갈리는 초고속 데이터의 영역, Redis(Remote Dictionary Server)에 도달하셨군요! 🫡

주식 시스템에서 실시간으로 변하는 '급등주 순위'나 '초단위 호가 데이터'를 매번 디스크(HDD/SSD)에 썼다 읽었다 하면 이미 기회는 사라지고 말 겁니다. 이때 모든 데이터를 메모리(RAM)에 상주시켜 빛의 속도로 응답하는 Redis는 선택이 아닌 필수입니다.

Redis의 작동 원리와 주식 시스템의 꽃인 Sorted Set을 분석해 드립니다!

---

⚡ 1. Redis의 작동 원리: "왜 그렇게 미친 듯이 빠른가?"

Redis가 전 세계에서 가장 빠른 데이터베이스로 꼽히는 이유는 단순합니다.

① 인메모리(In-Memory) 아키텍처

• 일반적인 DB는 데이터를 디스크에 저장하고 메모리를 캐시로 쓰지만, Redis는 메모리를 주 저장소로 씁니다. 디스크 탐색(Seek) 시간이 0에 가깝기 때문에 수십만 TPS(초당 트랜잭션)를 가볍게 처리합니다.

② 싱글 스레드(Single-Threaded)의 역설

• Redis는 한 번에 하나의 명령만 처리합니다. "멀티 코어 시대에 왜?"라고 의문이 드시겠지만, 스레드가 여러 개일 때 발생하는 컨텍스트 스위칭(Context Switching) 비용과 잠금(Locking) 경쟁을 아예 없애버림으로써 오히려 단순하고 극강의 속도를 냅니다.

③ 비차단 IO (Non-blocking IO)

• 한 번에 하나를 처리하되, IO 작업이 완료될 때까지 기다리지 않고 다음 요청을 바로 받습니다.

---

🏆 2. 주식 시스템의 핵심: Sorted Set (ZSET)

Redis에는 다양한 자료구조가 있지만 주식 시스템의 '실시간 랭킹'을 위해 태어난 자료구조가 바로 Sorted Set입니다.

① 작동 원리: "값(Value) + 점수(Score)"

• 일반적인 집합(Set)에 '점수(Score)'라는 개념을 추가한 것입니다.
• 데이터를 넣을 때 점수를 함께 주면, Redis가 내부적으로 Skip List와 Hash Table을 사용하여 데이터를 넣자마자 자동으로 정렬합니다.

② 주식 실시간 랭킹 시나리오

• 데이터 삽입: ZADD stock:ranking 7.5 "SAMSUNG" (삼성전자가 7.5% 상승했다는 정보를 넣음)
• 실시간 조회: ZREVRANGE stock:ranking 0 9 WITHSCORES (상승률이 높은 상위 10개 종목을 점수와 함께 즉시 가져옴)
• 복잡도: 데이터가 100만 개 있어도 정렬된 상태를 유지하므로 조회 속도가 O(log(N))으로 매우 빠릅니다.

---

🛠️ 3. Redis의 데이터 영속성 (Persistence)

"메모리에만 있으면 전원 꺼지면 다 날아가는 거 아냐?"라는 걱정, 사용자는 안 하셔도 됩니다. Redis는 두 가지 방패를 가지고 있습니다.

1. RDB (Snapshotting): 특정 시간마다 데이터 전체를 디스크에 스냅샷으로 저장합니다. (백업용)
2. AOF (Append Only File): 모든 쓰기 명령을 로그 파일에 기록합니다. 서버가 재시작되면 이 로그를 한 줄씩 다시 실행해서 데이터를 복구합니다.

• 사용자를 위한 팁: 주식 시스템처럼 데이터 유실이 민감하다면 AOF와 RDB를 동시에 사용하는 것이 정석입니다.

---

💡 4. 실전 활용 사례

① 분산 락 (Distributed Lock)

• B그룹(테마주)처럼 변동성이 클 때, 여러 파드가 동시에 같은 종목을 매수하려고 하면 꼬일 수 있습니다. Redis의 SETNX 명령을 이용해 "내가 이 종목 처리 중이니 건드리지 마!"라고 표시하는 락 시스템을 구현할 수 있습니다.

② 캐시 사이드 (Cache Aside)

• 자주 보는 A그룹(우량주)의 재무제표나 기업 정보는 MongoDB(NoSQL)에서 매번 가져오지 말고 Redis에 담아두세요. "Redis에 있으면 바로 주고, 없으면 DB에서 가져와서 Redis에 넣어둔다"는 전략으로 시스템 전체 부하를 80% 이상 줄일 수 있습니다.

---

💡 실전 비유: "셰프의 도구함 vs 거대 창고"

• MongoDB/SQL (거대 창고): 모든 식재료가 박스에 담겨 쌓여 있습니다. 재료를 찾으러 지게차를 타고 가서 박스를 열어야 하므로 시간이 걸립니다. 하지만 엄청나게 많은 양을 보관할 수 있죠.
• Redis (셰프의 조리대 위): 지금 당장 요리에 필요한 소금, 후추, 칼이 셰프 손 닿는 곳(메모리)에 놓여 있습니다. 0.1초 만에 집어 들 수 있습니다.
• Sorted Set: 조리대 위에 놓인 '주문서 꽂이'입니다. 주문이 들어오는 대로 주방장이 우선순위(Score)에 따라 꽂아두면, 요리사는 위에서부터 순서대로 처리하기만 하면 됩니다.

---

📊 요약: Redis 주요 자료구조 활용법

자료구조	특징	주식 시스템 활용 사례
String	가장 기본 (Key-Value)	종목 현재가, 사용자 세션, 인증 토큰
List	순서가 있는 목록 (Queue)	최근 체결 내역 50개, 로그 수집
Hashes	필드-값 쌍의 집합	종목 상세 정보 (이름, 코드, 상장일)
Sets	중복 없는 집합	관심 종목 리스트, 태그 관리
Sorted Sets	점수 기반 정렬 집합	실시간 급등락 랭킹, 거래량 순위

---

🚀 꼬리 질문 🫡

주식 전함은 이제 쿠버네티스(전함), Kafka(통신망), MongoDB(거대 저장소)를 거쳐 Redis(초고속 반응 장갑)까지 장착하며 무적의 진형을 갖추게 되었습니다.

그런데 이 모든 복잡한 데이터베이스와 메시지 브로커들을 관리하다 보면, '이 시스템이 정말 건강하게 돌아가고 있는가?'를 넘어 '어디서 돈이 새고(성능 저하) 있는가?'를 추적하는 것이 매우 중요해집니다. 수많은 파드와 DB 사이의 복잡한 호출 관계를 한눈에 파악해야 하죠.

"그럼 분산 시스템에서 요청의 흐름을 추적하는 'Distributed Tracing'과 그 대표 도구인 'Jaeger'나 'Zipkin'은 어떤 원리로 작동해?"