객체 메타데이터

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

예시로 이동

이 페이지에서는 객체와 함께 Cloud Storage에 저장되는 메타데이터 필드를 설명합니다.

소개

Cloud Storage에 저장된 객체에는 연결된 메타데이터가 있습니다. 메타데이터는 객체의 속성을 식별하며 객체에 액세스할 때 객체를 어떻게 처리해야 하는지 지정합니다. 메타데이터는 키:값 쌍으로 존재합니다. 예를 들어 객체의 스토리지 클래스는 메타데이터 항목 storageClass:STANDARD로 표현됩니다. storageClass는 메타데이터의 이고 모든 객체에는 이러한 키가 연결되어 있습니다. STANDARD는 이 특정 객체의 을 지정하며 값은 객체마다 다릅니다.

메타데이터의 변경 가능성은 메타데이터마다 다릅니다. 언제든지 수정할 있는 메타데이터가 있고 객체를 만들 때만 설정할 수 있는 메타데이터가 있습니다. 또한 볼 수만 있는 메타데이터가 있습니다. 예를 들어 언제든지 Cache-Control 메타데이터 값을 수정할 수 있지만 객체가 생성되거나 다시 작성될 때만 storageClass 메타데이터를 할당할 수 있습니다. 또한 generation 메타데이터 값을 직접 수정할 수 없으며 객체를 대체하면 generation 값이 변경됩니다.

수정 가능한 메타데이터

객체에 대해 사용자가 변경할 수 있는 메타데이터에는 다음과 같은 두 가지 카테고리가 있습니다.

  • 고정 키 메타데이터: 키가 설정되어 있지만 사용자가 값을 지정할 수 있는 메타데이터입니다.

  • 맞춤 메타데이터: 사용자가 키 및 키와 연결된 값을 모두 지정하여 추가하는 메타데이터입니다.

메타데이터를 수정할 때 대개 비 ASCII 문자는 피해야 합니다. XML API가 사용하는 HTTP 헤더에서는 비 ASCII 문자가 허용되지 않기 때문입니다. 또한 XML API를 사용할 때 요청 URL과 HTTP 헤더를 합친 크기가 16KB로 제한되므로 총 메타터이터 크기에서 이 제한을 고려해야 합니다.

고정 키 메타데이터

다음과 같은 객체 메타데이터를 수정할 수 있습니다. 단, 이를 위한 충분한 권한이 있어야 합니다.

액세스 제어 메타데이터

Cloud Storage는 Identity and Access Management(IAM)액세스제어 목록(ACL)을 사용하여 객체에 대한 액세스 권한을 제어합니다. 액세스 제어 방법과 관련 메타데이터에 대해 알아보려면 다음 링크를 사용하세요.

Cache-Control

Cache-Control 메타데이터는 Cloud Storage에서 데이터가 제공되는 방식의 두 가지 측면, 즉 데이터를 캐시할 수 있는지 여부와 데이터를 변환할 수 있는지 여부를 지정할 수 있습니다.

데이터 캐시하기

Cache-Control 메타데이터를 사용하면 브라우저 캐시와 인터넷 캐시가 객체를 캐시할 수 있는지 여부와 캐시할 수 있는 기간을 제어할 수 있으며, 이를 통해 미래의 요청을 충족할 수 있습니다. Cache-Control은 다음에 해당하는 객체에 액세스할 때만 적용됩니다.

Cloud Storage는 다음과 같이 Cache-Control표준 값을 준수합니다.

  • public: 객체가 어디서나 캐시될 수 있습니다.

  • private: 객체가 요청자의 로컬 캐시에 캐시될 수 있습니다.

  • no-cache: 객체가 캐시될 수 있지만 Cloud Storage에 의해 검증되기 전에는 이후 요청을 충족하는 데 사용될 수 없습니다.

  • no-store: 객체가 캐시될 수 없습니다.

  • max-age=TIME_IN_SECONDS: 객체가 비활성으로 간주되기 전에 캐시될 수 있는 기간입니다. max-age를 원하는 길이의 시간으로 설정할 수 있습니다. 특수한 상황을 제외하고 비활성 객체는 캐시에서 제공되지 않습니다.

적용 가능한 객체에 Cache-Control 메타데이터 항목이 없으면 Cloud Storage가 다음에 기본값을 사용합니다.

  • public, max-age=3600

