Redis 불편한 도구 그러나 (2) 어떻게 구조화 하는것이 redis에서는 올바른가

어떻게 구조화 하는것이 Redis에서는 올바른가: 초당 100건 Push 데이터 파이프라인

갑자기 이런 생각이 들었다.
“push 서버로 초당 100건씩 날아오는 자료를 전부 Redis에 저장해두고, 분리/검색 후 필요한 내용으로 변환해서 DB에 저장하면 어떨까?”

결론부터 말하면 가능하고, 더 중요한 포인트는 “Redis에 다 저장한다”가 아니라 수신/처리/저장을 분리해서 시스템이 느려져도 깨지지 않게 만드는 것이다.

---

핵심 아이디어

• 수신(Ingest): 받는 것 자체가 목표 (절대 막히면 안 됨)
• 큐/버퍼(Buffer): 처리 지연을 흡수 (유입과 처리를 분리)
• 처리(Process): 분리/정리/변환 (CPU를 쓰는 구간)
• DB 저장(Persist): 확정 기록만 남김 (느리더라도 안정적으로)

---

Redis에서 “올바른 구조화”의 핵심: 큐를 단계별로 분리

Redis를 DB처럼 “검색 가능한 저장소”로 쓰려 하면 곧 막힌다.
Redis는 키 기반 접근이 핵심이기 때문에, “흐름” 중심으로 구조를 잡는 게 안전하다.

• 원본 큐: 외부에서 들어온 데이터를 최대한 원형 그대로 보관 (유실 방지, 빠른 수신)
• 정리 큐: 파싱/정규화/분리 완료된 중간 산출물 (다음 단계 공통 입력)
• 저장 큐: DB로 내려보낼 대상만 모은 큐 (배치/재시도/확정 저장용)

---

워커가 여러 개로 나뉘는 이유

“처리1, 처리2” 같은 단계가 생기는 것은 복잡도가 늘었다는 뜻이 아니라, 책임이 분리되어 관리가 쉬워졌다는 신호다.

• 정리 워커: 원본을 정규화/필터링/라우팅 키 생성 → 정리 큐로 전달
• 스냅샷 워커: “현재 상태판”을 Redis에 유지 (조회/모니터링/화면 응답에 도움)
• DB 저장 워커: 확정 데이터만 DB에 저장 (배치 중심, 실패 재시도)

---

왜 이 방식이 안전한가

• 수신은 빠르게: 처리/DB가 느려져도 우선 받는 것은 계속 가능
• 병목이 눈에 보임: 어떤 큐가 쌓이는지 보면 어디가 느린지 즉시 파악
• 확장 쉬움: 느린 단계(워커)만 증설 가능
• 장애 대응 쉬움: 큐에 쌓인 데이터를 기반으로 재시도/재처리 설계 가능

---

정리

“초당 100건을 Redis에 넣고 DB에 저장”의 핵심은,
Redis를 검색 엔진처럼 쓰는 게 아니라 흐름(파이프라인)을 안전하게 분리하는 것이다.

최종 형태는 아래처럼 단순한 문장으로 고정된다.

수신 → Redis(원본 큐) → Worker(정리) → Redis(정리 큐)
→ Worker(스냅샷) / Worker(DB저장) → DB(확정 기록)