• 활용 예시 : 비디오 클립 라이브러리 (비디오 데이터)
  
  
  

Azure Blob Storage

• Azure Blob Storage : 비정형 데이터를 개체 또는 Blob(Binary Large Object)으로 클라우드에 저장하는 서비스
• 저장 데이터 유형

1. 텍스트 문서
2. 이미지 파일
3. 비디오 파일
4. 등등...
   
   
   

Blob Storage의 리소스

• 아래 다이어그램에서는 Blob Storage 리소스 간의 관계를 보여줍니다.

• Blob Storage에서 활용하는 리소스

1. Azure Storage 계정
2. Azure Storage 계정의 컨테이너
3. 컨테이너의 Blob
   
   
   

• Blob Storage 구성 시, 필요한 설정

1. Blob 컨테이너 옵션
2. Blob 형식 및 업로드 옵션
3. Blob Storage 액세스 계층 -> 액세스 계층이 뭔지??
4. Blob 수명 주기 규칙
5. Blob 개체 복제 옵션
   
   
   

Blob Storage Container

• Azure Blob Storage는 컨테이너 리소스를 사용하여 Blob 집합을 그룹화합니다.
• 컨테이너 구성 조건

1. 컨테이너 이름은 Storage 계정내에서 고유해야 합니다.
2. 이름의 길이는 3~63자
3. 액세스 수준 결정
   1. private : 익명 엑세스 금지
   2. blob : blob에 대한 익명의 public 읽기 권한만 허용
   3. container : blob을 포함한 컨테이너내 전체 blob에 대한 익명의 public 읽기 및 목록 엑세스 허용
      
      
      

Blob 액세스 계층

• 액세스 계층은 특정 데이터 사용 패턴을 지원하도록 최적화됨
  
  
  

• 액세스 게층 유형

1. 핫 엑세스 계층 : Azure Storage 계층의 개체를 자주 읽고 쓰는 시나리오에 최적화
   • 스토리지 비용이 가장 높음
   • 액세스 비용은 가장 낮음
2. 쿨 계층 : 자주 액세스하지 않는 대량의 데이터를 저장하는 데 최적화
   • 사용 사례 : 단기 백업 및 재해 복구 데이터 세트와 오래된 미디어 콘텐츠
   • 최소 30일 동안 저장되어 있어야 함
   • 자주 사용하진 않지만 즉시 사용가능해야 함
   • 핫 엑세스 계층에 비해 스토리지 비용은 낮고 엑세스 비용은 높음
3. 콜드 계층 : 자주 액세스하지 않는 대량의 데이터를 저장하는 데 최적화
   • 최소 90일 동안 저장되어 있어야 함
   • 쿨 계층에 비해 스토리지 비용이 낮고 액세스 비용은 높음
4. 보관 엑세스 계층 : 몇 시간의 검색 대기 시간을 허용할 수 있는 데이터에 최적화된 오프라인 계층
   • 사용 사례 : 보조 백업, 원래 원시 데이터 및 법적 필수 규정 준수 정보가 포함
   • 최소 180일 동안 저장되어 있어야 함
   • 가장 비용 효율적인 옵션
     
     
     

Blob 수명주기 관리 규칙 (Lifecycle Management)

• 수명 주기 정책 규칙을 사용하여 데이터를 적절한 액세스 계층으로 전환하고, 데이터 세트의 수명 주기가 끝날 때까지 만료 시간을 설정할 수 있음
• 수명주기 관리 규칙을 통해 수행가능한 작업

1. Blob을 쿨 스토리지 계층으로 전환하여(핫 스토리지 계층에서 쿨 스토리지 계층으로, 핫 스토리지 계층에서 보관 스토리지 계층으로 또는 쿨 스토리지 계층에서 보관 스토리지 계층으로) 성능 및 비용을 최적화합니다.
2. 수명 주기가 끝나면 Blob을 삭제합니다.
3. Azure Storage 계정 수준에서 하루에 한 번 실행하도록 규칙 기반 조건을 정의합니다.
4. 컨테이너 또는 Blob 하위 집합에 규칙 기반 조건을 적용합니다.
   
   
   

