オブジェクトのライフサイクル管理

設定 構成サンプル

Cloud Storage では、オブジェクトの有効期間（TTL）の設定、非現行バージョンの保持、コスト管理を容易にするためのストレージ クラスの「ダウングレード」など、一般的なユースケースをサポートするため、オブジェクトのライフサイクル管理機能を提供しています。

このページでは、この機能と使用可能なオプションについて説明します。ライフサイクル構成ファイルの一般的な形式については、JSON のバケット リソース表現と XML のライフサイクル構成形式をご覧ください。

はじめに

オブジェクトのライフサイクル管理を使用するには、ライフサイクル構成を定義します。また、その構成は、バケットに置かれる必要があります。この構成には、バケット内に現在あるオブジェクトと今後追加されるオブジェクトに適用する一連のルールが記述されます。オブジェクトがいずれかのルールの基準に一致すると、Cloud Storage ではオブジェクトに対して指定された操作が自動的に行われます次のような処理が例として挙げられます。

  • 365 日以上経過したオブジェクトのストレージ クラスを Coldline ストレージにダウングレードする。
  • 2019 年 1 月 1 日より前に作成されたオブジェクトを削除する。
  • バージョニングが有効になっているバケット内の各オブジェクトで、最新のバージョン 3 つのみを維持する。

ライフサイクルの構成

ライフサイクル管理の設定は一連のルールから構成されます。各ルールには、1 つのアクションと 1 つ以上の条件が含まれます。

  • ルール内の操作を実行するには、オブジェクトがルールで指定された条件のすべてに一致する必要があります。

  • 同じ操作を含む複数のルールを指定した場合、オブジェクトがルールのいずれかの条件に一致すると、そのオブジェクトに対して操作が実行されます。

  • 複数のルールが 1 つのオブジェクトに対して同時にそれらの条件を満たしている場合、Cloud Storage は次の考慮事項に基づいて、1 つのルールのみに関連付けられた操作を実行します。

    • Delete 操作は、どの SetStorageClass 操作よりも優先されます。
    • 保存時のストレージ料金が最も安いストレージ クラスにオブジェクトを切り替える SetStorageClass 操作が優先されます。

    たとえば、オブジェクト クラスを Nearline ストレージに変更するルールと Coldline ストレージに変更するルールがあり、両方のルールに同一の条件が設定されていると、条件に一致したときには、常に Coldline ストレージへ変更されます。

  • 本番環境に適用する前に、開発用のデータでライフサイクル ルールをテストし、意図しない条件下でルールがアクションを実行しないようにする必要があります。それができない場合は、ルールの matchesPrefix 条件または matchesSuffix 条件を使用して、本番環境データの小さなサブセットでテストを行う必要があります。

  • バケットのライフサイクル構成に対する変更が反映されるまでに最大で 24 時間かかることがあります。その間、オブジェクトのライフサイクル管理は古い構成に基づいてアクションを実行する可能性があります。

    たとえば、age 条件を 10 日から 20 日に変更した場合、最大 24 時間、古い構成に基づいて、11 日目のオブジェクトがオブジェクトのライフサイクル管理に基づいて削除される可能性があります。

ユースケースについては、オブジェクトのライフサイクル管理の構成例をご覧ください。

ライフサイクルの操作

ライフサイクル ルールには、次のアクションのいずれか 1 つのみを指定します。

削除

Delete アクションを指定すると、オブジェクトがライフサイクル ルールで指定されたすべての条件を満たしている場合に、オブジェクトが削除されます。デフォルトでは、ライブ オブジェクトを削除すると、オブジェクトは復元可能な状態で削除され、Cloud Storage によって 7 日間保持されます。この削除済み（復元可能）オブジェクトは、削除（復元可能）の保持期間内に復元できます。

例外: オブジェクトのバージョニングが有効になっているバケットでは、オブジェクトのライブ バージョンを削除すると非現行バージョンになりますが、非現行バージョンを削除すると、そのバージョンはバケットから削除されます。オブジェクトのバージョニングとともに Delete アクションを使用する例については、オブジェクト削除の構成をご覧ください。

オブジェクトにオブジェクト保留が設定されている場合、あるいは保持ポリシーがまだ処理されていない場合、Delete アクションはオブジェクトに適用されません。オブジェクトに対して Delete アクションの条件が満たされている限り、オブジェクト保持が解除され、保持ポリシーが満たされた後に Delete アクションが実行されます。

SetStorageClass

SetStorageClass アクションを指定すると、オブジェクトのストレージ クラスが変更され、オブジェクトがライフサイクル ルールで指定されたすべての条件を満たしている場合に、オブジェクトの変更時間が更新されます。

