1. 개요
- Azure Storage 란, 최신 데이터 스토리지 시나리오를 위한 Microsoft의 클라우드 스토리지 서비스입니다.
2. Azure Storage 이점
- 내구성 및 고가용성. 중복성은 일시적인 하드웨어 오류 발생 시 데이터를 안전하게 보호합니다. 또한 로컬 재해 또는 자연 재해로 인한 장애를 방지할 수 있도록 데이터 센터 또는 지리적 영역에서 데이터를 복제하도록 선택할 수도 있습니다. 이러한 방식으로 복제된 데이터는 예기치 않은 중단이 발생할 경우 항상 사용 가능한 상태로 유지됩니다.
- 보안. Azure Storage 계정에 기록된 모든 데이터는 서비스에 의해 암호화됩니다. Azure Storage는 데이터에 액세스할 수 있는 사용자를 자세히 제어할 수 있습니다.
- 확장 가능. Azure Storage는 오늘날의 애플리케이션에 대한 데이터 저장소 및 성능 요구 사항을 충족하기 위해 대규모로 확장할 수 있도록 설계되었습니다.
- 관리형 서비스. 하드웨어 유지 관리, 업데이트 및 중요한 문제를 Azure에서 처리합니다.
- 접근 용이성. Azure Storage의 데이터는 HTTP 또는 HTTPS를 통해 전 세계 어디에서든 액세스할 수 있습니다. Microsoft는 완성도 높은 REST API뿐만 아니라 .NET, Java, Node.js, Python, Go 등 기타 다양한 언어로 Azure Storage용 클라이언트 라이브러리를 제공합니다. Azure Storage는 Azure PowerShell 또는 Azure CLI에서 스크립트를 지원합니다. 또한 Azure Portal 및 Azure Storage Explorer는 데이터 작업을 위한 쉬운 시각적 솔루션을 제공합니다.
3. Azure Storage 종류 및 특징
| 기능 | 설명 | 사용하는 경우 |
| Azure Files | 산업 표준 SMB(서버 메시지 블록) 프로토콜, NFS(네트워크 파일 시스템) 프로토콜 및 Azure Files REST API를 통해 어디에서든지 액세스할 수 있는 완전 관리형 클라우드 파일 공유를 제공합니다. Azure 파일 공유를 Windows, Linux 및 macOS의 클라우드 또는 온-프레미스 배포에 동시에 탑재할 수 있습니다. |
- 이미 기본 파일 시스템 API를 사용하는 클라우드로 애플리케이션을 “리프트 앤 시프트”하여 Azure에서 실행 중인 다른 애플리케이션과 해당 애플리케이션 간에 데이터를 공유하려는 경우 - 온-프레미스 파일 서버 또는 NAS 장치를 바꾸거나 추가할 경우 - 여러 가상 머신에서 액세스해야 하는 개발 및 디버깅 도구를 저장할 경우. |
| Azure NetApp Files | 고급 데이터 관리 기능을 필요로 하는 가장 까다로운 고성능의 대기 시간이 짧은 워크로드를 처리할 수 있는 완전 관리형의 고가용성, 엔터프라이즈급 NAS 서비스를 제공합니다. | - POSIX 규격 Linux 및 Windows 애플리케이션, SAP HANA, 데이터베이스, HPC(고성능 컴퓨팅) 인프라 및 앱, 엔터프라이즈 웹 애플리케이션과 같이 마이그레이션하기 어려운 워크로드 배포 - 단일 서비스에서 NFSv3, NFSv4.1 및 SMB3.1.x를 비롯한 여러 파일 스토리지 프로토콜에 대한 지원이 필요하므로 코드 변경 없이 다양한 애플리케이션 리프트 앤 시프트 시나리오 사용 - 온프레미스 NetApp, AKS CSI와 연계가 가능하며, Window,Linux 모두 지원 가능 |
| Azure Blob | 구조화되지 않은 데이터를 블록 Blob에서 대규모로 저장 및 액세스할 수 있도록 합니다.(텍스트 및 이진 데이터에 대한 확장성이 뛰어난 개체 저장소) 또한 엔터프라이즈 빅 데이터 분석 솔루션을 위한 Azure Data Lake Storage도 지원합니다. |
- 애플리케이션에서 스트리밍 및 임의 액세스 시나리오를 지원 - 어디에서든 애플리케이션 데이터에 액세스 가능(글로벌 서비스) - Azure에서 엔터프라이즈 Data Lake를 빌드하고 빅 데이터 분석을 수행 가능 |
| Azure Elastic SAN | Azure Elastic SAN은 SAN 배포, 스케일링, 관리 및 구성을 간소화하는 동시에 고가용성과 같은 기본 클라우드 기능을 제공하는 완전히 통합된 솔루션입니다. | - iSCSI(internet Small Computer Systems Interface) 프로토콜을 통해 액세스하는 여러 유형의 컴퓨팅 리소스(예: SQL, MariaDB, Azure 가상 머신 및 Azure Kubernetes Services)와 상호 운용 가능한 대규모 스토리지로 사용 가능 |
| Azure (Managed) 디스크 | 연결된 가상 하드 디스크에서 데이터를 영구적으로 저장 및 액세스할 수 있습니다.( Azure VM용 블록 수준 스토리지 볼륨 ) | - 기본 파일 시스템 API를 사용하는 응용 프로그램을 데이터를 영구 디스크에 읽고 쓰도록 전환시 - 가상 머신 외부에서 액세스할 필요가 없는 데이터를 디스크가 연결된 컴퓨터에 저장 가능 |
| Azure 컨테이너 스토리지 | Azure Container Storage는 Kubernetes와 통합되고 컨테이너용으로 기본적으로 빌드되는 볼륨 관리, 배포 및 오케스트레이션 서비스입니다. | - Kubernetes 클러스터에서 실행되는 상태 저장 애플리케이션의 데이터를 저장하기 위해 영구 볼륨을 동적으로 자동으로 프로비전하려고 합니다. |
| Azure 큐 | 응용 프로그램 구성 요소 간의 비동기 메시지 큐를 허용합니다. Azure에서는 Storage 큐 및 Service Bus 큐의 두 가지 큐 유형을 지원 |
- 응용 프로그램 구성 요소를 분리하고 비동기 메시징을 사용하여 서로 통신 가능 - Storage 큐는 Azure Storage 인프라의 일부로 수많은 메시지를 저장합니다. 전 세계 어디서나 인증된 호출을 통해 HTTP 또는 HTTPS를 사용하여 메시지에 액세스할 수 있으며, 큐 메시지의 크기는 최대 64KB입니다. 비동기적으로 처리할 작업의 백로그를 만드는 데 일반적으로 사용 - Service Bus 큐는 더 폭넓은 Azure 메시징 인프라의 일부이며, 큐뿐 아니라 게시/구독과 여러 고급 통합 패턴도 지원 |
| Azure 테이블 | 클라우드에 구조화된 NoSQL 데이터를 저장하는 서비스로, 스키마 없이 디자인된 키/특성 저장소를 제공합니다. | - 웹 응용 프로그램의 사용자 데이터, 주소록, 장치 정보 및 서비스에 필요한 다른 유형의 메타데이터를 비롯한 유연한 데이터 집합을 저장 가능 |
| Azure 관리형 Lustre | HPC(고성능 컴퓨팅) 및 AI 워크로드를 위한 완전 관리형 종량제 파일 시스템을 제공합니다. 작업을 간소화하고, 설치 비용을 절감하고, 복잡한 유지 관리를 제거하도록 설계되었습니다. | - 높은 처리량과 짧은 대기 시간이 필요한 HPC 워크로드를 실행하며, 초고성능 대역폭, 병렬 I/O 최적화 - 기본 인프라를 관리할 필요 없이 클라우드에서 Lustre 워크로드를 실행하는 완전 관리 - Azure Blob과 연계 (데이터 tiering)가 가능하며, Linux 중심(Window 불가) |
4. Blob 데이터를 위한 엑세스 계층
-
4-1. 핫 액세스 계층 (Hot Access Tier):
- 장점: 가장 높은 성능을 제공하며, 자주 액세스하는 데이터에 적합합니다. 데이터 읽기/쓰기 속도가 빠르고 지연 시간이 낮습니다.
- 단점: 다른 계층에 비해 저장 비용이 높습니다.
- CRUD 작업: 모든 CRUD 작업이 빠르고 효율적으로 수행됩니다.
- 사용 사례: 자주 사용되는 파일, 이미지, 로그 데이터 등에 적합합니다.
-
4-2. 쿨 액세스 계층 (Cool Access Tier):
- 장점: 핫 계층보다 저렴한 저장 비용을 제공하며, 덜 자주 액세스하는 데이터에 적합합니다.
- 단점: 핫 계층보다 데이터 읽기/쓰기 속도가 느리고 지연 시간이 길 수 있습니다. 또한 최소 30일 동안 저장해야 합니다.
- CRUD 작업: 핫 계층보다 속도가 느릴 수 있지만, 대부분의 CRUD 작업이 여전히 가능합니다.
- 사용 사례: 백업 데이터, 재해 복구 데이터 등에 적합합니다.
-
4-3. 콜드 액세스 계층 (Cold Access Tier):
- 장점: 쿨 계층보다 더 저렴한 저장 비용을 제공하며, 드물게 액세스하는 데이터에 적합합니다.
- 단점: 데이터 읽기/쓰기 속도가 느리고 지연 시간이 매우 길 수 있습니다. 복원 작업이 필요할 수 있습니다. 또한 최소 90일 동안 저장해야 합니다.
- CRUD 작업: 데이터 읽기/쓰기 속도가 매우 느리므로, 데이터 복원 작업이 필요할 수 있습니다.
- 사용 사례: 보관 데이터, 규정 준수 데이터 등에 적합합니다.
-
44-4. 보관 액세스 계층 (Archive Access Tier):
- 장점: 가장 저렴한 저장 비용을 제공하며, 장기간 보관해야 하는 데이터에 적합합니다.
- 단점: 데이터 읽기/쓰기 속도가 가장 느리고 지연 시간이 가장 깁니다. 데이터 복원 작업이 필요하며, 복원 시간이 몇 시간 이상 걸릴 수 있습니다. 또한 최소 180일 동안 저장해야 합니다.
- CRUD 작업: 데이터 읽기/쓰기 속도가 매우 느리므로, 데이터 복원 작업이 필요합니다.
- 사용 사례: 장기 보관 데이터, 규제 준수 데이터 등에 적합합니다.
5. Blob의 엑세스 계층 설정 및 유의사항
- 액세스 계층은 언제든지 변경 가능하며, 필요에 따라 핫, 쿨, 콜드 계층 간에는 즉시 전환할 수 있습니다. 다만, 계층에 필요한 최소 일수가 경과하기 전에 Blob을 삭제하거나, 덮어쓰거나, 다른 계층으로 이동하면 조기 삭제 위약금이 부과됩니다.
- LRS, GRS 또는 RA-GRS에 대해 구성된 스토리지 계정만 보관 계층으로 Blob 이동을 지원합니다. 보관 계층은 ZRS, GZRS 또는 RA-GZRS 계정에 대해 지원되지 않습니다.
- 스토리지 계정에 대한 기본 온라인 액세스 계층을 설정합니다. 개별 Blob에 대한 설정을 명시적으로 다시 지정하지 않는 한, 계정의 Blob은 이 액세스 계층을 상속합니다.
- 업로드 시 Blob의 계층을 명시적으로 설정하여. 핫, 쿨, 콜드 또는 보관 계층으로 Blob을 만들 수 있습니다.
- Blob 계층 설정 작업을 통해 기존 Blob의 계층을 변경합니다. 일반적으로 이 작업은 더 핫한 계층에서 더 쿨한 계층으로 이동하는 데 사용합니다.
- Blob 복사 작업을 통해 Blob을 복사합니다. 일반적으로 이 작업은 더 쿨한 계층에서 더 핫한 계층으로 이동하는 데 사용합니다.
- 새 범용 v2 스토리지 계정에 대한 기본 액세스 계층은 기본적으로 핫 계층으로 설정됩니다. 스토리지 계정을 만들 때나 만든 후에 기본 액세스 계층 설정을 변경할 수 있습니다.
- 레거시 Blob Storage 계정을 만드는 경우 스토리지 계정을 만들 때 기본 액세스 계층 설정을 핫 또는 쿨로 지정해야 합니다. 스토리지 계정이 만들어지면 해당 계정에 대한 기본 액세스 계층 설정을 변경할 수 있습니다.
- 보관 계층의 Blob이 포함된 스토리지 계정에 대한 중복 구성을 변경하려면 먼저 보관된 모든 Blob을 핫, 쿨 또는 콜드 계층으로 다시 리하이드레이션해야 합니다. 리하이드레이션 작업에는 많은 비용과 시간이 소요될 수 있으므로 가능하면 보관된 Blob이 포함된 스토리지 계정에 대한 중복 구성을 변경하지 않는 것이 좋습니다.
- 계정이 LRS에 대해 구성되어 있는 동안 보관 계층으로 이동된 Blob이 없는 한 LRS에서 GRS로의 스토리지 계정 마이그레이션이 지원됩니다. 계정이 LRS가 된 시점으로부터 14일 이내에 업데이트를 수행하고 계정이 LRS로 설정된 동안 Blob이 보관 계층으로 이동되지 않은 경우 계정을 GRS로 다시 이동할 수 있습니다.
- 수명 주기 관리 정책을 사용하여 보관된 Blob을 온라인 계층으로 리하이드레이션할 수 없습니다. 프리미엄 블록 Blob 스토리지 계정에 저장된 데이터는 Blob 계층 설정 또는 Azure Blob Storage 수명 주기 관리를 사용하여 핫, 쿨, 콜드 또는 보관으로 계층화할 수 없습니다. 데이터를 이동하려면 URL API에서 블록 배치 또는 이 API를 지원하는 AzCopy 버전을 사용하여 블록 Blob 스토리지 계정에서 다른 계정의 핫 계층으로 Blob을 동기식으로 복사해야 합니다. URL에서 블록 배치 API는 서버에서 데이터를 동기적으로 복사합니다. 이는 모든 데이터를 원래 서버 위치에서 대상 위치로 이동하면 호출이 완료된다는 의미입니다.
6. 스토리지 구성시 복제 전략(중복도)
- Azure 스토리지 계정에서 데이터를 보호하기 위한 저장 옵션은 LRS, GRS, ZRS, GZRS 총 4가지가 있습니다. 각각의 특징과 적용되는 스토리지 및 지역, 기타 내용을 자세히 설명하면 다음과 같습니다.
|
LRS (로컬 중복 스토리지):
2. GRS (지역 중복 스토리지):
3. ZRS (영역 중복 스토리지):
4. GZRS (지역 영역 중복 스토리지):
|
7. Storage Account 핵심
- Storage Account 생성시 표준 스토리지는 Blob 및 Azure file 등 사용가능
- 프리미엄은 전용으로만 사용가능
- 프리미엄은 LRS, ZRS 만지원되고 표준은 다됨
- NFS 은 프리미엄으로만 사용 가능
- 백업 정책 중 유의사항은 Azure Files는 RA-GRS(읽기 액세스 지역 중복 스토리지) 또는 RA-GZRS(읽기 액세스 지역 영역 중복 스토리지)를 지원하지 않습니다.
- GRS 또는 GZRS를 활용하는 경우 보조 지역으로 장애 조치(failover)가 이루어지지 않는 한 보조 지역의 데이터에 읽기 또는 쓰기 권한을 할 수 없습니다. 보조 지역에 대한 읽기 액세스의 경우 RA-GRS(읽기 액세스 지역 영역 중복 스토리지) 또는 RA-GZRS(읽기 액세스 지역 영역 중복 스토리지)를 사용하도록 스토리지 계정을 구성합니다
8. 참고 문서
- Blob스토리지 Tier별 특징 : https://learn.microsoft.com/ko-kr/azure/storage/blobs/access-tiers-overview
- 스토리지별 비교 : https://learn.microsoft.com/ko-kr/azure/storage/common/storage-introduction?toc=%2Fazure%2Fstorage%2Fblobs%2Ftoc.json&bc=%2Fazure%2Fstorage%2Fblobs%2Fbreadcrumb%2Ftoc.json
- Blob 스토리지 기능 지원 범위 상세(참고) : https://learn.microsoft.com/ko-kr/azure/storage/blobs/storage-feature-support-in-storage-accounts
- 데이터 중복도 : https://learn.microsoft.com/ko-kr/azure/storage/common/storage-redundancy
- 스토리지 계정 계요 : https://learn.microsoft.com/ko-kr/azure/storage/common/storage-account-overview
'Azure 상식' 카테고리의 다른 글
| Azure VMSS의 특징과 Ochestration 모드 분석 (1) | 2025.08.04 |
|---|---|
| Azure Saving Plan, Reserved Instance을 활용한 비용절감 방안 이해 (2) | 2025.08.04 |
| VNet 구성시 Inbound/Outbound 구성방법 및 네트워크 흐름 (2) | 2025.08.04 |
| Azure Blob Storage Life Cycle 관리 (2) | 2025.07.28 |
| Azure RBAC (1) | 2025.07.28 |