설계에 의한 디커플링: 수십억 규모 벡터 검색

Decoupled by Design: Billion-Scale Vector Search

발행일: 2026년 3월 9일

작성자: Zero Qu, 에릭 린드그렌, Sheng Zhan, Ankit Vij, 세르게이 차레프 , 디마 코틀야로프

소개

벡터 검색은 제품 내 검색부터 추천 시스템, 개체 확인, 검색 증강 생성에 이르기까지 AI 애플리케이션의 기본 인프라가 되었습니다. 그러나 데이터세트가 수백만에서 수십억 개의 벡터로 증가함에 따라 이를 처리하기 위해 구축된 시스템이 비용이 많이 드는 방식으로 고장 나기 시작합니다. 메모리 비용이 폭발하고, 수집이 서빙을 지연시키며, 확장을 위해서는 모든 것을 복제해야 합니다.

Databricks에서는 기존 벡터 검색 서비스의 한계에 부딪혔고, 이에 따라 기본 원칙으로 돌아가 처음부터 다시 설계했습니다. 현재 Databricks 벡터 검색은 두 가지 배포 옵션을 제공합니다. 전체 정밀도 벡터를 메모리에 완전히 유지하여 수십 밀리초의 지연 시간을 보장하는 Standard 엔드포인트와, 스토리지와 컴퓨팅을 분리하여 훨씬 저렴한 비용으로 수십억 개의 벡터를 제공하는 Storage Optimized 엔드포인트가 있습니다. 후자는 수백 밀리초의 쿼리 지연 시간을 가지며, 이는 밀리초 단위의 낮은 응답 시간보다 비용과 규모가 더 중요한 워크로드를 위한 의도적인 절충안입니다.

스토리지 최적화 벡터 검색 은 세 가지 핵심 엔지니어링 결정에 의해 형성되었습니다.

스토리지와 compute의 분리. 벡터 인덱스는 클라우드 객체 스토리지에 있으며 서빙 시에만 메모리에 로드됩니다. 수집은 쿼리 경로와 완전히 격리된 임시 서버리스 Spark 클러스터에서 실행됩니다.
Spark 기반의 분산 인덱싱 알고리즘 구축. 단일 머신 인덱싱 라이브러리에 의존하는 대신, 저희는 분산 클러스터링, 벡터 압축, 파티션 정렬 데이터 layout을 클러스터 크기에 따라 선형적으로 확장되는 네이티브 Spark 작업으로 자체 개발했습니다.
듀얼 런타임 아키텍처를 갖춘 Rust 엔진에서 쿼리를 처리합니다. 특수 목적의 쿼리 엔진은 비동기 I/O와 CPU 바운드 벡터 계산을 위해 별도의 스레드 풀을 사용하므로 서로를 방해하지 않습니다.

그 결과 10억 벡터 인덱스를 8시간 이내에 구축하고 20배 더 빠른 인덱싱, 최대 7배 낮은 서빙 비용을 달성했습니다.

이 게시물은 저희가 어떻게 그것을 구축했는지에 대한 엔지니어링 스토리입니다.

기존 벡터 데이터베이스의 문제점

긴밀한 결합의 한계

당사의 Standard Vector Search를 포함한 많은 프로덕션 벡터 데이터베이스는 분산 키워드 검색에서 차용한 공유 아키텍처가 없는(shared-nothing) 아키텍처를 따릅니다. 각 노드는 데이터 세트의 무작위 샤드를 소유하고 전체 정밀도 벡터에 대해 독립적인 인메모리 HNSW(Hierarchical Navigable Small World) 그래프를 유지합니다. HNSW는 뛰어난 검색 품질을 제공하지만, 그래프 자체는 전적으로 메모리에 상주해야 하므로 확장하는 데 가장 비용이 많이 드는 구성 요소 중 하나가 됩니다. 이 설계는 짧은 지연 시간을 제공하고 트랜잭션 업데이트를 지원합니다. 수억 개의 벡터까지는 잘 작동합니다.

