Microsoft AZ-204: Azure Cosmos DB — 학습 가이드

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

다음의 일부입니다: Microsoft Azure Developer Associate AZ-204 — 학습 가이드. 검증된 답안으로 연습하기: Microsoft 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

Azure Cosmos DB는 짧은 지연 시간과 탄력적인 확장성을 갖춘 애플리케이션을 위해 설계된 완전 관리형, 전역 분산, 다중 모델 데이터베이스입니다. 공통의 파티셔닝된 스토리지 및 복제 엔진을 통해 여러 API를 제공하고, 5가지 조정 가능한 일관성 수준을 제공하며, 가용성, 지연 시간, 처리량, 일관성에 대한 포괄적인 SLA를 보장합니다. 데이터는 계정, 데이터베이스, 컨테이너(API에 따라 컬렉션/테이블/그래프)로 구성됩니다. 컨테이너는 파티션 키를 기준으로 수평으로 파티셔닝되고 확장되며, 모든 작업은 CPU, IOPS, 메모리를 추상화한 정규화된 단위인 요청 단위(RU)로 측정됩니다.

API 및 프로그래밍 기능

Cosmos DB는 여러 wire-compatible API를 지원하므로 데이터 모델을 다시 작성하지 않고도 네이티브 SDK와 드라이버를 사용할 수 있습니다.

SQL (Core) API: 새로운 워크로드에 권장되는 기본 API입니다. 풍부한 SQL 유사 쿼리(문서 내 SELECT, WHERE, ORDER BY, JOIN, 집계)와 계산된 조건자/프로젝션을 위한 결정론적 UDF를 사용하여 JSON 문서를 저장합니다. 서버 측 비즈니스 로직은 단일 논리 파티션 내에서 JavaScript 저장 프로시저 및 사전/사후 트리거로 실행되어, 파티션 키를 공유하는 여러 항목에 대한 ACID 트랜잭션을 지원합니다. TransactionalBatch는 파티션 내에서 다중 항목 작업을 제공합니다. 지점 읽기(id + 파티션 키)가 RU 효율성이 가장 높습니다. .NET 클라이언트는 new CosmosClient(endpoint, key)와 같은 코드로 생성합니다.
MongoDB API: MongoDB와 wire-compatible하여 표준 MongoDB 드라이버 및 도구(예: 마이그레이션을 위한 mongodump/mongorestore)를 사용할 수 있습니다. Cosmos DB의 분산, 자동 확장, SLA를 기반으로 MongoDB 기능을 사용할 수 있습니다. 동일한 논리 파티션 내에서 다중 문서 트랜잭션이 지원됩니다. 사용자별로 엄격한 원자성을 보장하려면, 샤딩되지 않은 컬렉션을 사용하거나 username과 같은 속성으로 샤딩하여 관련 문서가 파티션을 공유하도록 해야 합니다.
Cassandra API: Apache Cassandra 드라이버 및 CQL과 호환됩니다. 와이드 컬럼 및 시계열 액세스 패턴에 이상적입니다. 노드 관리 대신 자동 전역 분산 및 RU 기반 확장을 사용할 수 있습니다.
Gremlin API: TinkerPop Gremlin 쿼리 및 순회를 사용하는 속성 그래프 모델입니다. 확장 가능한 순회를 위해 정점(vertex)과 간선(edge)을 분산시키려면 파티셔닝이 필수적입니다.
Table API: Azure Table Storage와 호환되는 SDK 및 시맨틱을 사용하는 키-값 저장소이지만, Cosmos DB의 전역 분산, RU 처리량, 더 짧은 지연 시간의 인덱스를 기반으로 합니다.

여러 API에 공통적인 SDK 작업에는 CRUD, ETag를 사용한 낙관적 동시성, 업서트, 서버 측 스크립트(저장 프로시저, 트리거), UDF(SQL API)가 포함됩니다. 쿼리는 매개 변수화하여 RU를 줄이고 보안을 향상시킵니다. 대량 작업 및 스트리밍 API는 처리량이 높은 수집 작업 시 클라이언트 오버헤드와 RU 비용을 최소화합니다.

일관성, 인덱싱, 쿼리 시맨틱

Cosmos DB는 계정당 5가지 잘 정의된 일관성 수준을 제공합니다(많은 SDK에서 요청별로 재정의 가능).

강력(Strong): 선형성(Linearizability)을 보장하며, 읽기 작업 시 전역적으로 가장 최근에 커밋된 쓰기 작업을 확인합니다. 정확성을 극대화하지만 쓰기 지연 시간과 지역적 유연성을 제한하며, 다중 지역 쓰기가 활성화된 경우에는 사용할 수 없습니다.
제한된 부실(Bounded Staleness): 읽기 작업이 쓰기 작업보다 최대 K 버전 또는 T 시간만큼 뒤처집니다. 단조로운 읽기 및 쓰기 순서를 보장하며, 제한된 지연을 허용할 수 있는 전역 분산 읽기 작업에 적합한 절충안입니다.
세션(Session) (기본값): 세션별로 자신이 쓴 내용 읽기(read-your-writes), 쓰기 후 읽기(write-follows-reads), 단조로운 읽기(monotonic reads)를 보장합니다. 각 클라이언트는 세션 토큰을 유지하며, 노드 간에 이 토큰을 공유하면(예: SDK의 요청 옵션을 통해) 해당 노드들 간에 자신이 쓴 내용 읽기가 유지됩니다.
일관된 접두사(Consistent Prefix): 읽기 작업 시 순서가 맞지 않는 쓰기 작업은 절대 볼 수 없지만, 로그의 접두사만 볼 수 있습니다.
최종(Eventual): 순서 보장 없이 가장 높은 가용성과 가장 낮은 지연 시간을 제공합니다.

