gzip 압축 파일의 트랜스코딩

이 페이지에서는 gzip 압축 상태에서 파일을 변환하는 방법을 설명합니다. 이 페이지에서 트랜스코딩의 개요, 관련 메타데이터 작업을 위한 권장사항, Cloud Storage의 압축 파일 동작을 살펴봅니다.

트랜스코딩 및 gzip

gzip은 데이터 압축 형식이며, 일반적으로 파일의 크기를 줄입니다. 이렇게 하면 압축되지 않은 경우보다 적은 공간을 사용하여 파일을 더 빨리 전송하고 저장할 수 있습니다. 파일을 압축하면 비용과 전송 시간을 줄일 수 있습니다. Cloud Storage에서 트랜스코딩은 요청자에게 제공되기 전에 파일 압축으로 자동 변경합니다. 파일의 트랜스코딩 결과가 gzip으로 압축이 되면 압축이 가능하다고 간주되는 반면 파일이 더 이상 gzip으로 압축되지 않는 경우는 압축 해제가 가능하다고 간주됩니다. Cloud Storage는 압축 해제 형식의 트랜스코딩을 지원합니다.

Cloud Storage는 Brotli 압축 객체에 대해 압축 해제 트랜스코딩을 지원하지 않습니다.

압축 해제 트랜스코딩

압축 해제 트랜스코딩을 사용하면 Cloud Storage에 압축된 버전의 파일을 저장할 수 있으므로 저장 데이터 스토리지 비용이 절감되며 압축 없이 파일 자체를 요청자에게 제공할 수 있습니다. 예를 들어 고객에게 파일을 제공할 때 유용합니다.

압축 해제 트랜스코딩을 사용하려면 객체가 다음 2가지 기준을 충족해야 합니다.

  1. 파일이 Cloud Storage에 저장될 때 gzip으로 압축되어야 합니다.

  2. 객체의 메타데이터에 Content-Encoding: gzip이 포함되어야 합니다.

객체가 이 두 가지 기준을 충족하면 제공 시에 압축 해제 트랜스코딩을 거치며 이 객체가 포함된 응답에는 Content-Encoding 또는 Content-Length 헤더가 포함되지 않습니다.

기준을 충족하는 객체에서 압축 해제 트랜스코딩이 발생하지 않도록 하는 방법에는 2가지가 있습니다.

  • 객체에 대한 요청에 Accept-Encoding: gzip 헤더가 포함된 경우 객체는 특정 요청에서 Content-Encoding: gzip 응답 헤더와 함께 있는 그대로 제공됩니다.

  • 객체의 Cache-Control 메타데이터 필드가 no-transform으로 설정된 경우 객체는 Accept-Encoding 요청 헤더와 상관없이 모든 후속 요청에서 압축된 객체로 제공됩니다.

예를 들어 아웃바운드 데이터 전송 비용 또는 시간을 줄이거나 다운로드된 객체에 crc32c/md5 체크섬이 포함되어 있는지 확인하려는 경우 압축 해제 트랜스코딩을 막는 것이 유용합니다.

고려사항

압축 해제 트랜스코딩 작업 시 다음 사항에 유의하세요.

  • 압축 해제 트랜스코딩은 응답에서 반환된 데이터에 대한 무결성 검사를 무효화합니다. 객체와 함께 저장된 해시는 압축된 상태의 데이터를 나타내는 반면, 제공된 데이터는 압축이 해제되어 결과적으로 다른 해시 값을 갖기 때문입니다. 데이터 요청자가 무결성 검사를 위해 체크섬을 사용하는 경우 압축 해제 트랜스코딩을 사용해서는 안 됩니다.

  • 압축 해제 트랜스코딩을 사용하면 Cloud Storage에 객체를 압축된 상태로 저장할 수 있으므로 공간과 비용이 절약됩니다. 하지만 객체 다운로드 요금은 압축 해제된 크기를 기준으로 합니다. 압축 해제된 크기가 제공된 객체 크기이기 때문입니다.

  • Cloud Storage FUSE 마운트 버킷 내에서 액세스할 때 객체는 압축 해제 트랜스코딩을 수행하지 않으며 압축된 상태로 읽힙니다.

