1만 개의 벡터에서는 임베딩 검색이 쉽습니다. P99 지연 시간이 100ms 미만인 1억 개의 벡터에서는 인프라 문제가 되며, 이 패턴이 바로 이 문제를 해결합니다.

몇 천 개의 벡터로는 개발 단계에서 RAG pipeline 또는 추천 시스템이 훌륭하게 작동합니다. 이제 5천만 개의 임베딩을 가지고 있고, 쿼리는 100ms 미만의 latency를 필요로 하며, 인덱스는 계속 증가하고, 메모리를 많이 소모하고 있습니다. 수평적으로 확장하고, 메모리를 효율적으로 관리하며(모든 것이 RAM에 상주할 필요는 없습니다), 쿼리 성능을 저하시키지 않으면서 동시 쓰기를 처리하고, 기본적으로 검색 인덱스인 것에 월 1만 달러의 인프라 비용이 들지 않는 벡터 데이터베이스 아키텍처가 필요합니다.
Explore more design patterns and system architectures
MicrocosmWorks는 팀이 이미 PostgreSQL을 사용하고 있는 경우, 새로운 인프라 구성 요소를 도입할 필요가 없으며 하이브리드 SQL-plus-vector 쿼리를 기본적으로 지원하므로 500만~1,000만 개 미만의 벡터를 사용하는 프로젝트에 pgvector를 일반적으로 권장합니다. 1,000만 개 이상의 벡터를 처리하거나 높은 동시성에서 50ms 미만의 p99 지연 시간이 필요할 경우, Qdrant, Weaviate 또는 Milvus와 같은 전용 벡터 데이터베이스는 최적화된 인덱싱 알고리즘과 GPU 가속 검색을 통해 훨씬 더 나은 성능을 제공합니다. 저희는 아키텍처 검토 중에 고객의 실제 쿼리 패턴과 성장 예측을 벤치마킹하여 이러한 결정을 내릴 수 있도록 돕습니다.
MicrocosmWorks는 효율적인 검색을 위해 의미론적으로 관련된 데이터를 co-located 상태로 유지하면서, vector를 node들에 분산시키는 hash-based 또는 metadata-based sharding 전략으로 vector database clusters를 설계합니다. 우리는 관련 shard로 검색 요청을 분산시키고 전역 top-K aggregation을 사용하여 결과를 병합하며, 수십 개의 shard에 걸쳐서도 100ms 미만의 latency를 유지하는 query routing layers를 구현합니다. 우리의 monitoring dashboards는 dataset이 확장됨에 따라 hotspot이 발생하는 것을 방지하기 위해 shard balance, query distribution, 그리고 replication lag을 추적합니다.
MicrocosmWorks는 scalar quantization (float32를 int8로 줄임) 및 product quantization을 적용하여 vector storage를 4-8배 압축하며, 일반적으로 recall에서 2% 미만의 저하가 발생합니다. 이는 production에 배포하기 전에 고객의 실제 query workload에 대한 A/B testing을 통해 검증됩니다. 또한, quantized vectors가 초기 candidate retrieval에 사용되고 full-precision vectors는 상위 결과의 최종 re-ranking에만 사용되는 2단계 retrieval approach를 구현합니다. 이 하이브리드 전략을 통해 고객은 수억 개의 vectors를 극히 일부의 비용으로 저장하면서도, 비압축 작업과 구별할 수 없는 검색 품질을 유지할 수 있습니다.
MicrocosmWorks는 쓰기 내구성을 위해 동기식 복제를 사용하는 다중-복제본 구성으로 벡터 데이터베이스를 배포하고, 내결함성 및 로드 밸런싱을 위해 가용 영역에 걸쳐 분산된 읽기 복제본을 사용합니다. 당사는 노드 장애가 발생하더라도 10초 미만의 읽기 불가용성만 발생하고 데이터 손실은 전혀 없도록 상태 확인 기반의 리더 선출을 통한 자동화된 페일오버를 구성합니다. 당사의 코드형 인프라 템플릿에는 각 벡터 데이터베이스 엔진에 맞춰진 사전 구성된 백업 일정, 특정 시점 복구, 그리고 재해 복구 런북이 포함되어 있습니다.
MicrocosmWorks는 각 애플리케이션 또는 임베딩 모델이 적절한 인덱스 구성과 함께 자체적인 격리된 컬렉션을 가지도록 하는 다중 컬렉션 벡터 데이터베이스 배포를 설계하며, 동시에 비용 효율성을 위해 기본 클러스터 인프라를 공유합니다. 저희는 애플리케이션 컨텍스트를 기반으로 요청을 올바른 컬렉션으로 라우팅하고, 일치하는 모델로 쿼리 임베딩과 같은 컬렉션별 사전 처리를 적용하는 통합 쿼리 게이트웨이를 구현합니다. 이러한 멀티테넌트 벡터 데이터베이스 접근 방식은 애플리케이션별로 개별 클러스터를 운영하는 것에 비해 인프라 비용을 일반적으로 40-60% 절감합니다.
확장 가능한 벡터 데이터베이스 아키텍처는 프로덕션 규모에서 벡터 검색을 운영하는 데 따르는 과제를 해결합니다: 노드 간 인덱스 파티셔닝(sharding), 계층형 스토리지(메모리의 핫 세그먼트, SSD의 웜 세그먼트, S3의 콜드 세그먼트), 로드 밸런싱을 통한 쿼리 라우팅, 쿼리 로드 및 인덱스 크기에 기반한 autoscaling. 이 패턴은 배포 토폴로지, 용량 계획, 쓰기/읽기 격리, 비용 최적화를 다룹니다. 이는 대규모 RAG 및 추천 시스템을 가능하게 하는 인프라 계층입니다.
이 아키텍처는 쿼리 노드(read path)와 데이터 노드(write path)를 분리하여 클러스터형 토폴로지로 벡터 데이터베이스 노드를 배포합니다. 수집 파이프라인은 쿼리 latency에 영향을 미치지 않도록 쓰기 버퍼링을 통해 임베딩 생성 및 배치 upsert를 처리합니다. 쿼리 라우터는 shard 수준 병렬 처리로 읽기 복제본에 검색을 분산합니다. 계층형 스토리지는 자주 액세스되지 않는 세그먼트를 메모리에서 SSD로, 그리고 S3로 이동시키며, 투명한 쿼리 시간 로딩을 제공합니다. Autoscaling은 쿼리 QPS 및 P99 latency를 기반으로 복제본 수를 조정합니다.
| 계층 | 기술 |
|---|---|
| Vector Database | Milvus (분산), Qdrant (단일 노드/소규모 클러스터), Pinecone (관리형) |
| Storage Backend | MinIO / S3 (세그먼트 스토리지), SSD (웜 티어), RAM (핫 티어) |
| 조정 | etcd (Milvus 메타데이터), Pulsar/Kafka (write-ahead log) |
| Embedding Models | OpenAI text-embedding-3-large, Cohere embed-v4, BGE-M3, E5-large-v2 |
| 인프라 | Kubernetes (EKS/GKE) (임베딩을 위한 GPU 노드, 쿼리를 위한 메모리 최적화 노드 포함) |
| 모니터링 | Grafana + Milvus 메트릭스 익스포터, 사용자 지정 P99/recall 대시보드 |
| 사용 시기 | 피해야 할 시기 |
|---|---|
| 벡터 수가 5백만 개를 초과하고 증가하며, 수평적 확장이 필요할 때 | 벡터 수가 1백만 개 미만일 때 — 기존 PostgreSQL의 pgvector로 충분합니다 |
| 100ms 미만의 P99 쿼리 latency가 필수 요구사항일 때 | 500ms 이상의 쿼리 latency가 허용 가능할 때 — 더 간단한 옵션으로도 충분합니다 |
| 여러 애플리케이션/테넌트가 벡터 인프라를 공유할 때 | 단일 컬렉션을 가진 단일 애플리케이션일 때 — 관리형 서비스를 사용하세요 |
| 비용 최적화를 위해 계층형 스토리지가 필요할 때 (모든 것이 RAM에 있지 않아도 됨) | 예산이 완전 관리형 서비스를 허용하고, 해당 공급업체의 가격 정책이 현재 규모에 적합할 때 |
MW는 "첫날부터 적절한 크기로, 측정에 따라 확장"하는 접근 방식으로 벡터 데이터베이스 인프라를 설계합니다. 우리는 추측이 아닌 벡터 수, 차원, 인덱스 유형 및 목표 latency를 기반으로 용량 계획을 시작합니다. Kubernetes에 배포된 Milvus는 세그먼트 수, 메모리 사용량, 쿼리 latency 백분위수 및 recall 추정치를 추적하는 Grafana 대시보드를 포함합니다. 우리는 업무 시간 동안 10배의 트래픽 급증을 처리하고 밤새 스케일 다운하여, 정적 프로비저닝에 비해 인프라 비용을 40-60% 절감하는 autoscaling Milvus 클러스터를 구현했습니다.
미세 조정(fine-tuning) 없이 LLM이 데이터에 접근하도록 하세요. RAG는 범용 언어 모델과 도메인별 지식 간의 격차를 해소합니다.