수십억 개에 이르면 시스템이 무너집니다.

핵심 문제는 결합입니다. 인덱스, 가공되지 않은 데이터, 그리고 이를 제공하는 compute는 모두 동일한 노드에 바인딩됩니다. 확장이란 모든 것을 복제하는 것을 의미합니다. 더 많은 벡터는 더 많은 메모리를 필요로 하고, 이는 더 많은 노드를 필요로 하며, 각 노드는 해당 샤드의 인덱스와 데이터의 전체 복사본을 전달합니다. 컴퓨팅과 독립적으로 스토리지를 확장할 수 있는 방법은 없습니다.

이 결합은 수집(ingestion)까지 확장됩니다. 인덱스 빌딩은 검색 엔진 자체 내부에서 이루어집니다. 쿼리를 처리하는 동일한 컴퓨팅 리소스가 데이터 재구성, 인덱스 재구축, 압축도 처리합니다. 쓰기 작업이 많은 워크로드에서는 쿼리 지연 시간이 저하됩니다. 쿼리가 많은 워크로드에서는 수집(ingestion) 속도가 매우 느려집니다. 더 나쁜 것은 업서트(upsert), 삭제, 압축(compaction)과 같은 모든 데이터 변경이 하위 인덱스 재구축을 트리거하여, 쿼리를 처리하는 대신 유지보수에 CPU 사이클을 소모한다는 점입니다.

메모리 상주 인덱스는 비용이 많이 듭니다.

바로 그 인메모리 상주 방식 때문에 아키텍처가 빠르면서도 비용이 많이 듭니다. 768차원과 32비트 부동 소수점을 사용할 경우, 1억 개의 벡터는 인덱스 오버헤드를 제외하고 벡터 자체만으로도 약 286GiB의 RAM을 소비합니다. 10억 개의 벡터에는 테라바이트급 용량이 필요합니다. 기가바이트당 비용이 미미한 디스크 또는 객체 스토리지와 달리 메모리는 스택에서 가장 비싼 리소스입니다. 벡터가 추가될 때마다 RAM 요금이 직접적으로 증가합니다.

무작위 샤딩은 문제를 더욱 복잡하게 만듭니다. 벡터가 시맨틱 유사성과 관계없이 분산되기 때문에, 각 샤드의 관련성에 상관없이 모든 쿼리는 모든 샤드로 분산(scatter)된 다음 결과를 수집(gather)해야 합니다. CPU, 네트워크 오버헤드, 테일 레이턴시는 모두 샤드 수에 따라 증가합니다. 벡터를 추가하면 샤드도 추가해야 하며, 모든 새 샤드는 자체적인 메모리 상주 인덱스를 가집니다.

설계에 의한 분리

해답은 이 아키텍처 내에서 최적화하는 것이 아니라 결합 자체를 끊는 것입니다.

스토리지 최적화 벡터 검색은 모든 데이터가 클라우드 객체 스토리지에 있고 쿼리 노드는 상태 비저장이라는 단일 전제에서 시작합니다. 이로써 시스템은 두 가지 경계를 따라 분할됩니다. 즉, query 노드가 데이터를 소유하지 않도록 스토리지를 compute와 분리하고, 인덱스 빌드가 실시간 query와 경쟁하지 않도록 수집(ingestion)을 서빙과 분리합니다. 이를 통해 3계층 아키텍처가 탄생합니다:

수집 계층. 서버리스 Spark 의 분산 파이프라인이 가공되지 않은 데이터부터 완성된 인덱스까지 모든 인덱스 빌드를 처리합니다. 각 실행은 멱등성(idempotent)을 가지며 재시도할 수 있습니다.
스토리지 계층. 사용자 지정 클라우드 네이티브 스토리지 형식은 기록 시스템 역할을 합니다. 가공되지 않은 데이터 및 벡터 인덱스를 위한 열 기반 파일 형식과 키워드 검색을 위한 역 인덱스 형식을 결합하며, 이 모든 것은 불변의 데이터 조각을 사용하는 ACID 트랜잭션 하에 있습니다.
쿼리 레이어. 두 개의 무상태 서비스가 읽기를 처리합니다. 벡터 검색 서비스는 압축된 인덱스를 메모리에 보관하고 필요 시 객체 스토리지에서 전체 정밀도 데이터를 가져옵니다. 키워드 검색은 메타데이터 필터링 및 키워드 검색을 위한 역인덱스를 제공합니다. 두 서비스 모두 독립적으로 확장되므로 워크로드에 맞게 리소스를 조정할 수 있습니다.