콘텐츠 유형과 콘텐츠 인코딩 비교

트랜스 코딩과 Content-Type 및 Content-Encoding의 연관성과 관련하여 알아야 할 몇 가지 동작이 있습니다. 2가지 모두 객체와 함께 저장된 메타데이터입니다. 메타데이터를 객체에 추가하는 방법에 대한 단계별 안내는 객체 메타데이터 보기 및 수정을 참조하세요.

Content-Type은 모든 업로드에 포함되어야 하고 업로드되는 객체 유형을 나타내야 합니다. 예를 들면 다음과 같습니다.

Content-Type: text/plain

이는 업로드된 객체가 일반 텍스트 파일임을 나타냅니다. 지정된 Content-Type이 업로드된 객체의 실제 특성과 일치한다는 것을 보장할 수는 없지만 객체의 유형을 잘못 지정하면 요청자가 기대한 것이 아닌 다른 것을 수신하게 되어 의도하지 않은 동작이 발생할 수 있습니다.

Content-Encoding은 선택사항이며 원하는 경우 압축된 파일 업로드에 포함될 수 있습니다. 예를 들면 다음과 같습니다.

Content-Encoding: gzip

이는 업로드된 객체가 gzip으로 압축되었음을 나타냅니다. Content-Type과 마찬가지로 지정된 Content-Encoding이 업로드된 객체에 실제로 적용된다는 보장은 없으며 객체의 인코딩을 잘못 지정하면 후속 다운로드 요청 시 의도하지 않은 동작이 발생할 수 있습니다.

권장사항

  • gzip으로 압축된 객체를 업로드할 때 메타데이터를 설정하는 가장 좋은 방법은 Content-Type과 Content-Encoding을 모두 지정하는 것입니다. 다음은 압축된 일반 텍스트 파일의 예시입니다.

    Content-Type: text/plain
Content-Encoding: gzip

    이는 객체에 액세스하는 모든 사람에게 객체 상태에 대한 최대한의 정보를 제공합니다. 이렇게 하면 나중에 객체 다운로드 시 압축 해제 트랜스코딩을 할 수 있어 클라이언트 애플리케이션이 Content-Type의 시맨틱스를 올바르게 처리할 수 있게 됩니다.

  • 또는 압축을 나타내도록 Content-Type을 설정하고 Content-Encoding은 아예 지정하지 않고 객체를 업로드할 수 있습니다. 예를 들면 다음과 같습니다.

    Content-Type: application/gzip

    그러나 이 경우 객체에 대해 바로 알 수 있는 정보는 gzip으로 압축되어 있다는 것 뿐이며 기본 객체 유형에 관한 정보는 알 수 없습니다. 게다가 객체는 압축 해제 트랜스코딩의 대상이 아닙니다.

비권장사항

  • 가능은 하지만 gzip으로 압축된 파일을 압축된 파일의 원래 특성을 제외하고 업로드하면 안 됩니다. 예를 들어 gzip으로 압축된 일반 텍스트 파일의 경우 Content-Type: text/plain만 설정해서는 안 됩니다. 이렇게 하면 요청자에게 전달될 때 객체의 상태가 잘못 나타나게 됩니다.

  • 마찬가지로 Content-Encoding이 포함되어 있어도 Content-Type이 생략된 객체를 업로드하면 안 됩니다. 이렇게 하면 Content-Type이 기본값으로 설정될 수 있지만 업로드 방법에 따라 요청이 거부될 수 있습니다.

잘못된 방식

  • 객체의 압축을 중복 보고하도록 메타데이터를 설정하면 안 됩니다.

    Content-Type: application/gzip
