Redis / Kafka / OpenSearch 도입 근거

 

Redis를 쓴 이유

핵심: "빠른 임시 상태 저장소"

MSA 환경에서 서비스 간 공유 상태가 필요한데, DB를 쓰기엔 너무 느리고 무거운 것들이 있습니다.

용도                                                               이유

세션 / 인증 토큰 관리	JWT blacklist, refresh token을 DB 조회 없이 O(1)로 처리
서비스 간 캐시	자주 읽히는 노트 메타데이터, 권한 정보를 PostgreSQL 부하 없이 제공
분산 락(Distributed Lock)	여러 인스턴스가 동시에 같은 노트를 수정하는 Race Condition 방지
Rate Limiting	API 요청 횟수 카운트를 메모리에서 처리

PostgreSQL이 있는데 Redis가 필요한 이유? → PostgreSQL은 영속성, Redis는 속도와 TTL. 역할이 다릅니다.

---

Kafka가 필요한 이유

핵심: "서비스 간 결합도를 끊기 위해"

MSA에서 서비스가 서로 직접 HTTP 호출을 하면 동기 결합이 생깁니다.

 

 

노트 저장 → 검색 인덱싱 → 감사 로그 → 알림
         (직접 호출 시 하나라도 실패하면 전체 실패)

Kafka를 도입하면:

 

 

노트 서비스 → [Kafka Topic: note.created] → 검색 서비스 (독립 소비)
                                           → 감사 서비스 (독립 소비)
                                           → 알림 서비스 (독립 소비)

문제Kafka 해결 방식

장애 전파	소비자 서비스가 죽어도 메시지는 Kafka에 보존 → 복구 후 재처리
처리 속도 차이	빠른 생산자 / 느린 소비자 간 버퍼 역할
이벤트 소싱	노트 상태 변경 이력을 이벤트 스트림으로 재현 가능
확장성	소비자를 늘리는 것만으로 처리량 수평 확장

Redis Pub/Sub 쓰면 안 되나? → Redis는 메시지가 사라집니다(fire-and-forget). Kafka는 디스크에 보존되어 재처리가 가능합니다.

---

OpenSearch를 도입한 이유

핵심: "PostgreSQL LIKE 쿼리로는 못 하는 검색"

ELN(전자실험노트)은 본질적으로 문서 검색이 핵심 기능입니다.

PostgreSQL 한계OpenSearch 해결

LIKE '%키워드%' 는 Full Scan	역색인(Inverted Index) 으로 O(1)급 검색
한국어 형태소 분석 불가	nori 플러그인으로 "실험했다" → "실험" 매칭
관련도 점수 없음	BM25 스코어링으로 결과 랭킹
복잡한 필터 조합이 느림	집계(Aggregation)로 패싯 필터 고속 처리

추가로 Qdrant와의 역할 분리:

• OpenSearch → 키워드 기반 전문검색 (제목, 태그, 본문 텍스트)
• Qdrant → 벡터 유사도 기반 의미 검색 (RAG, "이것과 비슷한 실험 노트 찾기")

---

한 줄 요약

기술한 줄 이유

Redis	빠른 임시 상태 공유 — DB를 캐시·락·토큰 저장소로 쓰지 않기 위해
Kafka	서비스 간 비동기 이벤트 전달 — 직접 호출의 결합도와 장애 전파를 끊기 위해
OpenSearch	전문 검색 — PostgreSQL이 할 수 없는 형태소 분석·랭킹·집계를 위해