객체 스토리지를 위한 인덱스 구조

데이터가 객체 스토리지에 있는 경우 인덱스는 분할 가능해야 합니다. 즉, 쿼리 엔진은 전체 구조를 메모리에 로드하는 대신 관련 슬라이스만 가져와야 합니다.

HNSW 그래프는 그러한 속성을 갖지 않습니다. 각 검색 홉은 그래프의 어느 곳으로든 이동할 수 있으므로 단일 쿼리를 처리하려면 전체 구조가 메모리에 상주해야 합니다. HNSW 그래프를 객체 스토리지 파일에 매핑되는 조각으로 분할할 자연스러운 방법은 없습니다.

IVF(Inverted File Index)는 다른 접근 방식을 취합니다. 즉, 학습된 중심점(centroid)을 기준으로 근접성에 따라 벡터를 클러스터링하고 쿼리 시 가장 가까운 클러스터만 검색합니다. 각 클러스터는 객체 스토리지의 데이터 조각에 직접 매핑되므로 나머지 인덱스를 로드하지 않고도 독립적으로 가져올 수 있습니다.

이 알고리즘 선택은 데이터가 저장된 위치에 따라 직접적으로 결정됩니다. 표준 벡터 검색은 속도를 위해 전체 인덱스를 메모리에 유지하며, 이는 스토리지와 컴퓨팅을 하나로 묶습니다. 스토리지 최적화는 확장을 위해 데이터를 객체 스토리지로 이동시켜 이를 분리하지만, 자체 포함되어 가져올 수 있는 파티션으로 분해되는 인덱스가 필요합니다. IVF는 바로 이러한 기능을 제공합니다.

Spark를 이용한 분산 벡터 인덱싱

IVF는 분리된 저장소에 적합한 인덱스 구조를 제공합니다. 엔지니어링 과제는 이를 대규모로 구축하는 것입니다. 대부분의 벡터 인덱싱 라이브러리(FAISS, ScaNN, Annoy)는 모든 데이터가 단일 머신에 맞는다고 가정합니다. 이는 수천만 개의 벡터 규모에서 작동합니다. 768차원 임베딩을 사용하는 10억 개의 벡터에서는 인덱스 구축을 시작하기도 전에 테라바이트 규모의 원시 부동 소수점 데이터를 처리해야 합니다. 단일 머신으로는 이를 원활하게 처리할 수 없으며, 설령 처리하더라도 새로운 행이 추가될 때마다 수집 시간은 점점 길어지는 직렬 병목 현상이 발생합니다.

수평적으로 확장되는 인덱싱이 필요했습니다. 그래서 저희는 분산 K-평균, 프로덕트 양자화(Product Quantization), 파티션 정렬 데이터 레이아웃과 같은 모든 인덱싱 알고리즘을 임시 serverless Spark 클러스터에서 실행되는 네이티브 PySpark 작업으로 처음부터 구현했습니다. 주요 경로에는 단일 머신 인덱싱 라이브러리가 없습니다. 실행기(executor)를 더 많이 추가하면 가장 비용이 많이 드는 단계의 시간이 선형적으로 단축됩니다.

수집 파이프라인

각 수집 실행은 ACID 트랜잭션으로 래핑된 방향성 비순환 그래프(DAG) 단계로 실행됩니다.

