Azure 스토리지 계정

애저 Storage Account는 애저의 핵심 스토리지 서비스에 액세스할 수 있게 해 주는 기본 리소스입니다. 여기에는 Blob Storage(개체 저장소), 애저 파일(관리형 파일 공유), Queue Storage(메시지 큐), Table Storage(NoSQL 키-값 저장소), 애저 Data Lake Storage Gen2(분석을 위한 계층적 네임스페이스)가 포함됩니다. 하나의 Storage Account에서 이러한 모든 서비스를 동시에 호스팅할 수 있으며, 애저에서 고유한 네임스페이스를 제공합니다. 계정 이름은 계정에 포함된 모든 개체의 URL 일부가 됩니다.

애저는 여러 Storage Account 유형을 제공합니다. Standard 범용 v2(GPv2) — 대부분의 시나리오에 권장되는 유형으로, Standard 성능에서 모든 스토리지 서비스와 중복성 옵션을 지원합니다. Premium 블록 Blob — Blob Storage 작업에서 매우 낮은 지연 시간이 필요한 시나리오를 위한 SSD 기반 스토리지입니다. Premium 파일 공유 — 데이터베이스나 홈 디렉터리처럼 IOPS가 높은 작업 부하를 위한 SSD 기반 애저 파일 공유입니다. Premium 페이지 Blob — 애저 VM OS 및 데이터 디스크를 위한 SSD 스토리지입니다(Managed Disks가 내부적으로 이를 사용합니다). 대부분의 사용 사례에서는 Standard GPv2 계정으로 시작하면 됩니다.

애저 Storage는 하드웨어 장애로부터 데이터를 보호하기 위해 데이터를 자동으로 복제합니다. 네 가지 중복성 옵션은 다음과 같습니다. LRS (Locally Redundant Storage) — 단일 데이터 센터 내에 동기식 사본 세 개를 저장합니다. ZRS (Zone-Redundant Storage) — 한 지역의 세 가용성 영역에 동기식 사본 세 개를 저장합니다. GRS (Geo-Redundant Storage) — 주 지역에 LRS를 적용하고 보조 지역으로 비동기 복제합니다(LRS). GZRS (Geo-Zone-Redundant Storage) — 주 지역에 ZRS를 적용하고 보조 지역으로 비동기 복제합니다. 중복성이 높을수록 내구성과 비용도 높아집니다.

RTO, RPO 및 예산 요구 사항에 따라 중복성 계층을 선택하십시오. LRS — 가장 저렴하고 내구성이 11개의 9로 표현되지만 데이터 센터 장애에 대한 보호 기능은 없습니다. 개발/테스트 환경이나 다시 만들 수 있는 데이터에 사용하십시오. ZRS — 데이터 센터 장애를 보호하며, 단일 지역의 운영 데이터에 적합합니다. GRS/GZRS — 애저 지역 전체가 오프라인 상태가 되는 상황을 보호하며, 데이터는 쌍을 이루는 지역으로 비동기 복제됩니다. 지역 재해가 발생해도 반드시 유지되어야 하는 중요한 비즈니스 데이터에는 추가 비용이 들더라도 GRS 또는 GZRS가 적합합니다.

애저 Storage는 두 가지 성능 계층을 제공합니다. Standard — 하드 디스크 드라이브(HDD)를 기반으로 하며, 대부분의 작업 부하에 적합하고 GB당 비용이 낮습니다. Premium — 솔리드 스테이트 드라이브(SSD)를 기반으로 하며, 한 자릿수 밀리초의 I/O가 필요한 지연 시간 민감형 시나리오를 위해 설계되었습니다. Standard 스토리지는 저장된 GB를 기준으로 요금이 부과되고, Premium은 GB당 비용이 더 높지만 일관되고 예측 가능한 성능을 제공합니다. 웹 자산, 백업, 로그 및 보관 데이터에는 Standard가 적합합니다. I/O 집약적인 데이터베이스가 있는 VM이나 데스크톱 사용자가 액세스하는 파일 공유에는 Premium이 더 적합합니다.

Storage Account 이름은 애저의 모든 계정에서 전역적으로 고유해야 합니다(mystorageacct.blob.core.windows.net과 같은 공용 DNS 이름의 일부가 되기 때문입니다). 이름은 3~24자여야 하며 소문자와 숫자만 포함할 수 있습니다. 하이픈, 밑줄, 대문자는 사용할 수 없습니다. 이름이 전역적으로 고유해야 하므로 일반적인 단어와 브랜드 이름은 이미 사용 중인 경우가 많습니다. 회사 접두사, 환경(prod/dev), 용도(store/media)를 조합한 다음 필요한 경우 임의의 접미사를 추가하는 것이 좋습니다. 예: contosoprodmedia7x2.