Content-Encoding: gzip

    이 설정은 gzip으로 두 번 압축된 객체를 업로드한다는 것을 의미하지만 보통은 그렇지 않습니다. 실제로 파일을 두 번 압축하는 경우 아래의 압축된 객체에 gzip 사용하기 섹션을 참조하세요. 이러한 잘못 보고된 객체에서 압축 해제 트랜스코딩이 발생하면 객체는 ID가 인코딩되어 처리되지만 요청자는 여전히 객체와 관련된 압축 레이어를 가진 객체를 수신했다고 생각하게 됩니다. 객체 압축 풀기를 시도하면 실패합니다.

  • 마찬가지로 gzip으로 압축되지 않은 파일을 Content-Encoding: gzip을 사용하여 업로드하면 안 됩니다. 이렇게 하면 객체가 트랜스코딩에 적합한 것으로 나타나지만 객체에 대한 요청 시 트랜스코딩에 실패하게 됩니다.

압축된 객체에 gzip 사용하기

동영상, 오디오, 이미지 파일과 같은 일부 객체는 이미 압축되어 있는 gzip 파일입니다. 이러한 객체에 gzip을 사용하면 아무런 효과가 없습니다. 이렇게 하면 거의 모든 경우에 gzip 오버헤드로 인해 객체가 커집니다. 그렇기 때문에 압축된 콘텐츠에 gzip을 사용하는 것은 일반적으로 권장되지 않으며 사용시 원하지 않는 동작을 유발할 수 있습니다.

예를 들어 Cloud Storage는 '이중으로 압축된' 객체(gzip으로 압축되었을 뿐만 아니라 기본적으로 압축된 Content-Type을 지닌 객체)를 업로드하고 저장할 수 있습니다. 하지만 객체의 Cache-Control 메타데이터에 no-transform이 포함되지 않는 한 객체를 이중으로 압축된 상태로 제공하지 않습니다. 대신 외부, gzip, 압축 수준을 제거하고 Content-Encoding 응답 헤더를 삭제한 최종 객체를 제공합니다. 이는 Accept-Encoding: gzip을 사용하는 요청에서도 발생합니다. 따라서 클라이언트가 수신한 파일에는 Cloud Storage에 업로드되고 저장된 것과 동일한 체크섬이 없으므로 무결성 검사가 실패합니다.

범위 헤더 사용하기

트랜스코딩이 발생할 때 객체에 대한 요청에 Range 헤더가 포함되어 있는 경우 해당 헤더는 자동으로 무시됩니다. 즉, 부분 콘텐츠에 대한 요청이 충족되지 않았고 응답은 대신 요청된 객체 전체를 제공한다는 것을 의미합니다. 예를 들어 트랜스코딩에 적합한 10GB 객체가 있는데 요청에 Range: bytes=0-10000 헤더를 포함하면 10GB 객체 전체가 수신됩니다.

이 동작은 전체 파일을 먼저 압축 해제하지 않고서는 압축 파일에서 범위를 선택할 수 없기 때문에 발생합니다. 파일 일부에 대한 각 요청은 리소스 사용이 효율적이지 않은 파일 전체에 대한 압축 해제를 수반할 수 있습니다. 트랜스코딩을 사용할 때 Range 헤더를 사용하지 않는 것이 좋습니다. 요청된 범위뿐만 아니라 전체 객체 전송에 요금이 부과되기 때문입니다. Range 헤더가 있는 요청에 허용되는 응답 동작에 대한 자세한 내용은 사양을 참조하세요.

Range 헤더가 있는 요청이 필요한 경우 요청된 객체에 대해 트랜스코딩이 발생하지 않도록 해야 합니다. 객체를 업로드할 때 적절한 속성을 선택하여 이를 방지할 수 있습니다. 예를 들어 Content-Type: application/gzip이 있고 Content-Encoding이 없는 객체에 대한 범위 요청은 요청된 대로 수행됩니다.

다음 단계