파이프라인은 소스 Delta Table에서 시작됩니다. 소스 텍스트(사전 계산된 벡터가 아닌)를 기반으로 하는 인덱스의 경우, 파이프라인은 소스 데이터를 검증한 후 Mosaic AI Model Serving 을 호출하여 새 행이나 업데이트된 행에 대한 벡터 임베딩을 생성함으로써 수십억 개의 텍스트 레코드를 대규모로 고차원 벡터로 변환합니다.

거기에서 파이프라인은 작은 샘플에 대해 학습하여 벡터 공간의 구조를 학습한 다음 해당 구조를 전체 데이터 세트에 적용하여 모든 벡터를 파티션에 할당하고 압축한 후 결과를 객체 스토리지에 씁니다. 학습은 저렴합니다. 실행기 간에 테라바이트의 데이터를 셔플링하는 전체 데이터 세트 패스에 실제 시간이 소요됩니다.

K-평균: 대규모 파티셔닝

K-평균 클러스터링은 벡터 공간을 여러 영역으로 분할합니다. 이는 쿼리가 전체 데이터 대신 데이터의 일부만 검색할 수 있게 해주는 IVF 파티션입니다. 10억 행 데이터세트의 경우 약 32K개의 파티션을 생성합니다. 문제는 표준 구현에서는 모든 데이터가 단일 머신에 적합하다고 가정하는데, 이러한 규모에서 어떻게 K-평균을 실행하느냐는 것입니다.

Spark에서 처음부터 구축합니다.

저희 구현은 하이브리드 모델을 사용합니다. Spark는 분산 데이터 이동을 처리하고, 하드웨어 가속 선형 대수를 지원하는 수치 연산 라이브러리인 JAX 는 각 실행기(executor) 내부의 수학 연산을 처리합니다. 각 K-평균 반복은 3단계 Spark 파이프라인으로 구성됩니다:

할당(Assign) — 각 실행기는 로컬 벡터 배치와 모든 현재 중심점(centroid) 간의 거리를 계산하여 각 벡터의 가장 가까운 클러스터를 찾습니다.
셔플(Shuffle) — Spark는 중심점 ID를 기준으로 데이터를 재분할하여 동일한 클러스터에 할당된 모든 벡터를 같은 위치에 배치합니다.
집계(Aggregate) — 각 실행기는 같은 위치에 배치된 벡터들로부터 새로운 중심점 위치를 계산합니다.

거리 계산이 가장 빈번하게 실행되는 루프(hot loop)입니다. JAX는 이를 실행기당 단일 배치 행렬 연산으로 컴파일하여 개별 벡터를 반복하는 대신 전체 배치-중심점 거리 행렬을 한 번에 계산합니다.

학습은 전체 데이터 세트가 아닌 샘플에 대해 실행됩니다. 예를 들어 10억 개의 행의 경우 약 800만 개의 벡터(데이터의 약 0.8%)입니다. 이는 임의적인 것이 아닙니다. K-평균 반복당 비용은 O(n × k × d)이며, 여기서 n은 샘플 크기, k는 클러스터 수, d는 차원입니다. n과 k를 모두 √N에 비례하도록 설정하면 총 학습 비용이 O(N × d)가 되어 규모에 관계없이 데이터 세트 크기에 선형적으로 비례합니다.

이 선택은 통계적으로도 타당합니다. 코어셋 이론(coreset theory) 에 따르면 잘 분산된 데이터에서 고품질 K-평균 클러스터링을 수행하기 위해서는 O(k)개의 샘플이면 충분하며, k는 √N에 따라 확장되므로 샘플 크기가 충분하다는 것이 입증됩니다. 학습은 몇 번의 반복으로 완료되며, 다운스트림 파이프라인 단계를 위해 중심점을 객체 스토리지에 체크포인트합니다.

제품 양자화(Product Quantization): 64배 메모리 압축

K-평균은 대략적인 파티션을 제공합니다. 곱 양자화(PQ)는 벡터를 압축하여 대규모로 검색할 수 있게 해줍니다. 아이디어는 각 768차원 벡터를 16차원짜리 48개의 하위 벡터로 분할하고, 각 하위 벡터를 학습된 코드북에서 가장 가까운 항목을 가리키는 단일 바이트로 대체하는 것입니다. 3,072바이트 벡터가 48바이트가 되어 64배의 압축률을 보입니다. 10억 개의 768차원 벡터의 경우, 거의 3TiB에 달하는 가공되지 않은 데이터가 약 45GiB로 줄어듭니다.

