본문 바로가기

🖥️ 최종프로젝트/🚀 기능 개선4

[기능 개선] “31s 걸리던 쿼리를 146ms로 줄인 이야기” 🚀 연령대별 인기 키워드, 31s에서 146ms까지! 성능 개선 여정 💭 문제 인식 서비스 내에서 제공하는 "연령대별 인기 키워드" 기능은 사용자 통계를 기반으로 추천 기능과 연동되는 핵심 기능이었다. 하지만 데이터를 조회할 때마다 응답 속도가 지나치게 느리다는 피드백이 들어오기 시작했다. 🐢 성능 테스트 결과 로컬 조회 시간 : 31.49초배포 서버 : 504 Gateway Timeout 발생JMeter 부하 테스트 : 에러율 90% 이상 📌 통계 페이지조차 열리지 않는 상황..운영 환경에서는 사실상 사용이 불가능한 상태였다. 🔍 현재 구조 분석 문제가 발생한 기존 쿼리는 다음과 같이서브 쿼리를 활용한 다단계 집계 방식으로 작성되어 있었다. 해당 쿼리는 다음과 같은 흐름으로 동작한.. 2025. 4. 4.

[기능 개선] 자동 완성 + 부분 검색, 같이 쓰면 안 되는 이유 (feat. Nori 적용) 🔍 한글 형태소 분석기로 검색 정확도 개선하기: Nori + 자동완성 분리 전략 💭 문제 인식 기존에는 채용 공고 검색에 부분 검색(N-gram)과 자동 완성(Edge N-gram) 기능을 함께 적용하고 있었다.기본적인 검색은 가능했지만, 사용자가 기대하는 정확한 검색 결과를 반환하지 못하는 경우가 종종 발생했다. 📌 예시사용자가 "카드"라는 단어를 포함한 채용 공고를 찾고 싶을 때, 자동 완성 기능이 함께 동작하면서카로 시작하는 전혀 다른 채용 공고들까지 함께 검색되는 문제가 발생했다.결과적으로 원하는 결과보다 너무 많은 데이터가 함께 노출되면서 사용자는 정확한 검색이 어렵다는 인상을 받게 되었다. 🧱 기존 인덱스 구조의 한계 기존 인덱스 설정에서는 title, requiredSkills.. 2025. 4. 3.

[기능 개선] 채용 공고 검색 속도 48ms → 14ms, 어떻게 가능했을까? 🚀 QueryDSL에서 Elasticsearch로, 채용 공고 조회 성능 개선 💭 문제 인식 처음에는 MySQL + QueryDSL 기반으로 채용 공고를 조회하고 있었다.단순 조회 성능 자체는 비교적 빠른 편이었다.하지만 서비스가 성장하면서 부분 검색이나 자동 완성 등 검색 편의 기능을 확장해야 할 필요성이 커졌고, 이를 QueryDSL만으로 구현하기엔 구조적 한계가 있었다.특히 전체 채용 공고를 대상으로 키워드 기반 검색이나 사용자 입력에 실시간으로 반응하는 기능은 Elastisearch가 더 적합한 기술이라고 판단했다. 🔍 Elasticsearch 도입 배경채용 공고 검색 기능을 단순 키워드 조회에 그치지 않고 부분 검색, 자동 완성 등 검색 편의 기능을 확장할 필요가 있었다.하지만 MyS.. 2025. 4. 3.

[기능 개선] 검색어 저장할 때마다 DB에 인덱스 갱신… 괜찮을까? 🚀 Redis를 활용한 최근 검색 기록 조회 성능 개선기 💭 문제 인식 사용자가 검색어를 입력할 때마다 해당 검색어가 즉시 DB의 history 테이블에 저장되고 있었고,조회 요청도 매번 DB에서 직접 처리하고 있었다.처음에는 큰 문제가 없었지만,사용자 수가 늘어나면서 검색 요청과 저장 요청이 매우 빈번해졌고, 자연스럽게 아래와 같은 고민이 생겼다. ✅ 매 요청마다 저장이 일어나면 인덱스를 계속 갱신해야 하는데, 그 비용은 괜찮을까?✅ 실시간 처리에는 DB 대신 더 가벼운 저장소가 낫지 않을까? 🔍 도입 배경: 고민 끝에, 왜 Redis였을까?조회와 저장 요청이 매우 빈번해지면서, 기존처럼 매번 DB에 접근하는 구조는인덱스 재작성 비용과 응답 지연이라는 측면에서 효율적이지 않았다.처음엔 DB 튜.. 2025. 4. 2.

이전 1 다음

티스토리툴바