Skip to main content
이 제품의 최신 릴리즈를 사용할 수 있습니다.
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

S3 PutObject 요청을 사용하여 StorageGRID의 버킷에 객체 추가

S3 PutObject 요청을 사용하여 버킷에 객체를 추가할 수 있습니다.

충돌 해결

두 클라이언트가 동일한 키에 쓰기를 시도하는 등 클라이언트 요청이 충돌하는 경우 "최신 요청 우선" 원칙에 따라 처리됩니다. "최신 요청 우선" 평가 시점은 S3 클라이언트가 작업을 시작한 시점이 아니라 StorageGRID 시스템이 해당 요청을 완료한 시점을 기준으로 합니다.

객체 크기

단일 PutObject 작업에 권장되는 최대 크기는 5GiB(5,368,709,120바이트)입니다. 객체 크기가 5GiB보다 큰 경우, "멀티파트 업로드"을 사용하십시오.

단일 PutObject 작업에 대해 지원되는 최대 크기는 5TiB(5,497,558,138,880바이트)입니다.

참고 StorageGRID 11.6 이하 버전에서 업그레이드한 경우, 5GiB를 초과하는 객체를 업로드하려고 하면 S3 PUT Object size too large 경고가 트리거됩니다. StorageGRID 11.7 또는 11.8을 새로 설치한 경우에는 이 경우 경고가 트리거되지 않습니다. 하지만 AWS S3 표준을 준수하기 위해 향후 StorageGRID 릴리스에서는 5GiB보다 큰 객체 업로드를 지원하지 않을 예정입니다.

사용자 메타데이터 크기

Amazon S3는 각 PUT 요청 헤더 내 사용자 정의 메타데이터의 크기를 2KB로 제한합니다. StorageGRID는 사용자 메타데이터를 24KiB로 제한합니다. 사용자 정의 메타데이터의 크기는 각 키와 값의 UTF-8 인코딩 바이트 수를 합산하여 측정합니다.

사용자 메타데이터의 UTF-8 문자

요청에 사용자 정의 메타데이터의 키 이름 또는 값에 (이스케이프되지 않은) UTF-8 값이 포함된 경우 StorageGRID 동작은 정의되지 않습니다.

StorageGRID는 사용자 정의 메타데이터의 키 이름 또는 값에 포함된 이스케이프 처리된 UTF-8 문자를 구문 분석하거나 해석하지 않습니다. 이스케이프 처리된 UTF-8 문자는 ASCII 문자로 처리됩니다.

  • PutObject, CopyObject, GetObject, and HeadObject 요청은 사용자 정의 메타데이터에 이스케이프된 UTF-8 문자가 포함된 경우 성공합니다.

  • StorageGRID는 키 이름이나 값의 해석된 값에 인쇄할 수 없는 문자가 포함된 경우 x-amz-missing-meta 헤더를 반환하지 않습니다.

객체 태그 제한

새 객체를 업로드할 때 태그를 추가하거나 기존 객체에 태그를 추가할 수 있습니다. StorageGRID와 Amazon S3 모두 객체당 최대 10개의 태그를 지원합니다. 객체와 연결된 태그는 고유한 태그 키를 가져야 합니다. 태그 키는 최대 128자의 유니코드 문자, 태그 값은 최대 256자의 유니코드 문자까지 사용할 수 있습니다. 키와 값은 대소문자를 구분합니다.

객체 소유권

StorageGRID에서 모든 객체는 버킷 소유자 계정이 소유합니다. 여기에는 소유자가 아닌 계정이나 익명 사용자가 생성한 객체도 포함됩니다.

지원되는 요청 헤더

