검색어 추천 서비스 개발기

검색어 추천 기능은 대부분의 현대적인 웹사이트에서 사용자 경험을 개선하기 위해 중요한 역할을 합니다. 이 기능은 사용자가 검색창에 특정 단어나 구문을 입력하면, 이를 기반으로 관련성이 높은 추천 검색어를 실시간으로 제공하여 사용자가 원하는 정보를 보다 빠르고 효율적으로 찾을 수 있도록 돕습니다.

 

예를 들어, 사용자가 "강아"라고 입력했을 때, 서버에서는 이 입력된 부분을 기반으로 "강아지", "강아지 복숭아", "강아지 종류"와 같이 자주 검색되는 키워드를 실시간으로 검색하고, 그중에서 상위 키워드를 추천해 줍니다.

 

검색어 추천 기능의 기술적 특징은 크게 네 가지가 있다고 생각합니다.(구글 페이지를 분석한 결과에 대한 글쓴이의 생각임으로 부정확성이 있을 수 있습니다!)

1. 검색어 추천과 검색 결과를 위한 별도의 URL 사용
   • 검색어 추천을 요청하는 URL과 검색 결과를 요청하는 URL은 명확히 분리하여 설계해야 합니다.
2. 캐시 정책
   • 사용자가 동일한 검색어로 반복 요청을 보낼 때 서버의 과부하를 줄이기 위해 캐시 정책이 중요합니다.
3. 추천 검색어 요청 시점
   • 사용자가 검색어를 입력할 때 어느 시점에 추천 검색어를 요청할지 결정하는 것이 중요합니다. 
4. 빠른 응답 시간
   • 검색어 추천 기능은 매우 빠른 응답 시간이 요구됩니다. 페이스북에서는 100ms의 응답속도를 요구해야 사용자의 불편이 없다고 나와있습니다.

검색어 추천과 검색 결과를 위한 별도의 URL 사용

개발을 하다가 보니 어떻게 이 검색어가 사용자의 검색 결과 요청인지, 검색 추천 요청인지 알 수 있는 방법이 없었고, 이 궁금증을 해결하기 위해서 구글 사이트를 분석해 보았다.

 

아래의 사진과 같이 검색어 후보군을 요청하는 URL은 "complete/search"가 되고, 검색어 결과를 요청하는 URL은 "search"가 된다.

따라서 우리는 검색어 추천을 요청하는 URL과 검색 결과 및 검색 빈도수를 올려주는 URL을 다르게 설계해야 한다는 것을 알 수 있다.

검색어 추천URL

캐시 정책

검색 추천 기능이 매번 작동하게 되면 서버는 지속적으로 요청에 대한 결과를 생성하기 위해 상당한 자원을 소비해야 합니다. DAU가 천만명이고, 사용자가 하루에 평균 10번의 검색 추천을 요청한다고 가정했을 때 하루에 총 요청 수는 다음과 같이 계산될 수 있습니다.

Total Req per Day = Dau * request per User
10,000,000 = 1,000,000×10

//TPS로 변환했을 경우에는)
10,000,000 / 86400(sec/day) = 116(tps)

 

이렇게 높은 DAU로 인해 서버는 매초 약 116개의 검색 추천 요청을 처리해야 하며, 이 숫자는 사용자 수와 검색 빈도에 따라 더욱 증가할 수 있습니다. 특히, 수많은 사용자가 동시에 검색을 시도할 때 서버 부하가 급격히 증가할 수 있습니다. 이러한 문제는 서버 성능 저하뿐만 아니라 사용자 경험에도 부정적인 영향을 미칠 수 있습니다.

 

이러한 기술적 어려움을 해결하기 위해 구글은 로그인 사용자와 비로그인 사용자를 구분하는 캐시 정책을 도입했습니다

 

비로그인 캐시

먼저 비로그인 사용자의 특징을 보면 개인화된 추천 서비스를 수행하지 않아도 된다는 점이 있습니다. 따라서 구글에서의 캐시 정책은 아래의 그림과 같이 private와 max-age 속성으로 구성했습니다.

 