Blob 개체 복제

• 특정 정책 규칙에 의해 컨테이너의 Blob을 비동기적으로 복제할 수 있음
• 복제 컨텐츠

1. Blob 콘텐츠
2. Blob 메타데이터 및 속성
3. Blob과 연결된 모든 데이터 버전

• 개체 복제 구성 시, 고려할 사항

1. 원본 계정과 대상 계정 모두에서 Blob 버전 지정을 사용하도록 설정
2. 원본 계정의 Blob에 대한 스냅샷은 대상 계정에 복제되지 않음
3. 원본 및 대상 계정이 핫, 쿨, 또는 콜드 계층에 있는 경우 개체 복제가 지원됨
4. 원본 및 대상 계정이 모두 다른 계층에 있을 수 있음
5. 복제 정책에는 원본 컨테이너 및 대상 컨테이너를 지정하는 하나 이상의 규칙이 포함됨
   
   
   

• 개체 복제 구성 시, 이점

1. 읽기 요청 대기시간 단축
2. 서로 다른 지역에서 동일한 Blob 집합을 처리하여 컴퓨팅 워크로드의 효율성 증가
3. 데이터 분산을 위해 구성을 최적화 -> 단일 위치에서만 데이터 처리 후 다른 지역에는 복제만 하도록 함
4. 수명주기 관리 정책 최적화하여 비용 효율화
   
   
   

Blob type

• Blob type

1. Block Blob : 데이터 블록이 조합되어 블롭을 형성, 대부분의 Blob Storage 시나리오
2. Append Blob : Block Blob과 마찬가지로 데이터 블록으로 구성, 데이터가 지속적으로 Append되는 작업에 최적화 (ex. logging 등)
3. Page Blob : 읽기/쓰기 작업이 빈번한 경우에 더 효율적, Azure Virtual Machines는 운영 체제 디스크 및 데이터 디스크에 페이지 블랍을 사용
   
   
   

Blob Storage 가격

• 가격 책정 기준

1. 매월 저장된 데이터 볼륨 (핫, 쿨 등 액세스 계층에 따라 상이)
2. 수행된 작업의 수량 및 형식 + 데이터 전송 비용 (액세스 계층이 시원해질수록 액세스/트랜잭션 요금 증가)
3. 선택된 데이터 중복성 옵션
4. 복제 데이터 전송
5. 아웃바운드 데이터 전송

Azure Storage

• Azure Storage : Microsoft 클라우드 스토리지 솔루션, 데이터 개체에 대해 대규모로 스케일 가능한 개체 저장소를 제공 (파일 시스템 서비스, 메시징 저장소, NoSQL 저장소)
  
  
  

데이터 유형에 따른 Azure Storage 활용 검토

1. 가상머신 데이터
   • 디스크 및 파일이 포함
   • 디스크는 Azure IaaS 가상 머신에 대한 영구 블록 스토리지
   • Azure 관리 디스크를 통해 스토리지 제공
   • 데이터베이스 파일, 웹 사이트 정적 콘텐츠 또는 사용자 지정 애플리케이션 코드와 같은 데이터를 저장
   • 추가할 수 있는 데이터 디스크의 수는 가상 머신의 크기에 따라 달라짐
   • 파일 공유를 제공
2. 비정형 데이터
   • Azure Blob Storage 및 Azure Data Lake Storage를 사용하여 저장
   • Blob Storage : 스케일링 성능이 뛰어난 REST 기반 클라우드 개체 저장소
   • Azure Data Lake Storage : 서비스로서의 HDFS(Hadoop 분산 파일 시스템)입니다.
