Milvus 서버 사이징, CPU 최적화로 41% 성능 향상

임베딩 모델의 벡터 차원이나 검색 조건에 따라 필요한 물리 서버 규모는 천차만별입니다. 토스증권 데이터 인프라 팀 장재영 엔지니어는 온프레미스 환경에서 Milvus를 운영하며, 단순한 벤치마크 수치로는 파악할 수 없는 자원 소모의 균형을 찾기 위해 직접 실험을 수행했는데요. 그 결과, CPU와 메모리 배치를 재조정하는 것만으로 기존 서버에서 검색 품질을 훼손하지 않고 처리량을 41%까지 높일 수 있음을 입증했습니다. 벡터 검색을 도입하는 기업들이 가장 고민하는 부분이 바로 ‘얼마나 큰 서버가 필요한지’라는 점과 직결되는데요. 이 글에서는 수억 건의 데이터를 효율적으로 탐색하기 위한 HNSW 인덱스 원리부터, 실제 CPU 내부의 병목 현상을 파악하는 과정, 그리고 최종적으로 사이징 기준을 도출하기까지의 흐름을 상세히 풀어냅니다. 단순히 사양이 좋은 서버를 구매하는 것보다, 워크로드별로 최적의 절점점을 찾는 법이 어떻게 도출되었는지 순서대로 되짚어 보겠습니다.

Milvus 서버 사이징, CPU 최적화로 41% 성능 향상

벡터 검색, 왜 ‘(비슷함)’으로 찾나

SQL 언어에서 데이터를 찾을 때는 값이 정확히 일치하거나 패턴이 맞는 조건을 설정합니다. 하지만 사용자가 ‘배터리가 오래가는 휴대폰’이라고 검색했을 때, 설명란에 ‘충전 없이 하루 종일 쓴다’라고 적힌 제품은 단어 하나도 겹치지 않아 기존 검색 방식으로는 잡히지 않죠. 이 격차를 메우기 위해 임베딩 모델이 등장했고, 텍스트나 이미지를 의미를 가진 숫자 배열인 벡터로 변환해 유사도를 판단합니다. 이 배열에 포함된 숫자의 개수가 바로 차원인데, 모델에 따라 이 차원 수는 고정되어 있지 않아 서버 설계 시 중요한 변수가 됩니다. 저장된 모든 벡터와 검색어 벡터의 거리를 전수 비교하면 정답은 분명하지만, 데이터가 수억 건에 달하면 반응 속도가 용납되지 않습니다. 그래서 도입한 것이 ANN(근사 최근접 이웃 검색)이며, 이번 실험에서는 HNSW 인덱스를 활용했습니다. HNSW는 데이터를 여러 계층의 그래프로 나눠, 성긴 상위 계층에서 대략적인 후보를 추린 뒤 가장 아래층인 레이어 0에서 정밀 탐색을 수행합니다. 이렇게 접근하면 계산량은 크게 줄이되, 전수 비교 대비 일부 결과를 놓칠 수 있다는 치명적인 단점이 있습니다.

recall과 QPS, 하나만 보면 위험한 이유

벡터 검색 시스템의 성능을 평가할 때는 ‘얼마나 빠르다’는 지표만 보아서는 안 됩니다. 검색 품질을 나타내는 recall(회수율)과 처리 성능을 나타내는 QPS는 서로 줄다리기 같은 관계를 보이기 때문이죠. recall@10이 0.95라고 하면, 정답으로 인정되는 가장 가까운 10개 결과 중 9.5개를 평균적으로 찾아낸다는 뜻입니다. 토스증권은 이 95%라는 수치를 최소 품질 기준선으로 잡고, 그 이하인 경우 아무리 빠르다고 해도 생산 환경에서 사용 불가 판정을 내렸습니다. ef(effective neighbours) 설정값을 높이면 탐색 범위가 넓어져 recall은 좋아지지만, CPU마다 더 많은 연산을 수행해야 하므로 QPS는 떨어집니다. 반대로 ef를 낮추면 속도는 빨라지지만, 원하는 결과를 놓치는 비율이 급격히 상승하는 딜레마에 빠집니다. 결국 엔지니어는 이 두 값 사이에서서비스 수준 협약(SLO)을 만족하는 ‘최소 품질 기준’을 먼저 정의해야 합니다. 이 기준이 없으면, 나중에 발견되는 검색 결과의 정확도 하락은 사용자 이탈로 직결됩니다.

CPU 뼛속까지 파고든 병목 분석

