Azure Cosmos DB

서비스가 한 리전에서 시작해 여러 대륙으로 확장되면, 데이터베이스의 물리적 위치가 사용자 경험을 좌우하기 시작합니다. 서울에 DB가 있는데 유럽 사용자가 접속하면 왕복 지연만 수백 밀리초가 됩니다. 그렇다고 리전마다 독립 DB를 두면 데이터 동기화, 충돌 해결, 일관성 보장을 직접 구현해야 하는데, 이 작업은 복잡하고 실수하기 쉽습니다. 여기에 데이터 구조 문제가 겹칩니다. IoT 센서 로그, 사용자 프로필, 상품 카탈로그처럼 구조가 제각각인 데이터를 관계형 스키마에 억지로 맞추면 스키마 변경이 병목이 됩니다. 트래픽이 급증할 때 수직 확장(더 큰 서버)에는 한계가 있고, 수평 확장(샤딩)을 직접 구현하면 운영 복잡도가 급격히 올라갑니다. Cosmos DB는 글로벌 분산, 유연한 데이터 모델, 자동 수평 확장을 플랫폼 수준에서 제공해 이 문제들을 한꺼번에 해결합니다.

전통적인 관계형 데이터베이스는 단일 서버 또는 소수의 복제본으로 운영하기에 적합했습니다. 하지만 글로벌 서비스가 보편화되면서 두 가지 압력이 동시에 커졌습니다. 하나는 세계 각지의 사용자에게 빠른 응답을 줘야 한다는 지연 시간 압력이고, 다른 하나는 수백만 동시 요청을 감당해야 한다는 처리량 압력입니다. 관계형 DB를 여러 리전에 복제하고 샤딩하는 것은 가능하지만, 충돌 해결, 일관성 관리, 리밸런싱을 모두 애플리케이션 레벨에서 구현해야 했고, 이 복잡도는 팀 규모와 운영 예산을 빠르게 잡아먹었습니다. NoSQL 데이터베이스들이 수평 확장 문제를 해결했지만, 글로벌 분산과 튜닝 가능한 일관성까지 플랫폼 수준에서 제공하는 서비스는 드물었습니다. Cosmos DB는 '분산은 플랫폼이 맡고, 개발자는 파티션 키와 일관성 수준만 결정한다'는 방식으로 이 운영 복잡도를 줄이기 위해 만들어졌습니다.

Cosmos DB의 핵심 구조는 파티션 기반 분산입니다. 데이터를 저장할 때 파티션 키를 지정하면, 같은 파티션 키를 가진 문서들이 하나의 논리 파티션에 묶이고, Cosmos DB가 이 논리 파티션들을 물리 파티션에 자동으로 분배합니다. 데이터가 늘어나면 물리 파티션이 자동으로 분할되므로 용량에 사실상 제한이 없습니다. 처리량은 요청 단위(RU/s)로 측정됩니다. 1KB 문서 하나를 읽는 것이 1RU이고, 쓰기나 복잡한 쿼리는 더 많은 RU를 소비합니다. 프로비저닝 모드에서는 초당 처리할 RU를 미리 예약하고, 서버리스 모드에서는 실제 소비한 RU만큼만 과금됩니다. 글로벌 분산은 Azure 리전을 추가하는 것만으로 활성화됩니다. 데이터는 선택한 리전들에 자동 복제되고, 일관성 수준은 5단계 중 선택합니다. Strong은 모든 리전에서 항상 최신 데이터를 보장하지만 지연이 늘고, Eventual은 지연이 가장 낮지만 잠시 오래된 데이터를 읽을 수 있습니다. Session 일관성은 같은 세션 내에서 자기가 쓴 데이터를 반드시 읽을 수 있어서 대부분의 애플리케이션에 적합한 기본값입니다.

Cosmos DB와 Azure SQL Database는 둘 다 Azure의 핵심 데이터베이스이지만 설계 목표가 다릅니다. SQL Database는 관계형 스키마, ACID 트랜잭션, 복잡한 JOIN이 강점이고, 데이터 구조가 명확하며 정합성이 최우선인 워크로드에 맞습니다. Cosmos DB는 스키마 유연성, 글로벌 분산, 수평 확장이 강점이고, 데이터 구조가 다양하거나 여러 리전에서 밀리초 단위 응답이 필요할 때 적합합니다. 판단 기준은 이렇습니다. 데이터 간 관계가 복잡하고 트랜잭션으로 묶어야 하는 범위가 넓다면 SQL Database가 맞습니다. 반대로 각 항목이 독립적이고 글로벌 접근이 필요하며 스키마가 자주 변한다면 Cosmos DB가 더 자연스럽습니다. 둘 중 하나만 쓸 필요는 없고, 실제로는 트랜잭션 데이터는 SQL Database에, 세션이나 카탈로그 데이터는 Cosmos DB에 두는 조합도 흔합니다.

Cosmos DB는 글로벌 사용자 기반의 서비스, 대량 IoT 데이터 수집, 실시간 개인화 엔진, 게임 리더보드처럼 낮은 지연과 높은 처리량이 동시에 필요한 워크로드에서 자주 등장합니다. 특히 이커머스의 상품 카탈로그, 소셜 앱의 피드, 모바일 앱의 사용자 설정처럼 항목 단위로 독립적이고 읽기가 압도적으로 많은 패턴에 적합합니다. 반면 RU 기반 과금 모델은 쿼리 패턴에 따라 비용이 크게 달라질 수 있어서, 파티션 키 설계가 잘못되면 핫 파티션이 생기고 비용이 예상보다 빠르게 늘어납니다. 또한 파티션을 넘는 트랜잭션은 제한적이므로, 여러 엔티티에 걸친 ACID 트랜잭션이 필수인 경우에는 적합하지 않습니다. Cosmos DB를 도입할 때는 파티션 키 선정과 일관성 수준 결정을 가장 먼저 해야 하며, 이 두 가지가 성능과 비용을 결정짓는 가장 큰 설계 결정입니다.

다음에 볼 개념

함께 보면 좋은 개념