다음을 통해 공유

Azure Blob Storage에 대한 Azure 잘 설계된 프레임워크 관점

  • 아티클

Azure Blob Storage는 클라우드용 Microsoft 개체 스토리지 솔루션입니다. Blob Storage는 대량의 비구조적 데이터를 저장하는 데 사용됩니다. 구조화되지 않은 데이터는 텍스트 또는 이진 데이터와 같은 특정 데이터 모델 또는 정의를 준수하지 않는 데이터입니다.

이 문서에서는 설계자로서 스토리지 옵션을 검토하고 워크로드를 실행할 스토리지 서비스로 Blob Storage를 선택했다고 가정합니다. 이 문서의 지침은 Azure Well-Architected Framework 핵심 요소의 원칙에 매핑되는 아키텍처 권장 사항을 제공합니다.

Important

이 가이드를 사용하는 방법

각 섹션에는 디자인 전략과 함께 중요한 아키텍처 영역을 제공하는 디자인 검사 목록이 있습니다.

또한 이러한 전략을 구현하는 데 도움이 될 수 있는 기술 기능에 대한 권장 사항도 포함되어 있습니다. 권장 사항은 Blob Storage 및 해당 종속성에 사용할 수 있는 모든 구성의 전체 목록을 나타내지 않습니다. 대신 디자인 관점에 매핑된 주요 권장 사항을 나열합니다. 권장 사항을 사용하여 개념 증명을 빌드하거나 기존 환경을 최적화합니다.

안정성

안정성 핵심 요소의 목적은 충분한 복원력과 오류로부터 빠르게 복구할 수 있는 기능을 구축하여 지속적인 기능을 제공하는 것입니다.

안정성 디자인 원칙은 개별 구성 요소, 시스템 흐름 및 시스템 전체에 적용되는 고급 디자인 전략을 제공합니다.

디자인 검사 목록

디자인 검토 검사 안정성 목록에 따라 디자인 전략을 시작합니다.

  • 오류 모드 분석 사용: 가상 네트워크, Azure Key Vault 또는 Azure Content Delivery Network 또는 Azure Front Door 엔드포인트의 가용성과 같은 내부 종속성을 고려하여 실패 지점을 최소화합니다. 워크로드가 Blob Storage에 액세스하는 데 필요한 자격 증명이 Key Vault에서 누락되거나 워크로드가 제거된 콘텐츠 배달 네트워크를 기반으로 엔드포인트를 사용하는 경우 오류가 발생할 수 있습니다. 이러한 경우 워크로드는 다른 엔드포인트를 사용하여 연결해야 할 수 있습니다. 오류 모드 분석에 대한 일반적인 내용은 실패 모드 분석을 수행하기 위한 권장 사항 참조하세요.

  • 안정성 및 복구 목표 정의: Azure SLA(서비스 수준 계약)를 검토합니다. 스토리지 계정에 대한 SLO(서비스 수준 목표)를 파생합니다. 예를 들어 SLO는 선택한 중복 구성의 영향을 받을 수 있습니다. 지역 중단의 영향, 데이터 손실 가능성 및 중단 후 액세스를 복원하는 데 필요한 시간을 고려합니다. 또한 오류 모드 분석의 일부로 식별한 내부 종속성의 가용성을 고려합니다.

  • 데이터 중복성 구성: 최대 내구성을 위해 가용성 영역 또는 전역 지역에서 데이터를 복사하는 구성을 선택합니다. 최대 가용성을 위해 클라이언트가 주 지역의 중단 중에 보조 지역에서 데이터를 읽을 수 있도록 하는 구성을 선택합니다.

  • 애플리케이션 디자인: 어떤 이유로든 주 지역을 사용할 수 없게 되면 보조 지역에서 데이터를 읽는 것으로 원활하게 전환할 수 있도록 애플리케이션 을 디자인합니다. GRS(지역 중복 스토리지) 및 GZRS(지역 영역 중복 스토리지) 구성에만 적용됩니다. 중단을 처리하도록 애플리케이션을 디자인하면 최종 사용자의 가동 중지 시간이 줄어듭니다.

  • 복구 대상을 충족하는 데 도움이 되는 기능을 살펴봅니다. Blob이 실수로 손상, 편집 또는 삭제된 경우 복구할 수 있도록 복원할 수 있도록 합니다.

  • 복구 계획 만들기: 데이터 보호 기능, 백업 및 복원 작업 또는 장애 조치(failover) 절차를 고려합니다. 잠재적인 데이터 손실 및 데이터 불일치 및 장애 조치(failover) 시간과 비용을 준비합니다. 자세한 내용은 재해 복구 전략 설계에 대한 권장 사항 참조하세요.

  • 잠재적 가용성 문제 모니터링: Azure Service Health 대시보드를 구독하여 잠재적인 가용성 문제를 모니터링합니다. Azure Monitor 및 진단 로그의 스토리지 메트릭을 사용하여 경고를 조사합니다.

