[Microsoft Azure]4. 클라우드 데이터 플랫폼(3)

서버를 띄웠다. 웹 앱도 올렸다.

RDB? 테이블 설계하고, 스키마 잡고, 정규화하고...

근데 내가 다루는 데이터가 항상 깔끔한 테이블 형태일까?

IoT 센서 데이터, 게임 로그, 사용자 행동 데이터 — 이런 건 row-column 구조에 억지로 끼워 넣기 어렵다.

여기서 등장하는 게 NoSQL이고, Azure에서는 Cosmos DB와 Storage Account가 그 역할을 한다.

---

5-1. 클라우드 기반의 NoSQL

반정형 데이터란?

데이터는 크게 세 가지로 나뉜다.

정형 데이터(Structured) — RDB의 테이블처럼 행과 열이 명확하게 정의된 데이터다. SQL로 다루기 쉽고 스키마가 고정되어 있다.

비정형 데이터(Unstructured) — 이미지, 동영상, 로그 파일처럼 구조가 없는 데이터다. 그대로 저장하고 별도 처리 파이프라인을 태워야 한다.

반정형 데이터(Semi-structured) — 스키마가 데이터 자체에 내장되어 있는 형태다. JSON, XML, Avro, Parquet 같은 포맷이 여기에 해당한다. 테이블 형식이 아니면서도 어느 정도 구조를 가지고 있다.

반정형 데이터의 핵심 특성은 같은 컬렉션 안에 서로 다른 필드를 가진 엔터티가 공존할 수 있다는 것이다. 예를 들어 고객 A는 전화번호가 3개이고 고객 B는 2개인 경우, RDB에서는 별도 테이블로 분리하거나 NULL 컬럼을 남발해야 하지만 NoSQL에서는 그냥 각각의 document에 필요한 필드만 넣으면 된다.

반정형 데이터베이스 사용 사례

분야	활용 예시
IoT / 텔레매틱스	센서 데이터 수집, 반구조화 데이터의 실시간 처리
소매 / 마케팅	전 세계 분산 데이터, 문서 스토리지
게임	게임 내 통계, 소셜 미디어 통합, 리더보드
웹 / 모바일	클릭 분석, 챗봇, 실시간 애플리케이션

실무에서 IoT 데이터를 다뤄본 경험상, 센서별로 보내는 필드가 제각각인 경우가 많다. 온도 센서는 temperature만 보내고, 환경 센서는 temperature, humidity, co2를 다 보내고... 이런 상황에서 RDB로 스키마를 통일하려면 고통스럽다. NoSQL이 자연스러운 선택이 된다.

반정형 데이터 포맷

반정형 데이터를 저장하는 주요 포맷들을 살펴보자.

JSON (JavaScript Object Notation)

가장 널리 쓰이는 경량 데이터 교환 형식이다. 키-값 쌍의 객체와 배열을 기본 구조로 사용한다.

{
  "name": "Jane Smith",
  "age": 35,
  "city": "San Francisco",
  "hobbies": ["reading", "swimming"]
}

지원하는 데이터 타입: string, number, boolean, null, object, array

RESTful API의 사실상 표준 포맷이고, 설정 파일(package.json, tsconfig.json 등)부터 데이터 저장까지 어디서나 쓰인다. XML 대비 가볍고 가독성이 좋다는 게 최대 장점이다. 단점은 주석을 지원하지 않는다는 것과 날짜(Date) 같은 복잡한 타입을 네이티브로 표현할 수 없다는 것이다.

그 외 빅데이터 포맷들

포맷	특징	주 용도
Apache Avro	스키마 기반 직렬화, 스키마 진화 지원, 언어 독립적	Kafka 메시지, 데이터 파이프라인
ORC	컬럼형 저장, 데이터 스키핑, 스키마 내장	Hive 기반 Hadoop 워크로드
Parquet	컬럼형 저장, 중첩 구조 지원, 메타데이터 포함	Spark, BigQuery 등 분석 워크로드

Avro는 행 기반이라 쓰기에 유리하고, ORC와 Parquet는 컬럼 기반이라 분석 쿼리에 유리하다. 데이터 레이크를 구축할 때 Parquet가 사실상 표준처럼 쓰이고 있고, Spark이나 BigQuery에서 네이티브로 지원한다.

Azure Storage Account

Azure에서 비정형/반정형 데이터를 파일 형태로 저장하려면 스토리지 계정(Storage Account)을 사용한다. 하나의 스토리지 계정 아래에 용도별로 다양한 저장소가 제공된다.

