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

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

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

はじめに

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

オブジェクトのバージョニングが有効になっていると、必要に応じてオブジェクトのアーカイブ バージョンのリストを作成したり、オブジェクトのライブ バージョンを古い状態に復元したり、アーカイブ バージョンを完全に削除したりすることができます。バケットのバージョニングのオンとオフはいつでも切り替えることができます。バージョニングをオフにすると、既存のオブジェクトのバージョンが残され、バケットで新しくアーカイブされたオブジェクトのバージョンの蓄積が停止されます。

注意： アーカイブされたオブジェクトのバージョンは、削除されたバケットから復元できません。

重要: バケットのバージョニング構成を変更した場合、変更の反映に時間がかかる場合があります。このため、しばらくの間、バケット内のオブジェクトが変更前の設定で削除または上書きされる可能性があります。変更した設定でオブジェクトの削除または上書きを行うには、バージョニング設定を変更して少なくとも 30 秒以上経ってからオブジェクトの削除または上書きを行ってください。

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

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

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

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

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

注意: 作成できるオブジェクトのバージョン数にデフォルトの制限はありません。オブジェクトのアーカイブ バージョンは、オブジェクトのライブ バージョンと同じレートで課金されます。バージョニングを有効にする場合は、オブジェクトのライフサイクル管理を使用することを検討してください。これにより、新しいバージョンがアーカイブされると、最も古いバージョンのオブジェクトを削除できます。

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

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

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

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

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

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

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

最初に cat.jpg を Cloud Storage にアップロードすると、generation 番号と metageneration 番号を受信します。この例では、generation 番号は 1360887697105000 です。オブジェクトが新規であるため、metageneration 番号は 1 です。

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

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

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

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

カスタム メタデータ: color:black を追加して、cat.jpg を更新します。メタデータを更新すると、cat.jpg の metageneration の値が増えます。この場合は 1 から 2 になります。ただし、オブジェクト自体は変更されていないため、Cloud Storage は 1 つのバージョンの cat.jpg のみを引き続き保存し、バージョンの 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 を削除します。これを行うと、generation 番号が 1360887759327000 のバージョンがアーカイブされます。バケットには現在 2 つのアーカイブ バージョンの cat.jpg があり、ライブ バージョンはありません。どちらのアーカイブ バージョンもその generation 番号を使用すると参照できますが、generation 番号なしで cat.jpg にアクセスしようとすると失敗します。

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

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

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

アーカイブされたバージョンのいずれかを復元する

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

ヒント

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

gsutil を使用する

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

ETag を避ける

• 条件付きの更新の場合は、ETag ではなく generation 番号と metageneration 番号を使用することを検討してください。generation 番号と metageneration 番号により、メタデータの変更を含むすべてのオブジェクトの更新が追跡されるため、ETag よりも正確な処理が可能となります。

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

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

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

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

• 現在のライブ オブジェクトに対応する 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 になって更新が中止されます。