다음을 통해 공유

보관 계층에서 Blob 리하이드레이션

  • 아티클

Blob이 보관 액세스 계층에 있는 동안 해당 Blob은 오프라인 상태인 것으로 간주되며 읽거나 수정할 수 없습니다. 보관된 Blob의 데이터를 읽거나 수정하려면 먼저 Blob을 온라인 계층(핫 또는 쿨 계층)으로 리하이드레이션해야 합니다. 보관 계층에 저장된 Blob을 리하이드레이션하는 옵션에는 다음 두 가지가 있습니다.

보관 계층에서 blob을 리하이드레이션하는 데 몇 시간이 걸릴 수 있습니다. Microsoft는 리하이드레이션 시 최적의 성능을 위해 더 큰 Blob을 보관할 것을 권장합니다. 많은 수의 작은 Blob을 리하이드레이션하려면 각 Blob의 처리 오버헤드로 인해 추가 시간이 필요할 수 있습니다. 스토리지 계정당 최대 10 GiB를 우선 순위 검색으로 시간당 리하이드레이션할 수 있습니다.

보관된 Blob을 온라인 계층으로 리하이드레이션하는 방법을 알아보려면 보관된 Blob을 온라인 계층으로 리하이드레이션을 참조하세요.

리하이드레이션 우선 순위

Blob을 리하이드레이션하는 경우 Blob 계층 설정 또는 Blob 복사 작업에서 선택적 x-ms-rehydrate-priority 헤더를 통해 리하이드레이션 작업의 우선 순위를 설정할 수 있습니다. 리하이드레이션 우선 순위 옵션은 다음과 같습니다.

  • 표준 우선 순위: 리하이드레이션 요청이 수신된 순서대로 처리되며 크기가 10GB 미만인 개체의 경우 완료하는 데 최대 15시간이 걸릴 수 있습니다.
  • 높은 우선 순위: 리하이드레이션 요청이 표준 우선 순위 요청보다 우선되며 크기가 10GB 미만인 개체의 경우 1시간 이내에 완료될 수 있습니다.

리하이드레이션 작업이 진행되는 동안 리하이드레이션 우선 순위를 확인하려면 Blob 속성 가져오기를 호출하여 x-ms-rehydrate-priority 헤더의 값을 반환합니다. 리하이드레이션 우션 순위 속성은 ‘표준’ 또는 ‘높음’ 중 하나를 반환합니다.

표준 우선 순위는 기본 리하이드레이션 옵션입니다. 우선 순위가 높은 리하이드레이션이 더 빠르지만 표준 우선 순위 리하이드레이션보다 비용이 많이 듭니다. 우선 순위가 높은 리하이드레이션은 Blob 크기와 현재 수요에 따라 1시간 이상 걸릴 수 있습니다. 응급 데이터 복원 상황에서 사용할 수 있게 우선 순위가 높은 리하이드레이션을 예약하는 것이 좋습니다.

표준 우선 순위 리하이드레이션 작업이 보류 중인 동안 Blob에 대한 리하이드레이션 우선 순위 설정을 높음으로 업데이트하여 해당 Blob을 더 빠르게 리하이드레이션할 수 있습니다. 예를 들어 많은 수의 Blob을 대량으로 리하이드레이션하는 경우 초기 작업을 위해 모든 Blob에 대해 표준 우선 순위를 지정한 다음, 시간당 최대 10GiB의 제한까지 더 빠르게 온라인으로 가져와야 하는 개별 Blob에 대해 우선 순위를 높음으로 높일 수 있습니다.

보류 중인 작업에 대한 리하이드레이션 우선 순위 설정은 높음에서 표준으로 낮출 수 없습니다. 리하이드레이션 우선 순위 설정을 업데이트하면 청구에 영향을 줄 수 있습니다.

리하이드레이션 우선 순위 설정을 설정하고 업데이트하는 방법에 대한 자세한 내용은 보관된 Blob을 온라인 계층으로 리하이드레이션을 참조하세요.

표준 우선 순위 및 높은 우선 순위 리하이드레이션 요청 간 가격 차이에 대한 자세한 내용은 Azure Blob Storage 가격 책정을 참조하세요.