압축은 손실이 있지만, 핵심적인 설계 선택으로 대부분의 정확도를 복구합니다. 즉, 원시 임베딩 대신 잔차 벡터 (각 임베딩과 가장 가까운 K-평균 중심점 간의 차이)에 대해 PQ를 훈련합니다. K-평균은 대규모 구조를 포착하고, PQ는 각 파티션 내의 세분화된 변동만 인코딩하면 됩니다.

학습에서 스토리지까지

샘플에 대해 학습된 중심점 및 PQ 코드북을 사용하여 파이프라인은 이제 모든 행을 처리하여 각 벡터에 파티션 ID(가장 가까운 중심점)와 압축된 PQ 코드를 할당합니다. 10억 행 데이터세트의 경우 이는 파이프라인에서 가장 데이터 집약적인 단계입니다. 즉, 모든 실행기에서 거리와 인코딩을 계산하는 전체 데이터세트 Spark 작업입니다.

그다음은 셔플 단계입니다. 파이프라인은 파티션 ID를 기준으로 전체 데이터 세트를 재분할하여 동일한 IVF 파티션의 벡터를 객체 스토리지의 동일한 데이터 조각에 물리적으로 함께 배치합니다. 이 작업은 테라바이트 규모의 데이터가 실행기(executor) 간에 이동하기 때문에 비용이 많이 들지만, 쿼리 속도를 높여주는 핵심 요소입니다. 공동 배치가 없으면 단일 IVF 파티션을 탐색할 때 수천 개의 파일에 걸쳐 분산된 읽기가 발생하게 됩니다. 공동 배치가 있으면 동일한 탐색 시 몇 개의 연속된 조각에만 접근합니다.

쓰기는 각각 다른 쿼리 경로에 최적화된 세 가지 출력을 생성합니다.

벡터 인덱스 — 빠른 ANN 검색을 위해 쿼리 엔진이 메모리로 로드하는 형식으로 작성된 압축된 PQ 코드 및 파티션 메타데이터입니다.
키워드 인덱스 — 메타데이터 필터링 및 하이브리드 키워드 검색을 위한 역인덱스 파일입니다.
가공되지 않은 데이터 — 순차적 스캔과 무작위 액세스 모두에 최적화된 열 기반 형식으로 저장된 전체 정밀도 임베딩으로, 재순위 지정 중에 온디맨드 방식으로 가져옵니다.

세 가지 모두 불변의 프래그먼트로 작성됩니다. 즉, 일단 작성되면 절대 수정되지 않습니다. 쓰기가 완료되면 버전 매니페스트가 새 인덱스를 원자적으로 게시합니다. 이것이 수집과 서빙 간의 약속입니다. 즉, 쿼리 엔진이 직접 읽을 수 있도록 객체 스토리지에 준비된 일련의 불변하고 파티션에 정렬된 데이터 프래그먼트입니다.

대규모 수집

스토리지 최적화는 768차원에서 10억 개가 넘는 벡터 인덱스를 지원합니다. 이는 최대 3억 2천만 개의 벡터로 제한되는 표준 벡터 검색의 단계적 변화입니다.

수집은 서빙과 완전히 분리된 임시 Spark 클러스터에서 실행되기 때문에, 확장하려면 실행기(executor)를 추가하기만 하면 됩니다. 실제로 이는 프로덕션 인덱스 빌드 전반에 걸쳐 획기적인 개선 으로 이어집니다.

인덱스를 작성하고 객체 스토리지에 원자적으로 게시한 후의 다음 질문은 프로덕션 환경에서 쿼리를 충분히 빠르게 처리하는 방법입니다.

객체 스토리지를 위한 쿼리 엔진