권장 사항

추천 장점
중복성을 위해 계정을 구성합니다.

최대 가용성 및 내구성을 위해 ZRS(영역 중복 스토리지) 또는 GZRS를 사용하여 계정을 구성합니다.		 중복성은 예기치 않은 오류로부터 데이터를 보호합니다. ZRS 및 GZRS 구성 옵션은 다양한 가용성 영역에서 복제본(replica)te이며, 가동 중단 시 애플리케이션이 데이터를 계속 읽을 수 있도록 합니다. 자세한 내용은 가동 중단 시나리오 및 내구성 및 가용성 매개 변수별 내구성 및 가용성을 참조하세요.
장애 조치(failover) 또는 장애 복구(failback)를 시작하기 전에 마지막 동기화 시간 속성의 값을 검사 데이터 손실 가능성을 평가합니다. 이 권장 사항은 GRS 및 GZRS 구성에만 적용됩니다. 이 속성을 사용하면 계정 장애 조치(failover)를 시작하여 손실될 수 있는 데이터의 양을 예측할 수 있습니다.

마지막 동기화 시간 이전에 작성된 모든 데이터 및 메타데이터는 보조 지역에서 사용할 수 있지만 마지막 동기화 시간 이후에 작성된 데이터 및 메타데이터는 보조 지역에 기록되지 않으므로 손실될 수 있습니다.
백업 및 복구 전략의 일환으로 컨테이너 일시 삭제, Blob 일시 삭제, 버전 관리 및 지정 시간 복원 옵션을 사용하도록 설정합니다. 일시 삭제 옵션을 사용하면 스토리지 계정이 삭제된 컨테이너 및 Blob을 복구할 수 있습니다.

버전 관리 옵션은 Blob에 대한 변경 내용을 자동으로 추적합니다. 이 옵션을 사용하면 Blob을 이전 상태로 복원할 수 있습니다.

지정 시간 복원 옵션은 실수로 인한 Blob 삭제 또는 손상으로부터 보호하고 블록 Blob 데이터를 이전 상태로 복원할 수 있습니다.

자세한 내용은 데이터 보호 개요를 참조하세요.

보안

보안 핵심 요소의 목적은 워크로드에 기밀성, 무결성 및 가용성 보장을 제공하는 것입니다.

보안 디자인 원칙은 Blob Storage 구성의 기술 디자인에 접근 방식을 적용하여 이러한 목표를 달성하기 위한 고급 디자인 전략을 제공합니다.

디자인 검사 목록

보안에 대한 디자인 검토 검사 목록에 따라 디자인 전략을 시작합니다. 보안 상태를 개선하기 위해 취약성 및 컨트롤을 식별합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.

  • Azure Storage의 보안 기준을 검토합니다. 시작하려면 먼저 Storage의 보안 기준을 검토합니다.

  • 네트워크 컨트롤을 사용하여 수신 및 송신 트래픽 제한: 스토리지 계정에 대한 모든 공용 트래픽을 사용하지 않도록 설정합니다. 계정 네트워크 컨트롤을 사용하여 사용자 및 애플리케이션에 필요한 최소 수준의 액세스 권한을 부여합니다. 자세한 내용은 스토리지 계정의 네트워크 보안에 접근하는 방법을 참조하세요.

  • 공격 노출 영역 줄이기: 익명 액세스, 계정 키 액세스 또는 안전하지 않은(HTTP) 연결에 대한 액세스를 방지하면 공격 노출 영역을 줄일 수 있습니다. 최신 버전의 TLS(전송 계층 보안) 프로토콜을 사용하여 클라이언트가 데이터를 보내고 받도록 요구합니다.

  • 암호 또는 키를 사용하지 않고 액세스 권한 부여: Microsoft Entra ID는 공유 키 및 공유 액세스 서명에 비해 뛰어난 보안 및 사용 편의성을 제공합니다. 보안 주체가 작업을 수행하는 데 필요한 권한만 보안 주체에게 부여합니다.

  • 중요한 정보 보호: 계정 키 및 공유 액세스 서명 토큰과 같은 중요한 정보를 보호합니다. 이러한 형태의 권한 부여는 일반적으로 권장되지 않지만 순환, 만료 및 안전하게 저장해야 합니다.

  • 보안 전송 필요 옵션 사용: 모든 스토리지 계정에 대해 이 설정을 사용하도록 설정하면 스토리지 계정에 대한 모든 요청이 보안 연결을 통해 수행되어야 합니다. HTTP를 통해 수행된 모든 요청이 실패합니다.

  • 중요 개체 보호: 불변성 정책을 적용하여 중요한 개체를 보호합니다. 정책은 법률, 규정 준수 또는 기타 비즈니스 목적으로 저장된 Blob이 수정되거나 삭제되지 않도록 보호합니다. 설정된 기간 또는 관리자가 제한을 해제할 때까지 보류를 구성합니다.

  • 위협 감지: Microsoft Defender for Storage를 사용하도록 설정하여 위협을 감지합니다. 보안 경고는 활동의 비정상 현상이 발생할 때 트리거됩니다. 경고는 의심스러운 활동에 대한 세부 정보 및 위협을 조사하고 수정하는 방법에 대한 권장 사항과 함께 이메일을 통해 구독 관리자에게 알립니다.