private 속성의 의미는 가장 끝의 사용자 브라우저만 캐시를 저장할 수 있음을 나타내고, max-age의 경우 이 3600초 동안에는 동일한 요청에 대해 서버로부터 다시 데이터를 가져오는 대신, 로컬 캐시에서 데이터를 사용할 수 있음을 나타냅니다.

 

로그인 캐시

로그인된 사용자에게는 아래 그림과 같이 항상 개인화된 추천 서비스를 제공해야 합니다. 따라서 캐시 정책이 변경돼야 합니다.

 

구글은 no-cache와 must-revalidate 정책을 통해 응답 속도를 개선하고, 캐시를 효과적으로 관리할 수 있게 했습니다. no-cache의 경우, 응답이 캐시에 저장되기는 하지만, 이를 사용할 때마다 서버에 재검증 요청을 보내야 합니다.

 

즉, 서버의 확인 없이는 캐시 된 데이터를 사용할 수 없습니다. must-revalidate 속성 역시 캐시 된 응답이 만료되었을 때, 서버로부터 반드시 검증을 받아야 한다는 의미를 가지고 있습니다. 

 

이 두 가지 정책을 통해 서버는 클라이언트가 항상 최신 데이터를 받을 수 있도록 보장하면서도, 필요에 따라 캐시 된 데이터를 재사용하여 효율성을 높일 수 있습니다.

응답시간

응답 시간을 확인하면 매우 짧은 응답 시간을 가지고 있는 것을 확인할 수 있습니다. 구글도 페이스북 논문과 같이 최초의 요청에만 200ms가 되고 추후의 요청은 100ms로 응답을 전달합니다.

 

궁금한 점은 검색어 추천 기능이 실시간으로 반영되지 않아도 되는 이유가 궁금해짐

 

검색어 추천 서비스 개발기 Version 1

2024.08.11 - [개발] - 검색어 추천 개발기 Version 1

검색어 추천 개발기 Version 1

기능적으로는 만족하나 성능적 지표는 암울하다. 성능적 지표를 중점으로 버전 2를 구현해 보았습니다...

검색어 추천 서비스 개발기 Version 2

https://bjwan-career.tistory.com/304

검색어 추천 기능 Version 2

기능과 성능적 지표는 만족하지만 서비스는 53일 간만 유효하다. 그 이유는 글을 읽어보면 알 수 있습니다...

 

검색어 추천 서비스 개발기 Version 3

2024.08.12 - [개발] - 검색어 추천 서비스 V3(Redis + NoSQL)

검색어 추천 서비스 V3(Redis + NoSQL)

거의 모든 기능을 만족한다. 하지만 서비스가 지속되면 하나의 데이터베이스와 하나의 레디스로는 감당하기 힘들어질 수 있다. 따라서 샤딩과 클러스터를 적용해서 지속가능하게 만들자

 

검색어 추천 서비스 개발기 Version 4

데이터를 분산한 샤딩 적용기

2024.08.13 - [개발] - 검색어 추천 서비스 V4(Sharding)

검색어 추천 서비스 V4(Sharding)

 

 

 

[참고자료]

캐시 정책

https://ieftimov.com/posts/conditional-http-get-fastest-requests-need-no-response-body/

Conditional HTTP GET: The fastest requests need no response body

https://toss.tech/article/smart-web-service-cache

웹 서비스 캐시 똑똑하게 다루기

 

https://www.inflearn.com/community/questions/112647/no-store-%EB%A1%9C%EB%8F%84-%EC%B6%A9%EB%B6%84%ED%95%A0-%EA%B2%83-%EA%B0%99%EC%9D%80%EB%8D%B0-no-cache-must-revalidate-%EB%8A%94-%EC%99%9C-%EA%B0%99%EC%9D%B4-%EC%B6%94%EA%B0%80%ED%95%98%EB%8A%94-%EA%B2%83%EC%9D%B8%EA%B0%80%EC%9A%94

no-store 로도 충분할 것 같은데 no-cache, must... - 인프런 | 커뮤니티 질문&답변