스토리지와 컴퓨팅을 분리하면 비용 문제가 해결됩니다. 하지만 새로운 문제가 발생합니다. 이제 모든 쿼리가 객체 스토리지로의 네트워크 왕복을 포함하게 됩니다. 메모리에 들어갈 만큼 작은 압축 인덱스는 startup 시 로드되지만, 전체 정밀도 임베딩은 블롭 스토리지에 남아 있으며 온디맨드 방식으로 가져오거나 로컬 디스크 캐시에서 제공됩니다. 서빙 계층은 노드 외부로 데이터를 이동해도 쿼리 지연 시간에 영향을 주지 않을 만큼 충분히 빨라야 합니다.

쿼리 분석

최근접 이웃 검색이 엔진에 도달하면 다음과 같은 일이 발생합니다.

파싱 및 라우팅(I/O). gRPC 요청은 비동기 I/O 런타임에 도착하여 역직렬화된 후 올바른 색인으로 라우팅됩니다.
ANN 검색(CPU). 쿼리 벡터는 IVF 클러스터 중심점과 비교하여 가장 관련성이 높은 파티션을 식별합니다. 이러한 파티션만 조사하여 압축된 벡터를 스캔하고 근사 거리를 계산합니다. 양자화된 거리는 근사치이고 초기 범위를 넓히면 재순위 지정 후 최종 재현율이 향상되므로 검색은 의도적으로 후보를 초과하여 가져옵니다. 예를 들어 호출자가 10개를 요청할 때 400개를 가져옵니다.
전체 정밀도 벡터 가져오기 (I/O). 동시 바이트 범위 읽기는 클라우드 스토리지에서 각 후보에 대한 원시 임베딩을 가져옵니다. 수집 파이프라인이 동일한 IVF 파티션의 행을 동일한 데이터 조각에 함께 배치하기 때문에, 이러한 읽기는 파티션 프루닝(partition-pruned)되어 전체 데이터 세트에 무작위로 액세스하는 대신 소수의 파일에만 접근합니다. 이 단계는 엔드투엔드 지연 시간의 대부분을 차지합니다.
재순위화(Re-rank) (CPU). 전체 정밀도 임베딩은 정확한 거리 계산을 사용하여 점수를 매겨 압축으로 인해 손실된 정확도를 복구합니다.
직렬화 및 반환(I/O). 최종 상위 N개 결과는 연관된 메타데이터와 함께 직렬화되어 호출자에게 반환됩니다.

모든 쿼리는 비동기 I/O와 CPU 바운드 계산을 번갈아 수행합니다. 거리 계산이 비동기 런타임을 차단하면 보류 중인 스토리지 읽기가 쌓이고 지연 시간이 급증합니다.

두 개의 런타임

해결책은 이들이 동일한 스레드를 두고 경쟁하지 않도록 하는 것입니다. 쿼리 엔진은 GC 중지 없이 예측 가능한 지연 시간을 위해 Rust로 작성되었으며, 실행을 두 개의 전용 스레드 풀(하나는 비동기 I/O용, 다른 하나는 CPU 바운드 벡터 연산용)로 분할합니다. 어느 워크로드도 다른 워크로드를 방해할 수 없습니다.

I/O 런타임 은 Tokio 비동기 실행기에서 실행되며 gRPC 요청 구문 분석, 블롭 스토리지 범위 읽기, 서비스 간 통신 및 응답 직렬화를 처리합니다. 스토리지 읽기가 지연 시간의 병목 현상을 유발하므로 이 런타임은 차단 없이 수백 개의 동시 요청을 처리해야 합니다.

컴퓨팅 런타임 은 자체 스레드 풀에서 벡터 거리 계산, 파티션 프로빙, 재순위화를 실행합니다. CPU 코어의 일부는 I/O 런타임을 위해 명시적으로 예약되어 있으며, compute가 전체 머신을 소비하는 것은 절대 허용되지 않습니다.

읽기 병합(Read Coalescing)