3. 정형 데이터
   • 정형 데이터는 행, 열, 키와 함께 데이터베이스 테이블에 저장
   • Azure Table Storage, Azure Cosmos DB 및 Azure SQL Database를 사용하여 저장
   • Azure Cosmos DB : 글로벌 분산형 데이터베이스 서비스
   • Azure SQL Database : SQL 기반으로 구축된 완전 관리형 Database-as-a-Service
     
     
     

스토리지 계정 유형

• 스토리지 계정 : Azure Storage 서비스의 집합을 그룹화한 컨테이너
• 스토리지 계정이 삭제되면 해당 계정에 포함되어 있는 리소스들도 모두 삭제됨 (리소스 그룹과 흡사)
• 스토리지 계정은 리소스 그룹에 포함될 수 있음
• 모든 스토리지 계정 유형은 미사용 데이터에 대해 SSE(스토리지 서비스 암호화)를 사용하여 암호화됨

1. 표준 스토리지 계정 : HDD(하드 디스크 드라이브)를 통해 지원, 대량 저장소가 필요하거나 데이터 액세스가 자주 발생하지 않는 애플리케이션에 사용
2. 프리미엄 스토리지 계정 : SSD(반도체 드라이브)에서 백업되며 일관된 짧은 대기 시간 성능을 제공, 데이터베이스와 같이 I/O 집약적인 애플리케이션에서 Azure 가상 머신 디스크에 대한 프리미엄 스토리지를 사용 가능

Azure Storage 선택 시 고려사항

1. 대규모 데이터에 대한 스토리지 최적화를 고려
2. 고가용성이 있는 스토리지를 고려
3. 메시지의 스토리지를 고려
4. 정형 데이터에 대한 스토리지를 고려
   
   
   

Azure Storage 사용 시 고려사항

1. 내구성 및 가용성을 고려 : 데이터 센터 또는 지리적 영역에서 데이터를 복제
2. 보안 액세스를 고려 : 사용자 제어 가능
3. 스케일링 가능성을 고려
4. 관리 효율성을 고려 : 하드웨어 유지 관리, 업데이트 및 중요한 문제를 처리
5. 데이터 접근성을 고려 : HTTP/HTTPS, SDK, Azure PowerShell/Azure CLI 등 다양한 방식의 접근 방식 제공, Azure Portal 및 Azure Storage Explorer는 데이터 작업을 위한 간편한 시각적 솔루션을 제공
   
   
   

Azure Storage 서비스

1. Azure Blob Storage(컨테이너) : 텍스트 및 이진 데이터를 위한 대규모로 크기 조정 가능한 저장소

   • 텍스트 또는 이진 데이터와 같은 대량의 비정형 또는 비관계형 데이터를 저장하는 데 최적화
   • HTTP/HTTPS, URL, Azure Storage REST API, Azure PowerShell/Azure CLI, Azure Storage 클라이언트 라이브러리를 통해 접근 가능
   • NFS 프로토콜을 활용해서도 접근 가능
   • HTTP 또는 HTTPS를 통해 전 세계 어디에서나 액세스
     
     
     

2. Azure Files : 클라우드 또는 온-프레미스 배포에 대해 관리되는 파일 공유 스토리지

   • 고가용성 네트워크 파일 공유를 설정 가능 (공유 시 SMB프로토콜 또는 NFS프로토콜 활용)
   • REST 인터페이스 또는 스토리지 클라이언트 라이브러리를 통해 접근 가능
   • 파일 공유 액세스에 대한 인증을 제공하기 위해 스토리지 계정 자격 증명이 사용
   • 고가용성 네트워크 파일 공유를 지원
     
     
     

3. Azure Queue Storage : 애플리케이션 구성 요소 간의 안정적인 메시징을 위한 메시징 저장소

   • 메시지를 저장하고 조회하는 데 사용
   • 비동기적으로 처리할 메시지 목록을 저장하는 데 사용
   • Use Case : 고객 사진 업로드 -> 큐에 메세지 전송 -> Azure Function 작동 -> 메세지 조회한 후 썸네일 생성
     
     
     

