[Azure Storage] Azure Storage 서비스 소개

 

이번글에서는 Azure Storage 에 관련된 전반적인 서비스에 대해 기술해 보고자 한다.

전체 서비스에 대한 글을 보려면 : [MS Azure] - [MS Azure] 기초지식 : Azure 제공 서비스- 카테고리별

[MS Azure] 기초지식 : Azure 제공 서비스- 카테고리별

1. Requirement: Azure Storage Account

2. Dist Storage

3. Blob Storage

4. Azure Files

---

Azure Storage Account

스토리지 계정이란 Azure Storage 서비스의 집합을 그룹화 한 컨테이너라고 할 수 있다. 이 계정에는 데이터 서비스만 포함될 수 있다.

예를들어, Azure Blob, Azure Files, Azure Queues, Azure Tables. 만약 스토리지 계정안에 여러 데이터 리소스가 포함되어있는 상태에서 이 계정을 삭제하면 안에 있는 리소스들도 다 삭제된다. (Resource Group 을 삭제하면 안에 리소스도 다 삭제되는 원리와 같다)

Azure Storage Account 은 Resource Group 에 포함될 수 있다. 아래의 그림은 일반적인 리소스 그룹 구조를 보여준다.

 

이 스토리지 계정은 HTTP 또는 HTTPS 를 통해 전 세계 어디에서나 엑세스 할 수 있는 Azure Storage 데이터에 고유한 네임스페이스를 제공한다.

** NameSpace  : 개체를 구분할 수 있는 범위를 나타내는 말로 일반적으로 하나의 이름공간에는 하나의 이름이 단 하나의 개체만을 가르키게 된다.

Azure Storage Account Setting

스토리지 계정안에 정해놓은 모든 스토리지 서비스에 정책을 적용할 수 있다. 어떤한 정책을 정할 수 있는지 아래의 항목을 살펴본다.

1) 구독 Subscription: 계정의 서비스에 대한 요금이 청구되는 Azure 구독입니다.

2) 위치 Location: 서비스를 계정에 저장하는 데이터 센터입니다.

3) 성능 Performance: 스토리지 계정에 사용할 수 있는 데이터 서비스와 데이터 저장에 사용되는 하드웨어 디스크 종류를 결정합니다. 표준 을 사용하면 사용자가 모든 데이터 서비스(Blob, File, Queue, Table)에서 자기 디스크 드라이브를 사용할 수 있습니다. 프리미엄 에는 데이터 저장을 위한 추가 서비스가 포함됩니다. 예를 들어 구조화되지 않은 개체 데이터를 블록 blob 또는 추가 blob으로 저장하고, 프리미엄 파일 공유를 저장하고 만드는 데 사용되는 특수 파일 스토리지를 사용할 수 있습니다. 이러한 스토리지 계정은 스토리지에 SSD(반도체 드라이브)를 사용합니다.

4) 복제 Replication: 하드웨어 오류 또는 자연재해로부터 보호하기 위해 데이터의 복사본을 만드는 데 사용되는 전략을 결정합니다. 최소한 Azure에서는 스토리지 계정과 연결된 데이터 센터 내의 3개 데이터 복사본을 자동으로 유지합니다. 이것을 LRS(로컬 중복 스토리지)라고 하고, 하드웨어 오류로부터 보호하지만 전체 데이터 센터를 무력화하는 이벤트로부터는 보호할 수 없습니다. GRS(지역 중복 스토리지)와 같은 다른 옵션 중 하나를 업그레이드하여 전 세계의 여러 데이터 센터에서 복제를 가져올 수 있습니다.

5) 액세스 계층 Access Tier: 이 스토리지 계정에서 Blob에 액세스할 수 있는 속도를 제어합니다. 핫은 쿨보다 빠른 액세스를 제공하지만 비용이 증가합니다. 이 기능은 Blob에만 적용되며 새 Blob에 대한 기본값으로 제공됩니다.

6) 보안 전송 필요 Secure Transfer Required: 액세스에 대해 지원되는 프로토콜을 결정하는 보안 기능입니다. 활성화하면 HTTPS가 필요하고, 비활성화하면 HTTP가 허용됩니다.