스레드 격리 외에도 I/O 경로 자체도 조정이 필요했습니다. 초기 프로파일링 결과 엔진이 객체 스토리지에 많은 작은 단일 벡터 범위 읽기를 실행하고 있음이 드러났습니다. 각 호출에는 요청당 오버헤드와 지연 시간 변동성(수백 밀리초에 달하는 롱테일 포함)이 수반되므로, 작은 요청이 많다는 것은 쿼리당 지연 시간 분산이 높다는 것을 의미했습니다.

해결책은 읽기 병합(read coalescing) 이었습니다. 즉, 벡터당 하나의 범위 읽기를 실행하는 대신 스토리지 계층이 보류 중인 바이트 범위 요청을 파일 오프셋별로 정렬하고 구성 가능한 블록 크기 창 내에 있는 모든 요청을 단일 읽기로 병합합니다. 요청 수가 적고 크기가 클수록 호출당 오버헤드가 줄어들지만, 병합된 각 읽기는 쿼리에 필요하지 않은 바이트도 가져오게 됩니다. 바로 읽기 증폭(read amplification)입니다. 이 트레이드오프는 경험적 튜닝이 필요했습니다.

64KiB에서는 각 데이터 조각에 20회 이상의 스토리지 호출이 필요했지만, 가져온 데이터는 0.5MB 미만이었습니다. 즉, 요청당 오버헤드가 대부분을 차지했습니다. 블록 크기를 두 배로 늘리자 호출 수가 꾸준히 감소했고, 256KiB까지는 지연 시간이 개선되었습니다. 하지만 그 지점을 지나자 읽기 증폭(read amplification)이 주된 요인이 되었습니다. 512KiB에서는 호출 수가 훨씬 적었음에도 불구하고 지연 시간이 64KiB 기준선보다 다시 높아졌습니다. 2MiB에서는 15초 이상으로 폭증했습니다. 256KiB라는 최적의 지점에서는 조각당 읽기 증폭을 2MiB 미만으로 유지하면서 호출 수를 약 절반으로 줄여, 테스트한 구성 중 가장 낮은 p50 지연 시간을 기록했습니다.

종합하기

이 아키텍처의 모든 것은 확장성 및 비용을 위해 쿼리 지연 시간을 절충합니다. 768차원 및 상위 10개 결과에서 재현율(반환된 실제 최근접 이웃의 비율)은 1,000만 개 벡터에서 94% 이상, 1억 개에서 91% 이상, 10억 개에서도 90%를 유지합니다. 객체 스토리지에서 전체 정밀도 벡터를 가져와 정확한 거리를 다시 계산하는 재순위 지정 단계는 압축된 코드만으로는 대규모에서 손실될 정확도를 복구합니다. 이러한 재순위 지정 왕복은 쿼리 시간을 좌우하는 요소이기도 합니다. 모든 것을 메모리에 보관하는 Standard 엔드포인트에서 20~50밀리초가 걸리는 것과 비교하여 쿼리는 1,000만 개 벡터에서 약 300밀리초, 10억 개에서 약 500밀리초 내에 반환됩니다.

이 추가 밀리초로 얻을 수 있는 이점은 다음과 같습니다. 10억 벡터 규모의 인덱스 빌드는 8시간 이내에 완료되며, 이는 대규모 데이터 세트에서 Standard보다 20배 더 빠릅니다. 제품 Quantization은 인메모리 사용량을 10배 이상 압축하고, 수집은 각 빌드 후 리소스를 해제하는 임시 Spark 클러스터에서 실행되며, 스토리지와 서빙을 분리하면 어느 쪽도 과도하게 프로비저닝되지 않습니다. 그 결과 고객은 동일한 규모에서 최대 7배 저렴한 비용 을 누릴 수 있습니다.