다음과 같은 요청 헤더가 지원됩니다.

  • Cache-Control

  • Content-Disposition

  • Content-Encoding

    `aws-chunked`을(를) ``Content-Encoding``에 대해 지정하면 StorageGRID 는 다음 항목을 확인하지 않습니다.
    • StorageGRID는 청크 데이터에 대해 `chunk-signature`의 유효성을 검사하지 않습니다.

    • StorageGRID는 사용자가 제공하는 값을 x-amz-decoded-content-length 객체와 비교하여 검증하지 않습니다.

  • Content-Language

  • Content-Length

  • Content-MD5

  • Content-Type

  • Expires

  • Transfer-Encoding

    청크 전송 인코딩은 aws-chunked 페이로드 서명도 함께 사용되는 경우에 지원됩니다.

  • x-amz-checksum-sha256

  • x-amz-meta-, 그 뒤에 사용자 정의 메타데이터를 포함하는 이름-값 쌍이 옵니다.

    사용자 정의 메타데이터의 이름-값 쌍을 지정할 때 다음 일반 형식을 사용하십시오.

    x-amz-meta-name: value

    ILM 규칙의 참조 시간으로 사용자 정의 생성 시간 옵션을 사용하려면 `creation-time`을(를) 객체가 생성된 시점을 기록하는 메타데이터의 이름으로 사용해야 합니다. 예를 들면 다음과 같습니다.

    x-amz-meta-creation-time: 1443399726
    `creation-time`의 값은 1970년 1월 1일 이후 경과된 초 단위로 평가됩니다.
    참고 ILM 규칙은 참조 시간에 대해 *사용자 정의 생성 시간*을 사용하면서 동시에 균형 또는 엄격 수집 옵션을 사용할 수 없습니다. ILM 규칙을 생성할 때 오류가 반환됩니다.
  • x-amz-tagging

  • S3 객체 잠금 요청 헤더

    • x-amz-object-lock-mode

    • x-amz-object-lock-retain-until-date

    • x-amz-object-lock-legal-hold

      이러한 헤더 없이 요청이 이루어지면 버킷의 기본 보존 설정이 객체 버전 모드와 보존 만료일을 계산하는 데 사용됩니다. "S3 REST API를 사용하여 S3 Object Lock 구성"을 참조하십시오.

  • SSE 요청 헤더:

    • x-amz-server-side-encryption

    • x-amz-server-side-encryption-customer-key-MD5

    • x-amz-server-side-encryption-customer-key

    • x-amz-server-side-encryption-customer-algorithm

지원되지 않는 요청 헤더

다음 요청 헤더는 지원되지 않습니다.

  • If-Match

    `If-Match header`은(는) 승인되었지만 작동하지 않습니다.
  • If-None-Match

    `If-None-Match header`은(는) 승인되었지만 작동하지 않습니다.
  • x-amz-acl

  • x-amz-sdk-checksum-algorithm

  • x-amz-trailer

  • x-amz-website-redirect-location

    The x-amz-website-redirect-location 헤더는 `XNotImplemented`을 반환합니다.

스토리지 클래스 옵션

`x-amz-storage-class` 요청 헤더가 지원됩니다.  `x-amz-storage-class`에 제출된 값은 StorageGRID 수집 중에 객체 데이터를 보호하는 방식에 영향을 미치며, StorageGRID 시스템에 객체의 영구 복사본이 몇 개 저장되는지(ILM에 의해 결정됨)에는 영향을 미치지 않습니다.

수집된 객체와 일치하는 ILM 규칙이 엄격한 수집 옵션을 사용하는 경우 x-amz-storage-class 헤더는 아무런 효과가 없습니다.

다음 값을 사용할 수 있습니다 x-amz-storage-class:

  • STANDARD (기본값)

    • 듀얼 커밋: ILM 규칙에서 수집 동작에 대해 듀얼 커밋 옵션을 지정한 경우, 객체가 수집되는 즉시 해당 객체의 두 번째 복사본이 생성되어 다른 스토리지 노드에 배포됩니다(듀얼 커밋). ILM을 평가할 때 StorageGRID는 이러한 초기 임시 복사본이 규칙의 배치 지침을 충족하는지 확인합니다. 충족하지 않는 경우, 다른 위치에 새 객체 복사본을 생성하고 초기 임시 복사본을 삭제해야 할 수 있습니다.

    • 균형: ILM 규칙에 균형 옵션이 지정되어 있고 StorageGRID가 규칙에 지정된 모든 복사본을 즉시 생성할 수 없는 경우 StorageGRID는 서로 다른 스토리지 노드에 두 개의 임시 복사본을 생성합니다.

      StorageGRID가 ILM 규칙에 지정된 모든 객체 복사본을 즉시 생성할 수 있는 경우(동기 배치), x-amz-storage-class 헤더는 아무런 효과가 없습니다.

  • REDUCED_REDUNDANCY

    • 듀얼 커밋: ILM 규칙에서 수집 동작에 대해 듀얼 커밋 옵션을 지정한 경우, StorageGRID는 객체가 수집될 때 단일 임시 복사본을 생성합니다(싱글 커밋).

    • 균형: ILM 규칙에 균형 옵션이 지정된 경우, StorageGRID 시스템이 규칙에 지정된 모든 복사본을 즉시 생성할 수 없는 경우에만 임시 복사본을 하나만 생성합니다. StorageGRID 동기 배치를 수행할 수 있는 경우에는 이 헤더가 아무런 효과가 없습니다. 이 REDUCED_REDUNDANCY 옵션은 객체와 일치하는 ILM 규칙이 단일 복제본을 생성하는 경우에 가장 적합합니다. 이 경우 `REDUCED_REDUNDANCY`를 사용하면 모든 수집 작업마다 불필요한 객체 복사본 생성 및 삭제를 방지할 수 있습니다.

    다른 상황에서는 REDUCED_REDUNDANCY 옵션을 사용하는 것을 권장하지 않습니다. `REDUCED_REDUNDANCY`은(는) 수집 중 오브젝트 데이터 손실 위험을 증가시킵니다. 예를 들어, ILM 평가가 수행되기 전에 장애가 발생한 Storage Node에 단일 복사본이 처음에 저장되는 경우 데이터를 손실할 수 있습니다.

