다음을 통해 공유

URL에서 블록 추가

이 Append Block From URL 작업은 기존 추가 Blob의 끝에 새 데이터 블록을 커밋합니다.

이 Append Block From URL 작업은 Blob이 로 설정된 x-ms-blob-type상태로 AppendBlob 만들어진 경우에만 허용됩니다. Append Block From URL 버전 2018-11-09 이상에서만 지원됩니다.

요청

다음과 같이 Append Block From URL 요청을 생성할 수 있습니다. HTTPS를 사용하는 것이 좋습니다. myaccount 스토리지 계정 이름으로 바꿉니다.

PUT 메서드 요청 URI HTTP 버전
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=appendblock HTTP/1.1

에뮬레이트된 스토리지 서비스에 대해 요청할 때 에뮬레이터 호스트 이름 및 Azure Blob Storage 포트를 로 127.0.0.1:10000지정한 다음 에뮬레이트된 스토리지 계정 이름을 지정합니다.

PUT 메서드 요청 URI HTTP 버전
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=appendblock HTTP/1.1

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

URI 매개 변수

매개 변수 설명
timeout 선택 사항입니다. 시간 제한 매개 변수는 초 단위로 표시됩니다. 자세한 내용은 Blob Storage 작업에 대한 시간 제한 설정을 참조하세요.

요청 헤더

다음 표에서는 필수 및 선택적 요청 헤더에 대해 설명합니다.

요청 헤더 설명
Authorization 필수 사항입니다. 권한 부여 체계, 계정 이름 및 서명을 지정합니다. 자세한 내용은 Azure Storage 대한 요청 권한 부여를 참조하세요.
Date 또는 x-ms-date 필수 사항입니다. 요청에 대한 UTC(협정 세계시)를 지정합니다. 자세한 내용은 Azure Storage대한 요청 권한 부여를 참조하세요.
x-ms-version 모든 권한 있는 요청에 필요합니다. 이 요청에 사용할 작업의 버전을 지정합니다. 자세한 내용은 Azure Storage 서비스 대한버전 관리를 참조하세요.
Content-Length 필수 사항입니다. 요청 본문에서 전송되는 바이트 수를 지정합니다. 이 헤더의 값은 0으로 설정해야 합니다. 길이가 0이 아니면 오류 코드 400(잘못된 요청)과 함께 작업이 실패합니다.
x-ms-copy-source:name 필수 사항입니다. 원본 Blob의 URL을 지정합니다. 값은 Blob을 지정하는 최대 2KiB 길이의 URL일 수 있습니다. 값은 요청 URI에 표시되므로 URL로 인코딩되어야 합니다. 원본 Blob은 공용이거나 공유 액세스 서명을 통해 권한을 부여받아야 합니다. 원본 Blob이 공용인 경우 작업을 수행하는 데 권한 부여가 필요하지 않습니다. 다음은 원본 개체 URL의 몇 가지 예입니다.

https://myaccount.blob.core.windows.net/mycontainer/myblob
https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>
https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime>
x-ms-copy-source-authorization: <scheme> <signature> 선택 사항입니다. 복사 원본에 대한 권한 부여 체계 및 서명을 지정합니다. 자세한 내용은 Azure Storage대한 요청 권한 부여를 참조하세요.
Microsoft Entra ID에는 체계 전달자만 지원됩니다.
이 헤더는 버전 2020-10-02 이상에서 지원됩니다.
x-ms-source-range 선택 사항입니다. 지정된 범위의 원본 URL에 있는 Blob의 바이트만 업로드합니다. 이를 지정하지 않으면 전체 원본 Blob 콘텐츠가 단일 추가 블록으로 업로드됩니다. 자세한 내용은 Blob Storage 작업에 대한 범위 헤더 지정을 참조하세요.
x-ms-source-content-md5 선택 사항입니다. URI의 추가 블록 콘텐츠의 MD5 해시입니다. 이 해시는 URI에서 데이터를 전송하는 동안 추가 블록의 무결성을 확인하는 데 사용됩니다. 이 헤더를 지정하면 스토리지 서비스는 복사 소스에서 도착한 콘텐츠의 해시를 이 헤더 값과 비교합니다.

이 MD5 해시는 Blob과 함께 저장되지 않습니다.

두 해시가 일치하지 않으면 오류 코드 400(잘못된 요청)과 함께 작업이 실패합니다.
x-ms-source-content-crc64 선택 사항입니다. URI에서 추가 블록 콘텐츠의 CRC64 해시입니다. 이 해시는 URI에서 데이터를 전송하는 동안 추가 블록의 무결성을 확인하는 데 사용됩니다. 이 헤더를 지정하면 스토리지 서비스는 복사 소스에서 도착한 콘텐츠의 해시를 이 헤더 값과 비교합니다.