권장 사항

추천 장점
컨테이너 및 Blob에 대한 익명 읽기 액세스를 사용하지 않도록 설정합니다. 스토리지 계정에 대해 익명 액세스가 허용되는 경우 적절한 권한이 있는 사용자는 컨테이너의 익명 액세스 설정을 수정하여 해당 컨테이너의 데이터에 익명으로 액세스할 수 있도록 할 수 있습니다.
스토리지 계정에 Azure Resource Manager 잠금을 적용합니다. 계정을 잠그면 계정이 삭제되고 데이터 손실이 발생하지 않습니다.
스토리지 계정의 퍼블릭 엔드포인트에 대한 트래픽을 사용하지 않도록 설정합니다. Azure에서 실행되는 클라이언트에 대한 프라이빗 엔드포인트를 만듭니다. Azure 외부의 클라이언트 및 서비스에서 스토리지 계정에 직접 액세스해야 하는 경우에만 퍼블릭 엔드포인트를 사용하도록 설정합니다. 특정 가상 네트워크에 대한 액세스를 제한하는 방화벽 규칙을 사용하도록 설정합니다. 액세스 0으로 시작한 다음, 공격자에게 불필요한 개방을 만들 위험을 최소화하기 위해 클라이언트 및 서비스에 필요한 가장 낮은 수준의 액세스 권한을 증분 방식으로 부여합니다.
Azure RBAC(역할 기반 액세스 제어)를 사용하여 액세스 권한을 부여합니다. RBAC를 사용하면 손상될 수 있는 암호나 키가 없습니다. 보안 주체(사용자, 그룹, 관리 ID 또는 서비스 주체)는 Microsoft Entra ID에 의해 인증되어 OAuth 2.0 토큰을 반환합니다. 토큰은 Blob Storage 서비스에 대한 요청에 권한을 부여하는 데 사용됩니다.
공유 키 권한 부여를 허용하지 않습니다. 계정 키를 기반으로 하기 때문에 계정 키 액세스뿐만 아니라 서비스 및 계정 공유 액세스 서명 토큰도 사용하지 않도록 설정합니다. Microsoft Entra ID로 권한이 부여된 보안 요청만 허용됩니다.
계정 키를 사용하지 않는 것이 좋습니다. 계정 키를 사용해야 하는 경우 Key Vault에 저장하고 주기적으로 다시 생성해야 합니다. Key Vault를 사용하면 애플리케이션을 사용하여 키를 저장하는 대신 런타임에 키를 검색할 수 있습니다. 또한 Key Vault를 사용하면 애플리케이션을 중단하지 않고 키를 쉽게 회전할 수 있습니다. 계정 키를 주기적으로 회전하면 악의적인 공격에 데이터가 노출될 위험이 줄어듭니다.
공유 액세스 서명 토큰을 사용하지 않는 것이 좋습니다. Blob Storage 리소스에 대한 액세스를 보호하기 위해 공유 액세스 서명 토큰이 필요한지 여부를 평가합니다. 만들어야 하는 경우 공유 액세스 서명 모범 사례 목록을 만들고 배포하기 전에 검토합니다. 모범 사례는 공유 액세스 서명 토큰이 유출되는 것을 방지하고 누출이 발생하는 경우 신속하게 복구하는 데 도움이 될 수 있습니다.
클라이언트가 TLS 1.2의 최소 버전을 사용하여 데이터를 보내고 받을 수 있도록 스토리지 계정을 구성합니다. TLS 1.2는 최신 암호화 알고리즘 및 암호화 도구 모음을 지원하지 않는 TLS 1.0 및 1.1보다 더 안전하고 빠릅니다.
사용자 고유의 암호화 키를 사용하여 스토리지 계정의 데이터를 보호하는 것이 좋습니다. 자세한 내용은 Azure Storage 암호화용 고객 관리형 키를 참조하세요. 고객 관리형 키는 더 큰 유연성과 제어를 제공합니다. 예를 들어 Key Vault에 암호화 키를 저장하고 자동으로 회전할 수 있습니다.

비용 최적화