주의 특정 기간 동안 복제본이 하나만 존재하는 경우 데이터가 영구적으로 손실될 위험이 있습니다. 객체의 복제본이 하나만 있는 경우 스토리지 노드에 장애가 발생하거나 중대한 오류가 발생하면 해당 객체가 손실됩니다. 또한 업그레이드와 같은 유지 관리 절차 중에도 해당 객체에 대한 액세스가 일시적으로 제한됩니다.

이 설정을 지정하면 REDUCED_REDUNDANCY 객체가 처음 수집될 때 생성되는 복사본 수에만 영향을 미칩니다. 활성 ILM 정책에 따라 객체를 평가할 때 생성되는 객체 복사본 수에는 영향을 미치지 않으며, StorageGRID 시스템에서 데이터가 더 낮은 수준의 중복성으로 저장되는 결과를 초래하지도 않습니다.

참고 S3 객체 잠금이 활성화된 버킷에 객체를 수집하는 경우 REDUCED_REDUNDANCY 옵션은 무시됩니다. 레거시 규정 준수 버킷에 객체를 수집하는 경우 REDUCED_REDUNDANCY 옵션은 오류를 반환합니다. StorageGRID는 규정 준수 요구 사항을 충족하기 위해 항상 이중 커밋 수집을 수행합니다.

서버 측 암호화에 대한 요청 헤더

다음 요청 헤더를 사용하여 서버 측 암호화로 객체를 암호화할 수 있습니다. SSE와 SSE-C 옵션은 상호 배타적입니다.

  • SSE: StorageGRID에서 관리하는 고유 키로 객체를 암호화하려면 다음 헤더를 사용하십시오.

    • x-amz-server-side-encryption

      `x-amz-server-side-encryption` 헤더가 PutObject 요청에 포함되지 않으면 grid-wide link:../admin/changing-network-options-object-encryption.html["저장된 객체 암호화 설정"]가 PutObject 응답에서 생략됩니다.
  • SSE-C: 직접 제공하고 관리하는 고유 키로 객체를 암호화하려면 이 세 가지 헤더를 모두 사용하십시오.

    • x-amz-server-side-encryption-customer-algorithm: `AES256`을(를) 지정합니다.

    • x-amz-server-side-encryption-customer-key: 새 객체에 사용할 암호화 키를 지정하십시오.

    • x-amz-server-side-encryption-customer-key-MD5: 새 객체의 암호화 키의 MD5 다이제스트를 지정합니다.

주의 고객이 제공하는 암호화 키는 절대 저장되지 않습니다. 암호화 키를 분실하면 해당 객체도 손실됩니다. 고객이 제공한 키를 사용하여 객체 데이터를 보호하기 전에 "서버 측 암호화 사용"에 대한 고려 사항을 검토하십시오.
참고 객체가 SSE 또는 SSE-C로 암호화된 경우 버킷 수준 또는 그리드 수준의 암호화 설정은 무시됩니다.

버전 관리

버킷에 버전 관리가 활성화된 경우, 저장된 객체의 버전에 대한 고유 `versionId`가 자동으로 생성됩니다. 이 `versionId`는 `x-amz-version-id`응답 헤더를 사용하여 응답에도 반환됩니다.

버전 관리가 일시 중단되면 객체 버전은 null `versionId`으로 저장되며, 이미 null 버전이 존재하는 경우 덮어쓰여집니다.

Authorization 헤더에 대한 서명 계산

`Authorization` 헤더를 사용하여 요청을 인증할 때 StorageGRID는 다음과 같은 점에서 AWS와 다릅니다.
  • StorageGRID는 헤더를 host 내에 포함할 필요가 없습니다 CanonicalHeaders.

  • StorageGRID는 Content-Type`이(가) `CanonicalHeaders 내에 포함될 필요가 없습니다.

  • StorageGRID는 x-amz-* 헤더가 CanonicalHeaders 안에 포함될 필요가 없습니다.

참고 일반적으로 이러한 헤더를 항상 CanonicalHeaders 내에 포함하여 검증하는 것이 좋습니다. 하지만 이러한 헤더를 제외하더라도 StorageGRID는 오류를 반환하지 않습니다.