외부 검색 API 의 hits_per_page 가 우리 SearchClient 기본값 그대로여서 한 번에 100건을 가져오는데 화면에는 20건만 보여 주고 있었다. 나머지 80건은 매번 가져와서 그대로 버리고 있는 셈이었다.
Table of contents
Open Table of contents
원인 — 버리는 만큼의 비용
과금이 조회 건수 기준이라 하루 조회 수에 100을 곱한 만큼 비용이 나가고 있었다. hits_per_page 를 화면에서 실제로 쓰는 수에 맞추니 조회 건수가 5분의 1로 줄었다.
건수만 줄이면 되는 줄 알았는데 손대야 할 기본값이 하나 더 있었다. min_score 가 0으로 돼 있어서 관련 없는 결과까지 함께 나오고 있었다.
품질까지 나빴던 이유
min_score 가 없으면 상한 건수를 채우려고 점수가 낮은 것까지 끌어오게 된다. 그래서 검색어와 관련 없는 항목이 목록 뒤쪽에 계속 붙어 있었다.
건수를 줄이고 min_score 를 두니 억지로 채우던 것이 없어지면서 품질도 같이 좋아졌다. 가져와서 버리는 구조가 비용과 품질을 동시에 나쁘게 만들고 있었다.
판단 기준 — 하한을 정한 방법
두 가지 방법이 있었는데 min_score 를 상위 결과 점수의 비율로 자동 계산하는 것과 점수와 결과 제목을 같이 찍어 눈으로 보며 고정값을 정하는 것이다. 뒤쪽을 골랐다. 이유는 비율은 상위 결과가 전부 엉뚱할 때도 그중 일부를 통과시켜서다. 대신 색인이 크게 바뀌면 값을 다시 봐야 하는 것을 감수했다. 어느 점수 구간부터 관련 없는 것이 나오는지를 확인하고 그 경계를 잡았다.
검색어 하나로 정하면 그 검색어에만 맞는 값이 되므로 여러 개로 확인했다. timeout 도 함께 뒀는데 Guzzle 공식 문서대로 기본값 0 은 무한 대기라 느린 조회가 계속 잡고 있기 때문이고 제한에 걸리면 부분 결과라는 것을 Log::info() 로 남겼다.
조치 — 다른 기본값 훑기
검색 말고도 기본값을 그대로 쓰고 있는 자리를 전부 훑었다. PHP-FPM pm.max_children 과 Guzzle timeout 과 Redis ttl 과 SQS visibility_timeout 과 재시도 횟수 다섯 군데였고 대부분 기본값 그대로였다.
pm.max_children 이 기본값이라 요청이 몰릴 때 대기가 생기고 있어서 프로세스당 메모리를 실측한 뒤 올렸다. 전부 바꾼 것은 아니고 재시도 횟수처럼 그대로 두는 것은 왜 그대로 두는지를 주석으로 적었는데 기본값을 쓰는 것과 안 본 것은 다르기 때문이다.
검증 — 셋을 같이 본 검증
건수를 줄여 비용과 속도가 나아졌지만 품질이 나빠졌을 수 있어서 지표를 함께 봤다. 검색 후 클릭률은 올랐고 결과 없음 비율이 조금 늘어 있었다.
결과 없음이 는 것은 min_score 때문이었고 관련 없는 것을 안 보여 주니 아예 없는 경우가 생긴 것이다. 결과가 없으면 하한을 풀고 다시 찾되 관련도가 낮을 수 있다는 표시를 붙였다. 비용과 속도만 보고 품질을 안 보면 개선이 아니라 교환이 되므로 셋을 같이 봤다.
정리
- 기본값은 어느 상황에도 안 맞을 수 있다
- 가져와서 버리는 것이 있으면 그만큼 비용이 든다
- 건수만이 아니라 다른 기본값도 본다
- 하한이 없으면 억지로 채우면서 품질이 나빠진다
min_score는 점수와 결과를 같이 찍어 여러 입력으로 정한다timeout을 두고 부분 결과임을 표시한다- 기본값을 쓰는 자리를 훑고 그대로 두는 이유를 적는다
- 비용과 속도와 품질 셋을 같이 본다