비용 최적화는 지출 패턴을 감지하고, 중요한 영역에 대한 투자의 우선 순위를 지정하며, 조직의 예산 및 비즈니스 요구 사항을 충족하도록 다른 영역에서 최적화하는 데 중점을 둡니다.

비용 최적화 디자인 원칙은 이러한 목표를 달성하고 Blob Storage 및 해당 환경과 관련된 기술 설계에서 필요에 따라 장단위를 만들기 위한 높은 수준의 디자인 전략을 제공합니다.

디자인 검사 목록

투자 비용 최적화를 위한 디자인 검토 검사 목록에 따라 디자인 전략을 시작합니다. 워크로드가 워크로드에 할당된 예산에 맞게 조정되도록 디자인을 미세 조정합니다. 디자인은 적절한 Azure 기능을 사용하고, 투자를 모니터링하고, 시간이 지남에 따라 최적화할 기회를 찾아야 합니다.

  • 청구서를 계산하는 데 사용되는 미터를 식별합니다. 미터는 계정에 저장된 데이터 양(데이터 용량)과 데이터를 쓰고 읽기 위해 수행되는 작업의 수와 유형을 추적하는 데 사용됩니다. Blob 인덱스 태그, Blob 인벤토리, 변경 피드 지원, 암호화 범위 및 SFTP(SSH 파일 전송 프로토콜) 지원과 같은 선택적 기능의 사용과 관련된 미터도 있습니다. 자세한 내용은 Blob Storage에 대한 요금이 청구된 방법을 참조하세요.

  • 각 미터의 가격 이해: 적절한 가격 책정 페이지를 사용하고 해당 페이지에서 적절한 설정을 적용해야 합니다. 자세한 내용은 각 미터의 단가 찾기를 참조 하세요. 각 가격과 관련된 작업 수를 고려합니다. 예를 들어 쓰기 및 읽기 작업과 관련된 가격은 10,000개 작업에 적용됩니다. 개별 작업의 가격을 확인하려면 나열된 가격을 10,000으로 나눕니다.

  • 용량 및 작업 비용 예측: Azure 가격 계산기를 사용하여 데이터 스토리지, 수신 및 송신과 관련된 비용을 모델링할 수 있습니다. 필드를 사용하여 다양한 지역, 계정 유형, 네임스페이스 유형 및 중복 구성과 관련된 비용을 비교합니다. 특정 시나리오의 경우 Microsoft 설명서에서 사용할 수 있는 샘플 계산 및 워크시트를 사용할 수 있습니다. 예를 들어 데이터 보관 비용을 예측하거나 AzCopy 명령을 사용하여 Blob을 전송하는 비용을 예측할 수 있습니다.

  • 용량에 대한 청구 모델 선택: 약정 기반 모델을 사용하는 것이 소비 기반 모델을 사용하는 것보다 비용 효율적인지 평가합니다. 필요한 용량의 양을 잘 모르는 경우 소비 기반 모델로 시작하고 용량 메트릭을 모니터링한 다음 나중에 평가할 수 있습니다.

  • 계정 유형, 중복 수준 및 기본 액세스 계층을 선택합니다. 스토리지 계정을 만들 때 이러한 각 설정에 대한 값을 선택해야 합니다. 모든 값은 트랜잭션 요금 및 용량 요금에 영향을 미칩니다. 계정을 만든 후 계정 유형을 제외한 모든 설정을 변경할 수 있습니다.

  • 가장 비용 효율적인 기본 액세스 계층을 선택합니다. 각 Blob 업로드로 계층을 지정하지 않는 한 Blob은 기본 액세스 계층 설정에서 액세스 계층을 유추합니다. 스토리지 계정의 기본 액세스 계층 설정 변경은 액세스 계층이 명시적으로 설정되지 않은 계정의 모든 Blob에 적용됩니다. 많은 수의 Blob을 수집한 경우 이 비용이 상당할 수 있습니다. 계층 변경이 각 기존 Blob에 미치는 영향에 대한 자세한 내용은 Blob의 액세스 계층 변경을 참조 하세요.

  • 가장 비용 효율적인 액세스 계층에 직접 데이터 업로드: 예를 들어 계정의 기본 액세스 계층 설정이 핫이지만 보관 목적으로 파일을 업로드하는 경우 업로드 작업의 일부로 쿨 계층을 보관 또는 콜드 계층으로 지정합니다. Blob을 업로드한 후 수명 주기 관리 정책을 사용하여 마지막으로 액세스한 시간과 같은 사용 메트릭에 따라 Blob을 가장 비용 효율적인 계층으로 이동합니다. 최적 계층을 미리 선택하면 비용을 줄일 수 있습니다. 이미 업로드한 블록 Blob의 계층을 변경하는 경우 Blob을 처음 업로드할 때 초기 계층에 쓰는 비용을 지불한 다음 원하는 계층에 쓰는 비용을 지불합니다.

  • 데이터 수명 주기를 관리하기 위한 계획을 수립합니다. 액세스 계층 및 수명 주기 관리를 활용하여 트랜잭션 및 용량 비용을 최적화합니다. 자주 사용되지 않는 데이터는 쿨러 액세스 계층에 배치되어야 하는 반면 액세스되는 데이터는 더 따뜻한 액세스 계층에 배치되어야 합니다.

  • 필요한 기능을 결정합니다. 버전 관리 및 Blob 일시 삭제와 같은 일부 기능에는 추가 트랜잭션 및 용량 비용과 기타 요금이 발생합니다. 계정에 추가할 기능을 선택할 때 해당 기능을 설명하는 문서의 가격 책정 및 청구 섹션을 검토해야 합니다.

    예를 들어 Blob 인벤토리 기능을 사용하도록 설정하면 검색된 개체 수에 대한 요금이 청구됩니다. Blob 인덱스 태그를 사용하는 경우 인덱스 태그 수에 대한 요금이 청구됩니다. SFTP 지원을 사용하도록 설정하면 SFTP 전송이 없더라도 시간당 요금이 청구됩니다. 기능을 사용하지 않도록 결정하는 경우 계정을 만들 때 일부 기능이 자동으로 사용하도록 설정되므로 기능이 비활성화되었는지 확인합니다.

  • 가드레일 만들기: 구독 및 리소스 그룹을 기반으로 예산을 만듭니다. 거버넌스 정책을 사용하여 리소스 종류, 구성 및 위치를 제한합니다. 또한 RBAC를 사용하여 과다 지출로 이어질 수 있는 작업을 차단합니다.

  • 비용 모니터링: 비용이 예산 내에서 유지되는지 확인하고, 예측과 비용을 비교하고, 초과 지출이 발생하는 위치를 확인합니다. Azure Portal의 비용 분석 창을 사용하여 비용을 모니터링할 수 있습니다. 비용 데이터를 스토리지 계정으로 내보내고 Excel 또는 Power BI를 사용하여 해당 데이터를 분석할 수도 있습니다.

  • 사용량 모니터링: 사용 패턴을 지속적으로 모니터링하고 사용되지 않거나 사용되지 않는 계정 및 컨테이너를 검색합니다. 스토리지 인사이트를 사용하여 사용량이 없거나 낮은 ID 계정을 만듭니다. Blob 인벤토리 보고서를 사용하도록 설정하고 Azure Databricks 또는 Azure Synapse Analytics 및 Power BI와 같은 도구를 사용하여 비용 데이터를 분석합니다. 수많은 로그 파일, Blob 버전 또는 일시 삭제된 Blob을 수집하고 있음을 나타낼 수 있는 예기치 않은 용량 증가에 주의하세요. 개체를 더 비용 효율적인 액세스 계층으로 만료 또는 전환하기 위한 전략을 개발합니다. 개체를 만료하거나 더 저렴한 액세스 계층으로 개체를 이동하기 위한 계획을 세워야 합니다.

