Azure Blob Storage 관련 질문과 대답

플랫폼은 하루에 한 번 수명 주기 정책을 실행합니다. 정책을 구성한 후에는 정책을 적용하는 데 최대 24시간이 걸릴 수 있습니다. 정책이 적용되면 작업 실행에 소요되는 시간은 스토리지 계정의 크기 및 수행된 작업에 따라 달라질 수 있습니다.

업데이트된 정책은 적용되는 데 최대 24시간이 걸립니다. 정책이 적용되면 작업이 실행되는 데 걸리는 시간은 수행되는 스토리지 계정 및 작업의 크기에 따라 달라집니다. 업데이트 시 규칙을 사용하지 않거나 삭제하도록 하고 enableAutoTierToHotFromCool을 사용했으면 핫 계층으로 자동 계층화가 계속 발생합니다. 예를 들어 마지막 액세스를 기준으로 enableAutoTierToHotFromCool이 포함된 규칙을 설정합니다. 규칙이 사용되지 않거나 삭제되고 Blob이 현재 쿨 또는 콜드 계층에서 액세스되면 수명 주기 관리 외부에 액세스할 때 적용되므로 다시 핫 계층으로 이동합니다. 수명 주기 관리 규칙이 사용되지 않거나 삭제되면 Blob이 핫에서 쿨 또는 콜드로 이동하지 않습니다. autoTierToHotFromCool을 방지하는 유일한 방법은 마지막 액세스 시간 추적을 끄는 것입니다.

스토리지 계정에 있는 개체의 크기와 수에 따라 모든 개체를 처리하려면 둘 이상의 실행이 필요할 수 있습니다. 스토리지 리소스 로그를 검사 수명 주기 관리 정책에 의해 작업이 수행되고 있는지 확인할 수도 있습니다.

스토리지 계정에서 일시 삭제 또는 버전 관리와 같은 데이터 보호 기능을 사용할 수 있는지 확인합니다. 정책이 Blob을 삭제하는 경우에도 이러한 Blob은 이러한 기능이 구성된 방법에 따라 일시 삭제된 상태 또는 이전 버전으로 여전히 존재할 수 있습니다.

스토리지 계정에 적용되는 수명 주기 관리 정책이 있는 경우 계층을 변경하여 Blob을 리하이드레이션하면 수명 주기 정책에서 해당 Blob을 보관 계층으로 다시 이동하는 시나리오가 발생할 수 있습니다. 이는 마지막으로 수정한 시간, 만든 시간 또는 마지막 액세스 시간이 정책에 설정된 임계값을 초과하는 경우에 발생할 수 있습니다. 이 문제가 발생하지 않도록 하는 세 가지 방법이 있습니다.

• daysAfterLastTierChangeGreaterThan 조건을 정책의 tierToArchive 작업에 추가합니다. 수명 주기 관리 정책을 사용하여 Blob 보관을 참조하세요.

• 이 Blob에 영향을 주는 규칙을 일시적으로 사용하지 않게 설정하여 다시 보관되지 않도록 합니다 Blob을 다시 보관 계층으로 안전하게 이동할 수 있는 경우 규칙을 다시 사용하도록 설정합니다.

• Blob이 핫, 쿨 또는 콜드 계층에 영구적으로 유지되어야 하는 경우 수명 주기 관리 정책이 적용되지 않는 다른 위치에 Blob을 복사합니다.

정책의 Blob 접두사 일치 필드는 정책 작업을 적용하려는 Blob을 일치시키는 데 사용되는 전체 또는 부분 Blob 경로입니다. 경로는 컨테이너 이름으로 시작해야 합니다. 접두사 일치가 지정되지 않은 경우 정책은 스토리지 계정의 모든 Blob에 적용됩니다. 접두사 일치 문자열의 형식은 [container name]/[blob name]입니다.
접두사 일치 문자열에 대해 다음 사항에 유의합니다.