캐싱을 허용하면 더 새로운 객체 버전을 업로드 한 후에도 객체의 이전 버전이 계속 다운로드될 수 있습니다. 이는 max-age에 의해 결정되는 기간 동안에는 이전 버전이 캐시에서 "새로운" 상태인 것으로 유지되기 때문입니다. 또한 인터넷의 다양한 공간에서 객체가 캐시될 수 있기 때문에 캐시된 객체가 모두 만료되게 할 수 있는 방법은 없습니다. 공개적으로 읽을 수 있는 객체의 캐시된 버전을 제공하지 않으려면 객체에 Cache-Control: no-store을 설정합니다.

Cloud Storage 및 Cloud CDN을 사용한 캐싱에 대한 자세한 내용은 캐싱을 참조하세요.

캐시 동작을 보다 세부적으로 제어해야 하는 경우 버킷 앞에 Cloud CDN을 구성할 수 있습니다.

데이터 변환

Cache-Control 메타데이터를 사용하면 객체가 저장될 때 호환되지 않는 클라이언트의 gzip 콘텐츠 인코딩 삭제와 같이 변환을 데이터에 적용하지 않고 객체를 제공할 수도 있습니다. 객체를 그대로 제공하려면 Cache-Control:no-transform을 설정합니다.

Content-Disposition

Content-Disposition 메타데이터는 전송 중인 데이터에 대한 표시 정보를 지정합니다. Content-Disposition을 설명하면 콘텐츠의 표시 스타일을 제어할 수 있습니다. 예를 들어 첨부파일을 자동으로 표시할지 또는 첨부파일을 열기 위해 일정한 형태의 사용자 작업이 필요한지 여부를 결정할 수 있습니다. Content-Disposition 사양은 https://datatracker.ietf.org/doc/html/rfc6266을 참조하세요.

Content-Encoding

Content-Encoding 메타데이터를 사용하여 객체의 기반 Content-Type을 유지하면서 객체가 압축되었음을 나타낼 수 있습니다. 예를 들어 gzip으로 압축된 텍스트 파일은 Content-Type에 지정된 텍스트 파일이라는 팩트와 Content-Encoding에 지정된 gzip 압축 파일이라는 팩트를 가질 수 있습니다. 파일을 업로드하기 전에 지정된 Content-Encoding을 사용하여 파일이 압축되었는지 확인해야 합니다. 그렇지 않으면 객체를 다운로드할 때 예기치 않은 동작이 발생할 수 있습니다. 자세한 내용은 트랜스코딩 페이지를 참조하세요.

텍스트와 같이 압축 가능한 콘텐츠의 경우 Content-Encoding: gzip을 사용하면 네트워크 및 스토리지 비용이 절약되고 콘텐츠 제공 성능이 향상됩니다. 그러나 보관 파일 및 많은 미디어 형식과 같이 이미 압축된 콘텐츠의 경우 다른 수준의 압축을 적용하고 Content-Encoding 메타데이터에 표시하면 객체 크기와 성능에 악영향을 미치므로 이를 피해야 합니다.

Content-Language

Content-Language 메타데이터는 객체가 어느 언어를 대상으로 하는지 나타냅니다. 이 메타데이터에서 지원하는 값은 ISO 639-1 언어 코드를 참조하세요.

Content-Type

가장 일반적으로 설정되는 메타데이터는 Content-Type(미디어 유형이라고도 함)입니다. 이를 통해 브라우저가 객체를 제대로 렌더링할 수 있습니다. 모든 객체에는 Content-Type 메타데이터에 지정된 값이 있지만 이 값은 객체의 기본 유형과 일치하지 않을 수도 있습니다. 예를 들어 Content-Type이 업로더에서 지정되지 않아 확인될 수 없으면 객체를 업로드한 방법에 따라 application/octet-stream 또는 application/x-www-form-urlencoded로 설정됩니다. 유효한 콘텐츠 유형 목록은 IANA 미디어 유형 페이지를 참조하세요.

Custom-Time

Custom-Time 메타데이터는 밀리초가 0일 때 RFC 3339 형식 YYYY-MM-DD'T'HH:MM:SS.SS'Z' 또는 YYYY-MM-DD'T'HH:MM:SS'Z'로 표현되는 사용자 지정 날짜와 시간입니다. 일반적으로 이 메타데이터는 객체 수명 주기 관리에서 DaysSinceCustomTime 조건을 사용하도록 설정됩니다.

Custom-Time이 객체에 설정된 후에는 삭제할 수 없습니다. 또한 Custom-Time의 값은 줄일 수 없습니다. 즉, Custom-Time을 기존 Custom-Time보다 앞선 날짜/시간으로 설정할 수 없습니다. 그러나 객체를 재작성하여 Custom-Time을 효과적으로 삭제하거나 재설정할 수 있습니다.

