gzip 압축 파일의 트랜스코딩

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

트랜스코딩 및 gzip

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

압축 해제 트랜스코딩

파일이 gzip으로 압축된 객체로 Cloud Storage에 저장되면 요청자에게 전송되기 전에 자동으로 압축이 해제되어 결과적으로 요청자는 ID가 인코딩된 파일(압축되지 않은 파일)을 받게 됩니다. 이렇게 하면 Cloud Storage 내 객체 저장 비용이 줄어들고 요청자에게 압축되지 않은 파일을 제공할 수 있게 됩니다. 예를 들어 고객에게 파일을 제공할 때 유용합니다.

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

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

  2. 관련 메타데이터Content-Encoding: gzip을 포함합니다.

객체가 이 2가지 기준을 충족하면 요청 시 압축 해제 트랜스코딩을 거치며, 이 경우 Content-Encoding 헤더 없이도 제공됩니다. 2가지 기준을 모두 충족하는 객체를 압축된 상태(예: 이그레스 비용 또는 시간 절감을 위해)로 제공하려는 경우 압축 해제 트랜스코딩을 방지할 수 있는 2가지 방법이 있습니다.

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

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

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

Content-TypeContent-Encoding이 트랜스 코딩과 어떤 관련이 있는지에 대해 알아야 할 몇 가지 동작이 있습니다. 2가지 모두 객체와 함께 저장된 메타데이터입니다. 메타데이터를 객체에 추가하는 방법에 대한 단계별 안내는 객체 메타데이터 확인 및 편집을 참조하세요.

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

Content-Type: text/plain

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

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

Content-Encoding: gzip

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

권장사항

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

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

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

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

    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으로 압축되었을 뿐만 아니라 기본적으로 압축된 콘텐츠 유형을 지닌 객체)를 업로드하고 저장할 수 있습니다. 하지만 객체의 Cache-Control 메타데이터에 no-transform이 포함되지 않는 한 객체를 이중으로 압축된 상태로 제공하지 않습니다. 대신 외부, gzip, 압축 수준을 제거하고 Content-Encoding 응답 헤더를 삭제한 최종 객체를 제공합니다. 이는 Accept-Encoding: gzip을 사용하는 요청에서도 발생합니다.

범위 헤더 사용하기

트랜스코딩이 발생할 때 객체에 대한 요청에 Range 헤더가 포함되어 있는 경우 해당 헤더는 자동으로 무시됩니다. 즉, 부분 콘텐츠에 대한 요청이 충족되지 않았고 응답은 대신 요청된 객체 전체를 제공한다는 것을 의미합니다. 이 동작은 전체 파일을 먼저 압축 해제하지 않고서는 압축 파일에서 범위를 선택할 수 없기 때문에 발생합니다. 파일 일부에 대한 각 요청은 리소스 사용이 효율적이지 않은 파일 전체에 대한 압축 해제를 수반할 수 있습니다. 트랜스코딩을 사용할 때 Range 헤더를 사용하지 않는 것이 좋습니다. 요청된 범위뿐만 아니라 전체 객체 전송에 요금이 부과되기 때문입니다. Range 헤더가 있는 요청에 허용되는 응답 동작에 대한 자세한 내용은 사양을 참조하세요.

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

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

도움이 필요하시나요? 지원 페이지를 방문하세요.