• container1/과 같은 접두사 일치 문자열은 container1이라는 컨테이너의 모든 Blob에 적용됩니다. 후행 슬래시 문자(/)가 없는 container1의 접두어 일치 문자열은 컨테이너 이름이 문자열 container1로 시작하는 모든 컨테이너의 모든 Blob에 적용됩니다. 접두사는 이름이 container11, container1234, container1ab 등인 컨테이너와 일치합니다.
• container1/sub1/의 접두사 일치 문자열은 sub1/ 문자열로 시작하는 container1이라는 컨테이너의 모든 Blob에 적용됩니다. 예를 들어 접두사는 container1/sub1/test.txt 또는 container1/sub1/sub2/test.txt라는 이름의 Blob과 일치합니다.
• 별표 문자 *는 Blob 이름의 유효한 문자입니다. 별표 문자가 접두사에 사용되는 경우 접두사는 이름에 별표가 있는 Blob과 일치합니다. 별표는 와일드카드 문자로 작동하지 않습니다.
• 물음표 문자 ?는 Blob 이름의 유효한 문자입니다. 물음표 문자가 접두사에 사용되는 경우 접두사는 이름에 물음표가 있는 Blob과 일치합니다. 물음표는 와일드카드 문자로 작동하지 않습니다.
• 접두사 일치는 양수(=) 논리 비교만 고려합니다. 음수(!=) 논리 비교는 무시됩니다.
• 접두사 일치는 대/소문자를 구분하여 작동합니다.

불행히도 정책이 실행되는 시간을 추적할 수 있는 방법은 없습니다. 이는 백그라운드 스케줄링 프로세스이기 때문입니다. 그러나 플랫폼은 하루에 한 번 정책을 실행합니다.

일일 인벤토리 규칙은 매일 한 번 실행되도록 설계되었습니다. 또한 매주 일요일에는 주별 인벤토리 규칙이 예약되어 있습니다.

일관된 환경을 제공하기 위해 노력하지만 각 실행에 대한 정확한 실행 시간을 보장할 수는 없습니다. 인벤토리 규칙의 실행 시간은 다를 수 있습니다. 예를 들어 오늘 정책이 오전 12시 05분으로 예약된 경우 오전 12:07, 오전 12시 15분 또는 다음 날 다른 시간에 시작될 수 있습니다.

Blob 인벤토리 보고서는 세 가지 유형의 파일을 생성합니다. 인벤토리 파일을 참조하세요. Blob 인벤토리를 사용하는 기존 고객은 한 파일에서 여러 파일로 인벤토리 파일 수가 변경될 수 있습니다. 현재 우리는 이미 파일 목록을 제공하는 매니페스트 파일을 가지고 있습니다. 이 동작은 변경되지 않은 상태로 유지되므로 이러한 파일은 매니페스트 파일에 나열됩니다.

이 변경은 특히 500만 개 이상의 개체를 포함하는 대형 스토리지 계정의 경우 Blob 인벤토리 성능을 향상시키기 위해 구현되었습니다. 이제 결과가 여러 파일에 병렬로 작성되어 단일 인벤토리 파일을 사용하는 병목 현상이 제거됩니다. 이러한 변경은 지나치게 큰 단일 인벤토리 파일을 열고 작업하는 데 어려움을 보고했기 때문에 고객 피드백에 의해 촉발되었습니다.

사용자로서 이러한 변경은 Blob 인벤토리 실행 환경에 긍정적인 영향을 줍니다. 성능을 향상시키고 전체 실행 시간을 줄일 것으로 예상됩니다. 그러나 이러한 개선의 이점을 완전히 활용하려면 코드가 하나만이 아닌 여러 결과 파일을 처리하도록 업데이트되었는지 확인해야 합니다. 이 조정은 코드를 새로운 접근 방식에 맞게 조정하고 인벤토리 데이터 처리를 최적화합니다.