권장 사항

추천 장점
작은 파일을 더 큰 파일 로 압축한 후 쿨 계층으로 이동합니다. TAR 또는 ZIP과 같은 파일 형식을 사용할 수 있습니다. 쿨 계층은 데이터 전송 비용이 더 높습니다. 대용량 파일을 줄이면 데이터를 전송하는 데 필요한 작업 수를 줄일 수 있습니다.
보관 스토리지에서 Blob을 리하드레이션할 때 표준 우선 순위 리하일레이션을 사용합니다. 긴급 데이터 복원 상황에 대해서만 우선 순위가 높은 리하일레이션을 사용합니다. 자세한 내용은 보관된 Blob을 온라인 계층에 리하이딩하는 방법을 참조 하세요. 보관 계층에서 우선 순위가 높은 리하일레이션은 정상보다 높은 청구서로 이어질 수 있습니다.
적절한 로그 스토리지 위치를 선택하고 로그 보존 기간을 관리하여 리소스 로그 사용 비용을 줄입니다. 로그를 가끔(예: 준수 감사에 대한 로그 쿼리)만 쿼리하려는 경우 리소스 로그를 Azure Monitor 로그 작업 영역으로 보내는 대신 스토리지 계정으로 보내는 것이 좋습니다. Azure Synapse Analytics와 같은 서버리스 쿼리 솔루션을 사용하여 로그를 분석할 수 있습니다. 자세한 내용은 드문 쿼리에 대한 비용 최적화를 참조 하세요. 수명 주기 관리 정책을 사용하여 로그를 삭제하거나 보관합니다. 나중에 분석하기 위해 스토리지 계정에 리소스 로그를 저장하는 것이 더 저렴한 옵션일 수 있습니다. 수명 주기 관리 정책을 사용하여 스토리지 계정의 로그 보존을 관리하면 시간이 지남에 따라 많은 수의 로그 파일이 쌓이는 것을 방지하므로 불필요한 용량 요금이 발생할 수 있습니다.
버전 관리를 사용하도록 설정하는 경우 수명 주기 관리 정책을 사용하여 이전 Blob 버전을 자동으로 삭제합니다. Blob에 대한 모든 쓰기 작업은 새 버전을 만듭니다. 이렇게 하면 용량 비용이 증가합니다. 더 이상 필요하지 않은 버전을 제거하여 검사 비용을 유지할 수 있습니다.
버전 관리 기능을 사용하도록 설정하는 경우 버전 관리가 활성화되지 않은 계정에 자주 덮어쓰여지는 Blob을 배치합니다. Blob을 덮어쓸 때마다 새 버전이 추가되어 스토리지 용량 요금이 증가합니다. 용량 요금을 줄이려면 버전 관리가 비활성화된 별도 스토리지 계정에 자주 덮어쓴 데이터를 저장합니다.
일시 삭제를 사용하도록 설정하는 경우 일시 삭제를 사용하도록 설정하지 않은 계정에 자주 덮어쓰는 Blob을 배치합니다. 보존 기간을 설정합니다. 이 기능이 청구서에 미치는 영향을 더 잘 이해하려면 짧은 보존 기간부터 시작하는 것이 좋습니다. 최소 권장 보존 기간은 7일입니다. Blob을 덮어쓸 때마다 새 스냅샷 만들어집니다. 이러한 스냅샷 생성이 로그에 표시되지 않기 때문에 용량 요금 증가의 원인은 액세스하기 어려울 수 있습니다. 용량 요금을 줄이려면 일시 삭제를 사용하지 않도록 설정된 별도 스토리지 계정에 자주 덮어쓴 데이터를 저장합니다. 보존 기간은 일시 삭제된 Blob이 쌓여 용량 비용에 추가되는 것을 방지합니다.
데이터를 전송하는 데 사용되는 경우에만 SFTP 지원을 사용하도록 설정합니다. SFTP 엔드포인트를 사용하도록 설정하면 시간당 비용이 발생합니다. SFTP 지원을 신중하게 사용하지 않도록 설정한 다음 필요에 따라 사용하도록 설정하면 계정에 수동 요금이 발생하지 않도록 방지할 수 있습니다.
불필요한 요금을 방지하기 위해 필요하지 않은 암호화 범위를 사용하지 않도록 설정합니다. 암호화 범위는 월별 요금이 발생합니다.

