DynamoDB가 병목 현상이 된 이유
Perplexity의 검색 API는 까다로운 워크로드를 처리합니다. 각 요청은 일반적으로 10~20개씩 배치로 묶여 약 100~120개의 페이지 키를 가져옵니다. 각 레코드는 평균 약 50KB로, 쿼리당 상당한 데이터 볼륨을 차지합니다. 이러한 액세스 패턴은 빠르게 확장되는 웹 인덱스와 결합되어 사용량 기반 과금 모델의 한계를 빠르게 드러냈습니다.
DynamoDB의 비용 구조는 읽거나 쓰는 모든 바이트에 대해 요금을 청구합니다. Perplexity의 데이터 인덱스가 커지고 프로덕션 트래픽이 증가함에 따라, 이러한 바이트 단위 읽기 비용이 선형적으로 증가하여 관리형 데이터베이스의 비용 부담이 점점 커졌습니다. 이러한 경제적 압박은 Perplexity가 데이터베이스 전략을 재평가하게 된 중요한 동기가 되었습니다.
비용 외에도 DynamoDB의 관리형 특성은 중요한 제어 제한을 가했습니다. Perplexity는 특정 액세스 패턴에 최적화하기 위해 근본적인 데이터베이스 동작을 조정할 수 없었습니다. 엔지니어들은 다음 사항을 결정할 능력이 부족했습니다:
- 특정 머신에 대한 파티션 배치
- 캐싱을 위해 할당된 로컬 메모리
- 읽기 요청에 응답할 복제본 선택
특히 복제본 선택에 대한 세밀한 제어 부족은 하나의 느린 복제본이 전체 배치 읽기를 지연시켜 사용자에게 제공되는 테일 레이턴시(tail latency)에 큰 영향을 미친다는 것을 의미했습니다. Perplexity는 더 유연하고 성능이 뛰어난 솔루션이 필요했습니다.
가장 느린 복제본이 속도를 결정한다
DynamoDB의 배치 읽기는 레이턴시를 증폭시켰습니다. 10~20개씩 배치로 100~120개의 페이지 키를 가져오는 단일 검색 요청에서, 하나의 느린 복제본은 다른 레코드들이 빠르게 도착하더라도 전체 요청을 지연시킬 수 있었습니다. 가장 느린 작업이 전체 성능을 결정하는 이 현상을 테일 레이턴시(tail latency)라고 합니다.
Perplexity는 이를 해결하기 위해 특수 핫 키-값 저장소인 CobbleDB를 구축했습니다. Rust로 개발된 CobbleDB는 RocksDB 위에서 실행되며 로컬 NVMe 스토리지에서 직접 데이터를 제공합니다. 키는 파티션별로 논리적으로 그룹화되어 효율적인 데이터 지역성을 보장합니다. 이 아키텍처를 통해 Perplexity는 관리형 서비스에서는 불가능했던 캐싱 및 데이터 배치에 대한 세밀한 제어 권한을 확보했습니다.
스테이트리스(stateless) 라우터가 CobbleDB의 읽기 작업을 오케스트레이션합니다. 라우터는 여러 복제본에 병렬 요청을 보내고 헤지드 리드(hedged reads)를 사용합니다. 즉, 한 복제본이 지연되면 라우터는 즉시 다른 복제본에 동일한 읽기 요청을 보냅니다. 이 공격적인 전략은 느린 노드의 영향을 최소화하여 배치 작업의 테일 레이턴시를 크게 줄였습니다. 이 접근 방식을 통해 배치 읽기 중앙값 레이턴시는 31.4밀리초에서 5.6밀리초로, P99 레이턴시는 123밀리초에서 24밀리초로 감소하여 약 5배의 성능 향상을 달성했습니다.
5배의 성과—그리고 수치가 의미하는 것
Perplexity의 CobbleDB 전환은 프로덕션 배치 읽기 레이턴시를 획기적으로 개선했습니다. 중앙값 응답 시간은 DynamoDB의 31.4ms에서 단 5.6ms로 급감했습니다. 더욱 놀라운 점은 이전에는 전체 검색 요청을 지연시켰던 P99 테일 레이턴시가 123ms에서 약 24ms로 떨어져 약 5배의 속도 향상을 기록했다는 것입니다.
이러한 성능 향상은 상당한 경제적 이점과 함께 제공되었습니다. Perplexity의 내부 비용 모델은 CobbleDB가 모든 약정 등급에서 DynamoDB보다 최소 20% 저렴할 것으로 예측했습니다. 합성 테스트를 통해 CobbleDB의 견고함이 추가로 검증되었으며, 성능 저하 없이 초당 최대 500,000건의 요청까지 안정적인 처리량을 보여주었습니다.
이러한 결과는 인상적이지만, Perplexity의 특정 워크로드와 운영 모델을 반영한 것입니다. 평균 50KB 크기의 페이지 키 100~120개를 일괄 읽기(batch read)하는 특유의 검색 API는 테일 레이턴시(tail latency)를 완화하기 위한 hedged reads 사용을 포함하여 CobbleDB의 맞춤형 아키텍처로부터 직접적인 이점을 얻었습니다.
이러한 성공이 모든 팀이나 사용 사례에 대해 맞춤형 데이터베이스가 관리형 서비스보다 항상 뛰어난 성능을 보장한다는 것을 의미하지는 않습니다. Perplexity의 맞춤형 솔루션은 두 명의 엔지니어와 AI 에이전트를 활용하여 그들의 규모와 비용 요인에 최적화된 시스템을 구축함으로써 정밀한 요구 사항을 충족했습니다. 아키텍처에 대한 자세한 내용은 CobbleDB: Rebuilding AI Search Storage for Lower Latency and Cost를 참조하십시오.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
두 명의 엔지니어, AI 에이전트, 그리고 숨겨진 트레이드오프
CobbleDB의 빠른 개발은 엔지니어링의 새로운 지평을 보여줍니다. 약 40,000줄의 Rust 코드가 두 명의 엔지니어와 AI 코딩 에이전트의 협업을 통해 약 2개월 만에 완성되었습니다. 이러한 신속한 실행은 AI 보조 개발의 잠재력을 잘 보여줍니다.
업무 분담이 핵심이었습니다. AI 에이전트는 테스트 작성, 수정 사항 구현, 관측 가능성(observability) 훅 생성, 문서화, CI/CD 후속 작업 추적과 같은 반복적인 작업을 처리했습니다. 반면, 인간 엔지니어는 다음과 같은 전략적 요소에 대한 주도권을 유지했습니다:
- 아키텍처 설계
- 코드 리뷰
- 배포 게이트
- 프로덕션 결정
이러한 협업을 통해 소규모 팀은 이례적인 속도로 움직일 수 있었으며, 인간의 전문성을 고부가가치 문제에 집중할 수 있었습니다.
그러나 DynamoDB와 같은 관리형 서비스를 대체하는 것은 상당한 운영상의 트레이드오프를 수반합니다. 이제 Perplexity는 하드웨어 장애, 데이터 백업, 지속적인 안정성 보장에 대한 책임을 직접 집니다. 이 모델은 특수한 하이퍼스케일 워크로드에 대해 타의 추종을 불허하는 제어력과 성능을 제공하지만, 대부분의 스타트업이 감당하기 어려운 수준의 운영 성숙도와 자원 투입을 요구합니다. CobbleDB의 성공은 맞춤형 엔지니어링의 증거이지만, 운영 부담 증가라는 숨겨진 비용이 따릅니다.
자주 묻는 질문(FAQ)
CobbleDB란 무엇인가요?
CobbleDB는 이전의 DynamoDB 설정보다 낮은 레이턴시와 비용으로 검색 데이터를 제공하기 위해 구축된 Perplexity의 사내 키-값 저장소입니다.
CobbleDB는 어떻게 레이턴시를 줄였나요?
로컬 NVMe에서 RocksDB를 사용하고 병렬 복제본 읽기를 수행하며, 느린 요청을 다른 복제본에서 다시 시도하는 hedged reads를 사용합니다.
CobbleDB는 DynamoDB보다 얼마나 더 빨라졌나요?
보고된 중앙값(median) 일괄 읽기 레이턴시는 31.4ms에서 5.6ms로 감소했으며, P99 레이턴시는 123ms에서 약 24ms로 감소했습니다.
AI 에이전트가 CobbleDB를 자율적으로 구축했나요?
아니요. 에이전트는 테스트, 수정, 모니터링, 문서화와 같은 작업을 지원했으며, 엔지니어들이 시스템을 설계하고 변경 사항을 검토하며 프로덕션 릴리스를 제어했습니다.