아니요, 기존 데이터는 영향을 받지 않습니다. 새 Blob 인벤토리 결과에만 여러 인벤토리 파일이 있습니다.

아니요, 변경은 원활하게 수행됩니다.

필요한 작업은 현재 Blob 인벤토리 결과를 처리하는 방법에 따라 달라집니다.

• 현재 처리에서 단일 인벤토리 결과 파일을 가정하는 경우 여러 인벤토리 결과 파일을 수용하도록 코드를 수정해야 합니다.

• 그러나 현재 처리에 매니페스트 파일에서 결과 파일 목록을 읽는 작업이 포함된 경우 결과를 처리하는 방법을 변경할 필요가 없습니다. 기존 접근 방식은 업데이트된 기능에서 계속 원활하게 작동합니다.

권장되지는 않지만 가능합니다. 지원 채널을 통해 이 기능을 해제하도록 요청하세요.

현재 계정 팀과 지원 채널을 통해 작업하세요.

이 변경은 2023년 9월 1일부터 점진적 출시를 시작합니다.

아니요. Azure Compute는 디스크에 대한 메트릭을 지원합니다. 자세한 내용은 관리형 디스크와 비관리형 디스크의 디스크당 메트릭을 참조하세요.

가용성 및 대기 시간 데이터를 표시하는 차트와 같은 일부 Azure 메트릭 차트는 파선을 사용하여 알려진 두 시간 조직 데이터 요소 사이에 누락된 값(null 값이라고도 함)이 있음을 나타냅니다. 예를 들어 시간 선택기에서 1 minute 시간 세분성을 선택했지만 메트릭이 07:26, 07:27, 07:29 및 07:30에 보고된 경우 두 데이터 요소 사이에 분 간격이 있기 때문에 파선은 07:27 및 07:29를 연결합니다. 실선은 다른 모든 데이터 요소를 연결합니다. 메트릭에서 개수와 집계를 사용하면 파선은 0으로 감소합니다. 평균, 최소 또는 최대 집계의 경우 파선은 가장 가까운 알려진 두 개의 데이터 요소를 연결합니다. 또한 차트의 맨 오른쪽 또는 맨 왼쪽에서 데이터가 누락된 경우 파선은 데이터 요소가 누락된 방향으로 확장합니다.

Azure Resource Health 서비스를 기반으로 리소스 상태 경고를 구성하여 스토리지 계정의 가용성을 추적할 수 있습니다. 계정에 트랜잭션이 없는 경우 경고는 스토리지 계정이 있는 Storage 클러스터의 상태를 기반으로 보고합니다.

분석 로그에는 모든 작업에서 성공한 요청 및 실패한 요청을 포함하여 모든 읽기, 쓰기, 나열 및 삭제 작업에 대한 레코드가 있습니다. 분석 로그는 최선의 작업이며 순서가 보장되지 않습니다.

변경 피드는 Blob 생성, 수정 및 삭제와 같은 성공적인 변형 또는 계정 변경에 대한 트랜잭션 로그를 제공하는 솔루션입니다. 변경 피드는 모든 이벤트가 Blob당 성공적인 변경 순서로 기록되고 표시되도록 보장하므로 대량의 읽기 작업이나 실패한 요청에서 노이즈를 필터링할 필요가 없습니다. 변경 피드는 특정 보장이 필요한 애플리케이션 개발을 위해 기본적으로 설계되고 최적화되었습니다.

변경 피드로 두 기능을 모두 활용할 수 있으며 Blob Storage 이벤트는 동일한 전달 안정성을 보장하여 동일한 정보를 제공하며 주요 차이점은 이벤트 레코드의 지연, 순서 지정 및 스토리지입니다. 변경 피드는 변경 후 몇 분 이내에 로그에 레코드를 게시하고 Blob당 변경 작업 순서도 보장합니다. 스토리지 이벤트는 실시간으로 푸시되며, 순서가 지정되지 않을 수 있습니다. 변경 피드 이벤트는 사용자가 직접 정의한 보존 기간이 있는 안정적인 읽기 전용 로그로 스토리지 계정 내에 지속적으로 저장되지만, 스토리지 이벤트는 명시적으로 저장하지 않는 한 이벤트 처리기에서 일시적으로 사용됩니다. 변경 피드를 사용하면 여러 애플리케이션에서 Blob API 또는 SDK를 사용하여 로그를 자체의 편리한 방식으로 사용할 수 있습니다.