운영 우수성

운영 우수성은 주로 개발 관행, 관찰성 및 릴리스 관리를 위한 절차에 중점을 둡니다.

운영 우수성 디자인 원칙은 워크로드의 운영 요구 사항에 대한 이러한 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공합니다.

디자인 검사 목록

Blob Storage 구성과 관련된 관찰성, 테스트 및 배포에 대한 프로세스를 정의하기 위한 디자인 검토 검사 운영 우수성 목록에 따라 디자인 전략을 시작합니다.

  • 기본 테넌트 및 긴급 복구 계획 만들기: 데이터 보호 기능, 백업 및 복원 작업 및 장애 조치(failover) 절차를 고려합니다. 잠재적인 데이터 손실 및 데이터 불일치 및 장애 조치(failover) 시간과 비용을 준비합니다.

  • 스토리지 계정의 상태 모니터링: 스토리지 인사이트 대시보드를 만들어 가용성, 성능 및 복원력 메트릭을 모니터링합니다. 경고를 설정하여 고객이 문제를 파악하기 전에 시스템의 문제를 식별하고 해결합니다. 진단 설정을 사용하여 리소스 로그를 Azure Monitor 로그 작업 영역으로 라우팅합니다. 그런 다음 로그를 쿼리하여 경고를 더 자세히 조사할 수 있습니다.

  • Blob 인벤토리 보고서 사용: Blob 인벤토리 보고서를 사용하도록 설정하여 스토리지 계정 콘텐츠의 보존, 법적 보존 또는 암호화 상태 검토합니다. Blob 인벤토리 보고서를 사용하여 데이터의 총 데이터 크기, 연령, 계층 분포 또는 기타 특성을 이해할 수도 있습니다. Azure Databricks 또는 Azure Synapse Analytics 및 Power BI와 같은 도구를 사용하여 인벤토리 데이터를 더 잘 시각화하고 관련자를 위한 보고서를 만듭니다.

  • Blob을 삭제하거나 비용 효율적인 액세스 계층으로 이동하는 정책을 설정합니다. 초기 조건 집합을 사용하여 수명 주기 관리 정책을 만듭니다. 정책은 사용자가 정의한 조건에 따라 Blob의 액세스 계층을 자동으로 삭제하거나 설정합니다. 모니터링 메트릭 및 Blob 인벤토리 보고서를 사용하여 컨테이너 사용을 주기적으로 분석하여 비용 효율성을 최적화하기 위한 조건을 구체화할 수 있습니다.