객체 보존 조치

메타데이터 플래그를 사용하여 객체 보존 조치를 적용하면 객체가 삭제되거나 대체되지 않습니다. 자세한 내용은 객체 보존 조치 페이지를 참조하세요.

커스텀 메타데이터

커스텀 메타데이터는 키와 값을 모두 정의하는 메타데이터입니다. 커스텀 메타데이터를 만들려면 키와 값을 모두 지정합니다. 커스텀 메타데이터 key:value 쌍을 만든 후 키를 삭제하거나 값을 변경할 수 있습니다. 커스텀 메타데이터에는 크기 제한이 적용되며 스토리지 비용이 발생합니다.

메타데이터 보기 및 수정 페이지에는 커스텀 메타데이터 설정과 관련된 정보가 들어 있습니다.

x-goog-meta- 프리픽스

XML API는 요청 헤더를 사용하여 객체 메타데이터를 설정하고 검색합니다. 커스텀 메타데이터 헤더를 표준 요청 헤더와 명확히 구분하기 위해 XML API는 커스텀 메타데이터 헤더의 프리픽스로 x-goog-meta-를 사용합니다.

XML API를 사용하는 일부 도구도 이 규칙을 적용합니다. 예를 들어 gsutil로 커스텀 메타데이터를 설정할 때 x-goog-meta- 프리픽스를 포함해야 합니다. gsutil은 프리픽스를 사용하여 객체의 메타데이터를 볼 때 프리픽스를 삭제합니다.

수정할 수 없는 메타데이터

일부 메타데이터는 직접 수정할 수 없습니다. 이러한 메타데이터는 객체를 만들거나 재작성할 때 설정됩니다. 객체 만들기 또는 재작성을 수행할 때는 객체의 스토리지 클래스 또는 고객 관리형 암호화 키와 같은 일부 메타데이터를 설정할 수 있습니다. 객체의 세대 번호나 생성 시간과 같은 기타 메타데이터는 자동으로 추가되며 보기만 가능합니다.

세대 및 메타 세대 번호

메타데이터의 일부로 모든 Cloud Storage 객체에는 객체를 고유하게 식별하는 generation 속성과 metageneration 속성이 있습니다.

속성 설명
generation 객체 버전을 식별하며 버킷의 객체 버전 관리 사용 여부와 관계없이 모든 객체에 존재합니다.
  • 객체 버전의 generation 값은 변경되지 않습니다. 이름이 같은 새 객체로 기존 객체를 대체할 수 있지만, 새 객체에는 항상 다른 generation이 할당됩니다.
  • 연속 버전의 세대 번호가 증가한다는 보장은 없으며 각 새 버전에 고유한 세대 번호가 있습니다.
  • 객체가 같은 버킷에 있더라도 관련 없는 객체의 세대 번호 사이에는 관계가 없습니다.
metageneration 메타데이터 버전을 식별하고 주어진 generation 메타데이터가 업데이트될 때마다 증가합니다.
  • metageneration은 객체의 새 generation마다 1부터 시작합니다.
  • metageneration 속성은 generation 속성 없이는 의미가 없으며 이와 연결해서 사용되어야만 합니다. 두 객체 버전의 메타데이터 세대를 비교하는 것은 의미가 없습니다.

generationmetageneration 속성은 다음과 같은 경우에 사용됩니다.

  • 요청에서 전제조건을 사용하는 경우: 전제조건이 충족되지 않으면 전제조건이 실패하게 됩니다. 이러한 방식으로 실패하면 요청이 잘못된 객체 데이터를 검색하거나 객체의 메타데이터의 잘못된 상태를 수정하는 등 요청이 예기치 않은 버전의 객체에 적용되지 않도록 방지됩니다.

  • 이전 객체 버전을 나열, 액세스, 복원, 삭제하는 경우: 이전 객체 버전은 특히 객체 버전 관리를 사용하거나 이전에 사용한 버킷과 관련이 있습니다.

수정 시간

메타데이터의 일부로 모든 Cloud Storage 객체에는 객체 메타데이터가 수정된 마지막 시간을 나타내는 updated 속성이 있습니다. updated 시간은 처음에 객체의 생성 시간으로 설정되고 이후 객체 메타데이터가 변경될 때마다 변경됩니다. 여기에는 커스텀 메타데이터 수정과 같은 요청자가 수행한 변경사항과 객체 수명 주기 구성을 기반으로 하는 스토리지 클래스 변경과 같이 요청자 대신 Cloud Storage에서 수행된 변경사항이 포함됩니다.

다음 단계