SetStorageClass は、次のストレージ クラスの移行をサポートしています。

元のストレージ クラス 新しいストレージ クラス
Durable Reduced Availability（DRA）ストレージ Nearline ストレージ
Coldline ストレージ
Archive ストレージ
Multi-Regional ストレージ / Regional ストレージ1
Standard ストレージ、Multi-Regional ストレージ、Regional ストレージ Nearline ストレージ
Coldline ストレージ
Archive ストレージ
Nearline ストレージ Coldline ストレージ
Archive ストレージ
Coldline ストレージ Archive ストレージ

1 リージョン内のバケットの場合、新しいストレージ クラスを Multi-Regional ストレージにすることはできません。マルチリージョンまたはデュアルリージョンのバケットの場合、新しいストレージ クラスを Regional ストレージにすることはできません。

Cloud Storage では、ストレージ クラスの移行の正確性は検証されません。つまり、上記の表にないストレージ クラスの移行を指定することはできますが、移行は行われません。ライフサイクル ルールで、上記の表に掲載されているストレージ クラスの移行のいずれかが使用されていることを確認する必要があります。

不完全なマルチパート アップロードの中止

AbortIncompleteMultipartUpload アクションは、不完全なマルチパート アップロードを中止します。マルチパート アップロードがライフサイクル ルールで指定された条件を満たすと、関連するパートを削除します。

このアクションでは、次のライフサイクル条件のみを使用できます。

AbortIncompleteMultipartUpload アクションと他の条件を組み合わせたルールを作成しようとすると、エラーが発生します。

ライフサイクルの条件

ライフサイクル ルールには、ルールで定義されたアクションがオブジェクトに適用される前に、オブジェクトが満たす必要がある条件が含まれています。ライフサイクル ルールでは、次の条件がサポートされています。

すべての条件は任意ですが、少なくとも 1 つの条件が必要です。存在しない操作や条件を指定するなど、無効なライフサイクル構成を行うと、400 Bad request エラーが返され、既存のライフサイクル構成はそのまま残ります。

age

age 条件は、リソースが指定された経過時間（日数）に達すると満たされます。経過時間は、オブジェクトが作成された時点から測定されます。

  • オブジェクトの作成日時は、オブジェクトがバケットに正常に書き込まれた日時です（アップロードの完了時など）。

    • オブジェクトの経過時間は、オブジェクトが非現行バージョンになることによって影響を受けることはありません。

  • マルチパート アップロードの場合、作成日時はアップロードが開始された日時です。

たとえば、2022/01/10 10:00 UTC にリソースが作成され、age 条件が 10 日の場合、2022/01/20 10:00 UTC 以降のリソースについて条件が満たされます。

createdBefore

createdBefore 条件は、オブジェクトが UTC の指定された日付の午前 0 時より前に作成されていると満たされます。

customTimeBefore

customTimeBefore 条件は、オブジェクトの Custom-Time メタデータの日付がこの条件で指定された日付より早い場合に満たされます。この条件は、日付形式 YYYY-MM-DD を使用して設定されます。オブジェクトに Custom-Time メタデータが設定されないと、customTimeBefore が満たされることはありません。

daysSinceCustomTime

daysSinceCustomTime 条件は、オブジェクトの Custom-Time メタデータ フィールドに指定された日時から特定の日数が経過すると満たされます。たとえば、オブジェクトの Custom-Time が 2020-05-16T10:00:00Z で daysSinceCustomTime 条件が 10 日であれば、2020/05/26 10:00 UTC の時点でオブジェクトの条件が満たされたことになります。

オブジェクトに Custom-Time メタデータが設定されないと、daysSinceCustomTime が満たされることはありません。

daysSinceNoncurrentTime

daysSinceNoncurrentTime 条件は通常、オブジェクトのバージョニングとともに使用されます。この条件は、ライブ バージョンが削除または置換されたために、オブジェクトが非現行となった時点から特定の日数が経過すると満たされます。たとえば、オブジェクトが 2020/07/08 15:00 UTC の時点で非現行となり、daysSinceNoncurrentTime 条件が 10 日であれば、2020/07/18 15:00 UTC の時点でオブジェクトの条件が満たされたことになります。

isLive

isLive 条件は通常、オブジェクトのバージョニングとともに使用されます。false に設定すると、この条件は、オブジェクトが非現行バージョンである場合に満たされるようになります。true に設定すると、この条件は、オブジェクトがライブ バージョンである場合に満たされるようになります。バージョニングを使用しない場合、isLive が true のときは、すべてのオブジェクトがライブ バージョンとみなされます。