권장 사항

추천 장점
IaC(Infrastructure as Code)를 사용하여 ARM 템플릿(Azure Resource Manager 템플릿), Bicep 또는 Terraform에서 스토리지 계정의 세부 정보를 정의합니다. 기존 DevOps 프로세스를 사용하여 새 스토리지 계정을 배포하고 Azure Policy를 사용하여 해당 구성을 적용할 수 있습니다.
Storage 인사이트를 사용하여 스토리지 계정의 상태 및 성능을 추적합니다. 스토리지 인사이트는 모든 스토리지 계정에 대한 오류, 성능, 가용성 및 용량에 대한 통합 보기를 제공합니다. 각 계정의 상태 및 작업을 추적할 수 있습니다. 관련자가 스토리지 계정의 상태를 추적하는 데 사용할 수 있는 대시보드 및 보고서를 쉽게 만듭니다.

성능 효율성

성능 효율성은 용량을 관리하여 부하가 증가하는 경우에도 사용자 환경을 기본 파악하는 것입니다. 이 전략에는 리소스 크기 조정, 잠재적인 병목 현상 식별 및 최적화, 최고 성능 최적화가 포함됩니다.

성능 효율성 디자인 원칙은 예상된 사용량에 대해 이러한 용량 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공합니다.

디자인 검사 목록

성능 효율성에 대한 디자인 검토 검사 목록에 따라 디자인 전략을 시작합니다. Blob Storage 구성에 대한 주요 성능 지표를 기반으로 하는 기준을 정의합니다.

  • 규모 계획: 스토리지 계정의 크기 조정 대상을 이해합니다.

  • 최적의 스토리지 계정 유형을 선택합니다. 워크로드에 높은 트랜잭션 속도, 더 작은 개체 및 일관되게 낮은 트랜잭션 대기 시간이 필요한 경우 프리미엄 블록 Blob Storage 계정을 사용하는 것이 좋습니다. 대부분의 경우 표준 범용 v2 계정이 가장 적합합니다.

  • 클라이언트와 서버 간의 이동 거리 줄이기: 연결 클라이언트에 가장 가까운 지역에 데이터를 배치합니다(이상적으로는 동일한 지역에 위치). 개체 복제본(replica)tion 또는 콘텐츠 배달 네트워크를 사용하여 멀리 떨어진 지역의 클라이언트에 최적화합니다. 기본 네트워크 구성은 최상의 성능을 제공합니다. 보안 향상을 위해서만 네트워크 설정을 수정합니다. 일반적으로 네트워크 설정은 이동 거리를 감소하지 않으며 성능을 향상하지 않습니다.

  • 효율적인 명명 체계 선택: Blob 파티션 키(계정, 컨테이너, 가상 디렉터리 또는 Blob 이름)의 시작 부분에 가장 가까운 해시 태그 접두사를 사용하여 목록, 목록, 쿼리 및 읽기 작업의 대기 시간을 줄입니다. 이 체계는 대부분 플랫 네임스페이스가 있는 계정에 혜택을 줍니다.

  • 데이터 클라이언트의 성능 최적화: 워크로드의 데이터 크기, 전송 빈도 및 대역폭에 가장 적합한 데이터 전송 도구를 선택합니다. AzCopy와 같은 일부 도구는 성능에 최적화되어 있으며 개입이 거의 필요하지 않습니다. 대기 시간에 영향을 주는 요인을 고려하고 각 도구와 함께 게시된 성능 최적화 지침을 검토하여 성능을 미세 조정합니다.

  • 사용자 지정 코드의 성능 최적화: Blob REST 작업에 대한 자체 래퍼를 만드는 대신 Storage SDK를 사용하는 것이 좋습니다. Azure SDK는 성능에 최적화되어 있으며 성능을 미세 조정하는 메커니즘을 제공합니다. 애플리케이션을 만들기 전에 Blob Storage에 대한 성능 및 확장성 검사 목록을 검토합니다. 쿼리 가속을 사용하여 스토리지 요청 중에 원치 않는 데이터를 필터링하고 클라이언트가 불필요하게 네트워크를 통해 데이터를 전송하지 않도록 하는 것이 좋습니다.

  • 성능 데이터 수집: 스토리지 계정을 모니터링하여 제한으로 인한 성능 병목 상태를 식별합니다. 자세한 내용은 Monitor Storage 인사이트를 사용하여 스토리지 서비스 모니터링을 참조하세요. 메트릭과 로그를 모두 사용합니다. 메트릭은 제한 오류와 같은 숫자를 제공합니다. 로그는 활동을 설명합니다. 제한 메트릭이 표시되면 로그를 사용하여 제한 오류를 수신하는 클라이언트를 ID로 지정할 수 있습니다. 자세한 내용은 데이터 평면 감사 작업을 참조 하세요.