보관된 Blob을 온라인 계층으로 복사

Blob을 보관 계층에서 온라인 계층으로 이동하는 첫 번째 방법은 보관된 Blob을 핫, 쿨 또는 콜드 계층에 있는 새 대상 Blob에 복사하는 것입니다. Blob 복사 작업을 사용하여 Blob을 복사할 수 있습니다. 보관된 Blob을 온라인 계층의 새 Blob으로 복사할 경우 원본 Blob은 보관 계층에서 수정되지 않은 상태로 유지됩니다.

보관된 Blob을 다른 이름의 새 Blob이나 다른 컨테이너로 복사해야 합니다. 동일한 Blob으로 복사하여 원본 Blob을 덮어쓸 수 없습니다.

보관 계층에서 온라인 계층으로 Blob을 복사하면 필수 180일 기간이 경과하기 전에 보관 계층에서 Blob 계층을 변경하는 경우 부과되는 조기 삭제 요금을 피할 수 있습니다. 자세한 내용은 보관 액세스 계층을 참조하세요.

이 방법은 스토리지 계정에 적용되는 수명 주기 관리 정책이 있고 daysAfterLastTierChangeGreaterThan 조건이 정책의 각 tierToArchive 작업에 추가되지 않은 경우에도 사용할 수 있습니다. 이 경우 Blob 계층 설정 작업을 사용하여 Blob을 리하이드레이션하면 마지막 수정 시간이 정책에 대해 설정된 임계값을 초과하므로 수명 주기 정책이 리하이드레이션 후에 Blob을 보관 계층으로 다시 옮기는 시나리오가 발생할 수 있습니다. 복사 작업을 수행하면 원본 Blob이 보관 계층에 유지되고 다른 이름 및 마지막 수정 시간을 사용하여 새 Blob이 만들어지므로 리하이드레이션된 Blob이 수명 주기 정책에 따라 다시 보관 계층으로 이동될 위험이 없습니다.

보관 계층에서 Blob을 복사하는 작업은 선택된 리하이드레이션 우선 순위에 따라 완료하는 데 몇 시간이 걸릴 수 있습니다. 백그라운드에서 Blob 복사 작업은 보관된 원본 Blob을 읽어서 선택한 대상 계층에 새 온라인 Blob을 만듭니다. 리하이드레이션 작업이 완료되기 전에 부모 컨테이너의 Blob을 나열하면 새 Blob이 표시될 수도 있지만 해당 계층은 보관으로 설정됩니다. 보관 계층의 원본 Blob에서 읽기 작업이 완료되고 Blob의 콘텐츠가 온라인 계층의 새 대상 Blob에 기록되기 전에는 데이터를 사용할 수 없습니다. 새 Blob은 독립 복사본이므로 수정하거나 삭제해도 보관 계층의 원본 Blob에는 영향을 주지 않습니다.

Blob을 온라인 계층으로 복사하여 리하이드레이션하는 방법에 대해 알아보려면 복사 작업을 사용하여 Blob 리하이드레이션을 참조하세요.

Important

리하이드레이션이 완료될 때까지 원본 Blob을 삭제하지 마세요. 원본 Blob이 삭제된 경우 대상 Blob은 복사를 완료하지 못할 수 있습니다. 복사 작업이 완료되면 발생하는 이벤트를 처리하여 원본 Blob을 삭제해도 안전한 시기를 알 수 있습니다. 자세한 내용은 Blob 리하이드레이션에서 이벤트 처리를 참조하세요.

보관된 Blob을 온라인 대상 계층에 복사하여 리하이드레이션하는 기능은 2021-02-12 이전의 서비스 버전에 대해서만 동일한 스토리지 계정 내에서 지원됩니다. 서비스 버전 2021-02-12부터는 대상 계정이 원본 계정과 동일한 지역에 있는 한 보관된 Blob을 다른 스토리지 계정에 복사하여 리하이드레이션할 수 있습니다. 스토리지 계정 간에 리하이드레이션을 사용하면 프로덕션 데이터를 별도의 계정에 유지 관리하여 백업 데이터와 분리할 수 있습니다. 보관된 데이터를 별도의 계정에 격리하면 의도하지 않은 리하이드레이션으로 인한 비용을 줄이는 데도 도움이 될 수 있습니다.