이 CRC64 해시는 Blob과 함께 저장되지 않습니다.

두 해시가 일치하지 않으면 오류 코드 400(잘못된 요청)과 함께 작업이 실패합니다.

와 x-ms-source-content-md5 헤더가 모두 x-ms-source-content-crc64 있으면 요청이 실패하고 400(잘못된 요청)이 표시됩니다.

이 헤더는 버전 2019-02-02 이상에서 지원됩니다.
x-ms-encryption-scope 선택 사항입니다. 원본 콘텐츠를 암호화하는 데 사용할 암호화 범위를 나타냅니다. 이 헤더는 버전 2019-02-02 이상에서 지원됩니다.
x-ms-lease-id:<ID> Blob에 활성 임차가 있는 경우 필수입니다. 활성 임대가 있는 Blob에서 이 작업을 수행하려면 이 헤더에 대한 유효한 임대 ID를 지정합니다.
x-ms-client-request-id 선택 사항입니다. 로깅이 구성될 때 로그에 기록되는 1kibibyte(KiB) 문자 제한으로 클라이언트에서 생성된 불투명 값을 제공합니다. 이 헤더를 사용하여 클라이언트 쪽 활동과 서버가 수신하는 요청의 상관 관계를 지정하는 것이 좋습니다. 자세한 내용은 Azure Blob Storage 모니터링을 참조하세요.
x-ms-blob-condition-maxsize 선택적 조건부 헤더입니다. 추가 Blob에 허용되는 최대 길이(바이트)입니다. 작업으로 인해 Append Block From URL Blob이 해당 제한을 초과하거나 Blob 크기가 이미 이 헤더에 지정된 값보다 큰 경우 요청은 412(사전 조건 실패)로 실패합니다.
x-ms-blob-condition-appendpos 작업에만 사용되는 선택적 조건부 헤더입니다 Append Block from URL . 비교할 바이트 오프셋을 나타내는 숫자입니다. Append Block from URL 추가 위치가 이 숫자와 같은 경우에만 성공합니다. 그렇지 않으면 요청이 실패하고 412(전제 조건 실패)가 표시됩니다.
x-ms-file-request-intent header가 Azure 파일 URL이고 x-ms-copy-source header가 OAuth 토큰을 지정하는 경우 x-ms-copy-source-authorization 필요합니다. 허용되는 값은 backup. 이 헤더는 Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action 헤더를 사용하여 권한이 부여된 ID에 할당된 RBAC 정책에 포함된 경우 Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action 또는 x-ms-copy-source-authorization 부여하도록 지정합니다. 버전 2025-07-05 이상에 사용할 수 있습니다.

이 작업은 지정된 조건이 충족되는 경우에만 API가 성공하도록 하기 위해 추가 조건부 헤더의 사용을 지원합니다. 자세한 내용은 Blob Storage 작업에 대한 조건부 헤더 지정을 참조하세요.

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

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

요청 헤더 설명
x-ms-encryption-key 필수 사항입니다. Base64로 인코딩된 AES-256 암호화 키입니다.
x-ms-encryption-key-sha256 필수 사항입니다. 암호화 키의 Base64로 인코딩된 SHA256 해시입니다.
x-ms-encryption-algorithm: AES256 필수 사항입니다. 암호화에 사용할 알고리즘을 지정합니다. 이 헤더의 값은 AES256이어야 합니다.

요청 메시지 본문

요청 본문에는 블록의 내용이 포함됩니다.

샘플 요청

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=appendblock  HTTP/1.1  

Request Headers:  
x-ms-version: 2018-11-09  
x-ms-date: <date>  
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-65535
x-ms-blob-condition-appendpos: 2097152  
x-ms-blob-condition-maxsize: 4194304  
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 0 
If-Match: "0x8CB172A360EC34B"

응답

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

상태 코드

작업이 성공하면 상태 코드 201(생성됨)이 반환됩니다. 상태 코드에 대한 자세한 내용은 상태 및 오류 코드참조하세요.

응답 헤더

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

응답 헤더 설명
Etag 따옴표 ETag 안에 값이 포함되어 있습니다. 클라이언트는 이 값을 사용하여 요청 헤더를 통해 PUT 조건부 If-Match 작업을 수행합니다.
Last-Modified Blob이 마지막으로 수정된 날짜/시간입니다. 날짜 형식은 RFC 1123을 따릅니다. 자세한 내용은 헤더 날짜-시간 값의표현을 참조하세요.

