Blob 보관
보관 계층은 거의 액세스하지 않는 Blob 데이터를 저장하기 위한 오프라인 계층입니다. 보관 계층은 스토리지 비용이 가장 낮지만 온라인 계층(핫 및 쿨)에 비해 데이터 검색 비용과 대기 시간이 더 높습니다. 데이터는 최소 180일 동안 보관 계층에 남아 있어야 합니다. 그렇지 않으면 초기 삭제 요금이 부과됩니다. 보관 계층에 대한 자세한 내용은 보관 액세스 계층을 참조하세요.
Blob이 보관 계층에 있는 동안에는 읽거나 수정할 수 없습니다. 보관 계층에서 Blob을 읽거나 다운로드하려면 먼저 온라인 계층(핫 또는 쿨)으로 리하이드레이션해야 합니다. 보관 계층의 데이터는 리하이드레이션 작업에 대해 지정한 우선 순위에 따라 리하이드레이션하는 데 최대 15시간이 걸릴 수 있습니다. Blob 리하이드레이션에 대한 자세한 내용은 보관 계층에서 Blob 리하이드레이션 개요를 참조하세요.
주의
보관 계층의 Blob은 오프라인 상태입니다. 즉, 리하이드레이션될 때까지 읽거나 수정할 수 없습니다. 리하이드레이션 과정은 몇 시간이 걸릴 수 있으며 관련 비용이 있습니다. 데이터를 보관 계층으로 이동하기 전에 Blob 데이터를 오프라인으로 전환하면 워크플로에 영향을 미칠 수 있는지 여부를 고려합니다.
Azure Portal, PowerShell, Azure CLI 또는 Azure Storage 클라이언트 라이브러리 중 하나를 사용하여 데이터 보관을 관리할 수 있습니다.
업로드 시 Blob 보관
업로드 시 하나 이상의 Blob을 보관하려면 보관 계층에서 직접 Blob을 만듭니다.
Azure Portal에서 업로드할 때 Blob 또는 Blob 집합을 보관하려면 다음 단계를 따르세요.
대상 컨테이너로 이동합니다.
업로드 버튼을 선택합니다.
업로드할 파일을 선택합니다.
고급 섹션을 확장하고 액세스 계층을 보관으로 설정합니다.
업로드 버튼을 선택합니다.
기존 Blob 보관
다음 두 가지 방법 중 하나로 기존 Blob을 보관 계층으로 이동할 수 있습니다.
Blob 계층 설정 작업으로 Blob의 계층을 변경할 수 있습니다. Blob 계층 설정은 단일 Blob을 한 계층에서 다른 계층으로 이동합니다.
Blob 계층 설정을 사용하여 Blob을 보관 계층으로 이동하면 Blob을 다시 리하이드레이션할 때까지 Blob의 데이터를 읽거나 수정할 수 없습니다. 조기 삭제 간격이 경과하기 전에 Blob의 데이터를 읽거나 수정해야 하는 경우 Blob 복사 작업을 사용하여 보관 계층에서 Blob의 복사본을 만드는 것이 좋습니다.
Blob 복사 작업을 사용하여 온라인 계층의 Blob을 보관 계층으로 복사할 수 있습니다. Blob 복사 작업을 호출하여 온라인 계층(핫 또는 쿨)에서 보관 계층으로 Blob을 복사할 수 있습니다. 원본 Blob은 온라인 계층에 남아 있으며 온라인 계층에서 해당 데이터를 계속 읽거나 수정할 수 있습니다.
계층을 변경하여 기존 Blob 보관
Blob 계층 설정 작업을 사용하여 Blob을 핫 또는 쿨 계층에서 보관 계층으로 이동합니다. Blob 계층 설정 작업은 초기 삭제 간격이 경과하기 전에 보관된 데이터에 액세스할 필요가 없는 시나리오에 가장 적합합니다.
Blob 계층 설정 작업은 단일 Blob의 계층을 변경합니다. Blob 세트를 최적의 성능으로 보관 계층으로 이동하려면 대량 보관 작업을 수행하는 것이 좋습니다. 일괄 보관 작업은 단일 트랜잭션에서 서비스에 대한 일괄 Blob 계층 설정 호출을 보냅니다. 자세한 내용은 대량 보관 파일을 참조하세요.
Azure Portal의 보관 계층으로 기존 Blob을 이동하려면 다음 단계를 따르세요.
Blob의 컨테이너로 이동합니다.
보관할 Blob을 선택합니다.
계층 변경 단추를 선택합니다.
액세스 계층 드롭다운에서 보관을 선택합니다.
저장을 선택합니다.
복사 작업으로 기존 Blob 보관
Blob 복사 작업을 사용하여 Blob을 핫 또는 쿨 계층에서 보관 계층으로 복사합니다. 원본 Blob은 핫 또는 쿨 계층에 남아 있는 반면 대상 Blob은 보관 계층에서 만들어집니다.
Blob 복사 작업은 조기 삭제 간격이 경과하기 전에 보관된 데이터를 읽거나 수정해야 하는 시나리오에 가장 적합합니다. 보관된 Blob을 다시 리하이드레이션할 필요 없이 원본 Blob의 데이터에 액세스할 수 있습니다.
해당 없음
대량 보관
Blob을 컨테이너 또는 폴더의 보관 계층으로 이동하려면 Blob을 열거하고 각 Blob에 대해 계층 설정 작업을 호출합니다. 다음 예제에서는 이 작업을 수행하는 방법을 보여 줍니다.
해당 없음
많은 수의 Blob을 보관 계층으로 이동할 때 최적의 성능을 위해 일괄 처리 작업을 사용합니다. 일괄 처리 작업은 단일 요청으로 여러 API 호출을 서비스에 보냅니다. Blob 일괄 처리 작업에서 지원하는 하위 작업에는 Blob 삭제 및 Blob 계층 설정이 포함됩니다.
일괄 처리 작업으로 Blob을 보관하려면 Azure Storage 클라이언트 라이브러리 중 하나를 사용합니다. 다음 코드 예에서는 .NET 클라이언트 라이브러리를 사용하여 기본 일괄 처리 작업을 수행하는 방법을 보여 줍니다.
static async Task BulkArchiveContainerContents(string accountName, string containerName)
{
string containerUri = string.Format("https://{0}.blob.core.windows.net/{1}",
accountName,
containerName);
// Get container client, using Azure AD credentials.
BlobUriBuilder containerUriBuilder = new BlobUriBuilder(new Uri(containerUri));
BlobContainerClient blobContainerClient = new BlobContainerClient(containerUriBuilder.ToUri(),
new DefaultAzureCredential());
// Get URIs for blobs in this container and add to stack.
var uris = new Stack<Uri>();
await foreach (var item in blobContainerClient.GetBlobsAsync())
{
uris.Push(blobContainerClient.GetBlobClient(item.Name).Uri);
}
// Get the blob batch client.
BlobBatchClient blobBatchClient = blobContainerClient.GetBlobBatchClient();
try
{
// Perform the bulk operation to archive blobs.
await blobBatchClient.SetBlobsAccessTierAsync(blobUris: uris, accessTier: AccessTier.Archive);
}
catch (RequestFailedException e)
{
Console.WriteLine(e.Message);
}
}
일괄 처리 작업으로 계층을 변경하는 방법을 보여 주는 심층 샘플 애플리케이션은 AzBulkSetBlobTier를 참조하세요.
수명 주기 관리 정책을 사용하여 Blob 보관
Blob이 지정된 기간 동안 액세스되거나 수정되지 않은 경우 보관 계층으로 자동으로 이동하는 수명 주기 관리 정책을 만들어 거의 액세스하지 않는 Blob 데이터에 대한 비용을 최적화할 수 있습니다. 수명 주기 관리 정책을 구성한 후 Azure Storage에서 하루에 한 번 실행합니다. 수명 주기 관리 정책에 관한 자세한 내용은 데이터 수명 주기를 자동으로 관리하여 비용 최적화를 참조하세요.
Azure Portal, PowerShell, Azure CLI 또는 Azure Resource Manager 템플릿을 사용하여 수명 주기 관리 정책을 만들 수 있습니다. 간단히 하기 위해 이 섹션에서는 Azure Portal에서만 수명 주기 관리 정책을 만드는 방법을 보여 줍니다. 수명 주기 관리 정책을 만드는 방법을 보여 주는 추가 예제는 수명 주기 관리 정책 구성을 참조하세요.
주의
수명 주기 관리 정책을 사용하여 데이터를 보관 계층으로 이동하기 전에 적어도 180일 동안 데이터를 삭제하거나 다른 계층으로 이동할 필요가 없는지 확인합니다. 180일 기간이 경과하기 전에 삭제되거나 다른 계층으로 이동된 데이터는 조기 삭제 요금이 부과됩니다.
또한 보관 계층의 데이터를 읽거나 수정하려면 먼저 리하이드레이션해야 합니다. 보관 계층에서 Blob을 리하이드레이션하는 데는 몇 시간이 걸릴 수 있으며 관련 비용이 발생합니다.
Azure Portal에서 Blob을 보관하는 수명 주기 관리 정책을 만들려면 다음 단계를 수행합니다.
1단계: 규칙 만들기 및 Blob 유형 지정
Portal에서 스토리지 계정으로 이동합니다.
데이터 관리에서 수명 주기 관리 설정을 찾습니다.
규칙 추가 단추를 선택합니다.
세부 정보 탭에서 규칙의 이름을 지정합니다.
규칙 범위를 지정합니다. 스토리지 계정의 모든 Blob에 규칙을 적용하거나 필터를 사용하여 Blob을 제한합니다.
규칙을 적용할 Blob 유형을 선택하고 Blob 스냅샷 또는 버전을 포함할지 여부를 지정합니다.
2단계: 규칙 조건 추가
선택에 따라 기본 Blob(현재 버전), 이전 버전 또는 Blob 스냅샷에 대한 규칙을 구성할 수 있습니다. 확인할 두 가지 조건 중 하나를 지정합니다.
- 개체는 며칠 전에 마지막으로 수정되었습니다.
- 개체는 며칠 전에 만들어졌습니다.
- 개체는 며칠 전에 마지막으로 액세스되었습니다.
이러한 조건 중 하나만 적용하여 특정 유형의 개체를 규칙당 보관 계층으로 이동할 수 있습니다. 예를 들어 90일 동안 수정되지 않은 기본 Blob을 보관하는 작업을 정의하는 경우 90일 동안 액세스되지 않은 기본 Blob을 보관하는 작업도 정의할 수 없습니다. 마찬가지로 이전 버전을 보관하기 위해 이러한 조건 중 하나를 사용하여 규칙당 하나의 작업을 정의하고 스냅샷을 보관할 작업을 정의할 수 있습니다.
다음으로 개체를 수정하거나 액세스한 후 경과할 일 수를 지정합니다.
간격이 경과한 후 개체를 보관 계층으로 이동하도록 지정합니다.
규칙의 영향을 받는 Blob을 필터로 제한하도록 선택한 경우 Blob 접두사 또는 Blob 인덱스 일치를 사용하여 필터를 지정할 수 있습니다.
3단계: 규칙에서 리하이드레이션된 Blob을 제외하는지 확인
계층을 변경하여 Blob을 리하이드레이션하는 경우 마지막으로 수정한 시간, 만든 시간 또는 마지막 액세스 시간이 정책에 대해 설정된 임계값을 초과하는 경우 이 규칙은 Blob을 보관 계층으로 다시 이동시킵니다.
마지막으로 수정 규칙 조건을 선택한 경우 지난 x일 동안 리하이드레이션된 Blob을 건너뜁니다.를 선택한 다음, 이 규칙에서 리하이드레이션된 Blob이 제외되도록 하려는 일 수를 입력하여 이 문제가 발생하지 않도록 방지할 수 있습니다.
참고 항목
이 옵션은 마지막으로 수정 규칙 조건을 선택한 경우에만 표시됩니다.
추가 단추를 선택하여 정책에 규칙을 추가합니다.
정책 JSON 보기
수명 주기 관리 정책을 만든 후 목록 보기에서 코드 보기로 전환하여 수명 주기 관리 페이지에서 정책에 대한 JSON을 볼 수 있습니다.
위에 표시된 이미지에서 만든 간단한 수명 주기 관리 정책에 대한 JSON은 다음과 같습니다.
{
"rules": [
{
"enabled": true,
"name": "sample-archive-rule",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterLastAccessTimeGreaterThan": 90,
"daysAfterLastTierChangeGreaterThan": 7
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
]
}
}
}
]
}