Blob Storage — 대규모 비구조적 데이터(이미지, 동영상, 로그 등)를 저장한다. Hot, Cool, Archive 세 가지 접근 계층을 지원해서 자주 쓰는 데이터와 아카이빙 데이터의 비용을 차등 관리할 수 있다.

Blob은 다시 세 종류로 나뉜다:

종류	최대 크기	용도
Block Blob	4.7TB	이미지, 동영상 등 대형 바이너리 파일
Page Blob	8TB	VM 디스크 (VHD)
Append Blob	195GB	로그 데이터 (append-only)

Table Storage — 스키마 없는 NoSQL 키-값 저장소다. 간단한 구조화 데이터를 빠르게 저장하고 조회할 때 쓴다. 대규모 데이터셋에는 Cosmos DB가 더 적합하지만, 단순한 설정 데이터나 메타데이터 관리에는 Table Storage가 비용 면에서 유리하다.

File Storage — SMB 3.0 프로토콜 기반의 클라우드 파일 공유다. 온-프레미스와 클라우드 앱 모두에서 접근 가능하며, 단일 스토리지 계정에 최대 100TB까지 공유할 수 있다. 레거시 앱이 파일 시스템 경로를 요구하는 경우에 특히 유용하다.

Queue Storage — 메시지 기반 비동기 작업 흐름을 위한 큐 서비스다.

Disk Storage — Azure VM에 연결되는 관리형 디스크다.

스토리지 계정 전체의 공통 특징으로는 데이터 암호화, 다양한 복제 옵션(LRS, GRS, RA-GRS), 사용량 기반 과금이 있다.

---

5-2. CosmosDB의 이해와 활용

Azure Cosmos DB란?

Azure Cosmos DB는 Microsoft가 제공하는 다중 모델 NoSQL DBMS다.

핵심 특징을 정리하면:

• 분할된 문서 집합(partitioned document collection)으로 데이터를 관리한다
• 전 세계 어디서든 10ms 미만의 읽기/쓰기 지연시간을 SLA로 보장한다
• 다중 리전 복제를 통한 글로벌 분산이 가능하다
• Azure의 스케일링과 스토리지 기능을 그대로 활용한다

쉽게 말해 "글로벌 분산 + 낮은 지연시간 + 다중 데이터 모델"을 한 번에 제공하는 매니지드 NoSQL 서비스다. DynamoDB가 AWS 진영의 대표 NoSQL이라면, Cosmos DB는 Azure 진영의 대표다.

Cosmos DB 사용 사례

분야	활용
웹 / 소매	다중 마스터 복제로 글로벌 10ms 미만 응답, 모바일 앱 백엔드
게임	리더보드, 게임 내 통계, 소셜 미디어 통합
IoT	센서 데이터의 실시간 수집 및 저장 (Azure IoT Hub와 연계)

Cosmos DB API

Cosmos DB의 가장 독특한 점은 하나의 서비스에서 여러 데이터베이스 모델의 API를 제공한다는 것이다. 기존에 MongoDB나 Cassandra를 쓰던 애플리케이션도 코드를 거의 바꾸지 않고 Cosmos DB로 마이그레이션할 수 있다.

API	데이터 모델	주요 용도
API for NoSQL	JSON 문서	SQL 유사 쿼리, 범용 문서 저장
API for MongoDB	문서	기존 MongoDB 앱 마이그레이션, 실시간 분석
Cassandra API	와이드 컬럼	대규모 IoT, 시계열 데이터, 고성능 로깅
Gremlin API	그래프	소셜 네트워크, 추천 엔진, 공급망 관리
PostgreSQL API	관계형	기존 PostgreSQL 앱 마이그레이션

실무에서 MongoDB를 쓰다가 글로벌 분산이 필요해지면 Cosmos DB의 MongoDB API로 갈아타는 케이스가 꽤 있다. 드라이버 레벨에서 호환되기 때문에 connection string만 바꾸면 동작하는 경우가 많다.

RU (Request Unit)

Cosmos DB의 비용 모델을 이해하려면 RU(Request Unit) 개념을 알아야 한다.

RU는 Cosmos DB에서 모든 데이터베이스 작업(읽기, 쓰기, 쿼리)의 비용을 측정하는 단위다. 1KB 항목에 대한 point read가 1 RU다. 복잡한 쿼리나 대량 쓰기는 더 많은 RU를 소비한다.

사용자는 초당 RU 수(RU/s)를 프로비전하여 처리량을 확보한다. 100 RU/s 단위로 조정 가능하며, Azure Portal에서 실시간으로 RU 소비량을 모니터링할 수 있다.

