블록 목록 배치

이 연산은 Put Block List 블롭을 구성하는 블록 ID 목록을 지정하여 블롭을 작성합니다. 블롭의 일부로 작성되려면, 블록이 이전의 Put Block 연산에서 서버에 성공적으로 기록되어야 합니다.

변경된 블록만 업로드한 뒤, 새로 추가된 블록과 기존 블록을 함께 커밋하여 블롭을 업데이트할 수 있습니다 Put Block List . 이는 커밋된 블록 리스트에서 커밋할지 미커밋 블록 리스트에서 커밋할지 또는 가장 최근에 업로드된 블록 버전을 커밋할지 지정함으로써 할 수 있습니다.

요청

다음과 같이 Put Block List 요청을 생성할 수 있습니다. HTTPS를 사용하는 것이 좋습니다. myaccount를 저장 계정 이름으로 교체하세요:

에뮬레이트된 스토리지 서비스 요청

에뮬레이션 스토리지 서비스에 대해 요청을 할 때, 에뮬레이터 호스트명과 Blob 서비스 포트를 127.0.0.1:10000, 에뮬레이션 스토리지 계정 이름으로 지정하세요:

스토리지 에뮬레이터는 최대 2gibibytes(GiB)의 Blob 크기만 지원합니다.

자세한 내용은 로컬 Azure Storage 개발에 Azurite 에뮬레이터 사용을 참조하세요.

URI 매개 변수

요청 URI에 다음 추가 매개 변수를 지정할 수 있습니다.

요청 헤더

필수 및 선택적 요청 헤더는 다음 표에 설명되어 있습니다.

이 연산은 또한 지정된 조건이 충족될 때만 조건부 헤더를 사용하여 블록 리스트를 커밋하는 것을 지원합니다. 자세한 내용은 Blob Storage 작업대한 조건부 헤더 지정을 참조하세요.

요청 헤더(고객이 제공한 암호화 키)

버전 2019-02-02부터는 고객이 제공한 키로 블롭을 암호화하기 위한 요청에서 다음과 같은 헤더를 지정할 수 있습니다. 고객이 제공한 키(및 해당 헤더 집합)를 사용한 암호화는 선택 사항입니다.

요청 본문

요청 본문에서 Blob 저장소가 요청된 블록에 대해 검사해야 할 블록 목록을 지정할 수 있습니다. 이렇게 하면 전체 블롭을 다시 업로드하는 대신 개별 블록을 삽입, 교체, 삭제함으로써 기존 블롭을 업데이트할 수 있습니다. 변경된 블록을 업로드한 후에는, 기존 블록과 함께 새 블록을 커밋하여 새로운 버전의 블롭을 커밋할 수 있습니다.

블롭을 업데이트하려면, 서비스가 커밋된 블록 리스트, 미커밋 블록 리스트, 또는 먼저 미커밋 블록 리스트에서 블록 ID를 찾고, 그 다음에 커밋드 블록 리스트에서 찾아야 한다고 지정할 수 있습니다. 어떤 방식을 사용할지 표시하려면, 요청 본체 내 적절한 XML 요소 내에 있는 블록 ID를 다음과 같이 지정하세요:

• 요소 내에 Committed 블록 ID를 지정하여 Blob 저장소가 지정된 블록에 대해 커밋된 블록 리스트만 검색하도록 표시하세요. 만약 그 블록이 커밋된 블록 목록에 없으면, 블록은 블롭의 일부로 작성되지 않고, 블롭 스토리지는 상태 코드 400(잘못된 요청)을 반환합니다.

• 요소 내에 Uncommitted 블록 ID를 지정하여 Blob 저장소가 지정된 블록에 대해 미커밋 블록 리스트만 검색하도록 표시하세요. 만약 해당 블록이 미커밋 블록 목록에 없으면, 블록은 블롭의 일부로 기록되지 않으며, 블롭 저장소는 상태 코드 400(잘못된 요청)을 반환합니다.

• 요소 내에서 Latest 블록 ID를 지정하여 Blob 저장소가 먼저 미커밋 블록 리스트를 검색해야 함을 나타냅니다. 만약 그 블록이 미커밋 리스트에 있다면, 그 버전의 블록이 최신 것이므로 블롭에 기록되어야 합니다. 만약 그 블록이 미커밋 리스트에서 찾지 못하면, 서비스는 커밋드 블록 리스트에서 이름 있는 블록을 검색하고, 발견되면 그 블록을 블롭에 기록해야 합니다.

이 버전의 Put Block List 요청 본문은 다음과 같은 XML 형식을 사용합니다:

<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Committed>first-base64-encoded-block-id</Committed>  
  <Uncommitted>second-base64-encoded-block-id</Uncommitted>  
  <Latest>third-base64-encoded-block-id</Latest>  
  ...  
</BlockList>  
  

샘플 요청

시연 Put Block List을 위해 , 이제 커밋하려는 세 개의 블록을 업로드했다고 가정해 보세요. 다음 예시는 나열된 각 블록의 최신 버전을 사용해야 함을 표시하여 새로운 블롭을 커밋합니다. 이 블록들이 이미 커밋되었는지 알 필요는 없습니다.

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Latest>AAAAAA==</Latest>  
  <Latest>AQAAAA==</Latest>  
  <Latest>AZAAAA==</Latest>  
</BlockList>  
  

다음으로, 블롭을 업데이트하고 싶다고 가정해 봅시다. 새로운 블롭에는 다음과 같은 변화가 있습니다:

• ID ANAAAA==.가 있는 새로운 블록입니다. 이 블록은 먼저 Put Block 호출과 함께 업로드되어야 하며, 호출 때까지 Put Block List미커밋 블록 목록에 나타납니다.

• ID AZAAAA==.를 가진 블록의 업데이트 버전입니다. 이 블록은 먼저 Put Block 호출과 함께 업로드되어야 하며, 호출 때까지 Put Block List미커밋 블록 목록에 나타납니다.

• ID AAAAAA==.가 있는 블록 제거 이 블록이 다음 호출 Put Block List에 포함되지 않기 때문에, 블록은 사실상 블롭에서 제거됩니다.

다음 예시는 블롭을 업데이트하는 호출 과정을 Put Block List 보여줍니다:

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2009 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
x-ms-expiry-option: RelativeToNow
x-ms-expiry-time: 30000
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Uncommitted>ANAAAA==</Uncommitted>  
  <Committed>AQAAAA==</Committed>  
  <Uncommitted>AZAAAA==</Uncommitted>  
</BlockList>  
  

응답

응답에는 HTTP 상태 코드와 응답 헤더 집합이 포함됩니다.

상태 코드

작업이 성공하면 상태 코드 201(생성됨)이 반환됩니다.

상태 코드에 대한 자세한 내용은 상태 및 오류 코드참조하세요.

응답 헤더

이 작업에 대한 응답에는 다음 헤더가 포함됩니다. 응답에는 추가 표준 HTTP 헤더도 포함될 수 있습니다. 모든 표준 헤더는 HTTP/1.1 프로토콜 사양준수합니다.

샘플 응답

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sun, 25 Sep 2011 00:17:44 GMT  
ETag: “0x8CB172A360EC34B”  
Last-Modified: Sun, 25 Sep 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-version-id: <DateTime>  

Authorization

Azure Storage에서 데이터 액세스 작업을 호출할 때 권한 부여가 필요합니다. 아래 설명된 대로 Put Block List 작업에 권한을 부여할 수 있습니다.

요청이 x-ms-tags 요청 헤더를 사용하여 태그를 지정하는 경우 호출자는 Blob 태그 설정 작업의 권한 부여 요구 사항을 충족해야 합니다.

비고

이 연산은 Put Block List 블록들을 결합하여 블롭을 만드는 순서를 강제합니다.

동일한 블록 ID가 블록 목록에서 여러 번 지정할 수 있습니다. 블록 ID가 여러 번 지정된다면, 이는 최종 커밋된 블롭의 블록 목록 내 각 위치에 있는 바이트 범위를 나타냅니다. 만약 한 블록 ID가 목록에 두 번 이상 나타난다면, 두 블록 ID 인스턴스는 동일한 블록 리스트 내에서 지정되어야 합니다. 즉, 두 인스턴스 모두 원소, Uncommitted 원소 Latest 또는 원소 내에 Committed 지정되어야 합니다.

를 사용하면 Put Block List전체 블롭을 다시 업로드하지 않고도 개별 블록을 삽입, 업데이트, 삭제하여 수정할 수 있습니다. 현재 커밋된 블록 리스트와 커밋되지 않은 블록 리스트 모두에서 블록 ID를 지정하여 새로운 블롭을 만들거나 기존 블롭의 내용을 업데이트할 수 있습니다. 이렇게 하면 이미 기존 블록의 일부인 미커밋 블록 리스트에서 몇 개의 새 블록을, 나머지 블록 목록에서 기존 블록의 일부인 블록을 지정하여 블롭을 업데이트할 수 있습니다.

