퍼플렉시티, 다이나모DB 대신 자체 개발 코블DB로 전환

ai.euno.news 자동 뉴스 요약

퍼플렉시티(Perplexity)가 검색 서빙 계층의 핵심 데이터베이스를 아마존 다이나모DB(DynamoDB)에서 자체 개발한 러스트(Rust) 기반 분산 키-값 저장소 코블DB(CobbleDB)로 교체했다. 인포큐(InfoQ)에 따르면 이번 전환으로 배치 읽기 지연시간이 5배 줄었고, 스토리지 비용도 20% 이상 절감됐다¹.

문제의 발단은 AI 답변 엔진 특유의 읽기 패턴이었다. 퍼플렉시티에서는 질의 하나가 들어오면 100120개의 페이지 키가 생성되고, 이는 다시 1020개 단위의 병렬 배치로 쪼개져 조회된다. 짧은 메타데이터 스니펫만 반환하는 기존 검색엔진과 달리, LLM에 넘길 데이터는 청크 단위 본문과 밀집 벡터 임베딩까지 포함해야 해서 레코드 하나의 평균 크기가 약 50KB에 달했다. 초당 20만 건이 넘는 요청이 몰리는 상황에서 바이트 단위로 과금하는 다이나모DB 비용 구조는 감당하기 어려운 수준이 됐다.

비용만이 문제는 아니었다. 다이나모DB는 파티션 배치, 메모리 캐싱 정책, 레플리카 라우팅을 사용자에게 감추는 블랙박스 방식으로 동작한다. 엔지니어들은 캐시 미스, 가용 영역 간 네트워크 홉, 지연되는 레플리카 때문에 생기는 테일 레이턴시 스파이크를 통제할 방법이 없었다. 여기에 청킹 알고리즘 갱신이나 새 임베딩 모델 적용 때마다 발생하는 대량 재처리 작업이 실시간 사용자 요청과 같은 테이블에 몰리면서 이른바 노이지 네이버(noisy neighbor) 경합까지 겹쳤다.

퍼플렉시티는 이 문제를 저장소 하나로 풀지 않고 세 갈래로 분리했다. 필러(Pillar)는 YT사우루스(YTsaurus) 위에서 대용량 HDD를 이용해 웹페이지 메타데이터, 본문 조각, 벡터 표현을 버전 관리하며, 원자적 트랜잭션으로 크롤링 갱신·상태 변경·익스포트 큐를 함께 커밋한다. 로리(Lorry)는 상태를 갖지 않는 큐 소비자로, 필러가 내보낸 데이터를 파티션 단위 배치 파일로 묶어 아마존 S3에 저장하고 메타데이터만 코블DB에 알린다. 코블DB 워커 노드는 이 S3 배치를 독립적으로 가져와 적재하기 때문에, 쓰기 부하가 큰 크롤링 파이프라인과 지연시간에 민감한 서빙 경로가 완전히 분리된다.

코블DB 자체는 배치 조회에만 최적화된 분산 키-값 저장소다. 각 파티션은 독립된 컴퓨트 노드 세 곳에 레플리카를 두고, 코어 데몬은 로컬 NVMe SSD와 메모리 매핑 캐시를 결합한 로크스DB(RocksDB)를 임베디드 스토리지 엔진으로 쓴다. 상태를 갖지 않는 쿼리 라우터는 해시된 페이지 ID를 파티션에 매핑하고, 네트워크 오버헤드를 줄이기 위해 같은 가용 영역 안의 레플리카로 요청을 먼저 보낸다. 대상 레플리카의 응답이 느려지면 다른 노드의 레플리카로 동시에 투기적 읽기를 보내 지연을 숨긴다. 노드 내부에서는 로크스DB의 배치 멀티겟(MultiGet) 인터페이스로 여러 키를 한 번에 조회해 왕복 횟수를 줄였다.

설계에서 눈에 띄는 대목은 분산 트랜잭션 프로토콜과 동기 합의 알고리즘을 아예 배제했다는 점이다. 검색 서빙은 약간의 복제 지연을 감수할 수 있다는 전제 아래, 레플리카는 각자의 속도로 비동기 갱신을 적용한다. 정합성보다 처리량과 지연시간을 우선한 선택으로, 코블DB가 범용 데이터베이스가 아니라 퍼플렉시티의 특정 워크로드에 맞춰 만든 전용 시스템이라는 점을 그대로 드러낸다.

읽기 목록은 이 브라우저에 저장됩니다.