각 Storage Account에는 계정의 모든 항목에 대한 전체 관리자 액세스 권한을 부여하는 512비트 액세스 키가 두 개 있습니다. 이러한 키는 암호처럼 취급하여 코드나 구성 파일이 아닌 애저 Key Vault에 저장해야 합니다. 애저는 서비스 중단 없이 키 교체를 수행할 수 있도록 두 개의 키를 생성합니다. 애플리케이션이 Key 2를 사용하도록 업데이트한 다음 Key 1을 다시 생성하고, 애플리케이션을 Key 1로 전환한 후 Key 2를 다시 생성하면 됩니다. 더 세분화된 액세스 제어가 필요하면 마스터 키를 공유하는 대신 Shared Access Signatures(SAS) 또는 애저 RBAC를 사용하십시오.

애저 RBAC(Role-Based Access Control)는 키를 공유하지 않고 스토리지 데이터에 대한 액세스를 승인하는 권장 방법입니다. Blob Storage에 읽기 전용 액세스를 허용하려면 Storage Blob Data Reader 역할을 할당하고, 읽기/쓰기를 허용하려면 Storage Blob Data Contributor 역할을 할당하십시오. 이러한 역할은 Entra ID 사용자, 그룹 또는 관리 ID에 할당되므로 액세스가 공유된 비밀이 아니라 인증된 ID에 연결됩니다. 스토리지에 대한 RBAC 승인은 Blob, Queue 및 Table 서비스에서 사용할 수 있습니다(File에는 사용할 수 없습니다. File은 자체 액세스 제어가 있는 SMB/NFS 프로토콜을 사용합니다).

기본적으로 Storage Account는 모든 네트워크에서의 연결을 허용합니다. 운영 환경의 보안을 위해 Storage Account 방화벽을 사용하여 액세스를 제한하십시오. 특정 공용 IP 범위나 가상 네트워크 서브넷만 허용할 수 있습니다. 최고 수준의 보안을 위해 공용 인터넷 액세스를 완전히 비활성화하고 프라이빗 엔드포인트를 사용하십시오. 프라이빗 엔드포인트는 VNet 내부의 프라이빗 IP 주소로, 애저의 프라이빗 백본을 통해 Storage Account로 트래픽을 라우팅하며 공용 인터넷에는 전혀 노출하지 않습니다. 민감하거나 규제를 받는 데이터가 포함된 Storage Account에는 프라이빗 엔드포인트를 사용하는 것이 권장됩니다.

애저 Storage는 실수로 삭제하는 상황을 방지하기 위한 기본 제공 데이터 보호 기능을 제공합니다. Blob 일시 삭제 — 삭제된 Blob과 버전이 구성 가능한 기간(1~365일) 동안 보존되며, 백업에서 복원하지 않고도 복구할 수 있습니다. Blob 버전 관리 — 덮어쓸 때마다 새 버전이 생성되므로 Blob의 이전 버전을 복원할 수 있습니다. 컨테이너 일시 삭제 — 실수로 삭제한 컨테이너를 복구할 수 있습니다. 이러한 기능은 기본적으로 비활성화되어 있으므로, 다른 곳에 백업되지 않은 중요한 데이터를 보관하는 운영용 Storage Account에서는 활성화해야 합니다.

애저 Monitor는 모든 Storage Account의 메트릭을 자동으로 수집합니다. 여기에는 사용된 총 용량, 트랜잭션 수, 수신 및 송신 바이트, 종단 간 지연 시간이 포함됩니다. Storage Account의 애저 포털 Insights 블레이드에서 이러한 메트릭을 확인할 수 있으며, 용량, 가용성 및 성능을 위한 사전 작성 차트를 제공합니다. 자세한 액세스 감사를 수행하려면 Storage 진단 로그를 활성화하여 모든 읽기, 쓰기 및 삭제 작업을 로그 대상으로 기록하십시오. 이는 보안 조사와 규정 준수 보고에 유용합니다.

이 단원에서 다룬 Microsoft Azure Fundamentals(AZ-900) 개념을 얼마나 이해했는지 테스트해 보십시오.

이 단원에서는 다음을 학습했습니다. Storage Account는 모든 애저 스토리지 서비스의 루트 리소스이며 전역적으로 고유한 이름으로 식별됩니다. 또한 LRS, ZRS, GRS, GZRS와 같은 중복성 옵션은 비용이 증가하는 대신 점점 더 높은 수준의 내구성을 제공합니다. 그리고 마스터 액세스 키를 공유하기보다는 RBAC와 프라이빗 엔드포인트를 통해 액세스를 제어해야 합니다. 다음으로는 비정형 데이터를 위한 애저의 개체 저장소인 Blob Storage를 자세히 살펴보겠습니다.