요소에 Latest 블록 ID가 지정되어 있고, 커밋된 블록 리스트와 미커밋 블록 리스트 모두에 동일한 블록 ID가 존재한다면, Put Block List 미커밋된 블록 리스트에서 해당 블록을 커밋합니다. 만약 블록 ID가 커밋된 블록 리스트에 존재하지만 커밋되지 않은 블록 리스트에는 없다면, Put Block List 커밋된 블록 리스트에서 해당 블록을 커밋합니다.

블록 블롭의 각 블록은 크기가 다를 수 있습니다. 블록 블롭은 최대 50,000개의 커밋 블록을 포함할 수 있습니다. 블롭과 연관될 수 있는 최대 미커밋 블록 수는 100,000개입니다.

다음 표는 서비스 버전별 최대 허용 블록 및 블롭 크기를 설명합니다:

기존 블롭을 업데이트하려고 호출 Put Block List 하면, 그 블롭의 기존 속성과 메타데이터가 덮어써집니다. 하지만 기존의 스냅샷은 블롭과 함께 유지됩니다. 조건부 요청 헤더를 사용하여 지정된 조건이 충족될 때만 연산을 수행할 수 있습니다.

만약 블록이 빠져서 연산이 Put Block List 실패한다면, 그 블록을 업로드해야 합니다.

마지막 성공적인 Put Block 작업 후 일주일 이내에 블롭에 Put BlockPut Block List 대한 성공적인 호출이 없으면 미커밋 블록은 가라비지 컬렉션으로 처리됩니다. Blob에서 Put Blob 이 호출되면 커밋되지 않은 블록은 가비지 수집됩니다.

헤더에 x-ms-tags 태그가 제공된 경우, 반드시 쿼리 문자열로 인코딩되어야 합니다. 태그 키와 숫자는 명명과 길이 요구사항을 충족해야 하며, 이는 .Set Blob Tags 또한, 헤더에는 x-ms-tags 최대 2 KiB 크기의 태그가 포함될 수 있습니다. 더 많은 태그가 필요하다면, Set Blob Tags 연산을 사용하세요.

블롭이 활성 임대를 가지고 있다면, 클라이언트는 블록 리스트를 커밋하기 위해 요청할 때 유효한 리스 ID를 지정해야 합니다. 클라이언트가 임대 ID를 지정하지 않거나 잘못된 임대 ID를 지정하는 경우 Blob Storage는 상태 코드 412(사전 조건 실패)를 반환합니다. 클라이언트가 임대 ID를 지정했지만 블롭에 활성 임대가 없으면, 블롭 저장소는 상태 코드 412(전제 조건 실패)도 반환합니다. 클라이언트가 아직 존재하지 않는 블롭에 대해 리스 ID를 지정하면, 블롭 스토리지는 2013-08-15 버전 이후 요청에 대해 상태 코드 412(전제 조건 실패)를 반환합니다. 이전 버전의 경우 Blob 저장소는 상태 코드 201(생성됨)을 반환합니다.

블롭에 활성 임대 계약이 있고 업데이트를 요청 Put Block List 하면, 임대 계약은 업데이트된 블롭에서 유지됩니다.

Put Block List 블록 덩어리에만 적용됩니다. 페이지 블롭에서 호출하면 Put Block List 상태 코드 400(잘못된 요청)이 발생합니다.

블롭을 archive 덮어쓰는 것은 실패합니다. 그렇지 않으면, 헤더가 x-ms-access-tier 제공되지 않은 경우 블롭이 이전 블롭으로부터 티어를 상속받습니다.

결제

가격 책정 요청은 Blob Storage REST API를 통해 직접 Blob Storage API를 사용하는 클라이언트 또는 Azure Storage 클라이언트 라이브러리에서 비롯할 수 있습니다. 이러한 요청은 트랜잭션당 요금이 발생합니다. 트랜잭션 유형은 계정에 청구되는 방식에 영향을 줍니다. 예를 들어 읽기 트랜잭션은 쓰기 트랜잭션과 다른 청구 범주에 발생합니다. 다음 표에서는 스토리지 계정 유형에 따라 Put Block List 요청에 대한 청구 범주를 보여 줍니다.

지정된 청구 범주의 가격 책정에 대한 자세한 내용은 Azure Blob Storage 가격 책정참조하세요.

참고하십시오

블록 블롭, 덧붙인 블롭, 페이지 블롭을 이해하세요
Azure Storage 대한 요청 권한 부여
상태 및 오류 코드
블롭 서비스 오류 코드
Blob 서비스 작업에 대해 타임아웃을 설정하세요