オブジェクトのバージョニング

削除または上書きされたオブジェクトの取得をサポートするため、Cloud Storage にはオブジェクトのバージョニング機能があります。このページでは、この機能と、この機能を使用するときに使用可能なオプションについて説明します。オブジェクトのバージョニングを有効にして使用する方法については、オブジェクトのバージョニングの使用をご覧ください。

オブジェクトのバージョニングを有効にすると、Cloud Storage データが上書きされたり誤って削除されたりしないように保護できます。この機能を有効にするとストレージ コストが増加しますが、オブジェクトのライフサイクル管理を構成して古いオブジェクト バージョンが削除されるようにすれば、コストの増加をある程度軽減できます。

はじめに

バケットのオブジェクトのバージョニングを有効にします。有効にすると、オブジェクトのライブ バージョンが上書きまたは削除されるたびに、Cloud Storage によってオブジェクトのアーカイブ バージョンが作成されます。アーカイブ バージョンのオブジェクト名は変更されませんが、世代番号はそれぞれ異なります。すべてのオブジェクトには世代番号が関連付けられますが、識別のために世代番号が必要となるのはアーカイブされたオブジェクトのみです。

オブジェクトのバージョニングを有効にすると、必要に応じて、オブジェクトのアーカイブ バージョンを一覧表示すること、オブジェクトのライブ バージョンを古い状態に復元すること、アーカイブ バージョンを完全に削除することが可能です。バケットのバージョニングのオン / オフは、いつでも切り替えることができます。バージョニングをオフにすると、既存のオブジェクト バージョンはそのまま保持され、バケットでは、オブジェクトのアーカイブ バージョンを新たに作成して蓄積する処理が停止されます。

オブジェクトのバージョニングの詳細

Cloud Storage は、2 つのプロパティを組み合わせて使用することにより、オブジェクトのバージョンを識別します。1 つのプロパティでオブジェクトのデータのバージョンを識別し、もう 1 つのプロパティでオブジェクトのメタデータのバージョンを識別します。これらのプロパティは、オブジェクトのバージョニングが有効になっていない場合でも、常にオブジェクトのすべてのバージョンに存在します。これらのプロパティを条件付き更新の前提条件として使用することで、更新の順序を制御できます。

Cloud Storage は、次のプロパティを使用してすべてのオブジェクトにマークを付けます。

プロパティ 説明
generation コンテンツ(データ)の世代を識別します。オブジェクトのコンテンツが上書きされると更新されます。複数のオブジェクトが同じバケット内にある場合でも、無関係なオブジェクトの世代番号は互いに無関係です。
metageneration メタデータの世代を識別します。特定のコンテンツの世代メタデータが更新されるたびに、数値が増えます。metageneration は、オブジェクトの generation が新しくなるたび 1 にリセットされます。metageneration プロパティは generation プロパティがないと意味がないため、必ず一緒に使用する必要があります。言い換えると、データの世代が異なる 2 つのバージョンのメタデータの世代を比較しても意味がありません。

オブジェクトのバージョニングは、保持ポリシーが設定されているバケットでは有効にできません。

アーカイブされたオブジェクトのメタデータ

アーカイブされたオブジェクトに、ライブ オブジェクトのメタデータと異なる独自のメタデータが存在する場合があります。ここで重要なことは、アーカイブ バージョンには独自の ACL があり、必ずしもライブ バージョンのオブジェクトと同じ権限を持たないことです。

各オブジェクトには(ライブであってもバージョニングされていても)メタデータのセットが 1 つあります。最新のメタ世代番号のみがメタデータを参照します。古いメタ世代番号を使用して、その後変更されたメタデータにアクセスすることはできません。

アーカイブされたオブジェクトのメタデータを更新するには、リクエストでその generation を指定します。read-modify-write セマンティクスの安全性を確保するため、metageneration-match 前提条件を使用できます。この前提条件を使用した場合、メタデータを読み取ってから更新を送信するまでの間に、更新しようとしているメタデータが変更されていると、更新が失敗します。

オブジェクトのバージョニングの例

