Azure Blob Storage는 이미지, 동영상, 문서, 로그 파일 등 어떤 형태의 비정형 데이터도 저장할 수 있는 오브젝트 스토리지 서비스입니다. AZ-204 시험에서는 SDK 사용법, 속성과 메타데이터 구분, 스토리지 계층, 수명 주기 정책, 불변성 정책이 핵심입니다.
SDK: 세 가지 클라이언트 클래스
Blob Storage SDK를 이해하려면 세 가지 클라이언트 클래스의 역할을 구분하는 것이 가장 중요합니다. 아파트 단지를 예로 들겠습니다. 단지 전체를 관리하는 관리 사무소(BlobServiceClient), 각 동(BlobContainerClient), 그리고 각 호실(BlobClient)의 관계와 같습니다.
| 클래스 | 역할 | 비유 | |--------|------|------| | BlobServiceClient | 스토리지 계정 전체에 연결 | 아파트 관리 사무소 | | BlobContainerClient | 특정 컨테이너(폴더) 접근 | 특정 동 관리 | | BlobClient | 특정 Blob 파일 조작 | 특정 호실 |
각 클라이언트는 상위 클라이언트에서 가져오거나 직접 URL로 생성할 수 있습니다.
주요 작업 패턴
업로드: blob_client.upload_blob(data, overwrite=True) 다운로드: blob_client.download_blob().readall() 삭제: blob_client.delete_blob() 컨테이너 생성: container_client.create_container() Blob 목록 조회: container_client.list_blobs()
업로드 시 overwrite=True를 지정하지 않으면 이미 존재하는 Blob에 업로드할 때 예외가 발생합니다.
속성과 메타데이터: 파일에 대한 정보 저장
Blob 파일 자체 외에도 파일에 대한 정보를 두 가지 방식으로 저장할 수 있습니다. 책 한 권을 예로 들면, 책의 속성(두께, 페이지 수, 표지 색상 등 물리적 특성)과 도서관이 붙여놓은 라벨(청구 번호, 비치 위치, 대출 가능 여부)은 성격이 다릅니다.
시스템 속성 (System Properties)
Azure가 자동으로 관리하는 속성으로, HTTP 헤더와 직접 연결됩니다.
Content-Type: 파일 형식 (예: image/jpeg, application/pdf) Content-Length: 파일 크기 (바이트) ETag: 버전 식별자 (낙관적 동시성 제어에 사용) Last-Modified: 마지막 수정 시간 Content-Encoding, Content-Language 등
이 속성들은 SDK나 REST API를 통해 조회하고 일부는 수정할 수 있습니다.
사용자 정의 메타데이터 (User-Defined Metadata)
개발자가 임의로 정의하는 키-값 쌍입니다. Blob에 직접 저장되지 않고 별도로 관리됩니다.
형식: 키=값 쌍 (예: author=홍길동, project=alpha, environment=production) HTTP 헤더 이름 규칙을 따름 (영문자, 숫자, 하이픈만 사용) 조회: blob_client.get_blob_properties().metadata 설정: blob_client.set_blob_metadata({"author": "홍길동"})
시험에서는 시스템 속성과 사용자 정의 메타데이터를 구분하는 문제가 자주 출제됩니다.
스토리지 계층: 접근 빈도에 따른 비용 최적화
데이터를 얼마나 자주 접근하느냐에 따라 적합한 스토리지 계층이 다릅니다. 냉장고와 창고를 예로 들겠습니다. 자주 꺼내 먹는 음식은 냉장고(Hot)에, 가끔 쓰는 물건은 창고(Cool)에, 거의 쓰지 않는 물건은 더 깊은 창고(Cold)나 장기 보관 창고(Archive)에 넣는 것과 같은 원리입니다.
| 계층 | 특징 | 최소 보관 기간 | 접근 비용 | 저장 비용 | |------|------|-------------|---------|---------| | Hot | 자주 접근하는 데이터 | 없음 | 낮음 | 가장 높음 | | Cool | 가끔 접근하는 데이터 | 30일 | 중간 | 중간 | | Cold | 드물게 접근하는 데이터 | 90일 | 높음 | 낮음 | | Archive | 거의 접근하지 않는 데이터 | 180일 | 가장 높음 | 가장 낮음 |
Archive 계층의 특별한 특징을 반드시 기억해야 합니다.
오프라인 상태: Archive에 있는 Blob은 직접 읽을 수 없습니다 리하이드레이션(Rehydration): 데이터를 읽으려면 Hot 또는 Cool 계층으로 이동해야 하며 시간이 걸립니다 리하이드레이션 우선순위: Standard(수 시간~15시간), High(1시간 이내, 추가 비용)
최소 보관 기간 이전에 계층을 변경하거나 삭제하면 조기 삭제 비용이 발생합니다.
수명 주기 관리 (Lifecycle Management)
시간이 지남에 따라 자동으로 Blob의 계층을 변경하거나 삭제하는 정책을 설정할 수 있습니다. 마치 회사의 문서 보관 규정처럼 "3개월 지난 파일은 보관 창고로 이동, 1년 지난 파일은 폐기"라는 규칙을 자동으로 실행합니다.
수명 주기 정책은 JSON 형식으로 정의합니다.
규칙 구성 요소: 필터(대상 Blob 선택) + 작업(수행할 일) 필터 조건: Blob 이름 접두사, Blob 유형, 마지막 수정 날짜 등 지원 작업: tierToCool, tierToCold, tierToArchive, delete 적용 주기: 하루에 한 번 실행
예를 들어 "30일 이상 수정되지 않은 Blob은 Cool 계층으로 이동, 90일 이상이면 Archive로 이동, 365일 이상이면 삭제"하는 정책을 한 번에 설정할 수 있습니다.
불변성 정책 (Immutability Policy): 데이터 변경 방지
규제 요건이나 법적 의무를 위해 Blob 데이터가 변경되거나 삭제되지 않도록 보호하는 기능입니다. 공증된 계약서를 금고에 보관하는 것과 같습니다. 아무리 권한이 있어도 보관 기간 동안은 변경할 수 없습니다.
시간 기반 보존 정책 (Time-Based Retention Policy)
지정한 기간 동안 Blob을 수정하거나 삭제할 수 없습니다.
보존 기간: 1일~146,000일(400년) 설정 가능 잠금 전: 정책 수정/삭제 가능 잠금 후(Locked): 보존 기간 단축 불가, 정책 삭제 불가 (기간 연장만 가능) 활용: 금융 기록, 의료 데이터, 법적 문서 보관
Legal Hold
법적 분쟁이나 조사 중 증거 보전을 위해 기간 제한 없이 Blob을 보호합니다.
태그 기반으로 활성화/비활성화 Legal Hold가 활성화된 동안은 Blob 수정/삭제 불가 여러 태그를 동시에 적용 가능
| 정책 유형 | 기간 | 잠금 | 활용 | |---------|------|------|------| | 시간 기반 보존 | 지정 기간 | 잠금 가능 | 규제 준수, 법적 보관 | | Legal Hold | 무기한 | 태그로 해제 | 법적 분쟁, 조사 |
!기간 기반 보존 vs Legal Hold
시험 핵심 정리
"스토리지 계정 전체 연결" -- BlobServiceClient
"특정 컨테이너 접근" -- BlobContainerClient
"특정 파일 조작 (업로드/다운로드/삭제)" -- BlobClient
"HTTP 헤더로 관리되는 파일 정보" -- 시스템 속성 (Content-Type, ETag 등)
"개발자가 정의하는 키-값 쌍" -- 사용자 정의 메타데이터
"Archive에서 데이터 읽으려면" -- 리하이드레이션 필요 (Hot/Cool로 이동)
"최소 보관 기간: Hot=없음, Cool=30일, Cold=90일, Archive=180일"
"JSON 정책으로 자동 계층 전환/삭제" -- 수명 주기 관리
"기간 지정 후 수정/삭제 차단" -- 시간 기반 보존 정책
"기간 없이 수정/삭제 차단, 태그로 해제" -- Legal Hold