내보내기(0) 인쇄
모두 확장

페이지 배치

업데이트 날짜: 2014년 1월

Put Page 작업은 페이지 blob에 일정 범위의 페이지를 기록합니다.

다음과 같이 Put Page 요청을 생성할 수 있습니다. HTTPS를 사용하는 것이 좋습니다. myaccount를 사용자의 저장소 계정으로 바꿉니다.

 

  PUT 메서드 요청 URI HTTP 버전

https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page

HTTP/1.1

에뮬레이트된 저장소 서비스에 대해 요청을 수행할 때는 에뮬레이터 호스트 이름 및 Blob 서비스 포트를 127.0.0.1:10000으로 지정하고 뒤에 에뮬레이트된 저장소 계정 이름을 붙입니다.

 

  PUT 메서드 요청 URI HTTP 버전

http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=page

HTTP/1.1

자세한 내용은 개발 및 테스트에 Azure 저장소 에뮬레이터 사용를 참조하십시오.

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

 

매개 변수 설명

timeout

선택 사항입니다. timeout 매개 변수는 초 단위로 표시됩니다. 자세한 내용은 Blob 서비스 작업의 제한 시간 설정를 참조하십시오.

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

 

요청 헤더 설명

Authorization

필수 사항입니다. 인증 체계, 계정 이름 및 서명을 지정합니다. 자세한 내용은 Azure 저장소 서비스에 대한 인증를 참조하십시오.

Date 또는 x-ms-date

필수 사항입니다. 요청의 UCT(협정 세계시)를 지정합니다. 자세한 내용은 Azure 저장소 서비스에 대한 인증를 참조하십시오.

x-ms-version

인증된 모든 요청의 경우 필수입니다. 이 요청에 사용할 작업의 버전을 지정합니다. 자세한 내용은 Azure 저장소 서비스 버전 관리를 참조하십시오.

Range

Range 또는 x-ms-range가 필요합니다.

페이지로 기록되는 바이트 범위를 지정합니다. 시작 및 끝 범위를 모두 지정해야 합니다. 이 헤더는 HTTP/1.1 프로토콜 사양에 의해 정의됩니다.

페이지 업데이트 작업의 경우 페이지 범위는 최대 4MB일 수 있습니다. 페이지 지우기 작업의 경우 페이지 범위는 blob의 전체 크기 값까지 가능합니다.

페이지를 512바이트 경계에 맞춰야 할 경우 시작 오프셋은 512의 모듈러스여야 하고, 끝 오프셋은 512-1의 모듈러스여야 합니다. 예를 들어 유효 바이트 범위는 0-511, 512-1023 등입니다.

Blob 서비스는 Range 헤더의 단일 바이트 범위만 수락하며, 바이트 범위는 다음 형식으로 지정되어야 합니다. bytes=startByte-endByte.

Rangex-ms-range가 모두 지정된 경우 서비스에서 x-ms-range의 값이 사용됩니다. 자세한 내용은 Blob 서비스 작업의 범위 헤더 지정을 참조하십시오.

x-ms-range

Range 또는 x-ms-range가 필요합니다.

페이지로 기록되는 바이트 범위를 지정합니다. 시작 및 끝 범위를 모두 지정해야 합니다. 이 헤더는 HTTP/1.1 프로토콜 사양에 의해 정의됩니다.

페이지 업데이트 작업의 경우 페이지 범위는 최대 4MB일 수 있습니다. 페이지 지우기 작업의 경우 페이지 범위는 blob의 전체 크기 값까지 가능합니다.

페이지를 512바이트 경계에 맞춰야 할 경우 시작 오프셋은 512의 모듈러스여야 하고, 끝 오프셋은 512-1의 모듈러스여야 합니다. 예를 들어 유효 바이트 범위는 0-511, 512-1023 등입니다.

Blob 서비스는 x-ms-range 헤더의 단일 바이트 범위만 수락하며, 바이트 범위는 다음 형식으로 지정되어야 합니다. bytes=startByte-endByte.

Rangex-ms-range가 모두 지정된 경우 서비스에서 x-ms-range의 값이 사용됩니다. 자세한 내용은 Blob 서비스 작업의 범위 헤더 지정을 참조하십시오.

