토스증권, CPU·메모리 배치 조정으로 Milvus 검색 처리량 41% 개선

토스증권이 Milvus의 CPU와 인덱스 메모리를 같은 NUMA 노드에 배치해 검색 처리량을 41% 높였다고 밝혔다. 768차원 벡터 1억 건을 서버 3대·동시 요청 90개로 검색한 실험에서 처리량은 405→572 QPS로 늘었고 recall@10은 0.9541을 유지했다. 실제 서비스 적용 전에는 해당 데이터로 품질·처리량·지연시간을 다시 확인해야 한다.

내용·출처 업데이트 · 2026. 10. 12. 오후 7:47

실험은 적재·인덱스 빌드가 끝난 sealed 데이터의 CPU 검색을 대상으로 했으며, QueryNode의 자원 사용을 분석했다.

서버는 각각 Intel Xeon Silver 4516Y+ 2소켓·물리 코어 48개·메모리 512GB 구성이다. QueryNode 할당량은 48 vCPU·256GiB였다.

HNSW_SQ8·ef48 조건에서 자원 할당량과 검색 조건을 유지하고 CPU·메모리 위치만 조정했다. 원격 DRAM 읽기 비율은 약 50%에서 0.8%, IPC는 0.37에서 0.55로 바뀌었다.

검색 p99의 측정 구간 최댓값은 3.94초에서 2.04초로 줄었다. 전체 요청을 합친 지연시간 분포의 p99를 뜻하지 않는다.

별도 인덱스 비교에서 HNSW_SQ8은 recall@10 0.954·316 QPS·replica당 약 114GB를 기록했다. 비압축 HNSW는 약 335GB를 사용했으며, 각 구성의 검색 설정과 자원 할당량도 조정했으므로 인덱스만의 차이는 아니다.

Kubernetes 적용 조건: CPU Manager의 static 정책에서 전용 CPU를 받으려면 Guaranteed Pod와 컨테이너의 정수 CPU 요청이 필요하다. Memory Manager의 Static 정책에는 reservedMemory가 필요하며, kubeReserved·systemReserved·evictionHard의 메모리 예약량과 맞춰야 한다. Topology Manager의 single-numa-node는 자원을 한 NUMA 노드에 맞출 수 없으면 Pod 수용을 거부한다. 기본 scope는 container이므로 Pod의 모든 컨테이너가 같은 NUMA 노드에 놓인다고 볼 수 없다. CPU 번호와 예약량은 서버별 topology에 맞춰 정한다.

적용 전 확인: 낮은 IPC만으로 원격 메모리가 병목이라고 단정할 수 없다. 여러 NUMA 노드가 있는 서버에서 CPU 기반 sealed 데이터 검색을 운영한다면, remote DRAM 접근 비율과 QueryNode의 CPU·메모리 위치를 함께 확인할 수 있다. 배치 변경 전후에는 데이터·질의·동시성·자원 할당량을 맞추고, ef와 SQ8·refine 설정을 기록해 recall·QPS·지연시간을 비교한다. 토스의 HNSW_SQ8 실험은 refine을 끈 구성이다. 41%는 해당 실험의 결과이며 GPU 검색이나 실시간 적재 성능으로 확대할 수 없다.