SQL API의 경우 인덱싱은 기본적으로 자동이며 일관성(consistent)이 있습니다. 모든 항목과 속성은 스키마 관리 없이 인덱싱되므로, 쓰기 작업 시 인덱스가 즉시 업데이트됩니다(인덱싱 모드: Consistent). 다음과 같이 인덱싱 정책을 세분화할 수 있습니다.

크기가 크거나 쓰기 작업이 많은 경로를 제외하여 쓰기 RU 비용을 낮춥니다.
여러 속성에 대한 효율적인 ORDER BY와 여러 다른 속성에 걸친 필터링 및 정렬을 결합하는 쿼리를 지원하기 위해 복합 인덱스를 추가합니다.
GeoJSON 유형(Point, LineString, Polygon, MultiPolygon)에 대한 공간 인덱스를 추가하고 ST_DISTANCE, ST_WITHIN, ST_INTERSECTS와 같은 공간 함수로 쿼리합니다. id/파티션 키로만 읽는 쓰기 최적화 컨테이너의 경우 인덱싱 모드를 None으로 설정할 수도 있습니다. API마다 네이티브 패러다임(예: MongoDB 및 Cassandra 드라이버 구조)을 통해 인덱싱을 노출하지만, 모두 기본 Cosmos 인덱싱 엔진을 활용합니다.

항목 크기와 쿼리 형태에 유의해야 합니다. SQL API는 항목 크기 제한(예: 2MB)을 적용하며, 파티션 간 쿼리, 대규모 프로젝션, 복잡한 조건자는 RU 소비를 증가시킵니다. 선택적 프로젝션, 적절한 필터, 파티션 인식 쿼리를 사용하여 RU 비용을 최소화하세요.

파티셔닝 및 처리량(RU)

Cosmos DB는 논리적 파티션과 물리적 파티션을 구분합니다:

논리적 파티션은 파티션 키 값으로 항목을 그룹화합니다. 동일한 키를 공유하는 모든 항목은 트랜잭션 배치 및 서버 측 스크립트에 함께 참여합니다.
물리적 파티션은 서비스에 의해 관리되며 많은 논리적 파티션을 호스팅합니다. 처리량(RU)과 스토리지는 물리적 파티션에 분산됩니다. “핫” 논리적 파티션은 물리적 파티션의 처리량에 병목 현상을 일으킬 수 있습니다.

카디널리티가 높고 시간이 지남에 따라 액세스 분포가 균일한 효과적인 파티션 키를 선택하세요. 좋은 키는 기본 액세스 경로(예: userId, deviceId, tenantId 또는 orderId)와 상관관계가 있습니다. 편중(skew)을 유발하는 카디널리티가 낮거나 시간 버킷형 키(예: country, status 또는 day)는 피하세요. 단일 속성이 적합하지 않은 경우:

여러 속성을 연결하는 합성 키를 사용합니다.
접두사로 쿼리 가능성을 유지하거나 조회를 유지하면서 파티션 전반에 부하를 분산시키기 위해 임의 또는 해시된 접미사를 추가합니다.
여러 속성을 결합하여 더 나은 분산과 효율적인 접두사 쿼리를 가능하게 하는 계층적 파티션 키를 고려합니다.

처리량 모델:

프로비저닝된 처리량: 컨테이너 또는 데이터베이스(자식 컨테이너와 공유)에 RU/s를 예약합니다. 예측 가능한 성능과 비용 안정성을 제공합니다. 수동 또는 API/CLI를 통해 확장합니다.
자동 스케일링: 최대 RU/s를 설정하면 Cosmos DB는 부하에 따라 해당 최대치의 10%에서 100% 사이에서 탄력적으로 확장됩니다. 시간당 사용된 가장 높은 RU를 기준으로 청구되며, 가변적인 워크로드와 예측할 수 없는 피크에 적합합니다.
서버리스: 프로비저닝된 RU/s가 없으며, 작업의 RU 소비량에 따라 비용을 지불합니다. 예측 가능한 기준선이 없는 개발, 스파이크가 심한 워크로드 또는 낮은 처리량의 워크로드에 이상적입니다.

RU 최적화 기술에는 id+파티션 키를 사용한 포인트 읽기, 매개변수화된 쿼리, 선택적 프로젝션, JOIN과 유사한 패턴을 줄이기 위한 비정규화, 복잡한 다중 컨테이너 쿼리 대신 파생 뷰에 변경 피드를 사용하는 것이 포함됩니다. RU 비용이 많이 드는 재시도를 피하기 위해 동시성 제어에 If-Match와 함께 ETag를 사용하세요. RU 메트릭과 스로틀링(HTTP 429)을 모니터링하고 SDK에서 지터(jitter)가 포함된 재시도 정책을 구현하세요.

← Azure Storage 및 Blob Storage · 모든 도메인 · Azure 컨테이너 솔루션 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →