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

サンプルに移動

削除または上書きされたオブジェクトを取得できるようにするため、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.jpg の generation 番号または metageneration 番号には影響しません。

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

カスタム メタデータを追加して（この例では color:black）、cat.jpg のメタデータを更新します。メタデータを更新すると、cat.jpg の metageneration の値が増えます。この例では、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#1360887697105000 と cat.jpg#1360887759327000 は、手動またはオブジェクトのライフサイクル管理で削除しない限り、バケットに引き続き保存されます。

非現行バージョンの 1 つを復元する

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

オブジェクトのバージョニングのリファレンス

このリファレンス表には、オブジェクトのバージョニングで特定の操作を行うとどのように機能するかを示しています。

オブジェクトのバージョニングのステータス 操作 結果
無効
新しいバージョンで dog.png を上書きします。 新しいバージョンによってライブ バージョンが置き換えられ、新しい世代番号を受け取ります。古いライブ バージョンは完全に削除されます。
ライブ バージョンの上に dog.png の非現行バージョンをコピーします。1 非現行バージョンのコピーによってライブ バージョンが置き換えられ、新しい世代番号を受け取ります。古いライブ バージョンは完全に削除されます。
dog.png を削除します。 dog.png が完全に削除されます。
dog.png の非現行バージョンを、その世代番号を指定して削除します。1 非現行バージョンが完全に削除されます。
有効
新しいバージョンで dog.png を上書きします。 新しいバージョンによってライブ バージョンが置き換えられ、新しい世代番号を受け取ります。古いライブ バージョンが非現行バージョンになり、同じ世代番号が維持されます。
ライブ バージョンの上に dog.png の非現行バージョンをコピーします。 非現行バージョンのコピーによってライブ バージョンが置き換えられ、新しい世代番号を受け取ります。古いライブ バージョンが非現行バージョンになり、同じ世代番号が維持されます。
dog.png のライブ バージョンを、その世代番号を指定せずに削除します。 ライブ バージョンが非現行バージョンになり、同じ世代番号が維持されます。
dog.png のライブ バージョンを、その世代番号を指定して削除します。 ライブ バージョンが完全に削除されます。
dog.png の非現行バージョンを、その世代番号を指定して削除します。 非現行バージョンが完全に削除されます。

1 以前にバケットでオブジェクトのバージョニングが有効になっていた場合、非現行バージョンが存在することがあります。

ヒント

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

gsutil を使用する

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

ETag を避ける

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

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

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

    オブジェクトのバージョニングを有効にしてこれを行うときに、バケット内にオブジェクトのライブ バージョンがすでに存在する場合、Cloud Storage はそのオブジェクトを上書きしますが、上書きされたオブジェクトの新しい非現行バージョンの作成も行います。この場合、バケットには、上書きされたオブジェクト（現在は非現行バージョン）に加えて、以前は非現行バージョンであったオブジェクトの 2 つのコピー（1 つはライブコピーで、もう 1 つはコピー元の非現行バージョン）が存在し、そのすべてにストレージ料金が発生します。不必要に課金されないようにするには、現在のライブコピーを作成するために使用した非現行バージョンを削除します。

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

  • 世代番号を使用する場合、リクエストは、ライブ バージョンか非現行バージョンかにかかわらず、その名前と世代番号を持つオブジェクトがある限り、成功します。該当するオブジェクトが存在しない場合は、404 Not Found が返されます。

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

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

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

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

次のステップ