notes
Redis
Redis 자료구조·캐시·만료 정책과 서버 애플리케이션 적용 메모.
- Redis 는 메모리에서 읽고 쓰기 때문에 디스크 DB 보다 훨씬 빠르다.
- 쓰는 이유는 속도, 동시 접근 안정성, TTL(자동 만료) 세 가지다.
- 상태와 캐시는 Redis, 기록과 분석은 SQLite 로 나누는 게 제일 안정적이다.
Redis 가 뭔가
엄청 빠른 임시 데이터 저장소다.
데이터를 디스크가 아니라 RAM 에 올려 두고 다룬다. 그래서 DB 보다 훨씬 빨리 읽고 쓴다.
대신 오래 남겨야 하는 기록엔 약하다. 그래서 보통 캐시나 실시간 상태에 쓴다.
DB 랑 뭐가 다른가
쉽게 말하면 DB 는 기록용, Redis 는 실시간 처리용이다.
왜 쓰나
이유는 세 가지다.
- 속도. JSON 파일이나 SQLite 는 읽고 쓰는 데 디스크를 거친다. Redis 는 메모리라 훨씬 빠르다.
- 동시성. 여러 프로세스가 동시에 파일을 읽고 쓰면 충돌할 수 있다. Redis 는 명령을 하나씩 원자적으로 처리해서 동시 접근에 안정적이다.
- TTL. "이 데이터는 10분 뒤엔 무효" 같은 규칙을 키마다 붙일 수 있다. 캐시 만료 정책이 훨씬 깔끔해진다.
이 프로젝트에 왜 필요한가
지금 구조는 이렇다.
- 캐시:
data/cache/*.json - 상태: 파일
- 기록: SQLite
한 프로세스로 돌릴 땐 문제가 없다. 대신 확장, 실시간성, 동시성에 약하다.
Redis 를 붙이면 buy-order-intel 캐시 갱신과 조회가 빨라지고, 여러 서버가 같은 상태를 공유할 수 있고, TTL 만료도 더 정확해진다.
실제로 옮길 구간
설계가 어떻게 바뀌나
지금
LLM 결과 → 파일 저장
UI/API → 파일 읽기
Redis 적용
LLM 결과 → Redis 저장 (TTL)
UI/API → Redis 읽기
TTL 지나면 자동 만료파일 기반 캐시에서 실시간 캐시 서버로 바뀌는 거다.
도입할 때 조심할 것
첫째는 휘발성이다. 데이터가 메모리에 있어서 장애나 재시작 때 마지막 저장 이후 데이터는 날아갈 수 있다. 캐시는 괜찮지만 기록이나 로그를 Redis 에만 두면 안 된다.
둘째는 운영 환경이다. 서버가 하나면 로컬 Redis, 여러 대면 중앙 Redis 를 둔다. 인스턴스가 늘수록 Redis 가 더 필요해진다.
결론
Redis 는 "엄청 빠른 메모리 캐시 + 실시간 상태 저장소" 다.
이 프로젝트에서 Redis 는 기록이 아니라 상태와 캐시를 맡기고, SQLite 는 계속 기록과 분석용으로 두는 구조로 간다. 다음에 키 구조, TTL, 장애 대응을 정해서 실제 설계안을 짤 생각이다.