Azure Cosmos DB

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

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

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는 파티션을 넘는 ACID 트랜잭션을 제한적으로만 지원하므로, 여러 엔티티에 걸친 트랜잭션이 핵심 요구사항이라면 적합하지 않습니다.

Cosmos DB는 여러 리전의 사용자를 동시에 상대해야 하는 서비스에서 자주 선택됩니다. 이커머스의 상품 카탈로그, 소셜 앱의 피드, 모바일 앱의 사용자 설정처럼 항목 단위로 독립적이고 읽기가 압도적으로 많은 패턴이 대표적입니다. IoT 텔레메트리 수집이나 게임 리더보드처럼 쓰기 처리량이 높고 스키마가 유동적인 경우에도 파티션 키 기반 자동 확장이 잘 맞습니다. RU 기반 과금 모델은 쿼리 패턴에 따라 비용이 크게 달라질 수 있습니다. 파티션 키 설계가 잘못되면 특정 파티션에 부하가 몰리는 핫 파티션이 생기고, 비용이 예상보다 빠르게 늘어납니다. 팀에서 Cosmos DB 도입을 검토하기 시작하는 신호는 주로 두 가지입니다. 데이터베이스 위치 때문에 특정 리전 사용자의 응답 시간이 눈에 띄게 길어지거나, 트래픽 급증에 대비해 DB를 미리 수직 확장해 두어야 하는 상황이 반복될 때입니다.