시작하기
- Azure CosmosDB 는 Azure 의 글로벌 분산형 NoSQL 데이터베이스 서비스이다.
- 최근에는 벡터 데이터베이스 기능을 제공하여 RAG 패턴과 같은 AI 애플리케이션의 DB 로 활용될 수 있다.
- 공식 문서를 보면 방향성을 AI 데이터베이스로 잡은 것 같다. 앞으로 더 많이 사용될 DB 가 아닐까.
- CosmosDB 에 대해 깊이있게 정리해 보자.
Cosmosdb 의 특징
글로벌 분산
- region 간 자동 복제를 지원한다.
- multi-master 를 지원하여 여러 지역에서 동시에 읽기/쓰기가 가능하다.
- auto-failover: 특정 지역에서 장애가 발생할 경우 다른 지역으로 자동으로 failover 된다.
다중 데이터 모델
- cosmos 라는 네이밍에서 알 수 있듯이, 이것저것 다 지원하는 데이터베이스다.
- SQL, MongoDB, Cassandra, Gremlin, Table 등 다양한 API 를 제공한다.
- 모든 API는 동일한 물리적 저장소를 사용하지만, API별로 논리적 데이터 모델이 다르다.
- Core (SQL) API는 JSON 문서 기반, MongoDB API는 BSON, Cassandra API는 Wide-Column Store, Gremlin API는 Graph, Table API는 Key-Value Store 방식으로 저장한다.
- 벡터 데이터베이스 기능도 제공한다.
과금 모델
- RU (request units) 라는 처리량 단위를 사용하며, 이를 통해 과금을 측정한다.
- 이는 단위 시간에 얼마나 (리소스가 소요되는) 요청이 들어왔는지에 대한 메트릭이다.
- RU 제한은 특정 값으로 설정하거나 (provisioned throughput), pay-as-you-go 로 설정하거나, auto-scale 을 사용할 수 있다.
- auto-scale 옵션을 켜면 greedily scale 되므로 과금이 많이 발생할 수 있다.
- 제한된 RU 값을 넘어 들어오는 요청은 429를 반환한다.
- native SDK 클라이언트를 사용하면 재시도 요청을 자동으로 해 준다.
- 운영 시, RU 는 중요한 모니터링 대상이 된다. 기본적으로 제공되는 metric 대시보드를 통해 RU 사용량 추이는 어떠한지, 429 요청이 발생했는지 모니터링할 수 있다.
파티션의 개념
- 데이터베이스 샤딩과 비슷한데, 살짝 개념이 다르다.
- CosmosDB 컨테이너 (RDB의 테이블과 유사하다.) 의 데이터는 파티션이라는 하나 이상의 서버에 저장되는데, 처리량을 늘리거나 스토리지가 증가하면 자동으로 scale-out 된다.
scale-out / scale-up
- 보통 NoSQL 의 경우 안정 해시 등 알고리즘에 의해 노드를 늘리면 재배치가 발생한다.
- CosmosDB 는 PaaS 라서 인프라가 추상화되어 있는데, RU/s (처리량) 를 늘릴 경우 (scale-up 개념이다.) 어떻게 작동할까?
- 관련 문서: https://learn.microsoft.com/en-us/azure/cosmos-db/scaling-provisioned-throughput-best-practices
- Physical partition 의 개수에 따라 즉시 작동하거나 비동기적으로 scale-up 이 발생한다고 한다.
- 즉, physical partition 을 늘려야 해서 scale-out 이 발생하면 비동기적으로 처리되고, 그렇지 않으면 바로 처리된다.
파티션 키
크로스 파티션 쿼리
트랜잭션
NoSQL API
- 관련 문서: https://learn.microsoft.com/ko-kr/azure/cosmos-db/nosql/faq
- SQL 쿼리를 통해 데이터를 질의할 수 있다.
- 그러나 관계형 DB 와는 많은 차이점이 있는데, 정리하면 다음과 같다.
| 특징 | RDBMS SQL | CosmosDB NoSQL SQL |
|---|---|---|
| 데이터 모델 | 테이블(정규화) | JSON 문서 |
| JOIN | 지원 | LIMITED (Self JOIN만 가능) |
| 트랜잭션 | ACID 지원 | 단일 문서 내 트랜잭션 지원 |
| GROUP BY | 지원 | 지원 |
| Aggregation (SUM, COUNT) | 지원 | 지원 |
| 관계형 스키마 | 필수 | 비필수 (Schema-less) |
동시성 제어
- ETags 를 통해 OCC (optimistic concurrency control) 을 한다.
쿼리 최적화
- 다른 데이터베이스와 달리, CosmosDB 는 쿼리의 성능과 사용된 RU 를 같이 최적화해야 한다.
- 쿼리가 많은 RU 를 사용할 경우 동시 요청이 많아지면 병목이 된다.
인덱스
- 관련 문서: https://learn.microsoft.com/en-us/azure/cosmos-db/index-overview
- 인덱스는 indexing policy 에 따라 생성되며, 기본값은 모든 필드에 range index 가 적용된다.
- 인덱스의 종류는 range index, hash index 등이 있으며, range index 가 생성된 필드에는 >,< 등의 쿼리가 가능하다.
- 즉, 기본적으로 읽기 성능은 개선하고 쓰기 성능은 저하된 상태이다. (아마도 이는 인덱스 생성으로 인해 과금이 추가되는 특성에 따른 설계일 것이다.)
CosmosDB 사용 시 주의할 점
- CosmosDB 는 일반적인 DB와 많은 차이점을 보인다.
- 그렇다면, 사용할 때 주의할 점에는 어떤 게 있을까?
파티션 키의 설계
RU 관리
인덱스 설정
- 인덱스를 추가로 설정해야 생성되는 RDBMS 와 반대로, CosmosDB 는 설정하지 않으면 인덱스가 생성된다.
- 워크로드 특성 상 쓰기가 많다면 성능이 저하될 것이다.
- 이 경우에는 인덱스를 튜닝해야 한다.
쿼리 최적화
참고 자료
개발자의 생각 로그