以下の例では、ファイルを上書き、更新、削除したときに、オブジェクトのバージョニングが有効になっているバケット内の cat.jpg ファイルに何が起こるかを示します。

新しい画像をアップロードする

最初に cat.jpg を Cloud Storage にアップロードすると、Cloud Storage は generation 番号と metageneration 番号を受け取ります。この例では、generation 番号は 1360887697105000 です。新しいオブジェクトなので、metageneration 番号は 1 です。

cat.jpg は、オブジェクトのバージョニングが有効になっていない場合でも、generation 番号と metageneration 番号を受け取ります。これらの番号は、gsutil で stat コマンドを使用すると表示できます。手順については、オブジェクトのメタデータを表示するをご覧ください。

オブジェクトのバージョニングを有効にする

この時点で、バケットのオブジェクトのバージョニングを有効にするかどうかを決定します。有効にしても、cat.jpggeneration 番号または metageneration 番号には影響しません。

画像のメタデータを変更する

カスタム メタデータを追加して(この例では color:black)、cat.jpg のメタデータを更新します。メタデータを更新すると、cat.jpgmetageneration の値が増えます。この例では、1 から 2 になります。ただし、オブジェクト自体は変更されていないため、引き続き cat.jpg の 1 つのバージョンのみが保存され、バージョンの generation 番号は 1360887697105000 のままです。

画像の新しいバージョンをアップロードする

cat.jpg の新しいバージョンを Cloud Storage バケットにアップロードします。新しいバージョンをアップロードすると、オブジェクトのバージョニング機能により、既存の cat.jpg オブジェクトがアーカイブされます。アーカイブ バージョンは、これまでと同じストレージ クラスとメタデータを保持します。アーカイブ バージョンは、バージョンを一覧表示した場合にのみ表示されます。通常の一覧表示コマンドでは表示されません。アーカイブ バージョンは cat.jpg#1360887697105000 として参照されます。

一方、新たにアップロードされた cat.jpg は、オブジェクトのライブ バージョンになります。この新しい cat.jpg は、固有の generation 番号を取得します。この例では 1360887759327000 です。また、固有のメタデータと metageneration 番号 1 を取得します。つまり、メタデータ color:black は、指定しない限りこれには含まれません。cat.jpg, に対してアクセスまたは変更を行う場合、このバージョンが使用されます。また、cat.jpg のこのバージョンは、その generation 番号でも参照できます。たとえば、gsutil ツールを使用する場合は、cat.jpg#1360887759327000 として参照します。

画像のライブ バージョンを削除する

次に、cat.jpg を削除します。そうすると、世代番号が 1360887759327000 のバージョンがアーカイブされます。したがって、バケットには cat.jpg のアーカイブ バージョンが 2 つあり、ライブ バージョンはありません。アーカイブ バージョンはどちらも generation 番号で参照できますが、generation 番号を指定せずに cat.jpg にアクセスしようとすると失敗します。

同様に、バケットの通常のオブジェクト リストには、バケット内のオブジェクトの 1 つとして cat.jpg は表示されなくなります。オブジェクトのアーカイブ バージョンを一覧表示する方法については、アーカイブされたオブジェクトのバージョンを一覧表示するをご覧ください。

オブジェクトのバージョニングを無効にする

オブジェクトのバージョニングを無効にします。これにより、今後、オブジェクトはアーカイブされなくなります。オブジェクトの既存のアーカイブ バージョンは Cloud Storage に残ります。オブジェクトのバージョニングを無効にしても、cat.jpg#1360887697105000cat.jpg#1360887759327000 は、手動またはオブジェクトのライフサイクル管理で削除しない限り、バケットに引き続き保存されます。

アーカイブ バージョンの 1 つを復元する

オブジェクトのバージョニングを無効にしている場合でも、既存のアーカイブ バージョンのコピーを作成すると、そのバージョンを復元できます。復元するには、作成するコピーの名前を cat.jpg するだけです。これにより、バケットには cat.jpg の 3 つのバージョン(2 つのアーカイブ バージョンと、コピーから復元したライブ バージョン)が存在することになります。

ヒント