7) 가상 네트워크 Virtual Network: 지정한 가상 네트워크에서 인바운드 액세스 요청만을 허용하는 보안 기능입니다.

예를 들어 포함된 모든 서비스가 미국 서부데이터 센터에 저장되고, https에서만 엑세스 가능하고, 디벨로퍼 팀에게 청구되게 이러한 스토리지 계정을 설정할 수 있다. 이 말은 만약 위의 정책중 하나라도 다른 것이 있다면 스토리지 계정을 새로 만들어야 한다는 것을 의미한다. 따라서 필요한 스토리지 계정 수는 데이터의 다양성, 비용구분, 관리 오버헤드에 대한 허용치에 의해 결정된다.

How many storage accounts do you need?

1) Data Diversity : 데이터가 어디에서 소비되는지 (location) , 얼마나 민감한 데이터인지(Secure Transfer Required), 어떠한 그룹이 이 비용을 처리하는지(Subscription) 에 따라 여러개의 스토리지 계정이 필요할 수 있다.

예를 들어, 갖고 있는 데이터가 일부는 private, 일부는 public 데이터 인 경우, private data에는 virtual network 를 사용하도록 하고 이는 별도의 스토리지 계정이 필요하다.

2) Cost sensitivity : 비용을 줄이기 위해 여러개의 스토리지 계정을 사용하는 경우도 있다. 중요한 지역과 중요하지 않은 지역을 나누고, 중요한 데이터에는 geo-redundant storage 를 사용하고, 중요하지 않은 데이터는 locally-redundant storage 를 사용한다.

3) Tolerance for management overhead : 스토리지 계정은 비용을 최소화하면서 필요한 성능과 보안을 얻을 수 있는 강력한 도구이다. 일반적인 전략은 데이터 분석을 시작하고 위치, 청구, 복제 전략 등과 같은 특성을 공유하는 파티션을 만든 다음, 각 파티션에 대해 하나의 스토리지 계정을 만드는 것이다. 이는 관리를 용이하게 할 수 있다.

Choose your account settings

1) Storage Account 이름 : 소문자 숫자만 사용가능 3~24자만 가능

2) Deployment Model 배포모델 : Deployment Model은 리소스를 구성하는 사용하는 시스템이다. 여기서 말하는 Model이란 리소스를 만들고, 구성하고, 관리하는 데 사용하는 API 를 정의 한다.

- Resource Manager : Azure Resource Manager API 를 사용하는 제품

- Classic : Azure Service Management API 를 사용하는 레거시 제품

대부분의 Azure 리소스는 Resource Manager와만 작동하며, 선택할 모델을 쉽게 결정할 수 있다. 하지만 Storage Account, Virtual Machine, Virtual Network는 두 모델을 모두 지원하므로, 스토리지 계정을 만들 때 한 모델을 선택해야 한다.

두 모델 간의 주요 기능 차이점은 그룹화에 대한 지원이다. Resource Manager 모델은 클래식 모델에서 사용할 수 없는 리소스 그룹 이라는 개념을 추가할 수 있다. 리소스 그룹을 통해 단일 단위로 리소스의 컬렉션을 배포하고 관리가 가능하기 때문에  모든 새로운 리소스에는 Resource Manager 를 사용하는 것을 권장한다.

3) Account Kind 계정종류 : 해당 서비스의 계정과 가격에 포함할 수 있는 데이터 서비스를 결정하는 정책집합.

• StorageV2(범용 v2): 모든 스토리지 형식 및 모든 최신 기능을 지원하는 현재 제품
• 스토리지(범용 v1): 모든 스토리지 형식을 지원하는 레거시 종류이지만 모든 기능을 지원하지 않을 수 있다.
• Blob 스토리지: 블록 Blob 및 추가 Blob만을 허용하는 레거시 종류

현재는 StroaveV2 사용을 권장한다.

이제 스토리지 계정에 대해 알았다면 계정을 만드는 법을 알아야 할 것이다. 계정만들기는 아래 글을 참조하기 바란다.

[MS Azure/AZ104] - AZ104 실습 : Azure Storage Account 만들기

AZ104 실습 : Azure Storage Account 만들기

