CPU 뼛속까지 써먹고, Milvus 사이징 기준을 만들기까지

안녕하세요. 토스증권 Data Infra 팀 장재영입니다.토스증권에서는 벡터 검색 워크로드를 지원하기 위해 Milvus 기반의 검색 환경을 구성했는데요. 실제 서비스에 적용하기 전에, 요구하는 검색 품질과 응답 속도를 만족하려면 어느 정도의 물리 서버 자원이 필요한지 확인해야 했습니다.서버가 부족하면 필요한 처리량과 응답 속도를 맞추기 어렵고, 과하게 준비하면 그만큼 비용이 늘어납니다. 토스증권은 온프레미스 중심으로 인프라를 운영하고 있어, 서비스를 올리기 전에 필요한 CPU와 메모리 규모를 가늠해야 했습니다.그런데 같은 벡터 검색이라도 워크로드마다 조건이 달랐습니다. 사용하는 임베딩 모델에 따라 벡터 차원이 달랐고, 검색할 결과의 개수와 품질 목표, 데이터의 갱신 빈도도 달랐습니다. 공개 벤치마크의 QPS만으로는 이 조건들이 우리가 가지고 있는 장비에서 어떤 처리량과 지연시간을 보일지 알 수 없었어요. 서비스 요구사항과 모델의 사양, 인덱스 설정에 나뉘어 있는 정보를 모으고, 실제 자원 사용과 연결해 이해해야 했습니다.저희는 인덱스와 검색 설정을 바꿔 가며 품질과 처리량을 비교했습니다. 검색 중 CPU와 메모리가 어떻게 쓰이는지도 들여다봤는데요. CPU와 메모리 배치를 조정하자 같은 서버에서 검색 품질을 유지하며 처리량을 41% 높일 수 있었습니다. 여기에 검색 설정과 벡터 차원, 서버 수를 바꿔 가며 측정한 결과를 더해 사이징 기준을 만들었습니다. 이번 글에서는 검색 조건을 정하는 것부터 CPU 내부를 살펴보고 워크로드에 필요한 서버 대수를 계산하기까지, 저희가 직접 확인한 내용을 공유하려고 합니다.실험은 다음 순서로 진행했습니다.그림 1. 검색 품질과 비교 조건을 정하고, CPU·메모리 배치를 개선한 뒤 서버 규모를 산정하는 과정검색을 비교하기 전에벡터 검색의 품질과 처리 성능우리가 SQL에서 =나 LIKE로 검색할 때는 값이 일치하거나 문자열 패턴에 맞는 데이터를 찾습니다. 제품 설명에서 ‘배터리’라는 단어를 찾는다면, 그 단어가 없는 설명은 검색되지 않죠. 그런데 ‘배터리가 오래가는 휴대폰’을 찾는 사람에게는 ‘충전 없이 하루 종일 쓰는 스마트폰’이라는 설명도 유용한 결과일 수 있습니다.그림 2. 텍스트·이미지·음성을 임베딩 모델로 변환한 벡터. 배열에 들어 있는 숫자의 개수가 차원입니다.이렇게 표현이 달라도 의미가 비슷한 데이터를 찾는 데 벡터 검색을 활용할 수 있습니다. 임베딩 모델은 텍스트나 이미...