Content-Length

필수 사항입니다. 요청 본문에 전송 중인 바이트 수를 지정합니다. x-ms-page-write 헤더가 clear로 설정되었으면 이 헤더 값을 0으로 설정해야 합니다.

Content-MD5

선택 사항입니다. 페이지 콘텐츠의 MD5 해시입니다. 이 해시는 전송 중 페이지의 무결성을 확인하는 데 사용됩니다. 이 헤더를 지정하면 저장소 서비스가 도착한 콘텐츠의 해시를 전송된 헤더 값과 비교합니다. 두 해시가 일치하지 않으면 작업이 실패하고 오류 코드 400(잘못된 요청)이 표시됩니다.

Content-MD5 헤더가 x-ms-page-write로 설정된 경우 clear 헤더가 허용되지 않습니다. 요청에 포함된 경우 Blob 서비스가 상태 코드 400(잘못된 요청)을 반환합니다.

x-ms-page-write: {update | clear}

필수 사항입니다. 다음 옵션 중 하나를 지정할 수 있습니다.

  • Update: 요청 본문으로 지정된 바이트를 지정된 범위에 기록합니다. 업데이트를 수행하려면 RangeContent-Length 헤더가 일치해야 합니다.

  • Clear: 지정된 범위를 지우고 해당 범위에 대해 저장소에 사용된 공간을 해제합니다. 범위를 지우려면 Content-Length 헤더를 0으로 설정하고 Range 헤더를 지우려는 범위를 나타내는 값(최대 blob 크기까지)으로 설정합니다.

x-ms-lease-id:<ID>

blob에 활성 임대가 포함된 경우 필수입니다. 활성 임대가 포함된 blob에서 이 작업을 수행하려면 이 헤더에 대해 유효한 임대 ID를 지정합니다.

x-ms-if-sequence-number-le: <num>

선택 사항입니다. blob의 시퀀스 번호가 지정된 값보다 작거나 같으면 요청이 진행되고, 그렇지 않으면 요청이 실패하고 SequenceNumberConditionNotMet 오류(HTTP 상태 코드 412 – 전제 조건 실패)가 나타납니다.

x-ms-if-sequence-number-lt: <num>

선택 사항입니다. blob의 시퀀스 번호가 지정된 값보다 작으면 요청이 진행되고, 그렇지 않으면 요청이 실패하고 SequenceNumberConditionNotMet 오류(HTTP 상태 코드 412 – 전제 조건 실패)가 나타납니다.

x-ms-if-sequence-number-eq: <num>

선택 사항입니다. blob의 시퀀스 번호가 지정된 값과 동일하면 요청이 진행되고, 그렇지 않으면 요청이 실패하고 SequenceNumberConditionNotMet 오류(HTTP 상태 코드 412 – 전제 조건 실패)가 나타납니다.

If-Modified-Since

선택 사항입니다. DateTime 값입니다. 지정된 날짜/시간 이후 blob가 수정된 경우에만 페이지를 기록하려면 이 조건부 헤더를 지정합니다. blob가 수정되지 않은 경우 Blob 서비스가 상태 코드 412(전제 조건 실패)를 반환합니다.

If-Unmodified-Since

선택 사항입니다. DateTime 값입니다. 지정된 날짜/시간 이후 blob가 수정되지 않은 경우에만 페이지를 기록하려면 이 조건부 헤더를 지정합니다. blob가 수정된 경우 Blob 서비스가 상태 코드 412(전제 조건 실패)를 반환합니다.

If-Match

선택 사항입니다. ETag 값입니다. blob의 ETag 값이 지정된 값과 일치하는 경우에만 페이지를 기록하도록 이 조건부 헤더에 대한 ETag 값을 지정합니다. 값이 일치하지 않으면 Blob 서비스가 상태 코드 412(전제 조건 실패)를 반환합니다.

If-None-Match

선택 사항입니다. ETag 값입니다.

blob의 ETag 값이 지정된 값과 일치하지 않는 경우에만 페이지를 기록하도록 이 조건부 헤더에 대한 ETag 값을 지정합니다. 값이 동일하면 Blob 서비스가 상태 코드 412(전제 조건 실패)를 반환합니다.