Blob에 대한 모든 쓰기 작업(Blob의 메타데이터 또는 속성에 대한 업데이트 포함)은 Blob의 마지막 수정 시간을 변경합니다.
Content-MD5 클라이언트가 메시지 콘텐츠 무결성을 확인할 수 있도록 이 헤더가 반환됩니다. Blob Storage는 이 헤더의 값을 계산합니다. 요청 헤더에 지정된 값과 반드시 같을 필요는 없습니다. 버전 2019-02-02 이상에서는 요청에 이 헤더가 있는 경우에만 이 헤더가 반환됩니다.
x-ms-content-crc64 버전 2019-02-02 이상. 클라이언트가 메시지 콘텐츠 무결성을 확인할 수 있도록 이 헤더가 반환됩니다. Blob Storage는 이 헤더의 값을 계산합니다. 요청 헤더에 지정된 값과 반드시 같을 필요는 없습니다.

이 헤더는 헤더가 x-ms-source-content-md5 요청에 없을 때 반환됩니다.
x-ms-request-id 이 헤더는 만들어진 요청을 고유하게 식별하며 요청 문제를 해결하는 데 사용할 수 있습니다.
x-ms-version 요청을 실행하는 데 사용되는 Blob Storage의 버전을 나타냅니다. 이 헤더는 버전 2009-09-19 이상에 대해 수행된 요청에 대해 반환됩니다.
Date 응답이 시작된 시간을 나타내는 서비스에서 생성된 UTC 날짜/시간 값입니다.
x-ms-blob-append-offset 이 응답 헤더는 추가 작업에 대해서만 반환됩니다. 블록이 커밋된 오프셋(바이트)을 반환합니다.
x-ms-blob-committed-block-count Blob에 있는 커밋된 블록의 수입니다. 이를 사용하여 얼마나 더 많은 추가를 수행할 수 있는지 제어할 수 있습니다.
x-ms-request-server-encrypted: true/false 버전 2015-12-11 이상. 지정된 알고리즘을 사용하여 요청 내용이 성공적으로 암호화되면 이 헤더의 값이 true 설정됩니다. 그렇지 않으면 값이 false설정됩니다.
x-ms-encryption-key-sha256 버전 2019-02-02 이상. 이 헤더는 요청이 암호화를 위해 고객 제공 키를 사용한 경우 반환됩니다. 그런 다음 클라이언트는 제공된 키를 사용하여 요청 내용이 성공적으로 암호화되었는지 확인할 수 있습니다.
x-ms-encryption-scope 버전 2019-02-02 이상. 이 헤더는 요청이 암호화 범위를 사용한 경우 반환됩니다. 그런 다음 클라이언트는 암호화 범위를 사용하여 요청의 내용이 성공적으로 암호화되었는지 확인할 수 있습니다.

샘플 응답

Response Status:  
HTTP/1.1 201 Created  

Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: <date>  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-blob-append-offset: 2097152  
x-ms-blob-committed–block-count: 1000

승인

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

이 섹션의 권한 부여 세부 정보는 복사 대상에 적용됩니다. 복사 소스 권한 부여에 대한 자세한 내용은 요청 헤더 x-ms-copy-source에 대한 세부 정보를 참조하세요.

중요합니다

Microsoft는 관리 ID와 함께 Microsoft Entra ID를 사용하여 Azure Storage에 대한 요청을 승인하는 것이 좋습니다. Microsoft Entra ID는 공유 키 권한 부여에 비해 뛰어난 보안 및 사용 편의성을 제공합니다.

Azure Storage는 Microsoft Entra ID를 사용하여 Blob 데이터 요청에 대해 권한을 부여하는 것을 지원합니다. Microsoft Entra ID를 사용하면 Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하여 보안 주체에 권한을 부여할 수 있습니다. 보안 주체는 사용자, 그룹, 애플리케이션 서비스 주체 또는 Azure 관리 ID일 수 있습니다. 보안 주체는 OAuth 2.0 토큰을 반환하기 위해 Microsoft Entra ID에 의해 인증됩니다. 그런 다음 토큰을 사용하여 Blob service에 대한 요청을 승인할 수 있습니다.

Microsoft Entra ID를 사용한 권한 부여에 대한 자세한 내용은 Microsoft Entra ID사용하여 Blob에 대한 액세스 권한 부여를 참조하세요.

권한

아래에는 Microsoft Entra 사용자, 그룹, 관리 ID 또는 서비스 주체가 Append Block From URL 작업을 호출하는 데 필요한 RBAC 작업과 이 작업을 포함하는 최소 권한의 기본 제공 Azure RBAC 역할이 나와 있습니다.

Azure RBAC를 사용하여 역할을 할당하는 방법에 대한 자세한 내용은 Blob 데이터액세스하기 위한 Azure 역할 할당을 참조하세요.

비고

Append Block From URL 기존 추가 Blob의 끝에 블록을 업로드합니다. 데이터 블록은 서버에서 호출이 성공한 직후에 사용할 수 있습니다. 각 추가 Blob에 대해 최대 50,000개의 추가가 허용됩니다. 각 블록의 크기는 다를 수 있습니다.