복사 작업의 대상 Blob은 온라인 계층(핫 또는 쿨)에 있어야 합니다. 보관된 Blob을 보관 계층에도 있는 대상 Blob에 복사할 수 없습니다.

다음 표에서는 원본 및 대상 Blob의 계층에 따른 Blob 복사 작업의 동작을 보여 줍니다.

핫 계층 원본 쿨 계층 원본 보관 계층 원본
핫 계층 대상 지원됨 지원됨 2021-02-12 이상 버전에서 동일한 지역의 계정에서 지원됩니다. 이전 버전에 대해서만 동일한 스토리지 계정 내에서 지원됩니다. Blob 리하이드레이션 필요합니다.
쿨 계층 대상 지원됨 지원됨 2021-02-12 이상 버전에서 동일한 지역의 계정에서 지원됩니다. 이전 버전에 대해서만 동일한 스토리지 계정 내에서 지원됩니다. Blob 리하이드레이션 필요합니다.
보관 계층 대상 지원됨 지원됨 지원되지 않음

보조 지역에서 리하이드레이션

RA-GRS(읽기 액세스 지역 중복 스토리지)를 사용하도록 스토리지 계정을 구성한 경우 Blob 복사 작업을 사용하여 보조 지역의 Blob을 동일한 보조 지역에 있는 다른 스토리지 계정으로 리하이드레이션할 수 있습니다. 보조 지역에서 리하이드레이션을 참조하세요.

보조 지역에 대한 읽기 액세스 권한을 얻는 방법에 대한 자세한 내용은 보조 지역의 데이터에 대한 읽기 액세스 권한을 참조하세요.

Blob의 액세스 계층을 온라인 계층으로 변경

보관 계층에서 온라인 계층으로 Blob을 리하이드레이션하는 두 번째 옵션은 Blob 계층 설정을 호출하여 Blob의 계층을 변경하는 것입니다. 이 작업을 사용하면 보관된 Blob의 계층을 핫 또는 쿨 계층 중 하나로 변경할 수 있습니다.

Blob 계층 설정 요청이 시작되면 취소할 수 없습니다. 리하이드레이션 작업을 수행하는 동안 Blob의 액세스 계층 설정은 리하이드레이션 프로세스가 완료될 때까지 보관된 상태로 계속 표시됩니다. 리하이드레이션 작업이 완료되면 Blob의 액세스 계층 속성이 새 계층을 반영하도록 업데이트됩니다.

계층을 온라인 계층으로 변경하여 Blob을 리하이드레이션하는 방법을 알아보려면 계층을 변경하여 Blob 리하이드레이션을 참조하세요.

주의

Blob의 계층 변경은 마지막 수정 시간에 영향을 주지 않습니다. 스토리지 계정에 적용되는 수명 주기 관리 정책이 있는 경우 Blob 계층 설정을 사용하여 Blob을 리하이드레이션하면 마지막 수정 시간이 정책에 대해 설정된 임계값을 초과하므로 수명 주기 정책이 리하이드레이션 후에 Blob을 보관 계층으로 다시 이동하는 시나리오가 발생할 수 있습니다.

이 시나리오를 방지하려면 정책의 tierToArchive 작업에 daysAfterLastTierChangeGreaterThan 조건을 추가합니다. 또는 보관된 Blob을 온라인 계층에 복사 섹션에 설명된 대로 복사하여 보관된 Blob을 리하이드레이션합니다. 복사 작업을 수행하면 업데이트된 마지막 수정 시간으로 Blob의 새 인스턴스가 만들어지므로 수명 주기 관리 정책이 트리거되지 않습니다.

Blob 리하이드레이션 작업의 상태 확인

