DP-900 공식 출제 범위 도메인 3에는 "Azure Storage의 기능 설명"이 있고, 그 아래에 Blob Storage, Azure Files, Table Storage가 하나씩 나옵니다. 문제는 "이미지는 Blob"처럼 이름만 묻는 데서 그치지 않고, 계층별 최소 보관 기간, 수명 주기 정책, PartitionKey와 RowKey, 파일 공유 프로토콜처럼 한 단계 더 들어간 규칙을 자주 묻습니다.
이 글은 DP-900 학습자료 중 비관계형 데이터 기본 개념 편의 보충편입니다. 그 글에서 다룬 Blob 유형, 액세스 계층, 중복성의 기본기를 이어받아 스토리지 계정 구조, Blob 수명 주기 관리, Data Lake Storage Gen2의 계층 구조 네임스페이스, Azure Files의 프로토콜과 용량, Table Storage의 키 설계까지 시험에 나오는 세부 규칙을 정리합니다.
---
스토리지 계정: 모든 Azure Storage의 출발점
아파트 단지를 떠올려 보세요. 단지 하나 안에 짐을 맡기는 창고동, 여러 세대가 함께 쓰는 공용 사무실, 출입 기록을 적는 관리실 장부가 있습니다. Azure Storage에서는 스토리지 계정이 이 단지 역할을 하고, 그 안에 Blob 컨테이너, 파일 공유, 테이블, 큐가 들어갑니다.
| 서비스 | 계층 구조 | 접근 방식 | |------|------|------| | Blob Storage | 스토리지 계정 → 컨테이너 → Blob | HTTP(S) 기반 Blob API | | Data Lake Storage Gen2 | 스토리지 계정(계층 구조 네임스페이스 켬) → 파일 시스템 → 디렉터리 → 파일 | Blob API + 분석용 파일 시스템 드라이버 | | Azure Files | 스토리지 계정 → 파일 공유 → 디렉터리 → 파일 | SMB, NFS 마운트 | | Table Storage | 스토리지 계정 → 테이블 → 엔터티 | 키 기반 REST API |
데이터 복제 방식인 중복성은 스토리지 계정 단위로 정합니다. LRS는 한 데이터센터 안에 복사본 3개, ZRS는 같은 지역의 가용 영역 3곳에 복사본을 둡니다. GRS와 GZRS는 수백 km 떨어진 보조 지역에 비동기로 복제하고, 앞에 RA가 붙은 RA-GRS·RA-GZRS를 고르면 장애 조치 전에도 보조 지역에서 읽을 수 있습니다. 단, Azure Files는 보조 지역 읽기를 지원하지 않습니다.
시험 팁: "지역 장애에 대비하고, 장애 조치 전에도 보조 지역에서 데이터를 읽고 싶다" → RA-GRS 또는 RA-GZRS. "한 지역 안에서 데이터센터 하나가 멈춰도 데이터를 쓸 수 있어야 한다" → ZRS.
---
Blob Storage: 액세스 계층과 수명 주기 관리
Blob 유형과 최대 크기
Blob은 컨테이너 안에 저장되고, 접근 권한도 컨테이너 단위로 관리합니다. 컨테이너 안의 폴더는 Blob 이름에 들어간 "/"로 만든 가상 폴더라서, 폴더 단위로 권한을 주거나 한꺼번에 옮기는 작업은 할 수 없습니다.
| 유형 | 구조 | 최대 크기 | 쓰임 | |------|------|------|------| | 블록 Blob | 블록(최대 4,000MiB) 최대 50,000개 | 약 190.7TiB | 이미지·동영상·문서처럼 자주 바뀌지 않는 큰 파일 | | 페이지 Blob | 512바이트 고정 페이지 | 8TiB | 가상 머신 디스크, 임의 읽기·쓰기 | | 추가 Blob | 끝에만 블록 추가 가능 | 약 195GiB | 로그처럼 계속 덧붙이는 데이터 |
액세스 계층과 조기 삭제 요금
Hot·Cool·Cold·Archive 네 계층은 저장 비용과 액세스 비용의 균형을 다르게 잡습니다. Hot이 기본값이고, 아래로 갈수록 저장은 싸지고 꺼내 쓰는 비용은 비싸집니다. Cool은 최소 30일, Cold는 최소 90일, Archive는 최소 180일을 보관해야 하며, 그 전에 삭제하거나 다른 계층으로 옮기면 남은 기간만큼 조기 삭제 요금이 일할 계산으로 붙습니다. Cool로 옮긴 Blob을 21일 만에 지우면 남은 9일치 저장 요금을 내는 식입니다.
!Blob 액세스 계층과 수명 주기 관리
Archive는 오프라인 계층이라 그대로는 읽거나 수정할 수 없습니다. 먼저 Hot·Cool·Cold 중 하나로 바꾸는 리하이드레이션을 해야 합니다. 표준 우선순위는 10GB 미만 개체 기준 최대 15시간, 비용이 더 드는 높은 우선순위는 1시간 안에 끝날 수도 있어 긴급 복원에 씁니다.
수명 주기 관리 정책
새로 만든 데이터는 자주 쓰다가 시간이 지나면 거의 보지 않게 됩니다. 수명 주기 관리 정책은 JSON으로 작성한 규칙에 따라 Blob을 더 저렴한 계층으로 자동으로 옮기거나 삭제합니다.
조건: 생성 시간, 마지막 수정 시간, 마지막 액세스 시간(액세스 추적을 켠 경우)으로부터 지난 일수 작업: Cool·Cold·Archive로 계층 변경, 현재 버전·이전 버전·스냅샷 삭제 필터: 이름 접두사나 Blob 인덱스 태그로 대상 Blob 지정 비용: 정책 자체는 무료이고 계층 변경 작업 비용만 냅니다. 규칙을 바꾸면 적용까지 최대 24시간이 걸립니다.
시험 팁: "업로드 후 30일이 지나면 Cool, 180일이 지나면 Archive로 자동 이동하고 7년 뒤 삭제" → 수명 주기 관리 정책. "Archive의 Blob을 바로 읽을 수 없다" → 리하이드레이션이 먼저 필요합니다.
---
Data Lake Storage Gen2: 계층 구조 네임스페이스가 바꾸는 것
Data Lake Storage Gen2는 별도 서비스가 아니라 스토리지 계정의 계층 구조 네임스페이스 설정을 켠 Blob Storage입니다. 계정을 만들 때 켤 수도 있고 기존 계정을 업그레이드할 수도 있지만, 업그레이드는 한 방향이라 다시 평면 네임스페이스로 되돌릴 수 없습니다.
이름에 "/"를 넣어 흉내만 내던 폴더가 진짜 디렉터리가 되면서 두 가지가 달라집니다.
원자적 디렉터리 작업: 디렉터리 이름 변경·이동·삭제가 상위 디렉터리 항목 하나만 바꾸는 작업이 됩니다. 평면 구조에서는 Blob 수백만 개를 하나씩 처리해야 했습니다. Spark와 Hive는 작업이 끝날 때 임시 출력 폴더의 이름을 바꾸므로 분석 작업 시간이 크게 줄어듭니다. POSIX 호환 ACL: Azure RBAC와 별개로 파일·폴더마다 읽기·쓰기·실행 권한을 세밀하게 줄 수 있습니다.
| 구분 | Blob Storage (평면 네임스페이스) | Data Lake Storage Gen2 (계층 구조 네임스페이스) | |------|------|------| | 폴더 | 이름 속 "/"로 만든 가상 폴더 | 실제 디렉터리 | | 디렉터리 이름 변경 | Blob을 하나씩 처리 | 한 번의 원자적 작업 | | 세밀한 권한 | 컨테이너 수준 중심 | 파일·폴더별 POSIX ACL | | 주 용도 | 앱이 읽고 쓰는 개체 저장 | Databricks·Spark 등 대규모 분석 |
Blob의 액세스 계층과 수명 주기 관리는 그대로 쓸 수 있고, Microsoft Fabric의 OneLake도 Data Lake Storage Gen2 위에 만들어져 있습니다.
시험 팁: "빅데이터 분석용 저장소에 폴더 단위 권한과 디렉터리 작업이 필요하다" → 계층 구조 네임스페이스를 켠 Data Lake Storage Gen2.
---
Azure Files: 클라우드 파일 공유
Azure Files는 사무실 파일 서버를 클라우드로 옮긴 것입니다. 여러 컴퓨터가 같은 공유를 네트워크 드라이브처럼 마운트해 함께 씁니다.
| 프로토콜 | 지원 클라이언트 | 조건 | |------|------|------| | SMB | Windows, Linux, macOS | HDD·SSD 모두 가능 | | NFS | Linux | SSD 미디어 계층에서만, 가상 네트워크의 프라이빗 엔드포인트나 서비스 엔드포인트로 접근 |
미디어 계층은 SSD와 HDD 두 가지입니다. 한 자릿수 밀리초 지연이 필요하면 SSD, 비용이 더 중요하면 HDD를 씁니다. 종량제 HDD 파일 공유는 다시 트랜잭션 최적화·핫·쿨 세 가지 액세스 계층으로 나뉘고, 차가운 계층일수록 저장 비용은 낮고 트랜잭션 비용은 높습니다.
용량: 파일 하나는 최대 4TiB, 종량제 파일 공유는 최대 100TiB까지 커질 수 있습니다. Azure File Sync: 온프레미스 Windows Server에 자주 쓰는 파일을 캐시해 두고 Azure 파일 공유와 동기화합니다. 지사의 빠른 로컬 액세스와 클라우드 보관을 함께 얻습니다. 스냅샷: 공유의 읽기 전용 특정 시점 복사본을 공유당 최대 200개까지 만들 수 있습니다.
시험 팁: "Linux 서버들이 NFS로 마운트할 공유" → SSD 계층의 Azure Files. "지사 파일 서버에 자주 쓰는 파일은 로컬로 두고 원본은 Azure에" → Azure File Sync.
---
Table Storage: PartitionKey와 RowKey
Table Storage의 테이블은 관계형 테이블과 이름만 같습니다. 행(엔터티)마다 열이 달라도 되는 스키마 없는 키-값 저장소이고, 외래 키·관계·저장 프로시저·뷰가 없습니다. 그래서 고객 한 명의 전화번호와 주소를 한 행에 모두 넣는 비정규화된 형태로 저장하는 경우가 많습니다.
엔터티 하나는 시스템 속성 3개(PartitionKey, RowKey, Timestamp)를 포함해 최대 255개 속성, 전체 1MiB까지 담을 수 있습니다. Timestamp는 마지막 수정 시각으로 서버가 관리하며 사용자가 바꿀 수 없습니다.
키 설계와 쿼리 성능
PartitionKey는 관련 행을 같은 파티션에 묶는 값이고, RowKey는 파티션 안에서 행을 고유하게 구분하는 값입니다. 둘을 합친 값이 테이블 전체의 고유 키가 되고, 같은 파티션 안에서는 RowKey 순서로 정렬되어 저장됩니다.
| 쿼리 방식 | 조건 | 속도 | |------|------|------| | 포인트 쿼리 | PartitionKey + RowKey 모두 지정 | 가장 빠름, 행 하나 | | 범위 쿼리 | PartitionKey + RowKey 범위 | 빠름, 파티션 안의 연속 행 | | 파티션 스캔 | PartitionKey + 다른 속성 조건 | 파티션 하나를 훑음 | | 테이블 스캔 | PartitionKey 없음 | 가장 느림, 모든 파티션을 훑음 |
예를 들어 센서 데이터라면 PartitionKey에 센서 ID, RowKey에 측정 시각을 넣으면 "센서 A의 오늘 측정값"을 범위 쿼리로 빠르게 가져올 수 있습니다. 다른 속성으로도 자주 검색해야 하거나 전 세계에 분산해야 한다면, 모든 속성을 자동 인덱싱하는 Cosmos DB for Table이 대안입니다.
시험 팁: "Table Storage에서 엔터티를 고유하게 식별하는 것" → PartitionKey + RowKey 조합. "같은 파티션 안의 행은 무엇의 순서로 정렬되나" → RowKey.
---
시나리오로 연습하기
먼저 답을 떠올린 뒤 오른쪽 열을 확인해 보세요.
| 문제 상황 | 정답 | 판단 근거 | |------|------|------| | 촬영 직후에는 자주 보고 90일 뒤부터는 거의 보지 않는 사진을 자동으로 저렴하게 보관 | 수명 주기 관리 정책 | 경과 일수 기반 자동 계층 변경 | | Archive에 있는 계약서 스캔본을 오늘 안에 급히 열어야 한다 | 높은 우선순위 리하이드레이션 | 오프라인 계층은 먼저 온라인 계층으로 | | Cool에 넣은 데이터를 10일 만에 삭제했더니 추가 요금이 나왔다 | 조기 삭제 요금 | Cool은 최소 30일 | | Spark 작업의 출력 폴더 이름 변경이 너무 오래 걸린다 | 계층 구조 네임스페이스(Data Lake Gen2) | 원자적 디렉터리 작업 | | Windows와 macOS 사용자가 함께 쓰는 부서 공유 드라이브 | Azure Files (SMB) | 여러 OS에서 마운트 | | 지역 재해 대비 + 평소에도 보조 지역에서 읽기 | RA-GRS | 읽기 가능한 지역 중복 | | 매장 ID별로 모아 두고 거래 시각으로 빠르게 조회할 대량 키-값 데이터 | Table Storage (PartitionKey=매장 ID, RowKey=시각) | 파티션 + 정렬 키 | | 가상 머신의 디스크를 저장하는 Blob 유형 | 페이지 Blob | 512바이트 페이지, 임의 읽기·쓰기 |
---
시험 핵심 정리
시험장 가기 전 마지막으로 확인할 핵심 포인트입니다.
| 구분 | 핵심 암기 사항 | |------|------| | 스토리지 계정 | Blob 컨테이너·파일 공유·테이블·큐를 담는 단위, 중복성도 계정 단위 | | RA-GRS · RA-GZRS | 장애 조치 전에도 보조 지역에서 읽기 가능 (Azure Files는 미지원) | | 블록 · 페이지 · 추가 Blob | 일반 파일 · VM 디스크 · 로그 | | 최소 보관 기간 | Cool 30일, Cold 90일, Archive 180일, 미달 시 조기 삭제 요금 | | Archive | 오프라인, 리하이드레이션 필요 (표준 최대 15시간, 높은 우선순위는 더 빠름) | | 수명 주기 관리 정책 | 생성·수정·액세스 후 경과 일수로 계층 이동·삭제, JSON 규칙 | | Data Lake Storage Gen2 | 계층 구조 네임스페이스를 켠 Blob Storage, 업그레이드는 되돌릴 수 없음 | | 계층 구조 네임스페이스 | 원자적 디렉터리 작업 + POSIX ACL | | Azure Files 프로토콜 | SMB(여러 OS), NFS(Linux, SSD 전용) | | Azure File Sync | 온프레미스 Windows Server에 캐시하고 Azure 공유와 동기화 | | Table Storage 키 | PartitionKey + RowKey가 고유 키, 파티션 안은 RowKey 순 | | Table Storage 엔터티 | 최대 255개 속성(시스템 3개 포함), 1MiB, 스키마 없음 |