DP-900에서 비관계형 데이터 문제는 "Cosmos DB API를 언제 어떤 걸 쓰나"와 "Blob Storage 계층 중 어떤 것이 비용이 저렴한가"를 자주 묻습니다. 이 글에서는 Azure의 다양한 스토리지 서비스가 왜 존재하는지, 각각을 언제 써야 하는지 쉬운 비유와 함께 설명합니다.
왜 다양한 스토리지가 필요한가요?
창고를 생각해 보세요. 편의점 창고, 냉동 창고, 일반 물류 창고, 고문서 보관소는 각각 다른 방식으로 물건을 저장합니다. 매일 꺼내 쓰는 물건은 손 닿기 쉬운 곳에, 1년에 한 번 꺼내는 물건은 깊은 창고 안에 둡니다. 클라우드 스토리지도 마찬가지입니다. 데이터의 종류와 접근 빈도에 따라 최적화된 저장 방식이 필요합니다.
Azure는 목적에 따라 여러 스토리지 서비스를 제공합니다:
| 서비스 | 비유 | 용도 | |-------|------|------| | Blob Storage | 대형 사물함 | 사진, 동영상, 문서 등 파일 저장 | | Azure Files | 공유 네트워크 드라이브 | 여러 사람이 함께 쓰는 파일 서버 | | Azure Table Storage | 클라우드 스프레드시트 | 단순한 키-값 구조 데이터 | | Data Lake Storage Gen2 | 거대한 데이터 창고 | 분석용 대용량 원시 데이터 | | Azure Cosmos DB | 전 세계 도서관 네트워크 | 글로벌 분산 NoSQL 데이터 |
Azure Blob Storage — 거대한 파일 사물함
Blob(Binary Large Object)은 이미지, 동영상, PDF, 백업 파일처럼 크기가 크고 형식이 자유로운 데이터를 저장하는 서비스입니다. 개인 사물함을 생각해 보세요. 안에 무엇이 들어있든 상관없이 크기만 맞으면 넣을 수 있습니다.
Blob의 세 가지 유형
| 유형 | 특징 | 용도 | |------|------|------| | 블록 Blob (Block Blob) | 파일을 블록 단위로 저장, 병렬 업로드 가능 | 이미지, 동영상, 문서, 백업 (가장 일반적) | | 추가 Blob (Append Blob) | 기존 데이터 뒤에만 추가 가능, 수정 불가 | 로그 파일, 이벤트 스트림 | | 페이지 Blob (Page Blob) | 512바이트 페이지 단위, 랜덤 읽기/쓰기 | Azure VM 디스크 (VHD 파일) |
!Blob 스토리지 3가지 유형
액세스 계층 (Access Tier) — 비용과 속도의 트레이드오프
서랍장을 상상해 보세요. 매일 쓰는 물건은 가장 위 서랍에, 가끔 꺼내는 것은 중간 서랍에, 거의 쓰지 않는 것은 바닥 서랍 깊숙이 넣어둡니다. 접근하기 어려울수록 보관 비용은 낮지만 꺼내는 데 시간이 걸립니다.
| 계층 | 저장 비용 | 액세스 비용 | 적합한 데이터 | |------|---------|-----------|------------| | 핫 (Hot) | 높음 | 낮음 | 매일 접근하는 데이터 | | 쿨 (Cool) | 중간 | 중간 | 30일 이상 보관, 가끔 접근 | | 콜드 (Cold) | 낮음 | 중간~높음 | 90일 이상 보관, 드물게 접근 | | 아카이브 (Archive) | 매우 낮음 | 매우 높음 + 시간 지연 | 180일 이상, 거의 접근 안 함 |
아카이브 계층 주의사항: 데이터를 꺼내려면 먼저 핫/쿨 계층으로 "리하이드레이션(rehydration)"해야 합니다. 최대 15시간이 걸릴 수 있습니다. 비용은 가장 싸지만, 즉각 접근이 불가합니다.
중복성 (Redundancy) — 데이터 복사본 전략
| 옵션 | 복사본 위치 | 사용 사례 | |------|-----------|---------| | LRS (로컬 중복) | 동일 데이터센터 내 3개 복사본 | 비용 절감 우선, 지역 재해 위험 감수 | | ZRS (영역 중복) | 동일 지역 내 3개 가용 영역 | 데이터센터 장애에 대한 보호 | | GRS (지역 중복) | 다른 지역에도 비동기 복사 | 지역 재해 대비 | | GZRS (지역+영역 중복) | 다른 지역 + 영역 중복 | 최고 수준의 내구성 |
Azure Files — 공유 네트워크 드라이브
회사 사무실의 공용 파일 서버를 생각해 보세요. 팀원 누구나 같은 드라이브에 연결해 파일을 읽고 쓸 수 있습니다. Azure Files가 이것을 클라우드에서 제공합니다.
SMB(Windows 공유 방식) 또는 NFS 프로토콜을 지원하므로, Windows, Linux, macOS 어디서든 파일 공유를 마운트할 수 있습니다. 기존 온프레미스 파일 서버를 클라우드로 리프트 앤 시프트할 때 특히 유용합니다.
주요 활용 사례: 여러 VM이 공통 설정 파일을 공유 기존 파일 서버 마이그레이션 클라우드 기반 협업 파일 공유
Azure Table Storage — 클라우드 단순 저장소
Azure Table Storage는 NoSQL 키-값 저장소입니다. 거대한 스프레드시트처럼 생각하면 됩니다. 행마다 고정된 스키마가 없어서 각 행이 다른 속성을 가질 수 있습니다.
관계형 데이터베이스보다 훨씬 저렴하고 확장성이 좋지만, SQL JOIN이나 복잡한 쿼리는 지원하지 않습니다. 단순하고 빠른 조회가 필요한 대용량 데이터에 적합합니다.
주의: Azure Table Storage와 Cosmos DB Table API는 비슷해 보이지만 다릅니다. Cosmos DB Table API는 전 세계 분산, 밀리초 지연 시간 보장, 더 높은 SLA를 제공합니다.
Azure Data Lake Storage Gen2 — 분석을 위한 대형 창고
Data Lake Storage Gen2(ADLS Gen2)는 Blob Storage 위에 계층적 파일 시스템(Hierarchical Namespace)을 추가한 서비스입니다. 수십 테라바이트에서 수 페타바이트에 이르는 원시 데이터를 저장하고 분석 엔진(Azure Databricks, Synapse Analytics, HDInsight)이 직접 읽을 수 있게 최적화되어 있습니다.
비유를 들면, 일반 Blob Storage가 큰 창고라면 ADLS Gen2는 폴더와 서브폴더가 체계적으로 정리된 도서관 수준의 데이터 창고입니다. 파일/폴더 수준의 권한 설정(ACL)도 지원합니다.
주요 특징: 계층적 네임스페이스: 폴더 구조로 대용량 데이터 효율적 관리 POSIX 호환 ACL: 파일·폴더 수준 세밀한 권한 제어 Blob Storage와 동일한 중복성 옵션 Hadoop 및 분석 프레임워크와 호환
Azure Cosmos DB — 전 세계 도서관 네트워크
왜 글로벌 분산이 필요한가요?
서울에 데이터베이스 서버가 하나 있다고 가정해 봅시다. 뉴욕 사용자가 데이터를 요청하면 태평양을 건너 응답이 돌아옵니다. 왕복 지연 시간이 200ms 이상 걸릴 수 있습니다. 반면 전 세계 주요 도시마다 도서관 지점이 있다면, 가장 가까운 지점에서 책을 빌릴 수 있습니다.
Cosmos DB는 전 세계 Azure 리전에 데이터를 자동으로 복제해 어디서든 한 자릿수 밀리초(single-digit millisecond) 지연 시간을 보장합니다. 글로벌 사용자를 대상으로 하는 앱이라면 Cosmos DB가 최적입니다.
핵심 개념
일관성 수준 (Consistency Level): 글로벌 복제본 간에 데이터 동기화를 얼마나 엄격하게 할지 결정합니다. 강한 일관성(Strong)은 항상 최신 데이터를 보장하지만 지연 시간이 깁니다. 최종 일관성(Eventual)은 가장 빠르지만 잠시 오래된 데이터를 볼 수 있습니다. 그 사이에 Bounded Staleness, Session, Consistent Prefix 수준도 있습니다.
멀티 마스터 (Multi-master): 여러 리전에서 동시에 쓰기가 가능합니다. 서울과 뉴욕 사용자가 동시에 데이터를 수정할 수 있습니다.
요청 단위 (RU, Request Unit): Cosmos DB의 처리 용량 단위입니다. 1KB 항목 읽기 = 1 RU. 쓰기는 읽기보다 더 많은 RU를 사용합니다.
파티션 키 (Partition Key): 데이터를 효율적으로 나누는 기준 속성입니다. 마치 도서관에서 책을 장르별로 나눠 서가에 배치하는 것처럼, 파티션 키를 잘 선택하면 검색 속도가 빨라지고 핫 파티션을 방지할 수 있습니다. 파티션 키는 데이터가 고르게 분산되도록 카디널리티(고유값 수)가 높아야 합니다.
Cosmos DB API — 어떤 형식으로 데이터를 저장할까요?
Cosmos DB는 단일 엔진 위에 다양한 API를 제공합니다. 기존에 사용하던 데이터베이스 드라이버를 그대로 사용할 수 있어 마이그레이션이 쉽습니다.
| API | 데이터 모델 | 사용 사례 | 쿼리 방식 | |-----|-----------|---------|---------| | NoSQL (Core) | JSON 문서 | 범용, 권장 기본값 | SQL-like | | MongoDB | BSON 문서 | MongoDB 앱 마이그레이션 | MongoDB 쿼리 | | Cassandra | 열 패밀리 | 대용량 쓰기, 시계열 데이터 | CQL | | Gremlin | 그래프 (노드+엣지) | 소셜 네트워크, 추천 시스템 | Gremlin | | Table | 키-값 | Azure Table Storage 마이그레이션 | OData |
NoSQL API가 Cosmos DB의 기본이자 가장 많이 사용되는 API입니다. 나머지는 기존 데이터베이스에서 마이그레이션할 때 선택합니다.
시험 핵심 정리
"이미지, 동영상, 파일 저장" -- Blob Storage "매일 접근, 높은 저장 비용" -- 핫(Hot) 계층 "30일 이상 보관, 가끔 접근" -- 쿨(Cool) 계층 "거의 접근 안 함, 15시간 지연 리하이드레이션 필요" -- 아카이브(Archive) 계층 "동일 데이터센터 3개 복사본" -- LRS / "다른 지역에도 복사" -- GRS "로그 파일, 뒤에만 추가" -- 추가 Blob(Append Blob) "VM 디스크(VHD)" -- 페이지 Blob(Page Blob) "공유 파일 서버, SMB/NFS" -- Azure Files "단순 키-값, 스키마 없음" -- Azure Table Storage "대용량 분석용 원시 데이터, 계층적 네임스페이스" -- Data Lake Storage Gen2 "전 세계 분산, 한 자릿수 밀리초 지연" -- Cosmos DB "JSON 문서, 기본 API" -- Cosmos DB NoSQL API "MongoDB 앱 마이그레이션" -- Cosmos DB MongoDB API "그래프 데이터, 소셜 네트워크" -- Cosmos DB Gremlin API "열 패밀리, 대용량 쓰기" -- Cosmos DB Cassandra API "데이터 분산 기준, 고른 분포" -- 파티션 키(Partition Key) "처리 용량 단위, 1KB 읽기 = 1RU" -- 요청 단위(RU)