권장 사항

추천 장점
종속 리소스가 배치되는 동일한 지역에 스토리지 계정을 프로비전합니다. 모바일 디바이스 앱 또는 온-프레미스 엔터프라이즈 서비스와 같이 Azure에서 호스트되지 않는 애플리케이션의 경우 해당 클라이언트에 가까운 지역에서 스토리지 계정을 찾습니다. 자세한 내용은 Azure 지역을 참조하세요.

다른 지역의 클라이언트에 동일한 데이터가 필요하지 않은 경우 각 지역에 별도의 계정을 만듭니다.

다른 지역의 클라이언트에 일부 데이터만 필요한 경우 개체 복제본(replica)tion 정책을 사용하여 관련 개체를 다른 지역의 스토리지 계정에 비동기적으로 복사하는 것이 좋습니다.		 스토리지 계정과 VM, 서비스 및 온-프레미스 클라이언트 간의 물리적 거리를 줄이면 성능을 향상시키고 네트워크 대기 시간을 줄일 수 있습니다. 또한 물리적 거리를 줄이면 단일 지역 내의 대역폭 사용량이 무료이므로 Azure에서 호스트되는 애플리케이션의 비용도 줄어듭니다.
웹 클라이언트(스트리밍 비디오, 오디오 또는 정적 웹 사이트 콘텐츠)에서 광범위하게 사용하려면 Azure Front Door를 통해 콘텐츠 배달 네트워크를 사용하는 것이 좋습니다. 콘텐츠는 전 세계에 수백 개의 글로벌 및 로컬 지점이 있는 Microsoft 글로벌 에지 네트워크를 사용하기 때문에 클라이언트에 더 빠르게 전달됩니다.
Blob의 파티션 키에서 가능한 한 빨리 해시 문자 시퀀스(예: 세 자리)를 추가합니다. 파티션 키는 계정 이름, 컨테이너 이름, 가상 디렉터리 이름 및 Blob 이름입니다. 이름에 타임스탬프를 사용하려는 경우 해당 스탬프의 시작 부분에 초 값을 추가하는 것이 좋습니다. 자세한 내용은 분할을 참조 하세요. 파티션 키의 시작 부분에 가장 가까운 해시 코드 또는 초 값을 사용하면 쿼리를 나열하고 Blob을 읽는 데 필요한 시간이 줄어듭니다.
Blob 또는 블록을 업로드할 때 256KiB보다 큰 Blob 또는 블록 크기를 사용합니다. 256KiB를 초과하는 Blob 또는 블록 크기는 더 큰 Blob 및 블록 크기를 위해 특별히 만들어진 플랫폼의 성능 향상을 활용합니다.

Azure 정책

Azure는 Blob Storage 및 해당 종속성과 관련된 광범위한 기본 제공 정책 집합을 제공합니다. 이전 권장 사항 중 일부는 Azure 정책을 통해 감사할 수 있습니다. 예를 들어 다음과 같은 경우 검사 수 있습니다.

  • 컨테이너 및 Blob에 대한 익명 공용 읽기 액세스는 사용하도록 설정되지 않습니다.
  • Blob Storage에 대한 진단 설정은 리소스 로그를 Azure Monitor 로그 작업 영역으로 스트리밍하도록 설정됩니다.
  • HTTPS(보안 연결)의 요청만 수락됩니다.
  • 공유 액세스 서명 만료 정책을 사용할 수 있습니다.
  • 교차 테넌트 개체 복제본(replica)tion을 사용할 수 없습니다.
  • 공유 키 권한 부여를 사용할 수 없습니다.
  • 네트워크 방화벽 규칙이 계정에 적용됩니다.

포괄적인 거버넌스를 위해 스토리지 및 컴퓨팅 계층의 보안에 영향을 줄 수 있는 기타 정책에 대한 Azure Policy 기본 제공 정의를 검토합니다.

Azure Advisor 권장 사항

Azure Advisor 는 Azure 배포를 최적화하기 위한 모범 사례를 따르는 데 도움이 되는 개인 설정된 클라우드 컨설턴트입니다. 다음은 Blob Storage의 안정성, 보안, 비용 효율성, 성능 및 운영 우수성을 개선하는 데 도움이 되는 몇 가지 권장 사항입니다.

다음 단계

Blob Storage에 대한 자세한 내용은 Blob Storage 설명서를 참조 하세요.