Azure Blob Storage

안녕하세요. 막내즈입니다 ~!~!!

오늘은 Azure Blob Storage에 대해서 알아보도록 하겠습니다 !! 

 

Azure Blob Storage란?

대용량의 정형화되어 있지 않은 데이터를 저장하기에 최적화 된 저장소 (정형화되어있지않은 데이터란 특정 모델로 정의되지 않은 데이터로 텍스트나 바이너리 형식의 데이터를 말한다.)

 

Azure Blob Storage의 목적

1. 이미지나 문서를 브라우저에 용이하게 저장

2. 분산 접근을 위한 파일 저장

3. 영상과 음성 파일 실시간 스트리밍

4. 로그 파일 작성

5. 백업과 복원, 장애 복구(DR), 아카이브 용도

6. 온프레미스나 클라우드 환경 서비스의 분석을 위한 데이터 저장

 

---

Blob Storage의 리소스 유형

Blob storage는 위와 같은 구조로 되어있습니다. 즉, Storage account >> Container 안에 blob으로 저장됩니다.

 

1. Storage Account

• 저장된 데이터에 대한 고유한 네임 스페이스를 제공하며, Azure Storage에 저장되어 있는 개체들은 모두 이 고유한 계정명을 포함한 접근 주소를 가지고 있습니다.

2. Container

• 여러 Blob의 집합이며, 파일 시스템의 폴더와 유사하다고 볼 수 있습니다. 하나의 Storage Account에는 제한 없이 많은 수의 컨테이너를 생성할 수 있고, 컨테이너 역시 숫자에 제한 없이 많은 Blob을 가질 수 있습니다.

3. Blob

• Azure Storage에서 제공하는 Blob의 유형은 크게 세가지입니다. Blob 유형은 생성시에 지정할 수 있으며 생성한 이후에는 변경이 불가능합니다. 각각의 Blob의 버전은 ETag라고 부르는 고유한 Tag값을 가지고 있으며, 이를 사용해서 특정 Blob만을 변경하는 것을 한정할 수 있습니다. 또한, Blob은 쓰기 권한을 배타적으로 가지기 위해서 임대될 수 있는데, Blob이 임대 되고 나면, 임대 ID를 포함하고 있는 요청 작업만이 Blob을 수정할 수 있는 권한을 가집니다.

Blob의 유형

• Block Blobs - 텍스트와 바이너리 데이터를 저장하는 것으로, 일반적인 대용량 데이터 저장 작업에 대해 효율적입니다. 개별적으로 관리되는 하나 이상의 Block으로 구성됩니다. 4.75TiB(1테비바이트 = 2의 40제곱 바이트 = 1,099,511,627,776 바이트)까지의 데이터를 저장할 수 있습니다. Priview 형태로 지원되는 Block Blob은 190.7TiB까지 저장이 가능하다고 합니다.

• Append Blobs - Block Blobs과 유사하게 Block으로 구성되지만 다른 점은 Append동작에 최적화 되어 있다는 것입니다. 발생하는 Append 동작은 기존의 Block을 수정하거나 삭제하는 것은 지원되지 않습니다. 이러한 Append 동작은 데이터 로그를 적재하는 환경 등에 유용합니다. Append Blob 내에는 최대 4MiB크기의 Block을 50,000개까지 적재할 수 있기에 전체 최대 크기는 약 195GiB입니다.
• Page Blobs - 512 바이트의 페이지 집합으로 랜덤 액세스 동작에 최적화 되어 있습니다. Page Blob 내에는 최대 8TiB까지 적재할 수 있으며, VHD 파일을 저장해서 Azure에서 VM 디스크로 활용할 수 있는 기능을 지원합니다.

 

Blob Storage에 데이터 적재하는 방법

1. AzCopy - cmd를 활용하는 방법으로 간단한 명령어로 처리가 가능합니다. AzCopy를 사용하기 위해서 먼저 각 운영체제에 맞는 AzCopy 실행 파일을 다운로드 받아야 합니다.

2. Azure Data Factory - Account Key, SAS(Shared Access Signature) 등을 사용해서 Azure Blob Storage와 연결하고 데이터를 적재하는 것이 가능합니다.

 

 

Access tier란?

blob의 타입들이 따로 있듯이, blob에 접근하는 방식 또한 여러 tier로 나뉘어져 있습니다. 3가지의 tier가 있으며, 분류로는 online tier, offline tier로 나뉘어집니다.

• online tier: 사용자가 바로 접근가능한 tier
• offline tier: 사용자가 바로 접근이 불가능한 tier

 

Hot tier

online tier중 하나로, 저장하는데는 가장 큰 비용이 들지만, 접근하는데 있어서는 비용이 가장 적게 든다. 자주 사용되는 데이터에 적합한 tier입니다. 모든 redundnacy 옵션들을 제공합니다. (ex. LRS, GRS, RA-GRS etc)

Cool tier

online tier 중 하나로, hot tier보다 낮은 저장 비용이 들지만, 접근하는데 있어서는 더 높은 비용이 들어간다. 자주 사용되진 않지만 사용가능한 상태를 유지해야하는 데이터에 적합한 tier다. hot tier와 비교하였을 때, 조금 낮은 가용성을 제공하지만, 같은 내구성과 검색 속도를 제공한다. 최소 30일 이상 보관되어져야 하며, 30일이 지나기 전에 지우거나 tier 변경을 할시, 남은 기간만큼 early deletion fee를 지불해야 한다.(Blob stoarge accounts 제외) 모든 redundnacy 옵션들을 제공한다.

Archive tier

offline tier로 가장 낮은 저장 비용을 가지지만, 가장 높은 접근 비용이 들어간다. 거의 사용되지 않는 데이터들에게 적합한 tier이다. 최소 180일 이상 저장되어져야 하며, 180일이 지나기 전에 지우거나 tier 변경을 할 시, 남은 기간만큼 early deletion fee를 지불해야 한다. Archive tier의 blob을 cool이나 hot으로 변경하려면, rehydration이라는 작업이 필요하다.

Rehydration

archive tier에서 설명한 것과 같이 archive tier에서 다른 online access로 해당 데이터를 사용하기 위해 필요한 작업이다. rehydration 작업에는 2가지 priority가 존재하는데, standard와 high priority다.

• standard prioriy: 최대 15시간까지 걸릴 수 있다.
• high prioriy: 10GB 사이즈 제한이 있으나 최대 1시간 안에 처리가 된다.

rehydration에는 2가지 방법이 있습니다. 복사와 변경

• 복사: 주로 권장하는 방법이며, early deletion fee도 피할 수 있으며, lifecycle 관련 정책에서 발생할 수 있는 문제점 또한 피할 수 있다. 우선 접근에 prioity에 따라 몇 시간씩 걸리기는 하지만, 원본파일은 그대로 archive에 남아있게 된다. 기존에 archive로 설정된 blob과 같은 이름으로 설정할 수 없기에, 다른 이름으로 바꾸거나, 다른 container에 담으면 된다.
• 변경: 한번 initiating 되면 멈출 수 없다.