データの検証と変更検出

Cloud Storage では、バケットとの間で転送されるデータの検証が推奨されます。このページでは、CRC32C または MD5 のチェックサムを使用して検証を実行するためのベスト プラクティスと、gcloud storage rsync コマンドで使用される変更検出アルゴリズムについて説明します。

ハッシュを使用してデータの破損から保護する

Cloud へのアップロードや Cloud からのダウンロード中にデータが破損する可能性がある状況は、次のように多岐に及びます。

  • クライアントやサーバーのコンピュータ上のメモリエラーや、パスに沿ったルーター
  • ソフトウェアのバグ（たとえば、ユーザーが使用するライブラリにある）
  • アップロードが長時間にわたって行われた場合のソースファイルの変更

Cloud Storage では、データの整合性チェックに使用できるハッシュとして、CRC32C と MD5 の 2 種類のハッシュがサポートされています。CRC32C は、整合性チェックを実行するための推奨の検証方法です。MD5 を使用するユーザーはそのハッシュを使用できますが、MD5 ハッシュはすべてのオブジェクトでサポートされているとは限りません。

クライアントサイドの検証

ダウンロードしたデータの整合性チェックを行うには、データをすぐにハッシュ化し、結果をサーバーによって提供されたチェックサムと比較します。ただし、サーバー提供のチェックサムは、Cloud Storage に保存されている完全なオブジェクトに基づいています。つまり、次のタイプのダウンロードは、サーバー提供のハッシュを使用して検証できません。

  • サーバーから提供されるチェックサムは圧縮状態のオブジェクトを表しますが、提供されるデータは圧縮が解除されているため、ハッシュ値が異なります。そのため、解凍トランスコーディングが行われるダウンロードは課金対象となります。

  • オブジェクト データの一部のみを含むレスポンス。range リクエストを行うと発生します。Cloud Storage では、最後に受信したオフセットの後に完全なオブジェクトのダウンロードを再開する場合にのみ、リクエスト範囲を使用することをおすすめします。完全なダウンロードが完了したときにチェックサムを計算して検証できるためです。

チェックサムを使用してダウンロードを検証できる場合は、ハッシュ値が正しくないダウンロード済みデータを破棄し、推奨の再試行ロジックを使用してリクエストを再試行する必要があります。

サーバーサイドの検証

Cloud Storage は、次の場合にサーバーサイド検証を行います。

  • Cloud Storage 内でコピーまたは書き換えリクエストを実行したとき。

  • アップロード リクエストでオブジェクトに想定される MD5 または CRC32C ハッシュを指定したとき。指定したハッシュが Cloud Storage の計算値と一致する場合にのみ、Cloud Storage はオブジェクトを作成します。 一致しない場合、リクエストは BadRequestException: 400 エラーで拒否されます。

    • 該当する JSON API リクエストでは、オブジェクト リソースの一部としてチェックサムを指定します。

    • 該当する XML API リクエストでは、x-goog-hash ヘッダーを使用してチェックサムを指定します。XML API は、標準 HTTP の Content-MD5 ヘッダーも受け入れます（仕様を参照）。

    • また、アップロードされたオブジェクトのメタデータをリクエストして、アップロードされたオブジェクトのハッシュ値を想定値と比較し、不一致の場合にオブジェクトを削除することで、クライアントサイドでアップロードの検証を行うこともできます。この方法は、アップロードの開始時にオブジェクトの MD5 または CRC32C ハッシュが不明な場合に有効です。

並列複合アップロードの場合は、コンポーネントのアップロードごとに整合性チェックを実行してから、コンポーネントの前提条件をその作成リクエストとともに使用して、競合状態を回避します。Compose リクエストではサーバーサイドの検証は行われないため、エンドツーエンドの整合性チェックが必要な場合は、新しい複合オブジェクトに対してクライアントサイド検証を行う必要があります。

Google Cloud CLI の検証

Google Cloud CLI の場合、Cloud Storage バケットとの間でコピーされたデータが検証されます。これは、cp、mv、rsync コマンドに適用されます。ソースデータのチェックサムが宛先データのチェックサムと一致しない場合、gcloud CLI は無効なコピーを削除し、警告メッセージを出力します。これが発生するのは非常にまれです。発生した場合は、オペレーションを再試行する必要があります。

この自動検証はオブジェクト自体のファイナライズの後に行われるため、無効なオブジェクトが認識されて削除されるまでに 1～3 秒ほどかかります。また、アップロードが完了した後、検証を行う前に gcloud CLI が中断され、無効なオブジェクトが残る可能性があります。この問題は、--content-md5 フラグの使用時に発生するサーバーサイドの検証を使用して、単一ファイルを Cloud Storage にアップロードすると回避できます。

rsync の変更検出

gcloud storage rsync コマンドでは、MD5 または CRC32C チェックサムを使用して、ソースで見つかったオブジェクトのバージョンと宛先で見つかったバージョンに違いがあるかどうかを判断できます。このコマンドは、次の場合にチェックサムを比較します。

  • ソースと宛先がどちらも Cloud Storage バケットであり、両方のオブジェクトに MD5 または CRC32C チェックサムがある。

  • オブジェクトのソースまたは宛先のいずれにもファイルの変更日時（mtime）がない。

関連するオブジェクトがソースと宛先の両方で mtime 値を持つ場合（ソースと宛先がファイル システムの場合など）、rsync コマンドは、チェックサムではなく、オブジェクトのサイズと mtime を比較します。同様に、ソースがクラウド バケットで、宛先がローカル ファイル システムの場合、rsync コマンドは、ソース オブジェクトの作成時刻を mtime の代わりに使用します。チェックサムは使用しません。

mtime もチェックサムも使用できない場合、rsync はファイルサイズのみを比較して、オブジェクトのソース バージョンと宛先バージョンの間に変更があるかどうかを判断します。たとえば、複合オブジェクトには MD5 チェックサムがないため、複合オブジェクトを CRC32C をサポートしていないクラウド プロバイダのオブジェクトと比較するときに、mtime もチェックサムも使用できません。

次のステップ