다음 표에서는 서비스 버전별로 허용되는 최대 블록 및 Blob 크기에 대해 설명합니다.

서비스 버전 최대 블록 크기(경유 Append Block From URL) 최대 Blob 크기
버전 2022-11-02 이상 100MiB(미리 보기) 약 4.75TiB(100MiB × 50,000 블록)
2022-11-02 이전 버전 4MiB 약 195GiB(4MiB × 50,000블록)

버전 2020-10-02 이상에서는 복사 작업의 원본에 대해 Microsoft Entra ID 권한 부여가 지원됩니다.

Append Block From URL Blob이 이미 있는 경우에만 성공합니다.

를 사용하여 Append Block From URL 업로드된 Blob은 블록 ID를 노출하지 않으므로 추가 Blob에 대해 Get Block List 를 호출할 수 없습니다. 이렇게 하면 오류가 발생합니다.

요청에 다음과 같은 선택적 조건부 헤더를 지정할 수 있습니다.

  • x-ms-blob-condition-appendpos: 이 헤더를 클라이언트가 블록을 추가할 것으로 예상하는 바이트 오프셋으로 설정할 수 있습니다. 현재 오프셋이 클라이언트에서 지정한 오프셋과 일치하는 경우에만 요청이 성공합니다. 그렇지 않으면 오류 코드 412(사전 조건 실패)와 함께 요청이 실패합니다.

    단일 작성기를 사용하는 클라이언트는 이 헤더를 사용하여 네트워크 오류에도 불구하고 작업이 성공한 시기를 Append Block From URL 확인할 수 있습니다.

  • x-ms-blob-condition-maxsize: 클라이언트는 이 헤더를 사용하여 추가 작업이 예상 최대 크기(바이트)를 초과하여 Blob 크기를 늘리지 않도록 할 수 있습니다. 조건이 실패하면 오류 코드 412(사전 조건 실패)와 함께 요청이 실패합니다.

허용된 크기보다 큰 블록을 업로드하려고 하면 서비스에서 HTTP 오류 코드 413(요청 엔터티가 너무 큼)을 반환합니다. 또한 이 서비스는 허용되는 최대 블록 크기(바이트)를 포함하여 응답의 오류에 대한 추가 정보를 반환합니다. 50,000개 이상의 블록을 업로드하려고 하면 서비스에서 오류 코드 409(충돌)를 반환합니다.

Blob에 활성 임대가 있는 경우 클라이언트는 Blob에 블록을 쓰기 위해 요청에 유효한 임대 ID를 지정해야 합니다. 클라이언트가 임대 ID를 지정하지 않거나 잘못된 임대 ID를 지정하는 경우 Blob Storage는 오류 코드 412(사전 조건 실패)를 반환합니다. 클라이언트가 임대 ID를 지정하지만 Blob에 활성 임대가 없는 경우 서비스는 오류 코드 412를 반환합니다.

기존 블록 Blob 또는 페이지 Blob을 호출 Append Block From URL 하면 서비스에서 오류 코드 409(충돌)를 반환합니다. 존재하지 않는 Blob을 호출 Append Block From URL 하면 서비스에서 오류 코드 404(찾을 수 없음)를 반환합니다.

중복되거나 지연된 추가 방지

단일 작성기 시나리오에서 클라이언트는 조건부 헤더를 사용하여 x-ms-blob-condition-appendpos 현재 오프셋을 확인함으로써 중복 추가 또는 지연된 쓰기를 방지할 수 있습니다. 클라이언트는 또한 를 사용하여 ETag조건부로 확인하여 If-Match 중복 또는 지연을 피할 수 있습니다.

여러 작성기 시나리오에서 각 클라이언트는 조건부 헤더를 사용할 수 있습니다. 이는 성능에 최적이 아닐 수 있습니다. 가장 높은 동시 추가 처리량을 위해 애플리케이션은 애플리케이션 계층에서 중복 추가 및 지연된 추가를 처리해야 합니다. 예를 들어, 애플리케이션은 추가되는 데이터에 epoch 또는 시퀀스 번호를 추가할 수 있습니다.

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

청구서 발행

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

수술 Storage 계정 유형 청구 범주
URL에서 블록 추가(대상 계정1) 프리미엄 블록 Blob
표준 범용 v2
표준 범용 v1		 쓰기 작업
URL에서 블록 추가(소스 계정2) 프리미엄 블록 Blob
표준 범용 v2
표준 범용 v1		 읽기 작업

1 개대상 계정에는 쓰기를 시작하기 위해 하나의 트랜잭션에 대해 요금이 청구됩니다.
2 개소스 계정은 소스에 대한 각 읽기 요청에 대해 하나의 트랜잭션을 발생시킵니다.