x-ms-client-request-id

선택 사항입니다. 저장소 분석 로깅을 사용하도록 설정한 경우 분석 로그에 기록된 1KB 문자 제한의 클라이언트에서 생성한 불투명 값을 제공합니다. 클라이언트 쪽 작업과 서버가 받은 요청의 상관 관계를 지정하는 데 이 헤더를 사용하는 것이 좋습니다. 자세한 내용은 저장소 분석 로깅 정보Microsoft Azure 로깅: 로그를 사용하여 저장소 요청 추적을 참조하십시오.

이 작업은 또한 지정된 조건이 충족될 경우에만 작업을 실행하는 조건부 헤더 사용을 지원합니다. 자세한 내용은 Blob 서비스 작업의 조건부 헤더 지정를 참조하십시오.

요청 본문에는 페이지 콘텐츠가 포함됩니다.


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

Request Headers:
x-ms-page-write: update
x-ms-date: Fri, 16 Sep 2011 22:15:50 GMT
x-ms-version: 2011-08-18
x-ms-range: bytes=0-65535
Authorization: SharedKey myaccount:4KdWDiTdA9HmIF9+WF/8WfYOpUrFhieGIT7f0av+GEI=
Content-Length: 65536


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

Request Headers:
Range: bytes=1024-2048
x-ms-page-write: clear
x-ms-date: Sun, 25 Sep 2011 23:37:35 GMT
x-ms-version: 2011-08-18
Authorization: SharedKey myaccount:4KdWDiTdA9HmIF9+WF/8WfYOpUrFhieGIT7f0av+GEI=

응답에는 HTTP 상태 코드 및 응답 헤더 집합이 포함되어 있습니다.

작업에 성공하면 상태 코드 201(만들어짐)이 반환됩니다.

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

이 작업의 응답에는 다음과 같은 헤더가 포함됩니다. 응답에는 추가 표준 HTTP 헤더가 포함될 수도 있습니다. 모든 표준 헤더는 HTTP/1.1 프로토콜 사양을 따릅니다.

 

구문 설명

ETag

blob의 ETag입니다. 요청 버전이 2011-08-18 이상이면 ETag 값이 따옴표로 표시됩니다. ETag를 사용하면 If-Match 또는 If-None-Match 요청 헤더에 대한 값을 지정하여 조건부 Put Page 작업을 수행할 수 있습니다.

Last-Modified

blob를 마지막으로 수정한 날짜와 시간입니다. 날짜 형식은 RFC 1123을 따릅니다. 자세한 내용은 헤더의 날짜/시간 값 표현을 참조하십시오.

blob의 메타데이터 또는 속성에 대한 업데이트를 포함하여 blob에 대해 쓰기 작업을 수행할 때마다 blob의 마지막 수정 시간이 변경됩니다.

Content-MD5

이 헤더는 클라이언트가 메시지 콘텐츠 무결성을 확인할 수 있도록 반환됩니다. 이 헤더 값은 Blob 서비스에 의해 계산되며, 요청 헤더에 지정된 것과 동일한 값일 필요는 없습니다.

x-ms-blob-sequence-number

페이지 blob의 현재 시퀀스 번호입니다.

x-ms-request-id

이 헤더는 수행된 요청을 고유하게 식별하며, 이 헤더를 사용해서 요청 문제를 해결할 수 있습니다. 자세한 내용은 API 작업 문제 해결를 참조하십시오.

x-ms-version

요청을 실행하는 데 사용되는 Blob 서비스의 버전을 나타냅니다. 이 헤더는 2009-09-19 버전 이상에 대해 수행된 요청에 대해 반환됩니다.

Date

응답이 시작된 시간을 나타내는 서비스에서 생성된 UTC 날짜/시간 값입니다.

없음.

Response Status:
HTTP/1.1 201 Created

Response Headers:
Transfer-Encoding: chunked
Content-MD5: sQqNsWTgdUEFt6mb5y4/5Q==
Date: Sun, 25 Sep 2011 22:33:35 GMT
ETag: "0x8CB171BA9E94B0B"
Last-Modified: Sun, 25 Sep 2011 12:13:31 GMT
x-ms-version: 2011-08-18
x-ms-blob-sequence-number: 0
Content-Length: 0
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

