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

オブジェクトのライフサイクル管理を設定 構成サンプル

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 は、次のストレージ クラスの移行をサポートしています。

元のストレージ クラス 新しいストレージ クラス
Standard ストレージ Nearline ストレージ
Coldline ストレージ
Archive ストレージ
Nearline ストレージ Coldline ストレージ
Archive ストレージ
Coldline ストレージ Archive ストレージ

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

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

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

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

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

ライフサイクルの条件

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

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

age

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_"] などの条件を使用します。

ルール全体で、接頭辞と接尾辞は合わせて 1,000 個まで指定できます。 Cloud de Confiance コンソールでは、接頭辞または接尾辞を合計 1,000 個までコピーして貼り付けることができます。1 つの条件で接頭辞または接尾辞を 2 回使用することはできません。

matchesStorageClass

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

noncurrentTimeBefore

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

numNewerVersions

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

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

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

たとえば、オブジェクトが削除の条件を満たしても、オブジェクトが直ちに削除されないことがあります。そのため、オブジェクトにライフサイクル アクションが実行されるまで、オブジェクトは表示されます。

バージョニングされたオブジェクトのライフサイクルの動作

バケットでオブジェクトのバージョニングが有効になっている場合、ライフサイクル ルールに従って削除されるライブ オブジェクトは、非現行状態で一定期間存在することになります。非現行バージョンのオブジェクトが削除ルールの条件を満たしている場合、所定の時間が経過した後に非現行バージョンのオブジェクトも削除されます。

たとえば、180 日以上経過したオブジェクトを削除するライフサイクル ルールがあるとします。ライブ オブジェクトが 200 日経過すると削除され、非現行状態になります。非現行となったオブジェクトは 180 日以上経過しているため、しばらくすると、このオブジェクトも削除されます。

オブジェクトの作成日時

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

  • アップロードが完了するまでオブジェクトにライフサイクル ルールは適用されません。
  • オブジェクトの作成日はアップロードの完了時間に基づきます。これは、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 の Pub/Sub 通知を有効にします。この機能は、指定された操作が行われたときに、選択した Pub/Sub トピックに通知を送信します。この機能では、処理を行ったユーザーは記録されないので注意してください。

次のステップ