Blob 리하이드레이션 작업을 수행하는 동안 Blob 속성 가져오기 작업을 호출하여 상태를 확인할 수 있습니다. 리하이드레이션 작업의 상태를 확인하는 방법을 알아보려면 리하이드레이션 작업의 상태 확인을 참조하세요.

Blob 리하이드레이션에 대한 이벤트 처리

보관된 Blob의 리하이드레이션에는 최대 15시간이 걸릴 수 있으며, Blob 속성 가져오기를 반복적으로 폴링하여 리하이드레이션이 완료되었는지 여부를 확인하는 것은 비효율적입니다. Microsoft는 Azure Event Grid를 사용하여 성능과 비용 최적화 향상을 위해 리하이드레이션이 완료될 때 발생하는 이벤트를 캡처하는 것을 권장합니다.

Azure Event Grid는 BLOB 리하이드레이션 완료 시 Microsoft.Storage.BlobTierChanged 이벤트를 발생합니다.

  • Microsoft.Storage.BlobTierChanged 이벤트는 Blob 계층이 변경될 때 발생합니다. Blob의 리하이드레이션 상황에서 이 이벤트는 대상 Blob의 액세스 계층이 보관 계층에서 온라인 계층(핫, 쿨 또는 콜드 계층)으로 성공적으로 변경될 때 발생합니다. Blob 계층 설정 작업을 사용하여 보관된 Blob의 액세스 계층을 변경하거나 Blob 복사 작업을 사용하여 보관된 Blob을 온라인 계층의 새 대상 Blob에 복사할 수 있습니다.

리하이드레이션에서 이벤트를 캡처하고 Azure 함수 이벤트 처리기로 보내는 방법을 알아보려면 Blob 리하이드레이션 이벤트에 대한 응답으로 Azure 함수 실행을 참조하세요.

Blob Storage에서 이벤트를 처리하는 방법에 대한 자세한 내용은 Azure Blob Storage 이벤트에 대응 및 Event Grid 원본으로서의 Azure Blob Storage를 참조하세요.

가격 책정 및 대금 청구

Blob 계층 설정을 사용한 리하이드레이션 작업은 데이터 읽기 트랜잭션과 데이터 검색 크기에 따라 요금이 청구됩니다. 높은 우선 순위 리하이드레이션를 사용하는 경우 표준 우선 순위보다 작업 및 데이터 검색 비용이 더 높습니다. 높은 우선 순위 리하이드레이션은 청구서에 별도의 항목으로 표시됩니다. 10GB 크기 미만의 보관 Blob을 반환하는 높은 우선 순위 요청이 5시간 이상 걸리는 경우 높은 우선 순위 검색 요금이 부과되지는 않습니다. 그렇지만 표준 검색 요금이 계속 적용됩니다.

Blob 복사를 사용하여 보관된 Blob을 온라인 계층으로 복사하면 데이터 읽기 트랜잭션과 데이터 검색 크기에 따라 요금이 청구됩니다. 온라인 계층에서 대상 Blob을 만드는 경우 데이터 쓰기 트랜잭션에 대해 요금이 청구됩니다. 원본 Blob이 보관 계층에서 수정되지 않은 상태로 유지되기 때문에 온라인 Blob에 복사하는 경우 조기 삭제 요금은 적용되지 않습니다. 선택한 경우 높은 우선 순위 검색 요금은 적용됩니다.

보관 계층의 Blob은 최소 180일 동안 저장해야 합니다. 180일이 경과하기 전에 보관된 Blob의 계층을 삭제하거나 변경하면 초기 삭제 요금이 발생합니다. 예를 들어 Blob이 보관 계층으로 이동된 다음, 45일이 지나서 삭제되거나 핫 계층으로 이동되는 경우 보관 계층에 해당 Blob을 저장한 135일(180-45)에 해당하는 조기 삭제 요금이 청구됩니다. 자세한 내용은 보관 액세스 계층을 참조하세요.

블록 Blob 및 데이터 리하이드레이션 가격 책정에 대한 자세한 내용은 Azure Storage 가격 책정을 참조하세요. 아웃바운드 데이터 전송 요금에 대한 자세한 내용은 데이터 전송 가격 책정 정보를 참조하세요.

참고 항목