아빠는 개발자

Api 구조 aqqle api 컨셉 - 상품을 검색했을때 상품정보와 상품을 파는 매장정보까지 같이 반환 해주는 API 900gle은 vector의 유사도 검색에 비중을 높였다면 Aqqle 는 캐싱에 좀 더 포커싱을 맞추는 중 지금 까지 작업한 구조는 위와 같다. vector 의 유사도 검색이 들어가긴 하지만 simularity 플래그를 두어서 검색에서 빼는 조건을 추가 상품을 검색하면 상품정보를 가져오고 내 위치 기준 5km 이내의 점포 정보를 가저온다 LOCATION 엔 스토어 위치정보 ITEM 엔 상품정보 이제 테스트를 진행 해보자 근데 문제는 지금도 실행속도가 너무 빠르다. API 평균 : 20.64 API 평균 : 22.27 API 평균 : 21.58 평균 20이라고 치고 location 정보를 ..

검색성능 개선 final 이다. 지금까지 테스트 해본 결과를 바탕으로 구조를 잡아서 테스트 ( final 이라고 해놓고 진격의 거인마냥 final part 1, final part 2, final 1기 1쿨 이렇게 증식되지 않기를 바랄뿐..) 우선 이슈는 픽업 서비스 오픈 이후 response time이 튀는 현상이 발생했다. 당연히 검색쿼리로 데이터 조회 후 처리 로직이 추가되었으니 당연히 응답시간이 늘어나는건데 이것이 문제가 되고 있으니.. 늘어난 응답시간은 100ms 이하라서 사용자가 인지하기 힘든 속도이긴 하나. cloud watch 의 모니터링 대시보드에선 널뛰기를 하는 모습으로 나온다. 그래도 로직이 추가될때마다 성능이 저하된다면 문제가 맞긴 한듯하다 cloud watch의 ALB 대상그룹의 ..

API 를 만들고 응답시간을 측정해서 최적의 성능을 만들어 보자 일단 제물이 될 index 820만건의 location-index 일단 aqqle 의 shop API 를 응용해서 후다닥 만들어 보자. 복붙해서 이름만 바꾸니까 1분 미만 컷 지금은 bool > filter > term 쿼리로 조회하니 응답속도가 빠르다. 일단 이 상태에서 리소스 사용과 응답속도를 측정해보잣 캐싱이 안되고 있지만 너무 빠르다 일단 지난 캐시 테스트와 같은 구조로 multi_match 쿼리 와 count집계(aggs) 를 두번 추가 전체쿼리 더보기 { "size":100, "query":{ "bool":{ "must":[ { "multi_match":{ "query":"country_code", "fields":[ "CO^1...