このセクションでは、オブジェクトのバージョニングをより効果的に使用するために役立つヒントを紹介します。

gsutil を使用する

  • gsutil ツールは、バージョニングされたオブジェクトの操作を包括的にサポートし、オブジェクトのバージョニングに関連する多くのタスクを容易にします。たとえば、オブジェクトのアーカイブ バージョンを操作する際は、オブジェクト名の末尾に #generation 番号を追加します。オブジェクトのバージョニングで gsutil を使用する方法の詳細については、オブジェクトのバージョニングと同時実行制御をご覧ください。

ETag を避ける

  • 条件付き更新では、ETag の代わりに generation 番号と metageneration 番号を使用することを検討してください。generation 番号と metageneration 番号の組み合わせにより、メタデータの変更を含むすべてのオブジェクトの更新をトラッキングできるため、ETag より正確な処理が保証されます。

ファイルの削除と復元の動作を理解する

  • オブジェクトのアーカイブ バージョンを現在のライブ バージョンにコピーできます。アーカイブされたオブジェクトをコピーする手順については、アーカイブされたオブジェクトのバージョンのコピーをご覧ください。

    オブジェクトのライブ バージョンがすでに存在しているバケットでは、オブジェクトのバージョニングを有効にした状態でこれを実行すると、Cloud Storage によりそのオブジェクトが上書きされますが、上書きされたオブジェクトの新しいアーカイブ バージョンも作成されます。この場合、バケットには、上書きされたオブジェクト(現在はアーカイブ バージョン)に加えて、以前アーカイブされたオブジェクトの 2 つのコピー(ライブ バージョンとコピー元のアーカイブ バージョン)が存在し、そのすべてにストレージ料金が発生します。 不要な請求を避けるには、現在のライブ バージョンのコピー元のアーカイブ バージョンを削除します。

  • 世代を指定せずに削除リクエストを送信すると、現在のライブ オブジェクトがアーカイブされます。したがって、バージョンに対応していない後続のリクエストは、オブジェクトを見つけられなくなります。

  • 現在のライブ オブジェクトに対応する generation を指定して削除リクエストを送信すると、アーカイブ バージョンが作成されることなくオブジェクトが削除されます。

  • アーカイブされたオブジェクトを削除すると、オブジェクトのそのバージョンが完全に削除されます。

ライブ バージョンのオブジェクトの変更時に generation-match 前提条件を使用する

  • 世代番号を使用すると、その名前と世代番号のオブジェクトが存在すれば、リクエストは成功します。そのオブジェクトがライブ バージョンかアーカイブ バージョンかは関係ありません。該当するオブジェクトが存在しない場合は、404 Not Found が返されます。

  • generation-match 前提条件を使用すると、リクエストされたオブジェクトのライブ バージョンに指定された世代番号がある場合にのみ、リクエストが成功します。該当するオブジェクトが存在しないかまたはアーカイブされている場合は、412 Precondition Failed が返されます。

  • オブジェクト名の世代番号と generation-match 前提条件を同時に使用しないでください。両方を使用し、番号が一致する場合、前提条件の使用は冗長となります。番号が一致しない場合、リクエストは常に失敗します。

  • generation-match 前提条件を使用して複数の同時変更リクエストを行うと、Cloud Storage の強整合性機能により、これらのリクエストの 1 つのみが成功します。この機能は、複数のソースからオブジェクトが更新され、ユーザーが誤ってそれらを上書きしないようにする必要がある場合に役立ちます。

  • オブジェクトをアップロードするときに generation-match 前提条件を 0 に設定すると、そのオブジェクトのライブ バージョンが存在しない場合にのみ、指定したリクエストが実行されます。たとえば、ヘッダー x-goog-if-generation-match:0 を指定して XML API で新しいオブジェクトを作成する PUT リクエストを実行すると、オブジェクトが存在しない場合またはオブジェクトのアーカイブ バージョンのみが存在する場合に、そのリクエストは成功します。オブジェクトのライブ バージョンが存在する場合は、ステータス コード 412 Precondition Failed で更新が異常終了します。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。