AZ-104 시험에서 스토리지 도메인은 전체의 15~20%를 차지합니다. 처음 보면 낯선 용어들이 많지만, 실생활 비유를 통해 접근하면 훨씬 쉽게 이해할 수 있습니다. 이 글에서는 스토리지 계정 구성, 접근 제어, Blob Storage, Azure Files까지 핵심 개념을 하나씩 친절하게 설명합니다.
스토리지 계정
스토리지 계정은 은행의 금고와 같습니다. 은행에 가면 여러 종류의 금고(예금, 적금, 대여금고)가 있듯이, Azure 스토리지 계정 안에도 여러 종류의 저장 공간(Blob, Files, Queue, Table)이 존재합니다. 스토리지 계정 자체는 이 모든 것을 묶어 관리하는 "컨테이너" 역할을 합니다.
예를 들어, 회사 웹사이트의 이미지 파일, 로그 기록, 직원 공유 폴더를 모두 하나의 스토리지 계정 아래에서 관리할 수 있습니다. 스토리지 계정을 만들 때 가장 먼저 결정해야 하는 것이 바로 중복성(Redundancy) — 즉, 데이터를 얼마나, 어디에 복사해 둘 것인가입니다.
중복성 옵션
중복성이란 "데이터를 몇 곳에 백업해 두느냐"의 문제입니다. 하드 드라이브가 갑자기 망가지거나, 건물 전체에 정전이 일어나거나, 심지어 자연재해로 데이터 센터 전체가 피해를 입었을 때도 데이터를 잃지 않으려면 여러 곳에 복사본을 만들어 두어야 합니다.
| 옵션 | 복사 위치 | 리전 재해 보호 | 한 줄 요약 | |------|-----------|--------------|------------| | LRS | 단일 데이터센터 내 3개 복사 | 불가 | 가장 저렴, 같은 건물 내 보호 | | ZRS | 같은 리전의 3개 가용 영역(AZ)에 복사 | 불가 | 건물 단위 장애까지 보호 | | GRS | LRS + 수백 km 떨어진 다른 리전에도 복사 (총 6개) | 가능 (복구 전 읽기 불가) | 지역 재해까지 보호 | | RA-GRS | GRS와 동일 + 원격 리전에서 읽기도 가능 | 가능 (읽기 가능) | 재해 중에도 읽기 서비스 유지 | | GZRS | ZRS + 원격 리전 LRS (총 6개) | 가능 (최고 내구성) | 가장 강력한 보호 |
실생활 비유로 이해하기
LRS는 중요한 서류를 사무실 캐비닛 3개에 각각 복사해 두는 것과 같습니다. 캐비닛 하나가 망가져도 괜찮지만, 사무실 건물이 불에 타면 모두 잃습니다. ZRS는 같은 도시의 세 군데 다른 건물 금고에 보관하는 것입니다. 건물 하나가 무너져도 다른 건물에 데이터가 살아있습니다. GRS는 서울 사무실에 원본을 두고, 부산 창고에도 복사본을 숨겨두는 것입니다. 서울 전체가 재해를 입어도 부산 복사본이 있습니다. 단, 평소에는 부산 복사본을 직접 열람할 수 없고, 복구 절차를 거쳐야 합니다. RA-GRS는 GRS와 같지만, 평소에도 부산 창고를 "읽기 전용"으로 열람할 수 있습니다. 서울이 바쁠 때 부산에서 읽기 요청을 처리하도록 구성할 수도 있습니다. GZRS는 ZRS와 GRS를 합친 최강 조합입니다. 같은 리전에서는 세 건물에 분산 보관하고, 원격 리전에도 추가 복사본을 유지합니다.
시험에서 "가장 저렴한 옵션"을 고르라면 LRS, "리전 재해 보호 + 원격 읽기"가 필요하다면 RA-GRS를 선택하면 됩니다.
!스토리지 중복성 옵션 5가지
액세스 제어
스토리지 계정에 누가, 어떻게 접근할 수 있는지 관리하는 것이 액세스 제어입니다. 마치 건물 출입 시스템처럼, 아무나 들어올 수 없도록 열쇠와 출입증을 관리하는 것입니다.
액세스 키
액세스 키는 스토리지 계정의 마스터 키입니다. 이 키 하나만 있으면 해당 스토리지 계정의 모든 데이터에 접근하고 수정할 수 있습니다. 마치 건물 전체의 모든 방을 열 수 있는 마스터 열쇠와 같습니다. 그렇기 때문에 매우 강력하고, 그만큼 위험합니다. 절대 코드에 직접 적어두거나 외부에 노출해서는 안 되며, Azure Key Vault에 안전하게 보관하는 것을 권장합니다.
SAS (Shared Access Signature)
SAS는 임시 방문증과 같습니다. 마스터 키를 주기는 불안하지만, 특정 방에만, 정해진 시간 동안, 특정 행동(읽기 전용 등)만 허용하고 싶을 때 사용합니다.
예를 들어, 외부 파트너에게 이미지 파일을 24시간 동안만 다운로드할 수 있는 링크를 제공하고 싶다면, SAS 토큰이 포함된 URL을 생성해서 전달하면 됩니다. 24시간이 지나면 링크는 자동으로 무효화됩니다.
SAS의 종류는 다음과 같습니다:
서비스 SAS: 특정 서비스(예: Blob만, 또는 Files만)에 대한 접근을 허용합니다. 계정 SAS: 스토리지 계정 내 여러 서비스에 걸쳐 접근을 허용합니다. 저장된 액세스 정책(Stored Access Policy): SAS를 정책과 연결해두면, 나중에 해당 정책을 삭제하거나 변경하는 것만으로 관련 SAS를 모두 중앙에서 무효화할 수 있습니다. 마치 "회사 방문증 발급 정책"을 바꾸면 그 정책으로 발급된 모든 방문증이 무효가 되는 것과 같습니다.
스토리지 방화벽
스토리지 방화벽은 건물 보안 게이트와 같습니다. 특정 회사 네트워크(VNet)나 특정 IP 주소에서만 접근을 허용하고, 그 외의 모든 접근은 차단합니다. 예를 들어, 회사 내부망에서만 스토리지에 접근할 수 있도록 설정하면, 외부에서의 무단 접근을 원천 차단할 수 있습니다.
Blob Storage
Blob Storage는 디지털 창고와 같습니다. 이미지, 동영상, 문서, 로그 파일, 백업 데이터 등 형식에 상관없이 거의 모든 종류의 파일을 저장할 수 있습니다. "Blob"은 Binary Large Object의 약자로, 구조화되지 않은 데이터를 저장하는 데 최적화되어 있습니다.
Blob 유형
Blob Storage 안에도 저장하는 데이터의 특성에 따라 세 가지 유형이 있습니다. 창고 안에도 일반 선반, 냉동고, 서류 보관함이 따로 있는 것처럼 말입니다.
Block Blob: 가장 일반적인 유형입니다. 이미지, 동영상, 문서, 음악 파일처럼 "덩어리째" 저장하고 읽는 데이터에 사용합니다. 대부분의 시나리오에서 기본으로 사용하는 유형입니다. 파일을 여러 블록으로 나눠서 업로드하기 때문에 대용량 파일도 효율적으로 처리합니다.
Page Blob: 가상 머신(VM)의 디스크 파일(VHD)을 저장하는 데 특화된 유형입니다. 하드 드라이브처럼 특정 위치를 랜덤하게 읽고 쓰는 작업이 많을 때 사용합니다. VM을 생성하면 내부적으로 Page Blob이 디스크 역할을 합니다.
Append Blob: 로그 데이터처럼 "뒤에만 계속 추가"하는 데이터에 최적화된 유형입니다. 한 번 쓴 내용은 수정하거나 삭제할 수 없고, 새로운 내용을 뒤에 붙이는 것만 가능합니다. 서버 접속 기록이나 시스템 이벤트 로그처럼 시간 순서대로 기록이 쌓이는 데이터에 적합합니다.
스토리지 계층과 수명 주기
Blob Storage는 데이터를 얼마나 자주 사용하느냐에 따라 비용이 다른 네 가지 계층으로 관리할 수 있습니다. 창고 임대료와 비슷합니다 — 자주 꺼내 쓰는 물건은 가까운 창고에 보관하고, 거의 안 쓰는 물건은 멀지만 저렴한 창고에 넣어두는 것입니다.
핫(Hot): 자주 접근하는 데이터. 저장 비용은 높지만 읽기 비용이 저렴합니다. 현재 서비스 중인 이미지나 문서에 적합합니다. 쿨(Cool): 30일 이상 잘 사용하지 않는 데이터. 저장 비용은 핫보다 낮지만 읽기 비용은 높아집니다. 월별 보고서처럼 가끔만 조회하는 파일에 적합합니다. 콜드(Cold): 90일 이상 거의 사용하지 않는 데이터. 더 저렴하지만 읽기 비용은 더 높습니다. 아카이브(Archive): 180일 이상 거의 접근하지 않는 데이터. 가장 저렴하지만, 데이터를 읽으려면 먼저 "리하이드레이션" 과정(몇 시간 소요)을 거쳐야 합니다. 오프라인 상태이기 때문에 즉시 읽을 수 없습니다. 법적 보관 의무가 있는 오래된 문서나 장기 백업에 적합합니다.
수명 주기 관리 정책
매일 수동으로 "이 파일은 이제 쿨로 옮겨야겠다"고 관리하는 것은 비현실적입니다. 수명 주기 관리 정책은 이 과정을 자동화합니다. 예를 들어, "30일 이상 접근하지 않은 파일은 자동으로 쿨 계층으로 이동하고, 90일 이상 접근하지 않으면 아카이브로 이동하고, 1년이 지나면 자동으로 삭제한다"는 정책을 만들어두면, Azure가 알아서 처리해줍니다.
!Blob Storage 계층 4가지
데이터 보호
중요한 데이터를 실수로 삭제하거나 덮어쓰는 사고가 발생했을 때를 대비해, Azure는 여러 데이터 보호 기능을 제공합니다.
일시 삭제(Soft Delete)
일시 삭제는 휴지통 기능과 같습니다. 파일을 삭제해도 즉시 사라지지 않고, 설정한 기간(예: 14일) 동안 휴지통에 보관됩니다. 그 기간 안에 언제든지 복구할 수 있습니다. 실수로 중요한 파일을 지웠을 때 구원이 되는 기능입니다.
Blob 버전 관리
Blob 버전 관리는 문서 편집기의 자동 저장 이력과 같습니다. 파일을 수정할 때마다 이전 버전이 자동으로 보존됩니다. "어제 버전으로 되돌리고 싶다"는 상황에서 이전 버전을 언제든지 복원할 수 있습니다.
Blob 스냅샷
스냅샷은 특정 시점의 파일 상태를 사진처럼 찍어두는 기능입니다. 버전 관리가 수정할 때마다 자동으로 저장되는 것과 달리, 스냅샷은 내가 원하는 특정 시점에 수동으로(또는 정책에 따라) 찍어두는 읽기 전용 복사본입니다. 대규모 업데이트를 적용하기 전에 스냅샷을 찍어두면, 문제 발생 시 해당 시점으로 빠르게 복원할 수 있습니다.
Azure Files
Azure Files는 회사 공용 드라이브를 클라우드로 옮긴 것과 같습니다. 회사에서 "Z 드라이브"나 "팀 공유 폴더"를 사용해본 적 있으신가요? Azure Files는 그것과 똑같이, 여러 사람이 파일을 공유하고 동시에 편집할 수 있는 공유 폴더를 클라우드에서 제공합니다.
SMB(Windows 파일 공유 프로토콜) 또는 NFS(Linux 파일 공유 프로토콜)를 지원하므로, Windows와 Linux 모두에서 마치 로컬 드라이브처럼 마운트해서 사용할 수 있습니다.
ID 기반 접근
일반 회사 공용 드라이브와 마찬가지로, Azure Files도 회사 계정으로 로그인해서 접근할 수 있습니다. Azure AD DS(Azure Active Directory Domain Services) 또는 온프레미스 AD DS를 통한 Kerberos 인증을 지원합니다. 덕분에 "김철수 씨는 이 폴더에 읽기만 가능, 이박영 씨는 편집 가능"처럼 기존 회사 계정 체계 그대로 권한을 관리할 수 있습니다.
Azure File Sync
Azure File Sync는 회사 내부 파일 서버와 Azure Files를 자동으로 동기화해주는 서비스입니다. 예를 들어, 오래된 온프레미스(사내) 파일 서버를 당장 없애기는 어렵지만 클라우드로 점진적으로 이전하고 싶은 경우에 유용합니다. 파일 서버에서 변경된 내용이 자동으로 Azure Files에 반영되고, 반대로 Azure Files의 변경 사항도 파일 서버에 동기화됩니다.
또한 "클라우드 계층화(Cloud Tiering)" 기능을 통해 자주 사용하지 않는 파일은 자동으로 클라우드로만 올리고 로컬 서버에서는 삭제하여 디스크 공간을 절약할 수도 있습니다.
스냅샷
Blob 스냅샷과 마찬가지로, Azure Files도 파일 공유 전체의 특정 시점 복사본을 만들 수 있습니다. 파일 공유의 "과거 버전"을 보존해두었다가 필요할 때 개별 파일 또는 전체를 복원하는 데 사용합니다.
AzCopy
AzCopy는 대량 이사 트럭과 같습니다. Azure Portal에서 파일을 하나씩 업로드하는 것은 소량의 파일에는 괜찮지만, 수백 GB, 수 TB의 데이터를 옮길 때는 명령줄 도구인 AzCopy를 사용합니다.
예를 들어, 온프레미스 서버의 데이터를 Azure Blob Storage로 대량 이전하거나, 스토리지 계정 간에 데이터를 복사할 때 AzCopy를 사용하면 훨씬 빠르고 효율적입니다. SAS 토큰 또는 Entra ID(구 Azure AD) 인증을 사용해서 보안을 유지하면서 작업할 수 있습니다.