matchesPrefix と matchesSuffix

matchesPrefix 条件と matchesSuffix 条件は、オブジェクト名の先頭または末尾が指定した接頭辞または接尾辞と完全に一致している場合に満たされます。複数の文字列をリストとして指定できます（例: "matchesSuffix": [".jpg", ".png"]）。

matchesPrefix を使用する場合は、リクエストパスでオブジェクト名の前にバケット名または / を含めないでください。たとえば、Google Cloud CLI で、my_bucket というバケット内のオブジェクトのパスは gs://my_bucket/pictures/paris_2022.jpg のような形式になります。オブジェクトに一致させるには、"matchesPrefix":["pictures/paris_"] などの条件を使用します。

すべてのルールで最大 50 個の接頭辞と 50 個の接尾辞を指定できます。1 つの条件で接頭辞または接尾辞を 2 回使用することはできません。

matchesStorageClass

matchesStorageClass 条件は、バケット内のオブジェクトが、指定されたストレージ クラスとして保存されると満たされます。matchesStorageClass には、STANDARD、NEARLINE、COLDLINE、ARCHIVE、MULTI_REGIONAL、REGIONAL、DURABLE_REDUCED_AVAILABILITY の値を使用できます。

通常、Standard ストレージ オブジェクトで matchesStorageClass 条件を使用する場合は、次のものも含める必要があります。

  • バケットがリージョンにある場合、条件に REGIONAL と DURABLE_REDUCED_AVAILABILITY を含めます。

  • バケットがマルチリージョンまたはデュアルリージョンにある場合は、条件に MULTI_REGIONAL と DURABLE_REDUCED_AVAILABILITY を含めます。

これらの追加クラスを追加すると、バケット内のレガシー ストレージ クラスに設定されている古いオブジェクトもライフサイクル ルールの対象となります。

noncurrentTimeBefore

noncurrentTimeBefore 条件は通常、オブジェクトのバージョニングとともに使用されます。オブジェクトが指定された日付よりも前の日付に非現行となった場合にこの条件が成立します。条件は日付形式 YYYY-MM-DD を使用して設定されます。ライブ オブジェクトでは noncurrentTimeBefore が満たされることはありません。

numNewerVersions

numNewerVersions 条件は通常、オブジェクトのバージョニングとともに使用されます。この条件の値が N に設定されている場合、オブジェクトのバージョンは、それよりも新しいバージョンが少なくとも N バージョン（ライブ バージョンを含む）存在する場合に条件を満たします。ライブ オブジェクト バージョンの場合、それよりも新しいバージョンの数は 0 とみなされます。最も新しい非現行バージョンの場合、それよりも新しいバージョンの数は 1 であり（ライブ オブジェクト バージョンがない場合は 0）、以降、同様に続きます。

オブジェクトのライフサイクル動作

Cloud Storage は、オブジェクトのライフサイクル管理が構成されたバケット内のすべてのオブジェクトを定期的に検査し、バケットのルールに従って適用されるすべての操作を行います。Cloud Storage は非同期で操作を行います。このため、条件が一致してから操作が行われるまでに時間差が生じる場合があります。アプリケーションでは、ライフサイクル条件が満たされた後の一定期間内に発生するライフサイクル処理に依存しないでください。

たとえば、オブジェクトが削除の条件を満たしても、オブジェクトが直ちに削除されないことがあります。そのため、オブジェクトにライフサイクル アクションが実行されるまで、オブジェクトは表示されます。つまり、オブジェクトのバージョニングが有効になっているバケットでは、非現行状態のライブ オブジェクトが一定時間存在することになります。これは、非現行バージョンのオブジェクトが削除ルールの条件も満たす場合でも同じです。

オブジェクトが元の状態のままである限り、該当する料金が適用されます。ただし、例外として、オブジェクトが次の条件をすべて満たしている場合、保存時のストレージ料金はかかりません。

  • オブジェクトが、削除（復元可能）が無効になっているバケット内にある
  • オブジェクトが Delete アクションを伴うルールの対象である
  • ルールの条件が age 条件のみである
  • オブジェクトに対して age 条件が満たされている

SetStorageClass の費用に関する考慮事項

オブジェクトのストレージ クラスを手動で変更する場合と同様に、SetStorageClass の使用はクラス A オペレーションとカウントされ、宛先のストレージ クラスによって決まるレートで請求されます。

ただし、オブジェクトのストレージ クラスを手動で変更する場合と異なり、SetStorageClass を使用してもオブジェクトは書き換えられません。これで、オブジェクトのライフサイクル管理に一定の料金上のメリットがもたらされます。

