ハッシュと ETag: ベスト プラクティス

Cloud Storage では、バケット間で送受信するデータの検証に CRC32C チェックサムまたは MD5 チェックサムを使用することをおすすめします。このセクションでは、これらの検証を実行するためのベスト プラクティスについて説明します。

整合性チェックでのハッシュの使用

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

  • ノイズの多いネットワーク リンク
  • クライアントやサーバーのコンピュータ上のメモリエラーや、パスに沿ったルーター
  • ソフトウェアのバグ(たとえば、ユーザーが使用するライブラリにある)

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

CRC32C

Cloud Storage のすべてのオブジェクトには CRC32C ハッシュがあります。CRC32C を計算するためのライブラリには、以下があります。

Base64 でエンコードされた CRC32C のバイト順はビッグ エンディアンです。

MD5

Cloud Storage では、非複合オブジェクト用に MD5 ハッシュをサポートしています。このハッシュは、完全なオブジェクトにのみ適用されるため、範囲 GET の実行によって生じる部分ダウンロードの整合性チェックに使用することはできません。

ETag

非複合オブジェクトの場合、XML API はオブジェクトの MD5 を ETag ヘッダーの値として使用します。それ以外の場合は、仕様のとおり、基になるデータが変更されるたびに値が変更されること以外、ETag で使用される値について仮定することはできません。

XML API からのリクエストと JSON API からのリクエストでは、同じオブジェクトでも ETag 値が異なる場合があります。

検証

ダウンロードの整合性チェックは、ダウンロードしたデータをすばやくハッシュ化して結果をサーバーによって提供されたハッシュと比較することで実行できます。ハッシュ値が不適切なダウンロード済みのデータを破棄し、高コストになりがちな無限ループを回避するロジックを再試行します。

Cloud Storage は、次の場合にサーバー側検証を実行します。

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

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

別の方法として、アップロードされたオブジェクトのメタデータのリクエストを発行し、報告されたハッシュ値を比較し、不一致の場合はオブジェクトを削除することによって、アップロードをクライアント側で検証することもできます。この方法は、オブジェクトの MD5 または CRC32C ハッシュがアップロード開始の時点でわからない場合に役立ちます。独立したプロセスで互いのデータの削除や置換が行われる競合状態を回避するために、オブジェクトの生成と前提条件を使用することもおすすめします。

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

コピー オペレーションが終了したときに、gsutilcp コマンドと rsync コマンドにより、ローカル ファイルのチェックサムが Cloud Storage に保存されているオブジェクトのチェックサムに一致することが検証されます。一致しない場合、gsutil が、無効なコピーを削除し、警告メッセージを出力します。これが発生するのは非常にまれです。発生した場合は、オペレーションを再試行できます。

XML API

XML API では、Base64 でエンコードされた MD5 と CRC32C のハッシュは、x-goog-hash ヘッダーを介して露出され受け付けられます。これまで、MD5 はオブジェクトの ETag として使用されていましたが、オブジェクトの変更時に変更以外を保証しない不透明な ETag 値が一部のオブジェクトで使用されるため、ETag としての使用の仮定を回避する必要があります。

サーバー側アップロード検証は、x-goog-hash リクエスト ヘッダーを使用してローカルで計算されたハッシュを入力することで実行できます。さらに、標準 HTTP の Content-MD5 ヘッダーを使用して MD5 を指定できます(仕様をご覧ください)。

JSON API

JSON API では、オブジェクト リソースmd5Hash プロパティと crc32c プロパティにそれぞれ、Base64 でエンコードされた MD5 のハッシュと CRC32C のハッシュが含まれています。どちらのメタデータ プロパティを指定するかはオプションです。再開可能なアップロードまたは JSON API マルチパート アップロードの一部としてどちらかのプロパティを指定すると、新しいオブジェクトに対してサーバー側検証がトリガーされます。Cloud Storage でどちらかのプロパティの値が計算され、その値が指定した値と一致しない場合、オブジェクトは作成されません。アップロードでこれらのプロパティを指定しない場合には、Cloud Storage で値が計算され、オブジェクトのメタデータに書き込まれます。