서버 부하가 높을 때 단순히 코어 수만 늘리는 것은 비효율적인 접근입니다. 장재영 엔지니어는 Milvus 검색 요청이 들어왔을 때 CPU가 어떤 단계를 거쳐 데이터를 탐색하는지, 그리고 그 과정에서 어디에 시간이 낭비되는지 Profiling(프로파일링) 작업으로 정확히 짚었습니다. HNSW 탐색 과정에서는 메모리에서 그래프 노드를 읽고 참조해야 하는 작업이 빈번하게 일어납니다. 이때 CPU가 메모리로부터 데이터를 가져오는 지연 시간, 이른바 메모리 벽에 부딪히면 코어가 아무리 유휴 상태여도 전체 처리량은 정체됩니다. 실험 결과, 이 보행자 메모리 접근 패턴을 최적화하는 것이 CPU 점유율을 실질적으로 떨어뜨리는 핵심 파악했어요. 단순히 컴퓨트 파워가 높은 프로세서를 쓰는 것보다, 캐시 효율을 높이고 컨텍스트 스위칭을 줄이는 조치가 더 큰 효과를 보였습니다. 이는 온프레미스 환경에서 하드웨어 변경이 어려운 상황일 때, 소프트웨어 설정과 리소스 할당 전략만으로 성능을 끌어낼 수 있음을 알려줍니다.

41% 성능을 뺀 CPU·메모리 배치 전략

프로파일링 결과, CPU와 메모리의 기존 할당 방식에 숨어 있던 병목이 발견되었습니다. 처음에는 CPU 클러스터와 메모리 밴위트를 독립적으로 관리하던 방식에서, 검색 작업의 성격을 고려해 두 리소스를 보다 집중적으로 통합 조정하는 방식으로 변경했죠. 이 조정은 물리 서버를 추가 도입하거나 전력을 더 투입하지 않고서도, 동일한 하드웨어 위에서 더 많은 요청을 소화하게 만드는 마술 같은 효과였습니다. 구체적인 수치로는, baseline 대비 처리량(QPS)이 41% 증가하는 놀라운 결과가 나왔는데요. 이때도 당연히 recall@10 0.95 이상의 품질 기준은 단 한 번도 이탈하지 않았습니다. 이 경험은 벡터 DB 도입 시 ‘사양’보다 ‘배치’가 더 중요하다는 점을 여실히 보여줍니다. 같은 피스 사이즈(PIZ)라도, 어떤 프로세스에 더 많은 메모리 캐시를 우선 배정할지에 따라 시스템의 운명이 달라질 수 있거든요.

검색 조건이 바뀌면 서버 수도 바뀐다

비슷한 벡터 검색이라도 입력되는 데이터의 차원, 갱신 빈도, 최종 추출할 결과물 개수에 따라 필요한 서버 대수가 달라집니다. 예를 들어 벡터 차원이 1,536개인지 3,000개인지에 따라 메모리에 올라가는 데이터 규모가 두 배 이상 차이가 날 수 있습니다. 검색 결과가 많을수록 계산해야 할 유사도 비교 횟수가 기하급수적으로 늘어나 서버 부하가 극대화되는 경향이 있어요. 토스증권은 이러한 변수들을 하나씩 바꿔가며(측정한) 데이터를 쌓아 ‘사이징 기준표’를 만들어냈습니다. 이 표에는 특정 차원의 데이터가 얼마나 쌓였을 때, 몇 대의 서버가 어느 사양의 CPU와 메모리를 필요로 하는지 명확히 정리되어 있습니다. 벤더에서 제공하는 권장 사양표가 아니라, 실제 내 기업 환경의 워크로드에 맞춘 자립형 계산식이 된 것입니다. 이 리소스 산정식이 없다면, 트래픽 성장이 안정적일 때 서버 확장을 계획하기가 매우 두렵습니다.

당신의 Milvus, 지금 적절한 크기일까

이 글에서 공유한 과정은 특정 규모에 한정된 결과가 아니라, 모든 벡터 DB 운영팀이 반드시 거쳐야 할 설계 단계입니다. 특히 온프레미스나 프라이빗 클라우드에서 자원을 직접 제어하는 환경이라면,CPU 하나하나의 가용 시간을 아끼는 노력이 곧 돈 아끼기로 이어집니다. 여러분은 현재 운영 중인 Milvus 인스턴스의 실제 CPU 활용도가 어느 정도인지 자주 모니터링하고 계신가요? 그리고 recall 품질 저하 대비 CPU 선점 상황에서의 성능 저하 스펙트럼을 한번이라도 실측해 보셨는지요? 만약 아직이라면, 이 글의 실험 순서를 참고해 소량의 트래픽으로 우선 프로파일링 작업을 시작해 보시길 권합니다. 하드웨어 도입 예산을 다시 세워야 하는 시점이오면, 먼저 소프트웨어 컨피레이션(Configuraton)의 최적화 여지를 다 활용했는지부터 점검하는 것이 순서입니다. 데이터 인프라의 효율성은 단번에 완성되는 것이 아니라, 이런 세밀한 관찰과 반복 실험의 축적에서 태어나기 때문입니다.

자주 묻는 질문