DP-900 공식 출제 범위 도메인 3에는 "Azure Cosmos DB의 사용 사례 식별"과 "Azure Cosmos DB API 설명"이 들어 있습니다. 실제 문제는 여기서 한 걸음 더 들어가 파티션 키를 어떻게 고르는지, 요청 단위(RU)가 무엇에 따라 달라지는지, 서버리스와 자동 크기 조정 중 무엇이 맞는지, 다섯 가지 일관성 수준이 어떻게 다른지를 자주 묻습니다.
이 글은 DP-900 학습자료 중 비관계형 데이터 기본 개념 편의 보충편입니다. 그 글에서 소개한 RU, 파티션 키, 일관성 수준, API 목록을 시험 문제를 풀 수 있는 수준까지 넓혀 리소스 구조, 파티션 설계, 처리량 모드, 전 세계 분산과 일관성, API 선택 기준 순서로 정리합니다.
---
Cosmos DB는 어떤 데이터베이스인가?
전 세계에 지점을 둔 편의점 체인을 떠올려 보세요. 본사가 정한 상품 목록이 모든 지점에 복제되어 있어서, 손님은 가장 가까운 지점에서 바로 물건을 삽니다. Azure Cosmos DB는 이런 구조의 완전 관리형 NoSQL 데이터베이스(PaaS)입니다. 데이터를 원하는 Azure 지역에 복제해 두고, 사용자는 가장 가까운 복제본에서 읽고 씁니다.
Cosmos DB는 스키마에 얽매이지 않습니다. 같은 컨테이너 안의 항목이라도 속성 개수와 구조가 달라도 되고, 기본적으로 모든 속성을 자동으로 인덱싱하므로 스키마나 인덱스를 미리 정의할 필요가 없습니다. 데이터는 네 단계 구조로 정리됩니다.
| 단계 | 역할 | |------|------| | 계정 | 최상위 Azure 리소스, 사용할 API와 지역·일관성 기본값을 정함 | | 데이터베이스 | 관련 컨테이너를 묶는 논리적 이름 공간 | | 컨테이너 | 저장과 확장의 기본 단위, 파티션 키·처리량·인덱싱 정책·TTL을 여기서 설정 | | 항목 | 개별 데이터, API에 따라 문서·행·노드·엣지라고 부름 |
Cosmos DB가 잘 맞는 곳은 유연한 스키마, 전 세계 사용자, 일정하게 낮은 지연이 필요한 앱입니다. IoT·텔레메트리 수집, 게임의 플레이어 프로필과 순위표, 쇼핑몰의 상품 카탈로그와 장바구니, 웹·모바일 앱의 개인화가 대표적입니다. 반대로 여러 테이블을 복잡하게 JOIN해야 하면 Azure SQL Database, 대규모 분석이 목적이면 Microsoft Fabric이 더 맞습니다.
시험 팁: "전 세계 사용자에게 한 자릿수 밀리초 응답, 스키마가 자주 바뀌는 JSON 데이터" → Cosmos DB. "여러 테이블 JOIN이 많은 주문 시스템" → Cosmos DB가 아니라 Azure SQL Database.
---
파티션 키: 확장의 출발점
컨테이너의 데이터는 파티션 키 값에 따라 논리 파티션으로 나뉩니다. 같은 파티션 키 값을 가진 항목이 하나의 논리 파티션이 되고, Cosmos DB는 여러 논리 파티션을 내부의 물리 파티션에 나눠 담아 저장 공간과 처리량을 늘립니다.
논리 파티션 하나에는 최대 20GB까지 저장할 수 있습니다. 물리 파티션 하나는 초당 최대 10,000 RU를 처리하므로, 논리 파티션 하나도 이 한도를 넘을 수 없습니다. 프로비전된 처리량은 물리 파티션에 고르게 나뉩니다. 요청이 일부 파티션에 몰리면 그 파티션만 바쁜 핫 파티션이 생기고, 처리량을 다 쓰지 못한 채 요청이 제한(rate limiting)될 수 있습니다. 파티션 키는 한 번 정하면 그 자리에서 바꿀 수 없습니다. 바꾸려면 새 컨테이너를 만들어 데이터를 옮겨야 합니다.
| 좋은 파티션 키 | 나쁜 파티션 키 | |------|------| | 고유한 값이 많다 (사용자 ID, 기기 ID, 주문 ID) | 값이 몇 개뿐이다 (상태, 유형, 국가) | | 저장 공간과 요청이 여러 값에 고르게 퍼진다 | 특정 값에 데이터와 요청이 몰린다 | | 자주 쓰는 쿼리의 필터 조건에 들어간다 | 쿼리마다 모든 파티션을 훑어야 한다 |
한 키 값의 데이터가 20GB를 넘을 수 있다면 최대 3단계까지 키를 겹쳐 쓰는 계층적 파티션 키(예: 테넌트 ID → 사용자 ID)로 더 고르게 나눌 수 있습니다.
시험 팁: "파티션 키로 가장 적합한 속성" → 고유값이 많고 고르게 분포하는 속성. "일부 파티션에 요청이 몰려 처리량이 남는데도 요청이 거부된다" → 핫 파티션.
---
요청 단위(RU)와 처리량 모드
RU에 영향을 주는 요소
요청 단위(RU)는 CPU, IOPS, 메모리 같은 리소스를 하나의 숫자로 묶은 Cosmos DB의 성능 통화입니다. ID와 파티션 키로 약 1KB 항목 하나를 읽는 포인트 읽기가 1RU이고, 쓰기·쿼리·삭제 같은 모든 작업이 RU로 계산됩니다.
| 요소 | RU에 미치는 영향 | |------|------| | 항목 크기 | 클수록 읽기·쓰기 RU 증가 | | 인덱싱 | 기본은 모든 속성 자동 인덱싱, 일부를 빼면 쓰기 RU 감소 | | 속성 개수 | 많을수록 쓰기 RU 증가 | | 일관성 수준 | Strong·Bounded staleness는 읽기 RU가 약 2배 | | 쿼리 복잡도 | 결과 수, 조건, 함수가 많을수록 증가 |
처리량 모드
| 모드 | 방식 | 잘 맞는 상황 | |------|------|------| | 프로비전된 처리량 (수동) | RU/s를 미리 정해 예약. 컨테이너 전용 또는 데이터베이스 공유(최대 25개 컨테이너) | 트래픽이 꾸준하고 예측 가능 | | 자동 크기 조정 (autoscale) | 최대 RU/s를 정하면 그 10%~100% 사이에서 즉시 자동 조절 | 피크가 있지만 상한은 정할 수 있는 트래픽 | | 서버리스 | 미리 정하지 않고 쓴 RU만큼 과금, 단일 지역 계정만 가능 | 간헐적이고 예측하기 어려운 소량 트래픽, 개발·테스트 |
예를 들어 자동 크기 조정의 최대값을 20,000 RU/s로 정하면 처리량은 2,000~20,000 RU/s 사이에서 움직입니다. 서버리스 계정은 여러 지역에 분산할 수 없으므로, 전 세계 분산이 필요하면 프로비전된 처리량을 써야 합니다.
시험 팁: "가끔만 쓰이는 개발용 앱, 사용한 만큼만 지불" → 서버리스. "평소엔 한산하다가 이벤트 때 몰리는 트래픽, 상한 RU/s 지정" → 자동 크기 조정. "여러 지역에 복제" → 서버리스는 불가.
---
전 세계 분산과 다섯 가지 일관성 수준
다중 지역 쓰기
계정에 언제든 Azure 지역을 추가하면 데이터가 자동으로 복제되고, 사용자는 가장 가까운 지역 복제본에서 읽습니다. 다중 지역 쓰기를 켜면 쓰기도 가장 가까운 지역에서 처리됩니다. 다중 지역 쓰기 계정은 99.999% 가용성 SLA를 제공하고, 읽기와 쓰기 모두 99번째 백분위수 기준 10밀리초 미만을 보장합니다.
일관성 수준
복제본이 여러 지역에 있으면 "방금 쓴 값을 다른 지역에서 언제 볼 수 있는가"를 정해야 합니다. Cosmos DB는 이 균형을 다섯 단계로 제공합니다.
!Azure Cosmos DB의 다섯 가지 일관성 수준
| 수준 | 보장하는 것 | 비유 | |------|------|------| | Strong | 모든 읽기가 가장 최근의 쓰기를 반영 | 생방송 | | Bounded staleness | 정해진 시간이나 버전 수만큼만 뒤처짐 | 최대 5분 지연 중계 | | Session | 한 클라이언트 세션 안에서는 자기가 쓴 값을 바로 읽음 | 내가 단 댓글은 바로 내 화면에 보임 | | Consistent prefix | 순서가 뒤섞이지 않지만 최신이 아닐 수 있음 | 회차 순서대로 오는 재방송 | | Eventual | 시간이 지나면 모든 복제본이 일치, 가용성 최고 | 언젠가 도착하는 엽서 |
일관성 기본값은 계정 단위로 정하고, 필요하면 요청 단위로 더 약한 수준으로 낮출 수 있습니다. Session이 단일 지역·전 세계 분산 앱 모두에서 가장 널리 쓰입니다.
시험 팁: "사용자가 방금 수정한 프로필을 본인은 바로 봐야 한다" → Session. "항상 최신 값만 읽어야 한다" → Strong. "가장 높은 가용성과 낮은 지연, 잠시 오래된 값은 괜찮다" → Eventual. "지연은 허용하되 순서가 바뀌면 안 된다" → Consistent prefix.
---
API 선택 가이드
API는 계정을 만들 때 고르며, 애플리케이션이 쓰는 데이터 형식·쿼리 언어·클라이언트 라이브러리를 결정합니다. 내부 저장 방식은 같고 API가 그 위의 추상화 계층 역할을 합니다.
| API | 데이터 모델 | 쿼리 언어 | 이럴 때 | |------|------|------|------| | NoSQL | JSON 문서 | SQL과 비슷한 구문 | 새 앱의 기본 선택, 기본(네이티브) API (예전 이름 SQL API) | | MongoDB | BSON 문서 | MongoDB 쿼리 언어(MQL) | MongoDB 드라이버와 경험을 그대로 쓰고 싶을 때 | | Table | 키-값 | OData 스타일 키 조회 | Azure Table Storage 앱을 옮기면서 성능·전 세계 분산이 필요할 때 | | Apache Cassandra | 열 패밀리 | CQL | 기존 Cassandra 워크로드를 관리형으로 | | Apache Gremlin | 그래프 (정점·엣지) | Gremlin | 소셜 네트워크, 추천, 사기 탐지, 조직도처럼 관계가 핵심일 때 |
몇 가지 최신 변화도 함께 기억해 두세요. Azure Cosmos DB for PostgreSQL은 서비스 종료 과정에 있어 새 프로젝트에 권장되지 않습니다. PostgreSQL 워크로드는 Azure Database for PostgreSQL의 탄력적 클러스터, NoSQL 워크로드는 Cosmos DB for NoSQL이 대안입니다. 기존 MongoDB 앱을 MQL 기능까지 모두 살려 옮기려면 Microsoft는 별도 서비스인 Azure DocumentDB를 권장합니다. Cosmos DB for NoSQL은 Fabric 미러링으로 운영 데이터를 ETL 없이 Microsoft Fabric에 복제해, RU를 쓰지 않고 분석할 수 있습니다.
시험 팁: "그래프의 노드와 관계를 탐색" → Gremlin. "Cassandra 쿼리 언어(CQL)" → Apache Cassandra. "Cosmos DB의 기본 API, JSON + SQL 비슷한 쿼리" → NoSQL.
---
시나리오로 연습하기
먼저 답을 떠올린 뒤 오른쪽 열을 확인해 보세요.
| 문제 상황 | 정답 | 판단 근거 | |------|------|------| | 주문 컨테이너의 파티션 키를 "주문 상태"로 했더니 일부 파티션만 바쁘다 | 핫 파티션, 고유값이 많은 키로 재설계 | 값이 몇 개뿐인 키 | | 운영 중인 컨테이너의 파티션 키를 바꾸고 싶다 | 새 컨테이너를 만들어 데이터 이전 | 파티션 키는 그 자리에서 변경 불가 | | 사내 테스트용 앱, 하루 몇 번만 쓰이고 비용을 최소화 | 서버리스 | 쓴 RU만 과금 | | 블랙프라이데이에만 트래픽이 10배로 늘어난다 | 자동 크기 조정 | 최대값의 10~100% 자동 조절 | | 서울과 런던 사용자 모두 가까운 지역에 써야 한다 | 다중 지역 쓰기 | 99.999% SLA | | 쇼핑몰 사용자가 장바구니에 담은 상품을 즉시 확인해야 한다 | Session 일관성 | 자기 세션 안의 쓰기를 바로 읽음 | | 직원과 상사, 부서 관계를 따라가며 조회한다 | Cosmos DB for Apache Gremlin | 그래프 데이터 | | 1KB 항목을 ID와 파티션 키로 한 번 읽는 비용 | 1RU | 포인트 읽기 기준 |
---
시험 핵심 정리
시험장 가기 전 마지막으로 확인할 핵심 포인트입니다.
| 구분 | 핵심 암기 사항 | |------|------| | 리소스 구조 | 계정 → 데이터베이스 → 컨테이너 → 항목, 설정의 중심은 컨테이너 | | 스키마·인덱스 | 스키마 없음, 모든 속성 자동 인덱싱 | | 논리 파티션 | 같은 파티션 키 값의 항목 묶음, 최대 20GB | | 좋은 파티션 키 | 고유값이 많고 고르게 분포, 한 번 정하면 변경 불가 | | 핫 파티션 | 요청이 일부 파티션에 몰려 처리량 낭비·요청 제한 | | RU | 1KB 포인트 읽기 = 1RU, 크기·인덱싱·일관성·쿼리에 따라 증가 | | 프로비전 · 자동 크기 조정 | 예약 RU/s, 최대값의 10~100% 자동 조절 | | 서버리스 | 쓴 RU만 과금, 단일 지역, 간헐적 트래픽 | | 다중 지역 쓰기 | 가까운 지역에 쓰기, 99.999% SLA, 10ms 미만(P99) | | 일관성 5단계 | Strong → Bounded staleness → Session → Consistent prefix → Eventual | | API 5종 | NoSQL(기본), MongoDB, Table, Cassandra, Gremlin | | Cosmos DB for PostgreSQL | 서비스 종료 과정, 새 프로젝트에 비권장 |
---
다음 단계
Cosmos DB의 세부 규칙을 정리했다면, 기본기를 다룬 비관계형 데이터 기본 개념과 Blob·Files·Table의 규칙을 다룬 Azure Storage 심화를 함께 보세요. 여러 저장소 중 무엇을 고를지는 상황별 Azure 데이터 저장소 선택 가이드에서 한 번에 비교할 수 있습니다.