Azure Blob storage, 어디까지 써봤니? - 1

눕눕·2022년 4월 1일

Azure Blob Storage Account

Azure Blob storage

목록 보기

1/2

Blob storage 란?

Blog storage는 클라우드를 위한 Microsoft의 객체 스토리지 솔루션이다.

딱 한줄로 정의해보자면 위와 같으며, 매우 큰 규모의 비정형 데이터를 저장하기 위한 저장소로 보면된다.

Blob storage의 사용 용도

browser에 이미지 또는 문서 직접 제공
분산 액세스용 파일 저장
비디오 및 오디오 스트리밍
로깅
백업/복원, dr 및 보관용 데이터 저장
onprem 또는 Azure-hosted 서비스에서 분석하기 위한 데이터 저장

Blob 업로드, 다운로드 등의 작업들은 어떻게 지원될까?

사용자나 client app은 여러가지 방법을 통해 Blob storage를 활용할 수 있다.

Azure Storage REST API
Azure PowerShell
Azure CLI
client libraries (.net, java, node,js, pytho, go, php, ruby)

Blob storage 어떻게 만들면 되나?

쉽게 말하자면, Storage account를 생성하여 사용하면 된다.

Storage account를 생성하면 아래와 같이 Blob storage라는 부분은 보이지 않는다.

~~Storage account 생성하면 된다며?!~~

Blob storage는 아래와 같은 구조로 되어있다.
즉, Storage account >> Container 안에 blob으로 저장되어진다.

간단하게 말하면, Storage account는 위의 4가지 종류의 storage를 제공하는 큰 name splace 같으 느낌으로 보면 되고, 가장 위에 있는 Container라는 directory와 비슷한 개념 안에 Blob이라는 파일 개념들이 저장되어진다.

출처: https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction

Blob도 종류가 있다구요?

blob은 각각의 용도에 따라 block blob, append blob, page blob으로 3가지의 종류를 지원한다.

block blob

block blob은 사이즈가 큰 데이터를 업로드하는데 최적화 되어있다.

block blob은 많게는 50000개의 block들로 이루어질 수 있다. 이러한 여러개의 block들로 올리는 부분을 네트워크 부분으로 보자면, 여러 block들을 병렬로 업로드 함으로써, 업로드에 걸리는 시간을 줄일수 있다.

page blob은 page 단위기에 낭비가 있을 수 있으며, append blob은 block에 대한 update 및 delete관련한 제한이 있기에, blob을 사용할 때, 특정한 목적이 있지 않고 일반적인 이미지와 같은 데이터들을 저장할 때 가장 많이 쓰이는 blob의 종류는 block blob이 아닐까 생각한다.

page blob

512-byte 페이지들의 collection으로 page blob은 Random read / write 작업에 최적화 되어있다.

page blob은 주로 vm의 디스크들이 백업되어 저장되어지는 형태이다.

append blob

block들로 이루어진 blob이며 append operation에 최적화된 blob이다. blob이 modify될 때, blob의 마지막에만 block이 추가되어진다. 기존에 있던 block들에 대한 updating이나 deleting 작업은 할 수 없다.

logging 시나리오에 많이 사용되는 blob 종류다

Access tier는 또 뭐죠?

blob의 타입들이 따로 있듯이, blob에 접근하는 방식 또한 여러 tier로 나뉘어져 있다.

~~잘 안쓰는 1년지난 로그들 더 싸게 저장할 수 있으면 좋자나?~~

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다.

cool tier는 hot tier와 비교하였을 때, 조금 낮은 가용성(availablity)을 제공하지만, 같은 내구성(durability)과 검색 속도(retrieval latency)를 제공한다.

최소 30일 이상 보관되어져야 하며, 30일이 지나기 전에 지우거나 tier 변경을 할 시, 남은 기간만큼 early deletion fee를 지불해야 한다. (Blob storage accounts 제외)

모든 redundnacy 옵션들을 제공한다. (ex. LRS, GRS, RA-GRS etc)

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가 존재하는데, stnadard 와 high priority다.

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

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

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

변경: 한번 initiating 되면 멈출 수 없다.

Get Blob Properties operation으로 status를 확인 할 수 있다.

Azrue Event Grid의 아래 2가지 event를 활용하면 status 관련하여 파악이 쉬워진다.

Microsoft.Storage.BlobCreated event는 blob이 생성 되었을 때, 발생한다. 정확하게는 blob의 데이터가 fully rehydrate 되고, hot 또는 cool로 copy blob(복사 방법 사용시 사용하는 명령어)을 통해 복사가 되었을때 발생된다.
Microsoft.Storage.BlobTierChanged event는 blob의 tier가 변경 되었을 때 발생된다. 정확하게는 set blob(변경 방법 사용시 사용하는 명령어) operation이 성공적으로 blob의 tier를 hot 또는 cool로 변경하였을때 발생된다.