포스타입이 개인화 추천을 하는 방법 2부

포스타입 백엔드 엔지니어가 벡터 기반 개인화 추천 시스템을 실제 운영하며 맞닥뜨린 성능 장애와 용량 문제를 해결한 과정을 담은 2부다. 수백만 개의 벡터 KNN 검색이 피크 시간대에 전체 Elasticsearch 검색 성능을 흔드는 문제부터 클러스터 OOM 사태까지, 쿼리 최적화와 인프라 분리 두 가지 경로로 근본 해결에 이른다.

핵심 포인트

KNN 쿼리의 graph-first(HNSW) 방식 전환으로 피크 타임 검색 스레드 자원 독점 문제 해결
fetch 단계에서 post ID와 유사도 점수만 추출해 stored field 전체 읽기 제거, 디스크 I/O·압축 해제 비용 절감
`cancel_after_time_interval` 도입으로 타임아웃 시 실제 스레드 해제 보장
샤드 수를 노드 수의 배수로 재조정 후 reindex → 가장 부하가 집중된 노드에서 지연 81% 개선 (32.2ms→6.06ms)
KNN 인덱스를 별도 전용 클러스터로 분리해 추천 장애가 검색 전체로 전파되는 문제 차단
Matryoshka Representation Learning(MRL) 특성 활용해 벡터 차원 1024→512 축소, 그래프 메모리 78%→34%, 저장 용량 44% 절감

상세 정리

배경: 벡터 KNN 검색 도입 후 피크 시간대에 전체 검색 성능 저하 발생
문제 1: KNN 쿼리가 검색 스레드 자원을 독점 → graph-first(HNSW 그래프 우선 탐색) 방식 전환으로 해결
문제 2: fetch 단계에서 stored field 전체 읽기로 과도한 디스크 I/O 발생 → post ID+유사도 점수만 추출하도록 변경
문제 3: 타임아웃 설정만으로는 스레드 자원이 실제로 해제되지 않음 → `cancel_after_time_interval` 도입
문제 4: 샤드 분배 불균형으로 특정 노드에 부하 집중 → 샤드 수를 노드 배수로 재조정 후 reindex → 81% 지연 개선
문제 5: KNN 추천 클러스터 장애가 일반 검색 전체로 전파 → KNN 인덱스를 전용 별도 클러스터로 분리
OOM 사고 후 벡터 차원 축소 검토: MRL(Matryoshka Representation Learning)이 차원 축소 후 정밀도 유지 특성 활용
MRL 결과: 벡터 1024→512차원, 그래프 메모리 노드당 78%→34%, 저장 용량 44% 감소
최종 구조: 일반 검색 클러스터와 KNN 전용 클러스터 분리, 쿼리 최적화+인프라 분리의 이중 접근