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

サンプルに移動

削除または置換されたオブジェクトを取得できるようにするため、Cloud Storage にはオブジェクトのバージョニング機能があります。このページでは、この機能と、この機能を使用するときに使用可能なオプションについて説明します。

はじめに

バケットのオブジェクトのバージョニングを有効にします。有効にすると、次のようになります。

  • ライブ バージョンの世代番号を指定しない限り、ライブ オブジェクト バージョンを置換または削除するたびに、Cloud Storage には、非現行オブジェクト バージョンが保持されます。

    • 非現行バージョンではオブジェクトの名前が保持されますが、世代番号によって一意に識別されます。

    • 非現行バージョンは、それを含めるよう明示的に要求するリクエストにのみ表示されます。

  • オブジェクトのバージョンを完全に削除するには、削除リクエストに世代番号を含めるか、オブジェクトのライフサイクル管理を使用します。

  • オブジェクトの非現行バージョンは、ライブ バージョンとは独立して存在します。

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

  • このバケットでは、オブジェクトの新しい非現行バージョンが蓄積されなくなります。

  • バケットにすでに存在するオブジェクトのバージョンは影響を受けません。

考慮事項

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

  • オブジェクト バージョンの数にデフォルトの上限はありません。オブジェクトの各非現行バージョンは、ライブ時と同じレートで課金されます。

    • 早期削除料金は、オブジェクト バージョンがバケットから削除された場合にのみ適用されます。バージョンが非現行バージョンになったときは適用されません。バケットから削除されたバージョンの保存期間は、そのバケットが非現行バージョンになった時刻ではなく、バケットに追加された時刻に基づきます。

    • バージョニングを有効にする場合は、オブジェクトのライフサイクル管理の使用を検討してください。これを使用すると、指定した期間が終了するか、新しいバージョンが非現行になった場合に、オブジェクトの古いバージョンが削除されます。考えられる設定については、オブジェクトの削除のライフサイクル構成例をご覧ください。

非現行オブジェクトのメタデータ

非現行バージョンのオブジェクトに、ライブ バージョンのメタデータとは異なる独自のメタデータが存在する場合があります。ここで重要なことは、非現行バージョンはその 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 の 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 つはコピー元の非現行バージョン）が存在し、そのすべてにストレージ料金が発生します。不要な費用の発生を防ぐには、現在のライブ バージョンの作成に使用した [noncurrent version]12] を削除するか、オブジェクト ライフサイクル管理を構成して、非現行オブジェクトが指定した条件を満たしたときに削除されるようにします。

ライブ バージョンのオブジェクトの変更時に 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 で更新が異常終了します。

次のステップ