4. Azure Table Storage : 비관계형 구조적 데이터(구조적 NoSQL 데이터라고도 함)를 저장하는 서비스

   • 비관계형 구조화된 데이터(구조화된 NoSQL 데이터라고도 함)를 저장하는 서비스
   • 애플리케이션의 요구 사항이 변화함에 따라 데이터를 쉽게 적응시킬 수 있음
   • 일반적으로 전통적인 SQL에 비해 비용이 매우 낮음
   • Azure Table Storage는 Azure Cosmos DB의 일부
     
     
     

복제 전략 결정

LRS(로컬 중복 스토리지)

• 가장 저렴한 옵션
• 데이터 센터 수준 재해가 발생하면 모든 복제본 손실
• 거버넌스 요구 사항으로 인해 국가 또는 지역 내에서만 데이터를 복제하도록 제한되는 경우 활용
  
  
  

ZRS(영역 중복 스토리지)

• 단일 region의 3개의 클러스터간 데이터 동기화
• 각 스토리지 클러스터는 자체 가용성 영역에 상주
• 각 클러스터는 별도의 유틸리티와 네트워킹 기능을 갖추고 있음
• 뛰어난 성능과 짧은 대기 시간을 제공
  
  
  

GRS(지역 중복 스토리지)

• 데이터 원본의 위치에서 수백 마일 떨어진 보조 region에 데이터를 복제
• 지역 단위의 재해에도 높은 내구성
• RA-GRS(읽기 액세스 지역 중복 스토리지)는 GRS를 기준
  • RA-GRS : 데이터를 보조region의 다른 데이터 센터에 복제하고, 보조 region에서 읽을 수 있는 옵션 제공
• GRS 또는 RA-GRS를 사용하도록 설정된 스토리지 계정의 경우 모든 데이터는 먼저 로컬 중복 스토리지(LRS)를 사용하여 복제 -> GRS를 사용하여 보조 지역에 비동기적으로 복제 -> 보조 region의 데이터는 LRS를 사용
  
  
  

GZRS(지역 영역 중복 스토리지)

• 지역 중복 스토리지에서 제공하는 지역 가동 중단에 대한 보호 기능과 영역 중복 스토리지의 고가용성을 결합
• 데이터는 주 지역에 있는 3개의 Azure 가용성 영역에 복사 -> 보조 region에 복사
  
  
  

스토리지 액세스

• Azure Storage에 저장되는 모든 개체에는 고유한 URL 주소가 있음
• 하위 도메인 + 도메인 이름 = 각 서비스 관련 스토리지 계정의 엔드포인트
• ex) 스토리지 계정 이름 : mystorageaccount

• 스토리지 계정의 mycontainer 위치에 있는 myblob 데이터에 액세스 : //mystorageaccount.blob.core.windows.net/mycontainer/myblob.
  
  
  

사용자 지정 도메인

• www.contoso.com과 같은 사용자 지정 도메인을 매핑하면 해당 도메인을 활용하여 개체에 접근 가능
• 사용자 지정 도메인 구성 방법

1. 직접 매핑
   • 하위 도메인: blobs.contoso.com
   • Azure Storage 계정: <storage account>.blob.core.windows.net
   • 직접 CNAME 레코드: contosoblobs.blob.core.windows.net
2. 중간 도메인 매핑
   • CNAME 레코드: asverify.blobs.contoso.com
   • 중간 CNAME 레코드: asverify.contosoblobs.blob.core.windows.net
     
     
     

서비스 엔드포인트 구성에 대해 알아야 할 사항

• 하나 이상의 공용 IP 범위에 대한 액세스를 허용하도록 서비스를 구성할 수 있어야 함
• 서브넷 및 가상 네트워크는 스토리지 계정과 동일한 Azure 지역 또는 지역 쌍에 있어야 함