현재의 "서버리스" 데이터베이스는 진짜 서버리스가 아닙니다
(lambdadb.ai)서버리스의 환상
- 서버리스는 클라우드 기술의 핵심 트렌드로 자리 잡았다.
- 이 패러다임은 개발자들이 서버 관리의 부담 없이 비즈니스 로직에만 집중할 수 있도록 한다.
- 비용 지불 방식: 사용한 만큼만 비용을 지불하며, 운영 오버헤드는 사실상 제로에 가깝다.
- 여러 서버리스 데이터베이스가 시장에 등장했으며, Elastic, Confluent, Pinecone과 같은 기존 리더와 Neon, WarpStream, Upstash, Turbopuffer와 같은 새로운 도전자가 경쟁하고 있다.
기존 서버리스 데이터베이스의 문제점
- 많은 서버리스 데이터베이스는 진정한 서버리스가 아니다.
- 대부분의 서비스는 클라우드 네이티브 아키텍처에 기반하고 있으며, 이는 서버풀 시대를 위한 혁신적인 설계이다.
- 서버 클러스터를 운영하며, 복잡한 소프트웨어와 인간의 개입을 통해 부하를 예측하고 용량을 관리한다.
- 이러한 환상은 사용자에게 실질적인 문제를 야기한다.
비효율적인 아키텍처의 영향
- 아키텍처 불일치는 단순한 기술적 세부 사항이 아니라 사용자에게 실제 문제를 일으킨다.
- 사용자는 유휴 서버에 대한 비용을 지불하게 되며, 서버 클러스터는 항상 다양한 목적을 위해 실행된다.
- 확장성 문제: 새로운 서버를 클러스터에 추가하는 데 몇 분이 걸리며, 즉각적인 트래픽 급증을 처리할 수 없다.
- 제한된 선택권: 각 클라우드 지역에 대한 인프라 관리를 필요로 하므로, 사용자는 선택할 수 있는 서비스 지역이 제한된다.
지속 불가능한 모델
- 서버풀 아키텍처에 기반한 “서버리스” 데이터베이스는 지속 가능하지 않다.
- 제공자는 서버 클러스터 운영을 위해 상당한 투자 자금을 필요로 하며, 이로 인해 가격이 변경될 수 있다.
- 경량 사용자는 시스템을 보조하기 위해 과도한 요금을 지불하게 되고, 성공적인 사용자는 예상치 못한 가격 인상에 직면하게 된다.
서버리스 네이티브 아키텍처의 필요성
- 클라우드 컴퓨팅 초기에는 대부분의 “클라우드” 데이터베이스가 레거시 데이터베이스였다.
- 서버리스 네이티브 아키텍처는 인프라 관리의 모든 것을 클라우드 제공자에게 맡기며, 서버 클러스터 대신 무상태 함수와 서버리스 서비스를 사용한다.
- 이 접근 방식은 클라우드 인프라를 단일 대형 슈퍼컴퓨터로 취급하여 즉각적인 확장성과 진정한 요청당 지불 모델을 가능하게 한다.
- 리트머스 테스트: 데이터베이스가 진정한 서버리스 네이티브인지 확인하기 위해, Kubernetes 클러스터나 VM을 프로비저닝하지 않고 클라우드 계정에 배포할 수 있는지를 확인해야 한다.
LambdaDB 소개
- LambdaDB는 서버리스 네이티브로 구축된 새로운 검색 엔진이다.
- 이 시스템은 서버리스 기능과 리소스의 집합으로 운영되며, 데이터베이스 로직과 인프라를 완전히 분리한다.
- 사용자 요청은 지역 게이트웨이를 통해 흐르며, 요청 유형에 따라 제어 함수(Control Functions) 또는 데이터 함수(Data Functions)로 라우팅된다.
- 엔터프라이즈 기능: LambdaDB는 시점 복원 및 제로 복사 클로닝과 같은 기능을 제공하며, 인프라 관리가 필요 없다.
LambdaDB의 작동 방식
- LambdaDB 아키텍처: 모든 구성 요소는 서버리스 클라우드 서비스로 구축된다.
- 게이트웨이는 사용자 요청의 API 키를 검증하고, 요청을 제어 함수 또는 데이터 함수로 라우팅한다.
- 제어 함수는 CRUD 작업 및 데이터 관리 요청을 처리하며, 데이터 함수는 실제 데이터 쓰기 및 읽기를 수행한다.
- 쓰기 경로: Writer Function은 요청을 기록하고, 이를 내구성 있는 서버리스 쓰기 버퍼에 기록한 후 클라이언트에 응답한다.
비용 효율성의 역설
- LambdaDB는 서버풀 데이터베이스에 비해 컴퓨팅 비용을 줄인다.
- Lambda의 단위 가격이 EC2 인스턴스보다 높지만, 고가용성 및 내결함성을 보장하기 위해 필요한 중복성 덕분에 비용이 절감된다.
- 고정 용량의 낭비: 기업의 평균 컴퓨팅 활용도는 10-20%에 불과하여, 서버리스 컴퓨팅은 50-90%의 비용을 절감할 수 있다.
성능 및 확장성
- 성능 및 확장성: LambdaDB는 960차원 벡터를 사용하여 수백만 개의 벡터를 추가하는 실험을 통해 성능을 입증하였다.
- 쓰기 지연 시간: 10개의 초당 업서트에서 중앙값 지연 시간은 43ms이며, 트래픽이 100배 증가해도 지연 시간이 비슷하게 유지된다.
- 쿼리 지연 시간: 쿼리 지연 시간은 다양한 부하에서 안정적이며, 99번째 백분위수는 172ms에서 210ms 사이이다.
- 최적화 노력: 쿼리 함수의 지연 시간을 개선하기 위해 지속적으로 최적화하고 있으며, 서버리스 인프라도 개선되고 있다.
고객에게 제공되는 이점
- 비용 절감: LambdaDB는 유휴 서버가 없기 때문에 10배 이상 저렴하다.
- 즉각적이고 무한한 확장성: LambdaDB는 밀리초 내에 수천 개의 병렬 함수로 확장할 수 있다.
- 단순한 시작 및 확장: 강력한 AI 애플리케이션을 구축할 수 있으며, 성장함에 따라 아키텍처는 여전히 간단하고 비용 효율적이다.
- 엔터프라이즈 기능: 시점 복원 및 제로 복사 클로닝과 같은 기능을 제공하며, 복잡성이나 비용 없이 사용할 수 있다.
미래 계획 및 비전
- LambdaDB는 이미 수억 개의 문서에 대해 매일 수백만 개의 요청을 처리하고 있다.
- 장기 계획: 다른 데이터 모델(관계형 데이터, 스트림, 키-값, 그래프 등)을 지원할 계획이다.
발상은 좋으나 쿼리 지연 시간이 줄이기 위해서 필연적으로 state가 필요해집니다. mysql, postgresql 등과 비교해서 쿼리 지연시간이 거의 100배나 높은 것 같습니다. 거의 파일 시스템에 입력하고 출력하는 것과 유사한 것 같네요.
좋은 의견 감사드립니다. 말씀해주신 "지연 시간을 줄이기 위해 state가 필요하다"는 점은 저희 아키텍처의 핵심적인 트레이드오프를 정확히 짚어주셨습니다.
먼저 쿼리 지연 시간에 대해 말씀드리면, 저희 벤치마크에서 p99(99th percentile)는 약 130-210ms 수준입니다. 아마 100배 차이라고 하신 부분은 본문에 언급된 '콜드 스타트 시 수 초가 걸릴 수 있다'는 최악의 경우를 보시고 말씀하신 것 같습니다. 짚어주신 대로 이 부분은 분명 저희 아키텍처의 단점이며, 본문에 언급했듯 프로덕션 환경에서는 0.01% 미만(P99.99)에서 발생합니다. 그외 대부분의 쿼리는 각 람다의 로컬 메모리와 디스크를 캐시로 활용하여 안정적인 성능을 내도록 설계되어 있습니다.
따라서 말씀해주신 대로, 모든 쿼리가 10ms 이하로 보장되어야 하는 초저지연 금융 거래 시스템 등에는 이러한 아키텍처가 적합하지 않을 수 있습니다. 하지만 대다수의 AI 기반 검색 및 추천 애플리케이션에서는 P99 기준 100-200ms 수준의 지연 시간은 충분히 좋은 성능이며, 인프라 비용과 운영 부담을 90% 이상 절감하는 이점이 훨씬 크다고 생각합니다.
다시 한번 깊이 있는 의견에 감사드립니다.
한글로 답변이 달릴 줄은 몰랐습니다! (너무 시니컬하게 썼네요...)
획기적인 아이디어라는 생각을 먼저 했었습니다. 사실 서버리스 DB들의 가장 큰 문제점이 드러나지 않는 곳에서 실제 서버가 돌아가고 있는 점이었습니다. 그래서 트래픽이 몰리면 그 서버가 할당 될 때까지 먹통이 되는 상황이 발생합니다. (대략 5분 정도) 그래서 현존하는 클라우드(AWS 등)의 서버리스 DB가 프로덕션 레벨에서 사용하기 어렵거든요.
써볼까? 싶었는데 걱정했던 이유는 그럼 mysql, postgresql 등에서 만들어놓은 인덱싱, 정렬 등의 바이너리 로직등을 구현해야하는데 그만큼 신뢰있는 오픈소스 DB 프로젝트를 람다 위에서 다시 만드는게 얼마나 어려운 일일까? 라는 생각이 들어서 였습니다.
직접 만드시는 제품이니 많은 발전을 기대하겠습니다~!