[기능 개선] 검색어 저장할 때마다 DB에 인덱스 갱신… 괜찮을까?

🚀 Redis를 활용한 최근 검색 기록 조회 성능 개선기

 

💭 문제 인식

사용자가 검색어를 입력할 때마다
해당 검색어가 즉시 DB의 history 테이블에 저장되고 있었고,
조회 요청도 매번 DB에서 직접 처리하고 있었다.

처음에는 큰 문제가 없었지만,
사용자 수가 늘어나면서 검색 요청과 저장 요청이 매우 빈번해졌고, 자연스럽게 아래와 같은 고민이 생겼다.

✅ 매 요청마다 저장이 일어나면 인덱스를 계속 갱신해야 하는데, 그 비용은 괜찮을까?
✅ 실시간 처리에는 DB 대신 더 가벼운 저장소가 낫지 않을까?

 

🔍 도입 배경: 고민 끝에, 왜 Redis였을까?

조회와 저장 요청이 매우 빈번해지면서, 기존처럼 매번 DB에 접근하는 구조는
인덱스 재작성 비용과 응답 지연이라는 측면에서 효율적이지 않았다.

처음엔 DB 튜닝이나 인덱스 최적화도 고려했다.
하지만 검색어 기록은 최근 데이터 위주로 빠르게 읽고 쓰는 특성을 가지기 때문에,
메모리 기반의 빠른 저장소인 Redis가 더 적합하다고 판단했다.

 

🧠 해결 아이디어: 인덱싱 없이 Redis로 처리해보자!

 

• 검색어 저장은 더 이상 바로 DB에 저장하지 않고, 먼저 Redis에 저장한다.
• 조회 역시 Redis에서 바로 처리하여  DB 접근 없이 빠른 응답 속도를 확보한다.
• 그리고 일정 시간마다 Redis의 검색어를 DB로 동기화하여 영속성도 함께 보장한다.

 

 

🔎 Redis 적용 전: DB 기반 조회

Redis 적용 전 로컬에서 성능 확인

⚡ Redis 적용 후: 캐시 기반 초고속 조회

Redis 적용 후 로컬에서 성능 확인

👉 약 83% 응답 속도 개선

 

 

🔁 동기화 및 만료 처리

검색어가 DB에는 바로 저장되지 않기 때문에, 데이터 유실을 방지하고 저장 공간을 효율적으로 관리하기 위한 로직을 설계했다.

✅ 주기적인 동기화

• 30분마다 스케줄러를 실행하여 Redis에 저장된 검색어를 DB에 저장한다.
• DB에 존재하지 않는 검색어만 선별적으로 저장하여 중복 저장을 방지하고 디스크 I/O를 최소화할 수 있도록 했다.

✅ 일정 시간 동안 검색이 없으면 사용자 기록 자동 삭제

• Redis에는 사용자 단위로 검색어 목록이 저장된다.
• 사용자가 검색을 수행할 때마다 TTL(Time To Live)이 자동으로 갱신된다.
• 만약 1시간 동안 검색이 이뤄지지 않으면, 해당 사용자의 검색어 기록 전체가 Redis에서 자동으로 삭제된다.

📌 이 방식 덕분에 자주 검색하는 '활성 사용자'의 데이터는 Redis에 유지되고, 1시간 이상 검색하지 않는 '비활성 사용자'의 데이터는 자동으로 정리되어 메모리 자원을 효율적으로 관리할 수 있는 구조가 완성된다.

 

 

✅ 정리 및 회고

항목	Redis 적용 전	Redis 적용 후
저장 위치	DB 직접 저장	Redis 캐시 저장
조회 속도	102ms	17ms
장점	데이터 영속성 확보	빠른 응답, DB 부하 감소
단점	-	동기화 로직 필요 (보완 완료)