---

Disk Storage

Disk Storage는 Azure 가상 머신에 디스크를 제공한다. 애플리케이션 및 기타 서비스는 온-프레미스 시나리오에서와 같이 필요한 만큼 이러한 디스크를 액세스하고 사용할 수 있다. Disk Storage를 사용하면 연결된 가상 하드 디스크에서 데이터를 영구적으로 저장 및 액세스 가능하다.

디스크는 SSD(반도체 드라이브)에서 종래의 회전식 HDD(하드 디스크 드라이브)에 이르기까지 다양한 크기 및 성능 계층으로 제공. 중요도가 낮은 워크로드에는 표준 SSD 및 HDD 디스크를, 중요 업무용 프로덕션 애플리케이션에는 프리미엄 SSD 디스크를, 데이터 집약적 워크로드(예: SAP HANA), 최상위 계층 데이터베이스, 트랜잭션 집약적 워크로드에는 Ultra Disks를 사용할 수 있다. Azure는 IaaS(Infrastructure as a Service) 디스크에 대해 업계 최고의 0% 연간 실패율로 엔터프라이즈급 내구성을 일관되게 제공한다.

---

Blob Storage

Azure Blob Storage는 클라우드용 개체 스토리지 솔루션이다. 방대한 양의 데이터(예: 텍스트 또는 이진 데이터)를 저장가능. Azure Blob Storage는 비정형이므로 포함될 수 있는 데이터 종류에 대한 제한이 없다. Blob Storage는 수천 개의 동시 업로드, 대용량 비디오 데이터, 끊임없이 증가하는 로그 파일을 관리할 수 있으며, 어디서나 인터넷을 통해 연결 가능하다.

Blob은 일반적인 파일 형식으로 제한되지 않는다. 즉, 하나의 Blob에 과학 기기에서 스트리밍된 몇 기가바이트의 이진 데이터, 다른 애플리케이션용 암호화된 메시지 또는 개발 중인 앱에 대한 사용자 지정 형식의 데이터가 포함될 수 있다. 디스크 스토리지와 비교해 Blob Storage의 한 가지 이점은 개발자가 디스크를 살피거나 관리할 필요가 없다는 점이다. 데이터는 blob으로 업로드되고 Azure에서 실제 스토리지 요구 사항을 관리하기 때문이다.

Blob Storage가 적합한 경우

1) 브라우저에 이미지 또는 문서 직접 제공

2) 분산 액세스용 파일 저장.

3) 비디오 및 오디오 스트리밍.

4) 백업/복원, 재해 복구 및 보관용 데이터 저장

5) 온-프레미스 또는 Azure 호스팅 서비스에서 분석하기 위한 데이터 저장.

6) 가상 머신에 대해 최대 8TB의 데이터를 저장

Blob을 컨테이너에 저장하면 비즈니스 요구 사항에 따라 Blob을 구성하는 데 유용하다.

Access 계층

클라우드에 저장된 데이터가 기하급수적으로 증가할 수 있다. 높아지는 스토리지 수요에 대한 비용을 관리하기 위해, 액세스 빈도 및 계획된 보존 기간과 같은 특성을 기반으로 데이터를 구성하는 것이 좋다. 클라우드에 저장된 데이터는 전체 수명에 걸쳐 생성, 처리 및 액세스하는 방법에 따라 다를 수 있다. 일부 데이터는 수명 기간 전반에 걸쳐 활발하게 액세스되고 수정된다. 일부 데이터는 수명 기간 초반에는 빈번하게 액세스되지만 데이터가 오래될수록 액세스 빈도가 급격하게 떨어진다. 일부 데이터는 클라우드에서 유휴 상태로 유지되고 저장된 후 극히 드물게 액세스되기도 한다. 이와 같이 다양한 액세스 요구 사항을 수용하기 위해 Azure에서는 액세스 요구 사항에 따라 스토리지 비용의 균형을 맞추는 데 사용할 수 있는 몇 가지 액세스 계층 제공한다.

1) Hot Access tier: 자주 액세스하는 데이터(예: 웹 사이트의 이미지)를 저장하는 데 최적화