RU 기반 과금이라는 건 결국 쿼리 최적화가 곧 비용 최적화라는 뜻이다. 파티션 키를 잘못 잡으면 cross-partition query가 발생하고, 그만큼 RU를 더 먹는다. 설계 단계에서 파티션 키 선정이 매우 중요하다.

Cosmos DB의 일관성 수준

Cosmos DB는 5단계 일관성 수준을 제공한다: 강력(Strong), 제한된 부실(Bounded Staleness), 세션(Session), 일관된 접두사(Consistent Prefix), 최종(Eventual).

강력 일관성은 모든 리전에서 항상 최신 데이터를 읽을 수 있지만 지연시간이 길고 RU 비용이 높다. 최종 일관성은 가장 빠르고 저렴하지만 오래된 데이터를 읽을 가능성이 있다. 대부분의 실무 시나리오에서는 세션 일관성이 좋은 균형점이다 — 같은 세션 내에서는 자기가 쓴 데이터를 즉시 읽을 수 있으면서도 성능은 좋다.

데이터 마이그레이션

Cosmos DB Migration Tool을 사용하면 JSON 파일, MongoDB, SQL Server, CSV, Azure Table Storage, Amazon DynamoDB, HBase 등 다양한 소스에서 데이터를 가져올 수 있다. 기존 인프라에서 Cosmos DB로의 전환 장벽을 낮추기 위한 장치다.

---

5-3. CosmosDB의 아키텍처 구성

Python에서 Cosmos DB 연결

Cosmos DB를 애플리케이션에서 사용하려면 azure-cosmos Python SDK를 통해 연결한다. 구조는 단순하다:

Azure Cosmos DB ↔ Python (azure-cosmos) ↔ 사용자

필수 조건:

• Azure 계정 및 활성 구독
• Azure Cosmos DB for NoSQL 계정
• Python 3.7 이상

선택사항으로 Azure CLI 또는 Azure PowerShell을 사용할 수 있다.

Microsoft 공식 Quickstart 문서(https://learn.microsoft.com/ko-kr/azure/cosmos-db/nosql/quickstart-python)를 따라가면 database 생성, container 생성, item upsert, point read, query까지 한 사이클을 경험할 수 있다. 각 작업마다 소비된 RU(Request charge)가 출력되므로 비용 감각을 잡기에도 좋다.

Cosmos DB를 사용하면 일관성과 응답 속도에 대한 고민이 많이 줄어든다. 하지만 비용이 만만치 않기 때문에 모든 데이터를 Cosmos DB에 넣기보다는 낮은 지연시간이 정말 필요한 핫 데이터에만 제한적으로 쓰는 게 현명하다. 콜드 데이터는 Blob Storage나 Table Storage로 분리하는 것이 일반적인 패턴이다.

---

실습 진행

Azure Cosmos DB를 리소스로 추가해보자.

배포 완료

빠른 시작으로 DB생성하기

실습과 조금 바뀐 부분이 있다. 하지만 똑같이 DB 컨테이너를 생성해준다.

DB 테이블 생성된 모습

이제 다시 우분투 터미널로 돌아가자

코스모스 라이브러리 설치

키를 복사한다

코드 작성 완료

컨테이너 및 DB생성 완료

삽입 및 조회 코드 작성

성공!!

이번 실습 역시 새롭고 신기하다기 보다는

클라우드 리소스를 활용한 원격 저장소를 활용해 본다는 점에서

의의가 크게 다가왔다.

---

정리

• 데이터는 정형/반정형/비정형으로 나뉘며, NoSQL은 반정형·비정형 데이터를 다루는 데 적합하다
• 반정형 데이터 포맷으로 JSON, Avro, ORC, Parquet 등이 있고, 용도에 따라 선택한다
• Azure Storage Account는 Blob, Table, File, Queue, Disk 등 용도별 저장소를 제공한다
• Azure Cosmos DB는 다중 모델 NoSQL DBMS로, 10ms 미만의 글로벌 응답 시간을 보장한다
• Cosmos DB는 NoSQL, MongoDB, Cassandra, Gremlin, PostgreSQL 등 다양한 API를 지원한다
• 비용은 RU(Request Unit) 기반이므로, 파티션 키 설계와 쿼리 최적화가 비용 절감의 핵심이다
• Cosmos DB는 강력하지만 비용이 높으므로, 꼭 필요한 핫 데이터에 제한적으로 사용하는 것이 좋다

다음 시간에는 클라우드 기반의 웹 서비스 플랫폼을 배워보자.