Data Eng Wiki

How We Selected the Next Vector Database at Booking.com

11 min read

How we selected the next vector database at Booking.com

Author: Başak Tuğçe Eskili, Klaus Schaefers (Booking.com) | Source: booking.ai | Published: 2026-08-11

한 줄 요약

공개 벤치마크는 작은 데이터셋·합성 워크로드·낮은 동시성을 쓰므로 신뢰하지 않고 프로덕션을 최대한 닮은 자체 평가를 설계했고, 그 과정에서 가장 중요한 교훈은 특정 벤더가 아니라 평가 자체의 소유권이었다.

핵심 주장/내용

  • 왜 인프라 결정인가: 벡터 검색을 백엔드 구현 세부로 취급했지만 오늘날 그것이 사용자 경험을 직접 구동한다. 진짜 승리는 속도만이 아니라 컨텍스트다 — 효율적으로 검색할 수 있는 도메인 데이터의 다양성을 넓히는 것이 시스템에 정확하고 개인화된 경험을 전달할 컨텍스트의 깊이를 준다. 따라서 기저 벡터 DB 선택이 primary datastore나 메시지 큐를 고르는 것과 유사한 인프라 결정이 되고, 예측 가능하고 확장 가능해야 한다
  • 출발점 OpenSearch와 그것을 넘어선 지점: 사내 Embedding Service를 벡터 DB로 처음 런칭할 때 벡터 지원이 있는 OpenSearch를 골랐다. 대체로 실용적 결정이었다 — 이미 사내에 채택되어 있고, AWS에서 가용하고, Terraform으로 쉽게 프로비저닝할 수 있어 새 기술이나 운영 오버헤드를 도입하지 않고 빠르게 움직여 첫 임베딩 유스케이스를 온보딩할 수 있었다
    • 규모에서의 고통: 더 많은 팀이 채택하며 워크로드 프로파일이 크게 바뀌었다. 데이터셋이 수억 임베딩으로 커졌고, 쿼리가 종종 필터링과 결합되며 복잡해졌고, 동시성이 증가했고, 동시에 특히 사용자 대면 애플리케이션에서 레이턴시 기대가 조여졌다
    • 이 조건에서 벡터 무거운 워크로드에 범용 검색 엔진을 쓰는 것의 한계를 만났다. 수용 가능한 성능을 얻으려면 지속적 튜닝과 점점 큰 클러스터가 필요했고, 운영 오버헤드가 커지고 엔진의 내재적 한계를 보상하려 하드웨어를 확장하면서 비용이 급등했다. 근본적으로 망가진 것은 없었지만 운영하기 어려워지고 진화가 느려지고 비싸졌다. 위에 만든 고가치 유스케이스를 가능하게 하는 것보다 AWS OpenSearch 인프라를 관리하는 데 더 많은 시간을 쓰고 있었다
  • 일반 벤치마크가 적용되는지 검증: 대안을 탐색하자 공개 벤치마크와 비교 글이 많았지만 대부분 작은 데이터셋, 합성 워크로드, 낮은 동시성을 사용했다. Booking의 현실은 매우 다르다 — 대형 임베딩 데이터셋, 검색과 필터링의 결합, 고도로 동시적인 워크로드. 이 규모에서 레이턴시나 효율(목표 recall과 tail latency를 만족하는 데 필요한 CPU·RAM·클러스터 크기)의 작은 차이가 사용자 경험과 비용 둘 다에 큰 영향을 준다
    • 그래서 외부 벤치마크에 의존하지 않고 프로덕션 워크로드를 최대한 닮은 평가를 설계하기로 했다. 목표는 최고의 마케팅 수치를 가진 시스템이 아니라 우리 조건에서 가장 안정적으로 행동하는 시스템을 식별하는 것
  • 평가 설계:
    • 데이터셋 — Amazon Reviews 2023 기반으로 1억 임베딩 구성. Electronics, Baby Products, Home & Kitchen 등 카테고리의 수백만 레코드 처리. 텍스트를 벡터로 만드는 데 all-MiniLM-L6-v2 사용 — 이미 사내 모델 카탈로그에 있어 기존 프로덕션 워크로드가 쓰는 모델을 대표하고, 임베딩 품질과 추론 속도의 좋은 균형을 제공. 벡터 외에 rating과 커스텀 태그 같은 메타데이터도 저장해 filtered KNN 검색 성능을 평가 — AI 애플리케이션이 매일 마주하는 복잡한 실세계 쿼리를 복제
    • 워크로드 3종 — Full a-KNN(전체 데이터셋에 대한 근사 최근접 검색. ANN이 정확도를 속도와 교환하므로 각 시스템을 비교 가능한 목표 recall ~0.99로 튜닝해 레이턴시·처리량 결과가 낮은 검색 품질이 아니라 시스템 효율을 반영하게), Filtered a-KNN(벡터 유사도와 메타데이터 필터링 결합. 실제 사용에 더 가까운데 검색이 좀처럼 제약 없지 않고 ANN 실행 전에 메타데이터로 후보 집합을 제한하는 prefiltering이 종종 필요), 혼합 read/write(전체 연산의 약 20%를 지속 인제스션 스트림으로 도입해 실시간 갱신 시뮬레이션. closed-loop 워크로드로 각 클라이언트가 응답을 받는 즉시 다음 요청을 발행해 동시 인덱싱 압박 하의 쿼리 레이턴시를 평가)
    • 스케일링 축 — 동시성(병렬 클라이언트 5 → 50 → 100 스레드), 요청률(높은 동시성이 자연히 처리량을 올려 시스템을 포화로 밀어냄), 데이터셋 크기(소규모 편향을 피하려고 모든 워크로드를 전체 1억 벡터에 실행). 특히 P99 tail latency에 주목했는데 그것이 사용자 경험을 가장 가깝게 반영하기 때문
    • recall 측정 — ANN이 근사이므로 성능 차이가 낮은 품질의 결과 반환 때문이 아님을 검증해야 했다. 인덱스에 이미 있는 약 200만 벡터를 랜덤 샘플링해 각각을 쿼리로 쓰고, 쿼리 벡터 자신이 예상 top-k 최근접 이웃에 나타나는지 확인해 Recall@k 측정. 각 시스템의 ANN 검색 파라미터(search breadth 등)를 튜닝해 약 99%의 비교 가능한 목표 recall을 달성, 비교가 주로 검색 품질이 아니라 레이턴시·처리량·운영 특성 차이를 반영하게 했다