예. IP 기반 및 VNET 방화벽을 포함한 스토리지 계정 네트워크 보안 규칙은 정적 웹 사이트 엔드포인트에 대해 지원되며 웹 사이트를 보호하는 데 사용될 수 있습니다.

아니요. 정적 웹 사이트는 $web 컨테이너의 파일에 대한 익명 퍼블릭 읽기 권한만 지원합니다.

Azure CDN(Azure Content Delivery Network)을 사용하여 정적 웹 사이트로 사용자 지정 도메인을 구성할 수 있습니다. Azure CDN은 전 세계 어디에서나 웹 사이트에 대해 일관되게 낮은 대기 시간을 제공합니다.

Azure CDN을 사용하여 정적 웹 사이트에서 사용자 지정 SSL 인증서를 구성할 수 있습니다. Azure CDN은 전 세계 어디에서나 웹 사이트에 대해 일관되게 낮은 대기 시간을 제공합니다.

Azure CDN - Verizon Premium을 사용하여 정적 웹 사이트의 호스트 헤더를 구성할 수 있습니다. 여기에서 의견을 보내 주시기 바랍니다.

잘못된 대소문자를 사용하여 파일 이름을 참조하는 경우 404 오류가 발생할 수 있습니다. 예를 들어 index.html가 아닌 Index.html입니다. 정적 웹 사이트의 URL에서 파일 이름과 확장명은 HTTP를 통해 제공되더라도 대/소문자를 구분합니다. Azure CDN 엔드포인트가 아직 프로비저닝되지 않은 경우에도 발생할 수 있습니다. 전파가 완료될 때까지 새 Azure CDN을 프로비저닝한 후 최대 90분 동안 기다립니다.

Azure Portal에서 계정의 정적 웹 사이트 구성 페이지를 열고 인덱스 문서 이름 필드에 설정된 이름과 확장명을 찾습니다. 이 이름이 스토리지 계정의 $web 컨테이너에 있는 파일 이름과 똑같은지 확인합니다. 정적 웹 사이트의 URL에서 파일 이름과 확장명은 HTTP를 통해 제공되더라도 대/소문자를 구분합니다.

아니요, Blob 데이터 내에서 검색해야 하는 경우에는 쿼리 가속 또는 Azure Search를 사용하세요.

Blob 인덱스 태그는 문자열 데이터 형식만 지원하고 쿼리는 사전순으로 결과를 반환합니다. 숫자의 경우 숫자 앞에 영(0)을 추가합니다. 날짜 및 시간의 경우 ISO 8601 호환 형식으로 저장합니다.

아니요, Resource Manager 태그는 구독, 리소스 그룹 및 스토리지 계정 등의 컨트롤 플레인 리소스를 구성하는 데 도움이 됩니다. 인덱스 태그는 데이터 평면에서 Blob 관리 및 검색을 제공합니다.

Storage 용량은 한 달 동안 저장된 일일 평균 데이터 양(GB)을 단위로 요금이 청구됩니다. 예를 들어 한 달 동안 처음 15일은 꾸준히 10GB의 스토리지를 사용하고 나머지 15일은 스토리지를 사용하지 않은 경우 5GB의 스토리지 평균 사용량에 대해 요금이 청구됩니다.

다음 단계

Azure Blob Storage에 대한 자세한 내용은 다음 링크를 참조하세요.

• Azure Storage 소개
• Azure Blob Storage란