시맨틱 검색, 추천 파이프라인, 검색 증강 생성과 같은 많은 워크로드의 경우, 이러한 트레이드오프는 명확하게 확장성과 비용에 유리합니다. 검색 후 단계(랭킹, 필터링, LLM 생성)는 종종 엔드투엔드 시간의 대부분을 차지하여, 40밀리초와 400밀리초의 차이를 최종 사용자에게 보이지 않게 만듭니다. 1밀리초가 중요한, 지연 시간에 민감한 서빙의 경우 Standard Vector Search가 더 나은 도구입니다. 두 가지 옵션은 상호 보완적이며, 서로 다른 워크로드를 위한 서로 다른 도구입니다.

배운 점

기존 시스템을 최적화하는 대신 벡터 검색 시스템을 처음부터 구축함으로써 조합을 통해서만 성과를 거둘 수 있는 일련의 시도를 강행했습니다.

스토리지와 compute의 분리는 query 엔진이 충분히 빠른 경우에만 효과가 있습니다. 데이터를 노드 외부로 이동하면 비용이 절감되지만, 오브젝트 스토리지에 대한 네트워크 왕복이든 로컬 디스크 캐시에서의 읽기이든 모든 쿼리에 I/O가 추가됩니다. 듀얼 런타임 Rust 엔진은 바로 그 지연 시간을 흡수하기 위해 존재합니다. 비동기 I/O는 수백 개의 읽기 작업을 동시에 처리하는 한편, CPU 스레드는 블로킹 없이 거리 계산을 처리합니다. 그 엔진이 없었다면 이 아키텍처는 저렴한 스토리지와 느린 쿼리를 제공했을 것이며, 이는 매력적인 절충안이 아닙니다.

분산 색인 생성은 색인 형식이 이를 지원하는 경우에만 작동합니다. Spark에서 K-평균과 PQ를 구축하면 수집을 수평적으로 확장할 수 있지만, 출력은 쿼리 엔진이 재구축 단계 없이 객체 스토리지에서 직접 처리할 수 있는 형태여야 합니다. 사용자 정의 스토리지 형식, 즉 불변 데이터 조각, 분리된 트랜잭션 매니페스트, 클라우드 스토리지의 ACID 의미 체계가 이러한 선순환 구조를 완성합니다. 수집은 쿼리 엔진이 읽는 형식으로 직접 데이터를 씁니다.

압축은 경제적 수단입니다. 프로덕트 양자화(Product Quantization)는 메모리 비용만 줄이는 것이 아닙니다. 이는 아키텍처의 실행 가능성 자체를 바꿉니다. 이 수준의 압축이 없으면 10억 개 벡터에 대한 양자화된 코드를 메모리에 저장하는 데 여전히 테라바이트의 RAM이 필요하며 표준 벡터 검색에 대한 비용 이점은 사라집니다. PQ를 사용하면 ANN 검색 단계를 메모리에 유지하면서 다른 모든 것을 객체 스토리지로 푸시할 수 있습니다.

이들은 서로 독립적인 최적화가 아닙니다. 이 중 하나라도 제거하면 시스템 비용이 너무 많이 들거나 빌드 또는 서빙 속도가 너무 느려져 실용성이 떨어집니다.

결론

앞으로의 어려운 문제들은 이러한 트레이드오프에서 직접적으로 비롯됩니다. 더 스마트한 캐싱, 계층형 스토리지, 더 밀도 높은 인메모리 표현을 통해 쿼리 성능(더 빠른 응답, 더 높은 처리량, 더 나은 동시성)을 더욱 향상시키는 것입니다. 수십억 규모에서 거의 실시간으로 업데이트합니다. 최종 순위 신호로서의 원시 벡터 거리를 넘어, 벡터 유사성, 키워드 관련성 및 도메인 컨텍스트를 결합하여 가장 가깝기만 한 것이 아니라 가장 유용한 결과로 만드는 학습된 다단계 순위 지정으로 나아가고 있습니다.

우리는 차세대 AI 제품이 아직 발명되지 않은 인프라를 기반으로 구축될 것이며, 그 인프라를 구축하는 엔지니어들이 AI의 가능성을 만들어갈 것이라고 믿습니다. 여러분도 그중 한 명이 되고 싶다면, 우리와 함께 만들어 가세요!

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)

소개