주요 수치 / 사실

  • 데이터셋 1억 임베딩, recall 목표 ~0.99, 동시성 5→50→100 스레드, 혼합 워크로드의 인제스션 비중 ~20%
  • 일관된 패턴: 전용 벡터 DB가 OpenSearch보다 워크로드를 효율적으로 처리했다 — 더 낮은 tail latency, 동시성 하에서 더 나은 처리량, 더 예측 가능한 스케일링 특성을, 종종 더 적은 리소스로. 그 효율이 비용으로 직결되어 비교 가능한 recall과 SLO 목표에서 OpenSearch baseline 대비 사용 비용(컴퓨트·메모리 footprint) 약 40% 감소
  • 직관적인 것을 확인: 벡터 검색을 위해 특별히 만들어진 시스템은 벡터 능력이 추가된 범용 검색 엔진과 다르게 행동한다. 평가한 옵션 중 Weaviate가 시나리오 전반에서 가장 일관된 성능을 보여 Embedding Service의 새 백엔드로 선택
  • 마이그레이션을 크게 단순화한 것은 더 일찍 내린 아키텍처 결정이었다 — 모든 DB 접근이 이미 사내 서비스 뒤로 추상화되어 클라이언트가 기저 스토리지와 직접 상호작용한 적이 없었다. 덕분에 여러 DB를 병렬로 돌리고 백엔드를 투명하게 전환할 수 있었고, 대부분의 팀에게 마이그레이션이 설정 변경 정도였다
  • 가장 중요한 교훈은 특정 벤더나 기능이 아니라 평가 자체의 소유권이다. 대규모에서 워크로드는 고도로 특수하고 일반 벤치마크가 실세계 동작을 반영하는 경우가 드물다. 자체 프로덕션 형태 테스트를 돌린 것이 실제로 중요한 조건에서 선택한 시스템이 버틸 것이라는 확신을 주었다
  • 벡터 검색이 현대 ML·AI 시스템의 기초 인프라가 되었다. 다른 중요한 datastore와 같은 엄격함으로 취급하고, 현실적으로 테스트하고, 스토리지 레이어를 추상화하고, 최고 수치가 아니라 안정성을 최적화한 것이 큰 차이를 만들었다

관련 위키

Source: 원문 보기

그래프 뷰

백링크