이 작업은 계정 소유자 또는 이 blob 또는 해당 콘텐츠에 쓰기 권한이 있는 공유 액세스 서명을 갖고 있는 모든 사용자가 호출할 수 있습니다.

Put Page 작업은 페이지 blob에 일정 범위의 페이지를 기록합니다. 이 작업은 기존 페이지 blob에서만 호출할 수 있습니다. 새 페이지 blob를 만들기 위해 호출하거나 블록 blob에서 호출할 수 없습니다. 현재 존재하지 않는 blob 이름을 사용해서 Put Page를 호출하면 BlobNotFound 오류(HTTP 상태 코드 404 – 찾을 수 없음)가 반환됩니다.

새 페이지 blob를 만들려면 Blob 배치를 호출하고 페이지 blob로 만들려는 blob 유형을 지정합니다. 페이지 blob 크기는 최대 1TB일 수 있습니다.

blob에 활성 임대가 포함된 경우 페이지를 기록하려면 클라이언트가 요청에 유효한 임대 ID를 지정해야 합니다.

페이지 업데이트 작업

Update 옵션을 사용하여 Put Page를 호출하면 지정된 페이지 blob에서 내부 쓰기가 수행됩니다. 업데이트를 수행하면 지정된 페이지의 콘텐츠를 덮어씁니다.

Important중요
Put Page 중에 서버 시간이 초과되거나 연결이 닫혔을 때 페이지가 업데이트되거나 업데이트되지 않았을 수 있습니다. 따라서 성공을 나타내는 응답을 받을 때까지 계속해서 업데이트를 다시 시도해야 합니다.

업데이트 작업을 위해 Put Page에 제출된 각 페이지 범위는 크기가 최대 4MB일 수 있습니다. 이 페이지의 시작 및 끝 범위는 512바이트 경계로 정렬되어야 합니다. 크기가 4MB보다 큰 페이지 범위를 업로드하려고 시도하면 서비스에서 상태 코드 413(요청 엔터티 너무 큼)이 반환됩니다.

페이지 지우기 작업

Clear 옵션을 사용하여 Put Page를 호출하면 지정된 페이지에서 사용되는 저장소 공간이 해제됩니다. 지워진 페이지는 더 이상 페이지 blob의 일부로 추적되지 않습니다.

지워진 페이지는 해당 저장소 리소스가 해제되었으므로, 더 이상 저장소 계정 요금으로 부과되지 않습니다. 이에 대한 유일한 예외는 페이지 blob에 대한 기존 스냅숏이 있는 경우입니다. 스냅숏에 있는 페이지는 동일 페이지가 원본 blob의 일부로 존재하지 않더라도 요금이 부과됩니다.

동시성 관리 문제

Blob 서비스는 겹치는 페이지에 대한 동시 쓰기를 순차적으로 처리합니다. 서비스에서 마지막으로 처리된 페이지에 따라 blob의 콘텐츠가 결정됩니다. 따라서 blob 콘텐츠의 무결성을 보장하기 위해서는 클라이언트가 다음 방법 중 하나 이상을 사용해서 겹치는 페이지에 대한 쓰기를 처리해야 합니다.

  • Put Page에 대해 성공한 각 호출에 대해 Last-Modified 응답 헤더 값을 확인할 수 있습니다. Blob 서비스로부터 반환된 응답 순서가 서비스에서 실행된 순서와 반드시 일치하지는 않습니다. 하지만 Last-Modified 값은 항상 서비스가 요청을 처리한 순서를 나타냅니다.

  • 낙관적 동시성을 사용해서 blob의 ETag 또는 마지막으로 수정된 시간에 따라 조건부로 업데이트를 수행할 수 있습니다. 이 방법은 동시 쓰기 작업 수가 비교적 적은 경우에 적합합니다. 이 목적을 위해서는 조건부 요청 헤더 If-Match, If-None-Match, If-Modified-SinceIf-Unmodified-Since를 사용합니다.

  • Blob 임대를 호출하여 1분 동안 또는 임대가 갱신된 경우 이보다 긴 시간 동안 다른 쓰기 작업을 수행하지 못하도록 blob를 잠글 수 있습니다.

  • blob의 시퀀스 번호를 사용해서 응답이 없는 요청을 다시 시도해도 동시 업데이트가 발생하지 않도록 보장할 수 있습니다. 이 방법은 높은 페이지 쓰기 처리량이 필요한 클라이언트에 가장 적합할 수 있습니다. 이에 대한 자세한 설명은 다음 섹션을 참조하십시오.

