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

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

はじめに

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

カスタム メタデータ color:black を追加して cat.jpg のメタデータを更新します。メタデータを更新すると、cat.jpgmetageneration の値が増えます。この場合は 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#1360887697105000cat.jpg#1360887759327000 を削除するまではバケットに保存されたままです。

ヒント

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

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 になって更新が中止されます。

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