데이터를 저장하는 방법에는 여러 가지가 있습니다. 사진은 앨범에, 서류는 파일 캐비닛에, 오래된 물건은 창고에 보관하듯, Azure도 데이터 종류와 용도에 따라 다양한 스토리지 서비스를 제공합니다. 이 글에서는 Azure 스토리지 서비스 전체를 처음 배우는 분도 이해할 수 있도록 비유와 함께 설명합니다.
Azure Storage 계정이란?
Azure Storage 계정은 모든 Azure 스토리지 서비스를 사용하기 위한 최상위 그릇입니다. 스토리지 계정을 만들면 그 안에 Blob, 파일, 큐, 테이블 등 다양한 스토리지 서비스를 담을 수 있습니다. 은행 계좌에 비유하면, 계좌(Storage 계정) 안에 예금(Blob), 적금(Files), 외화(Queue) 등 여러 상품을 넣어두는 것과 같습니다.
스토리지 계정을 만들 때 선택하는 주요 설정은 세 가지입니다. 첫째는 성능 계층입니다. Standard는 HDD 기반으로 저렴하고, Premium은 SSD 기반으로 고성능입니다. 둘째는 중복성 옵션으로 LRS, ZRS, GRS, RA-GRS, GZRS 중 선택합니다. 셋째는 계정 종류로 General Purpose v2가 가장 권장됩니다.
Azure Blob Storage — 만능 창고
Blob(Binary Large Object) Storage는 Azure에서 가장 많이 쓰이는 스토리지입니다. 이미지, 동영상, 문서, 백업 파일, 로그 파일 등 어떤 형태의 데이터든 저장할 수 있는 만능 창고입니다. 파일 크기 제한이 거의 없고, 수십억 개의 개체를 저장할 수 있습니다.
Blob에는 세 가지 타입이 있습니다. 각각 다른 용도에 최적화되어 있으므로 상황에 맞게 선택해야 합니다.
Block Blob — 일반 박스
가장 일반적인 타입입니다. 이미지, 동영상, 문서, 백업 등을 저장합니다. 파일 전체를 블록 단위로 나눠서 업로드하므로, 대용량 파일 업로드 시 중간에 실패해도 해당 블록만 다시 업로드하면 됩니다. 대부분의 일반적인 파일 저장 요구에 Block Blob을 사용합니다.
Page Blob — 무작위 접근 서랍
랜덤(무작위) 읽기/쓰기가 필요할 때 사용합니다. Azure VM의 가상 하드 디스크(VHD) 파일이 Page Blob으로 저장됩니다. 특정 위치의 데이터를 빠르게 읽고 쓸 수 있어 디스크 용도에 적합합니다. 최대 8TB까지 지원합니다.
Append Blob — 덧붙이기 전용 노트
한 번 쓴 내용은 수정하지 않고 끝에 계속 추가하는 방식입니다. 로그 파일이나 감사(Audit) 데이터 기록에 적합합니다. 한 번 기록된 내용은 수정이나 삭제 없이 끝에만 추가됩니다. 보안 감사 기록, 스트리밍 로그처럼 무결성이 중요한 데이터에 이상적입니다.
| Blob 타입 | 특징 | 용도 | |----------|------|------| | Block Blob | 블록 단위 업로드 | 이미지, 동영상, 문서, 백업 | | Page Blob | 랜덤 읽기/쓰기 | VM 가상 디스크 (VHD) | | Append Blob | 끝에만 추가 | 로그 파일, 감사 데이터 |
스토리지 접근 계층 — 창고의 온도 관리
Blob Storage에는 데이터 사용 빈도에 따라 선택할 수 있는 네 가지 접근 계층이 있습니다. 자주 꺼내는 물건은 손 닿기 쉬운 곳에, 거의 안 꺼내는 물건은 깊숙한 창고에 보관하면 비용을 아낄 수 있는 것처럼, 접근 빈도에 따라 저장 비용과 접근 비용이 달라집니다. 핵심 원칙은 저장 비용과 접근 비용이 반비례한다는 것입니다. 저장 비용이 낮을수록 꺼낼 때 비용이 높아집니다.
Hot 계층 — 냉장고 (자주 꺼내는 곳)
매일 또는 자주 접근하는 데이터에 적합합니다. 저장 비용이 가장 높지만, 데이터를 꺼내는(접근) 비용은 가장 낮습니다. 예시: 현재 운영 중인 웹사이트의 이미지 파일, 오늘 생성된 로그 파일, 활발히 사용 중인 애플리케이션 데이터.
Cool 계층 — 창고 선반 (가끔 꺼내는 곳)
30일 이상 접근하지 않을 것으로 예상되는 데이터에 적합합니다. 저장 비용이 Hot보다 저렴하지만, 접근 시 비용이 발생합니다. 예시: 한 달 이상 지난 백업 파일, 분기별 리포트, 가끔 확인하는 모니터링 데이터.
Cold 계층 — 지하 창고 (거의 안 꺼내는 곳)
90일 이상 접근하지 않을 데이터에 적합합니다. Cool보다 저장 비용이 더 낮습니다. 비교적 최근에 추가된 계층으로, Cool과 Archive 사이의 중간 옵션입니다.
Archive 계층 — 장기 보관 금고
180일 이상 거의 접근하지 않을 데이터를 위한 가장 저렴한 저장 계층입니다. 데이터를 꺼낼 때(리하이드레이션)는 최대 수 시간이 걸릴 수 있습니다. 규제상 장기 보관이 필요한 의료 기록, 법적 문서, 오래된 미디어 파일 등에 사용합니다. 리하이드레이션 우선순위를 높음(1시간 이내)으로 설정하면 더 빨리 꺼낼 수 있지만 비용이 더 높아집니다.
| 계층 | 저장 비용 | 접근 비용 | 최소 보관 기간 | 적합한 데이터 | |------|---------|---------|------------|------------| | Hot | 높음 | 낮음 | 없음 | 자주 접근하는 데이터 | | Cool | 중간 | 중간 | 30일 | 가끔 접근하는 데이터 | | Cold | 낮음 | 높음 | 90일 | 드물게 접근하는 데이터 | | Archive | 매우 낮음 | 매우 높음 (리하이드레이션) | 180일 | 장기 보관, 거의 접근 안 함 |
!Blob 스토리지 액세스 계층
Azure Files — 클라우드 공유 드라이브
Azure Files는 SMB(Windows 공유 폴더 프로토콜) 또는 NFS 프로토콜로 마운트해서 사용하는 완전 관리형 파일 공유 서비스입니다. 회사 서버에 있던 공유 드라이브(예: Z: 드라이브)를 클라우드로 옮긴 것과 같습니다. 여러 VM이나 컴퓨터에서 동시에 같은 파일에 접근할 수 있습니다.
왜 Azure Files를 쓸까요? 온프레미스 파일 서버를 클라우드로 이전하거나, 여러 VM이 공통 설정 파일이나 데이터를 공유해야 할 때, 또는 레거시 애플리케이션이 파일 공유 방식으로 데이터를 주고받을 때 사용합니다.
SMB 2.1, SMB 3.0, NFS 4.1 프로토콜 지원 Windows, Linux, macOS에서 마운트 가능 Azure File Sync: 온프레미스 파일 서버와 Azure Files 간 자동 동기화 — 온프레미스 서버를 캐시로 활용하고 데이터는 Azure에 중앙 보관 스탠다드(HDD), 프리미엄(SSD) 두 가지 성능 계층 제공
Azure Queue Storage — 번호표 대기열
Queue Storage는 메시지를 순서대로 저장하고 처리하는 대기열 서비스입니다. 은행이나 음식점의 번호표 시스템과 같습니다. 고객(애플리케이션 A)이 번호표를 뽑고(메시지 삽입), 직원(애플리케이션 B)이 차례대로 처리합니다. 두 애플리케이션이 직접 연결되지 않아도 메시지를 주고받을 수 있어, 서비스 간 결합도를 낮추고 처리 속도 차이도 완충해 줍니다.
실용적인 예시를 들면, 사진 업로드 웹사이트를 생각해 보세요. 사용자가 사진을 올리면(메시지 삽입), 리사이징·썸네일 생성 서비스(메시지 처리)가 대기열에서 사진을 꺼내 처리합니다. 업로드가 한꺼번에 몰려도 대기열이 완충 역할을 해 처리 서비스가 과부하되지 않습니다.
최대 64KB 크기의 메시지 저장 메시지를 최대 7일간 보관 비동기 작업 처리, 마이크로서비스 간 통신에 적합 처리 완료 전 메시지가 다시 보이지 않도록 visibility timeout 설정 가능
Azure Table Storage — 단순 NoSQL 테이블
Table Storage는 키-값(Key-Value) 형식의 단순한 NoSQL 데이터 저장소입니다. 엑셀 스프레드시트처럼 행(Row)과 열(Column)로 구성되지만, 스키마가 고정되어 있지 않아 각 행마다 다른 컬럼을 가질 수 있습니다. 관계형 DB보다 훨씬 저렴하고, 대용량 비정형 데이터 저장에 적합합니다. 복잡한 쿼리나 관계형 데이터가 필요한 경우에는 Cosmos DB를 추천합니다.
모든 항목은 파티션 키(Partition Key)와 행 키(Row Key)의 조합으로 고유하게 식별됩니다. 같은 파티션 키를 가진 항목들은 같은 물리적 서버에 저장되어 빠르게 조회할 수 있습니다.
Azure Managed Disks — VM의 하드 디스크
Managed Disks는 Azure VM에 연결하는 가상 하드 디스크입니다. VM을 만들면 기본적으로 OS 디스크가 하나 포함되지만, 추가 데이터 저장을 위해 Managed Disk를 더 붙일 수 있습니다. "관리형(Managed)"이라는 말은 디스크의 물리적 관리(스토리지 계정 배치, 복제, 가용성 구역 분산 등)를 Azure가 자동으로 처리한다는 뜻입니다. 예전에는 직접 스토리지 계정을 만들어 연결했지만, 이제는 Azure가 알아서 관리합니다.
성능 유형별 특징: Ultra Disk: 극한의 IOPS와 처리량, SAP HANA·대형 SQL 같은 고성능 데이터베이스용 Premium SSD v2: 고성능, 낮은 지연시간, IOPS와 처리량을 개별 조정 가능 Premium SSD: SSD 기반, 고성능 프로덕션 워크로드에 표준 Standard SSD: 균형 잡힌 성능과 비용, 웹 서버·개발 환경에 적합 Standard HDD: 가장 저렴, 백업·비중요 데이터에 사용
스토리지 중복성 옵션 — 데이터 복사본 관리
중복성(Redundancy)은 데이터를 여러 곳에 복사해두어, 장애 발생 시에도 데이터를 잃지 않도록 하는 전략입니다. 중요한 서류를 여러 장 복사해서 서로 다른 장소에 보관하는 것과 같습니다. 중복성 수준이 높을수록 보호 범위가 넓어지지만 비용도 높아집니다.
LRS (Locally Redundant Storage) — 같은 건물 안에 3개 복사
데이터를 같은 데이터센터(단일 물리적 위치) 안에 3개의 복사본으로 저장합니다. 가장 저렴하지만, 데이터센터 전체 장애(화재, 홍수 등) 시 데이터를 잃을 수 있습니다. 재현이 가능한 데이터나 비용이 최우선인 환경에 사용합니다.
ZRS (Zone-Redundant Storage) — 같은 도시 내 다른 건물 3개에 복사
같은 Azure 지역(Region) 내 3개의 서로 다른 가용성 구역(Availability Zone)에 데이터를 복사합니다. 하나의 데이터센터(건물) 전체가 화재나 정전으로 멈춰도 다른 가용성 구역에서 데이터에 접근할 수 있습니다. 고가용성이 중요한 프로덕션 환경에 권장합니다.
GRS (Geo-Redundant Storage) — 다른 도시 창고에도 보관
기본 지역(Primary Region)에 LRS로 3개 복사한 후, 수백 킬로미터 떨어진 보조 지역(Secondary Region)에도 3개 복사합니다. 총 6개 복사본. 지역 전체를 덮치는 재난(지진, 광역 홍수 등)이 발생해도 데이터를 보존합니다. 단, 장애 조치(Failover) 전까지는 보조 지역에 접근할 수 없습니다.
RA-GRS (Read-Access Geo-Redundant Storage) — 다른 도시 창고에서 평소에도 읽기 가능
GRS와 동일하게 지리적으로 복제하되, 보조 지역 데이터를 평소에도 읽기 전용으로 접근할 수 있습니다. 재해가 발생하기 전에도 지리적으로 가까운 보조 지역에서 읽기 요청을 처리해 글로벌 사용자 대상 서비스의 지연시간을 줄일 수 있습니다.
GZRS / RA-GZRS — 최고 수준의 이중 보호
기본 지역에서 ZRS(3개 가용성 구역에 복제)를 사용하고, 보조 지역에도 LRS로 복제합니다. 가용성 구역 장애(건물 단위)와 지역 재난(도시 단위) 모두에 대응할 수 있는 최고 수준의 중복성입니다. RA-GZRS는 보조 지역을 읽기 전용으로 접근 가능한 버전입니다.
| 중복성 | 복사 위치 | 내결함성 범위 | 비용 | |-------|---------|------------|------| | LRS | 단일 DC, 동일 지역 | DC 내 장비 장애 | 최저 | | ZRS | 3개 가용성 구역, 동일 지역 | 가용성 구역 단위 장애 | 중간 | | GRS | 동일 지역 LRS + 보조 지역 LRS | 지역 단위 재난 | 높음 | | RA-GRS | GRS + 보조 지역 읽기 전용 접근 | 지역 재난 + 글로벌 읽기 | 더 높음 | | GZRS | 동일 지역 ZRS + 보조 지역 LRS | 구역 장애 + 지역 재난 모두 | 최고 |