2) Cool Access tier : 자주 액세스하지 않고 30일 이상 저장하는 데이터(예: 고객에 대한 송장)에 최적화

3) Archive access tier : 거의 액세스하지 않고 180일 이상 보관하며 유연한 대기 시간 요구 사항(예: 장기 백업)이 있는 데이터에 적합

핫 및 쿨 액세스 계층만 계정 수준에서 설정 간으하다. Archive access tier 은 계정 수준에서 사용할 수 없다.

핫, 쿨 및 보관 계층은 업로드 중 또는 업로드 후에 Blob 수준에서 설정할 수 있다.

쿨 액세스 계층의 데이터는 가용성은 약간 낮아도 되지만 핫 데이터와 유사하게 여전히 내구성, 검색 대기 시간 및 처리량 특성이 높아야 한다. 쿨 데이터의 경우 핫 데이터와 비교할 때 가용성 SLA(서비스 수준 계약)가 약간 낮고 액세스 비용이 더 많이 들지만 스토리지 비용이 적어 그런대로 균형이 맞다

Archive access tier 는 데이터를 오프라인으로 저장하며 스토리지 비용이 가장 적지만, 데이터 리하이드레이션 및 액세스에 비용이 가장 많이 든다.

---

Azure Files

Azure Files는 클라우드에서 산업 표준 SMB(서버 메시지 블록) 및 네트워크 파일 시스템(미리 보기) 프로토콜을 통해 액세스할 수 있는 완전 관리형 파일 공유를 제공합니다. Azure File 공유는 Windows, Linux 및 macOS의 클라우드 또는 온-프레미스 배포를 통해 동시에 탑재가능하다. Azure 가상 머신이나 클라우드 서비스에서 실행되는 애플리케이션은 데스크톱 애플리케이션이 일반적인 SMB 공유를 탑재하는 것처럼 File Storage 공유를 탑재하여 파일 데이터에 액세스할 수 있다. 제한 없는 수의 Azure 가상 머신 또는 역할이 파일 스토리지 공유를 동시에 탑재하고 액세스할 수 있습니다. 일반적인 사용 시나리오로는 전 세계 어디서나 파일을 공유하고, 진단 데이터 또는 애플리케이션 데이터를 공유하는 경우가 있다.

Azure Files가 적합한 경우

1) 여러 온-프레미스 애플리케이션에서 파일 공유를 사용. Azure Files를 사용하면 데이터를 공유하는 애플리케이션을 Azure로 쉽게 마이그레이션할 수 있다. 온-프레미스 애플리케이션에서 사용하는 것과 동일한 드라이브 문자에 Azure 파일 공유를 탑재하는 경우에는 파일 공유에 액세스하는 애플리케이션 부분이 최소한의 변경으로 작동해야 한다.

2) 구성 파일을 파일 공유에 저장하고 여러 VM에서 액세스한다. 그룹의 여러 개발자가 사용하는 도구 및 유틸리티를 파일 공유에 저장할 수 있으며, 이렇게 하면 모든 사람이 찾아서 동일한 버전을 사용할 수 있다.

3) 데이터를 파일 공유에 쓰고 이 데이터를 나중에 처리하거나 분석한다. 예를 들어 진단 로그, 메트릭 및 크래시 덤프에 이런 작업을 수행할 수 있습니다.

 

다음은 리소스 URI와 SAS 토큰을 보여 주는 서비스 SAS URI의 예

 

 

 

---

Reference

출처1 : docs.microsoft.com/ko-kr/learn/modules/azure-storage-fundamentals/

Azure Storage 서비스 살펴보기 - Learn

출처2 : docs.microsoft.com/ko-kr/learn/modules/create-azure-storage-account/2-decide-how-many-storage-accounts-you-need

필요한 스토리지 계정 수 결정 - Learn

출처 3 : docs.microsoft.com/ko-kr/azure/storage/files/

Azure Files 설명서

출처 4 : docs.microsoft.com/ko-kr/azure/storage/common/storage-introduction?toc=/azure/storage/blobs/toc.json

Azure Storage 소개 - Azure의 클라우드 스토리지

출처 5 : docs.microsoft.com/ko-kr/azure/storage/