たとえば、オブジェクトを Nearline ストレージとしてアップロードし、20 日後にライフサイクルの構成でオブジェクトのストレージ クラスを Coldline ストレージに変更したとします。この変更で取得料金や早期削除料金は発生しません。ストレージ クラスの変更から 60 日後にオブジェクトを削除した場合、Coldline ストレージの最低保存期間は 90 日で、オブジェクトの作成から合計 80 日経過しているため、10 日分の早期削除料金が発生します。

また、オブジェクトを Nearline ストレージとしてアップロードし、20 日後にリライト操作でストレージ クラスを変更したとします（Coldline ストレージに戻したとします）。この変更で、取得料金と 10 日間の早期削除料金のどちらも発生します。リライトから 60 日後にオブジェクトを削除すると、30 日の早期削除料金が発生します。

どちらの例でも、バケットで削除（復元可能）が有効になっていると、ストレージの費用は増加しますが、削除（復元可能）の保持期間の長さに応じて早期削除の費用は減少します。

オブジェクトの作成日時

多くの場合、オブジェクトのアップロードは実行後すぐに開始しますが、再開可能なアップロードなど、複数のリクエストで発生するアップロードでは、最初のアップロード リクエストが送信されてから最後のアップロード リクエストが送信されるまでに数日かかることがあります。このような場合、次の点に注意してください。

  • アップロードが完了するまでオブジェクトにライフサイクル ルールは適用されません。
  • オブジェクトの作成日はアップロードの完了時間に基づきます。これは、age と createdBefore のライフサイクル条件に影響します。
  • オブジェクトに Custom-Time を設定する場合は、アップロードの開始時に行います。リクエストの作成時間に基づいて Custom-Time を設定した場合、Custom-Time はオブジェクトの作成時間よりもかなり前になることがあります。これは、customTimeBefore と daysSinceCustomTime のライフサイクル条件に影響します。

有効期限のメタデータ

Delete 処理が age 条件でバケットに指定されている場合（および matchesStorageClass 以外の条件なし）、一部のオブジェクトに有効期限メタデータがタグ付けされることがあります。オブジェクトの有効期限は、オブジェクトがオブジェクトのライフサイクル管理による削除の対象となる（または対象となった）日時を示します。バケットのライフサイクル構成または保持ポリシーが変更されると、有効期限が変更される可能性があります。

有効期限のメタデータが存在しない場合、必ずしもオブジェクトが削除されないことを意味するわけではなく、削除の有無や削除の時期について判断する十分な情報がないことを意味します。 たとえば、オブジェクトの作成時点が 2020/01/10 10:00 UTC で、age 条件が 10 日であれば、オブジェクトの有効期限は 2020/01/20 10:00 UTC になります。ただし、次の場合はオブジェクトに有効期限は使用できません。

  • Delete ルールにその他の条件が指定されている（matchesStorageClass を除く）。

  • オブジェクトのストレージ クラスを含まない matchesStorageClass 条件を使用している。

  • Cloud Storage は保留の解除を確認できないため、オブジェクトは保留状態になります。

  • バケットで削除（復元可能）が有効になっている。

オブジェクトがすぐに削除されない場合であっても、有効期限後にストレージの料金が発生することはありません。削除される前のオブジェクトにはひき続きアクセスでき、ストレージ以外の料金（リクエスト、ネットワーク帯域幅）が発生します。オブジェクトの有効期限が利用できない場合、オブジェクトが削除されるまでストレージの料金が発生します。

有効期限を設定する際は、次の点に注意してください。

  • バケットに保持ポリシーが設定されている場合、オブジェクトのライフサイクル管理の age 条件を満たし、オブジェクトが保存ポリシーで指定された保持期間を満了する時間が有効期限になります。

  • 異なるライフサイクル管理ルールにより、オブジェクトに適用される有効期限が複数存在し、それらが矛盾する場合は、最も早い有効期限が使用されます。

ライフサイクルの処理を追跡するためのオプション

Cloud Storage が行うライフサイクル管理の処理を追跡するには、次のオプションのいずれかを使用します。

  • Cloud Storage の使用状況ログを使用します。この機能は、処理と処理を行ったユーザーの両方をログに記録します。ログエントリの cs_user_agent フィールドの値が GCS Lifecycle Management の場合、ライフサイクルの構成に応じて、Cloud Storage が処理を実行しています。
  • バケット用の Cloud Storage の Pub/Sub 通知を有効にします。この機能は、指定された操作が行われたときに、選択した Pub/Sub トピックに通知を送信します。この機能では、処理を行ったユーザーは記録されないので注意してください。

次のステップ