페이지 Blob 시퀀스 번호를 사용해서 요청 다시 시도

Put Page 호출이 시간 초과되거나 응답을 반환하지 않는 경우 해당 요청이 확실히 성공했는지 여부를 확인할 수 있는 방법이 없습니다. 따라서 요청을 다시 시도해야 할 수 있지만, Windows Azure 저장소 서비스의 분산 특성으로 인해 다시 시도한 요청이 성공한 후에 원래 요청이 처리될 수도 있습니다. 그 결과 지연되었던 원래 요청이 업데이트된 다른 항목을 덮어써서 예기치 않은 결과가 발생할 수 있습니다. 다음 시퀀스에서는 이러한 경우를 보여줍니다.

  1. 페이지 0에 값 "X"를 쓰려는 Put Page 요청이 시간 초과되어 응답이 반환되지 않습니다.

  2. 페이지 0에 값 "X"를 쓰려는 다시 시도된 요청이 성공합니다.

  3. 페이지 0에 값 "Y"를 쓰려는 요청이 성공합니다.

  4. 원래 요청이 성공하여 페이지 0에 값 "X"가 기록됩니다.

  5. 이제 클라이언트에 값 "Y"가 포함되어야 하지만 페이지 0을 읽으면 값 "X"가 반환됩니다.

이러한 종류의 충돌은 원래 요청이 상태 코드 100-499 사이 또는 503(서버 작업 중)을 반환하지 않는 경우에 발생할 수 있습니다. 이러한 상태 코드 중 하나가 반환되면 해당 요청이 성공 또는 실패했는지를 확인할 수 있습니다. 하지만 서비스가 이 범위 이외의 상태 코드를 반환하면 원래 요청의 상태를 확인할 수 있는 방법이 없습니다.

이러한 종류의 충돌을 방지하기 위해서는 요청을 다시 시도할 때 원래 요청이 이후에 성공하지 않도록 보장하기 위해 페이지 blob의 시퀀스 번호를 사용할 수 있습니다. 이렇게 하려면 원래 요청을 다시 시도하기 전에 시퀀스 번호를 증분해야 합니다. 그런 후 조건부 시퀀스 번호 헤더를 사용해서 시퀀스 번호가 예상한 시퀀스 번호와 일치하지 않으면 요청이 실패했는지 확인할 수 있습니다. 다음 시퀀스에서는 이러한 방법을 보여줍니다.

  1. 클라이언트가 Blob 배치를 사용해서 페이지 blob를 만들고 해당 시퀀스 번호를 0으로 설정합니다.

  2. if-sequence-number-lt 헤더를 1로 설정해서 페이지 0에 값 "X"를 쓰려는 Put Page 요청이 시간 초과되거나 응답을 반환하지 않습니다.

  3. 클라이언트가 시퀀스 번호를 1로 업데이트하기 위해 Set Blob 속성을 호출합니다.

  4. if-sequence-number-lt2로 설정해서 페이지 0에 값 "X"를 쓰려는 다시 시도된 요청이 성공합니다.

  5. if-sequence-number-lt2로 설정해서 페이지 0에 값 "Y"를 쓰려는 요청이 성공합니다.

  6. 원래 요청이 결국 처리되었지만 시퀀스 번호가 1보다 작아야 하는 조건을 지정하므로 요청이 실패합니다(즉, if-sequence-num-lt 헤더가 1로 설정됨). 오류는 SequenceNumberConditionNotMet(HTTP 상태 코드 412 – 전제 조건 실패)입니다.

  7. 페이지 0을 읽으면 예상한 대로 값 "Y"가 반환됩니다.

표시:
© 2014 Microsoft