このページでは、gzip ファイルの圧縮時と解凍時の変換について説明します。このページには、Cloud Storage でのトランス コーディングの概要、関連するメタデータの操作に関するベスト プラクティス、圧縮ファイルの動作が記載されています。
トランス コーディングと gzip
gzip は、データ圧縮の 1 つの形式で、主にファイルのサイズを縮小します。圧縮されていない場合よりも高速でファイルを転送でき、より小さいスペースでの保存が可能です。ファイルを圧縮するとコストと転送時間の両方を減らすことが可能です。Cloud Storage の「トランス コーディング」は、ファイルをリクエスト元に提供する前にファイルの圧縮を自動的に変更します。トランス コーディングの結果としてファイルが gzip 圧縮される場合、ファイルは「圧縮」と見なされ、これに対し結果のファイルが gzip 圧縮されなくなった場合、「解凍」と見なされます。Cloud Storage は、トランス コーディングの解凍形式をサポートします。
Cloud Storage では、Brotli 圧縮オブジェクトの解凍トランス コーディングはサポートされていません。
解凍トランス コーディング
解凍トランス コーディングを使用すると、ファイルの圧縮バージョンを Cloud Storage に保存できます。保存時のストレージ コストを抑えながら、圧縮を行わずにファイル自体をリクエスト元に提供できます。これは、お客様にファイルを提供する場合などに便利です。
解凍トランス コーディングを行うには、オブジェクトが次の 2 つの条件を満たしている必要があります。
ファイルが Cloud Storage への保存時に gzip 圧縮されている。
オブジェクトのメタデータに
Content-Encoding: gzip
が含まれている。
オブジェクトがこれらの 2 つの条件を満たす場合、提供時に解凍トランス コーディングが実行されます。オブジェクトを含むレスポンスに 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 の比較
Content-Type
と Content-Encoding
がトランス コーディングに与える影響について知っておくべきいくつかの動作があります。どちらもメタデータであり、オブジェクトとともに保存されます。オブジェクトにメタデータを追加する方法については、オブジェクトのメタデータの表示と編集をご覧ください。
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 圧縮してアップロードすることを意味しますが、通常、このような操作は行いません(ファイルをあえて 2 回圧縮する場合は、後述の圧縮されたオブジェクトでの 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 ヘッダーの使用
トランス コーディングの実行時に、オブジェクトのリクエストに Range
ヘッダーが含まれている場合、そのヘッダーは自動的に無視されます。つまり、部分的なコンテンツのリクエストは処理されず、オブジェクト全体のレスポンスが返されます。たとえば、トランスコード可能な 10 GB のオブジェクトがあり、ヘッダー Range: bytes=0-10000
がリクエストに含まれる場合、そのまま 10 GB のオブジェクト全体が受信されます。
このような動作が発生するのは、最初にファイル全体を解凍しないと、圧縮されたファイルの特定の範囲を選択できないためです。ファイルの一部を対象とする各リクエストは、ファイル全体の解凍を伴い、大きなファイルは場合に非効率的にリソースを使用します。このため、トランス コーディングを使用する場合には Range
ヘッダーを使用しないよう注意してください。このヘッダーを使用すると、リクエストした範囲だけでなくオブジェクト全体の転送料金が発生するためです。Range
ヘッダーを使用するリクエストに対して許可されているレスポンスの動作については、仕様をご覧ください。
Range
ヘッダーを使用するリクエストが必要な場合は、リクエストされたオブジェクトに対してトランス コーディングを実行しないようにする必要があります。これは、オブジェクトをアップロードするときに適切なプロパティを選択することによって実現できます。たとえば、Content-Type: application/gzip
が指定され、Content-Encoding
が指定されていないオブジェクトに対する範囲リクエストはリクエストどおりに実行されます。
次のステップ
gcloud storage cp
の使用時に--gzip-local
フラグを指定して、ファイルのアップロードに gzip content-encoding を適用する方法について学習する。- オブジェクト メタデータの表示と編集の方法を確認する。