2021년 4월에 게시한 블로그 포스트의 후속 편입니다.
저희는 주요 서버리스 데이터베이스들의 성능을 실제 웹 사용 사례와 서버리스 함수 환경에서 비교하는 샘플 애플리케이션을 구축했습니다. 비교 대상은 DynamoDB, MongoDB(Atlas), Firestore, Cassandra(Datastax Astra), FaunaDB, Redis(Upstash)입니다.
애플리케이션과 소스 코드는 모두 공개되어 있으니 언제든지 직접 확인해 보실 수 있습니다.
테스트 방법
이번 벤치마크에서 측정한 항목은 각 데이터베이스에서 조회수 상위 10개 뉴스 기사를 가져오는 데 걸리는 지연 시간(latency)입니다. 테스트 데이터는 New York Times API에서 수집한 실제 뉴스 기사 7,001건으로 구성되어 있습니다.
측정에 사용된 쿼리는 다음과 같습니다:
select * from news where section = "World" order by view_count desc limit 10
백엔드는 AWS Lambda의 서버리스 함수로 구현했으며(Firestore의 경우 Google Cloud Functions 사용), 네트워크 지연을 최소화하기 위해 가능한 한 서버리스 함수와 데이터베이스를 같은 리전에 함께 배치했습니다.
측정 시에는 데이터베이스 연결 시간을 제외하고, 쿼리 실행 직전과 직후의 타임스탬프만 기록했습니다. 지연 시간은 백엔드(서버리스 함수 내부)에서 측정·기록되므로 브라우저와 서버 간 네트워크 지연은 포함되지 않으며, 서버리스 함수의 콜드 스타트 시간의 영향도 받지 않습니다.
또한 동적인 실제 환경을 재현하기 위해 상위 10개 기사에 매번 무작위 view_count 값을 부여했습니다. 이렇게 하면 데이터베이스가 매번 다른 기사 세트를 반환하도록 강제되어 캐시를 활용할 수 없게 됩니다. 단, 업데이트 작업 자체는 지연 시간 계산에서 제외했습니다.
다음은 현재(8월 25일 기준)까지 측정된 지연 시간 결과입니다:
각 데이터베이스별 적용 설정
아래는 각 데이터베이스에 적용한 커스텀 설정 목록입니다.
DynamoDB
- 리전: US-West-1
- 읽기/쓰기 용량: 50 (기본값은 5)
- 인덱스: 파티션 키 section(String), 정렬 키 view_count(Number)로 구성된 GSI
- 참고: 클라이언트가 이미 같은 리전(US-West-1)에 있으므로 글로벌 테이블은 활성화하지 않았습니다.
MongoDB (Atlas)
- 리전: AWS N. Virginia (us-east-1)
- 클러스터 티어: M5 (General)
- 인덱스: section + view_count 복합 인덱스
- 참고: MongoDB의 서버리스 오퍼링도 시도해 보고 싶었지만 Node.js 드라이버가 없어 테스트하지 못했습니다. 다만 DB 연결을 지연 시간 측정 구간 밖에서 유지하므로 큰 문제는 되지 않습니다.
Firestore
- 리전: GCP US-Central
- 모드: Datastore
- 인덱스: section(오름차순) + view_count(내림차순) 복합 인덱스
Cassandra (Datastax Astra)
- 리전: AWS US-East-1
- 요금제: 종량제(Pay as you go)
- 인덱스: PRIMARY KEY (section, view_count, id)
- API: REST API
FaunaDB
- 요금제: 개인 플랜(월 $25)
- 인덱스: term=section, value=view_count
- API: FQL
Redis (Upstash)
- 리전: AWS US-West-1
- 요금제: 종량제(Pay as you go)
- 인덱스: SortedSet 사용
- 참고: 싱글 존(Single Zone)과 멀티 존(Multi Zone) 데이터베이스를 각각 따로 테스트했습니다.
특이 사항
- FaunaDB: 기본적으로 더 강력한 일관성 보장과 글로벌 복제를 제공하며, 배포 리전을 직접 선택할 수 없습니다. 이러한 특성이 상대적으로 낮은 성능의 원인일 수 있습니다.
- Firestore: 다른 데이터베이스와 비슷한 성능을 보이지만 변동 폭이 더 큽니다. 콜드 커넥션(cold connection) 오버헤드 때문으로 추정되며, 연결을 유지하는 방법을 찾지 못했습니다. 관련 아이디어가 있다면 공유해 주시면 감사하겠습니다.
- Cassandra: 기본 키 필드 업데이트가 허용되지 않고, 잦은 업데이트가 예상될 때는 세컨더리 인덱스 사용이 권장되지 않습니다. 그래서 view_count를 갱신할 수 없었는데, 이것이 성능에 영향을 줄 수 있습니다.
- Redis (Upstash): 싱글 존이 약간 더 빠르게 보이지만, 싱글 존과 멀티 존 설정 간 성능 차이는 크지 않습니다. 또한 REST API는 높은 퍼센타일 구간에서 네이티브 API에 근접한 성능을 보여줍니다.
맺음말
이 벤치마크는 지속적인 프로젝트입니다. 저희는 앞으로도 코드를 꾸준히 리팩토링하여 벤치마크의 품질을 개선해 나갈 계획이며, 특정 제품의 코드를 리팩토링할 때마다 해당 제품의 히스토그램을 초기화할 것입니다. 코드를 살펴보시고 개선할 점이 있다면 알려주세요. Twitter와 Discord를 통해 의견을 보내주실 수 있습니다.