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

Cloud Storage では、オブジェクトの有効期間(TTL)の設定、古いバージョンのアーカイブ、コスト管理を容易にするためのストレージ クラスのダウングレードなど、一般的な作業をサポートするため、オブジェクトのライフサイクル管理機能を提供しています。このページでは、この機能と使用可能なオプションについて説明します。オブジェクト ライフサイクル管理を有効にする方法や、ライフサイクル ポリシーの例については、ライフサイクルの管理をご覧ください。

はじめに

バケットにライフサイクル管理の設定を割り当てることができます。たとえば、バケット内のすべてのオブジェクトに適用されるルールを設定できます。オブジェクトがいずれかのルールの条件に一致すると、Cloud Storage はオブジェクトに指定された操作を自動的に実行します。次のような処理が例として挙げられます。

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

ライフサイクルの設定

ライフサイクル管理の設定は一連のルールから構成されます。ルールを定義する場合、任意の操作に任意の条件を指定できます。1 つのルールに複数の条件を指定した場合、オブジェクトがすべての条件に一致しないと、操作は実行されません。同じ操作を含む複数のルールを指定した場合、オブジェクトがルールのいずれかの条件に一致すると、操作が実行されます。1 つのルールには 1 つの操作のみを設定します。

1 つのオブジェクトに複数の操作が設定されている場合、Cloud Storage は 1 つの操作だけを実行し、別の操作を実行する前にオブジェクトを再度評価します。Delete 操作は SetStorageClass 操作よりも優先されます。複数の SetStorageClass 操作が指定されている場合、保存時のストレージ料金が最も安いストレージ クラスに切り替える操作が選択されます。

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

ライフサイクルの操作

ライフサイクルのルールでは次の操作を使用できます。

  • Delete: ライブ オブジェクトまたはアーカイブされたオブジェクトを削除します。ライブ オブジェクトとは、アーカイブされた世代でないオブジェクトです。詳細については、オブジェクトのバージョニングをご覧ください。この操作は、バージョニングされたオブジェクトとバージョニングされていないオブジェクトの両方に実行できます。バージョニングが有効なバケットでは、ライブ オブジェクトを削除するとアーカイブされたオブジェクトが作成されますが、アーカイブされたオブジェクトを削除するとオブジェクトが完全に削除されます。

  • SetStorageClass: ライブ オブジェクトまたはアーカイブされたオブジェクトのストレージ クラスを変更します。この操作は、バージョニングされたオブジェクトとバージョニングされていないオブジェクトの両方に実行できます。この操作は、次のストレージ クラスの移行で実行できます。

    元のストレージ クラス 新しいストレージ クラス
    Multi-Regional Storage Nearline Storage
    Coldline Storage
    Regional Storage Nearline Storage
    Coldline Storage
    Nearline Storage Coldline Storage

ライフサイクルの条件

ライフサイクル ルールには次の条件を指定できます。

  • Age: オブジェクトの作成後に指定の日数が経過すると条件が満たされます。Age 条件を指定すると、ライフサイクル管理が設定されたバケット内のオブジェクトに有効期限(TTL)を指定することになります。Age 条件が満たされたとみなされる日時は、オブジェクトの作成時点に指定の値を加えて計算されます。たとえば、オブジェクトの作成時点が 2017/01/10 10:00 UTC で、Age 条件が 10 日であれば、2017/01/20 10:00 UTC 時点で条件が満たされたことになります。これは、オブジェクトの作成後にバージョニングでオブジェクトがアーカイブされる場合にも当てはまります。

  • CreatedBefore: この条件は、オブジェクトが指定の日付(UTC)の深夜より前に作成されていると満たされます。

  • IsLive: このライフサイクル条件は値が true の場合はライブ オブジェクトのみに、false の場合はアーカイブされたオブジェクトにのみ一致します。この条件では、バージョニングされていないバケットのオブジェクトはライブだとみなされます。

  • MatchesStorageClass: この条件は、バケット内のオブジェクトが指定されたストレージ クラスに保存されると満たされます。通常、この条件を Multi-Regional Storage または Regional Storage のオブジェクトに使用する場合には、類似したストレージ クラスのすべてのオブジェクトが対象になるように、STANDARDDURABLE_REDUCED_AVAILABILITY を条件に追加する必要があります。

  • NumberOfNewerVersions: バージョニングされたオブジェクトにのみ関連します。この条件の値が N に設定されている場合、このバージョンよりも新しいバージョンが N 個以上(ライブ バージョンを含む)存在すると、オブジェクトが条件に一致します。ライブ オブジェクトであれば新しいバージョンの数は 0、最新のアーカイブされたバージョンであれば新しいバージョンの数は 1(ライブ オブジェクトが存在しない場合は 0)となります。

すべての条件はオプションですが、少なくとも 1 つの条件が必要です。条件を省略すると、ライフサイクル ルールでは、その条件に基づいてフィルタリングしません。たとえば、Age が省略されている場合、オブジェクトは年齢に基づいてフィルタリングされません。

Consolegsutil ツールJSON API、または XML API を使用してライフサイクル設定を操作できます。JSON および gsutil ツールを使用するときのライフサイクル設定の一般的な形式については、JSON のバケット リソース表現をご覧ください。XML のライフサイクル設定の一般的な形式については、XML のライフサイクル設定形式をご覧ください。存在しない操作や条件を指定するなど、無効なライフサイクル設定を行うと、400 Bad request エラーが返され、既存のライフサイクル設定はそのまま残ります。

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

Cloud Storage は、オブジェクトのライフサイクル管理が設定されたバケット内のすべてのオブジェクトを定期的に検査し、バケットのルールに従って適用されるすべての操作を実行します。Cloud Storage は非同期で操作を実行します。このため、条件が一致してから操作が実行されるまでに時間差が生じる場合があります。

たとえば、オブジェクトが削除の条件を満たしても、オブジェクトが直ちに削除されないことがあります。そのため、オブジェクトにライフサイクル操作が実行されるまで、オブジェクトは表示されます。オブジェクトのストレージに課金されることはありませんが、オブジェクトにアクセスすると、料金設定に従って所定のオペレーションと帯域幅の料金が発生します。

ライフサイクル設定に対する更新が反映されるまでに、最大で 24 時間かかります。したがって、ライフサイクル管理の設定を変更してから 24 時間が経過するまでは、古い設定で操作が実行される可能性があります。

たとえば、Age 条件を 10 日から 20 日に変更した場合、変更後 24 時間が経過するまでは、オブジェクト ライフサイクル管理が古い設定に従って 11 日目のオブジェクトを削除する可能性があります。

Nearline Storage オブジェクトと Coldline Storage オブジェクトの早期削除

オブジェクト ライフサイクル管理では、ストレージ クラスが変更されても、オブジェクトの書き換えを行いません。このため、SetStorageClass 機能によりオブジェクトを Nearline Storage または Coldline Storage に移行した場合、それ以降の早期削除と関連する課金は、ストレージ クラスがいつ変更されたかに関係なく、オブジェクトの最初の作成時間に基づいて行われます。

たとえば、オブジェクトを Regional Storage としてアップロードし、20 日後にライフサイクルの設定でオブジェクトのストレージ クラスを Nearline Storage に変更したとします。ここでオブジェクトを削除すると、オブジェクトの作成から 20 日経過しているため、10 日分の早期削除料金が発生します。ストレージ クラスを Nearline Storage に変更してから 10 日後にオブジェクトを削除した場合、オブジェクトの作成から 30 日経過しているため、早期削除料金は発生しません。

また、オブジェクトを Regional Storage としてアップロードし、20 日後に書き換え操作でストレージ クラスを変更したとします(Nearline Storage に戻したとします)。ここでオブジェクトを削除すると、書き換え時間が新しい作成時間になるため、30 日間の早期削除料金が発生します。同様に、書き換えから 10 日後にオブジェクトを削除すると、20 日間の早期削除料金が発生します。

有効期限のメタデータ

Delete 処理が Age 条件でバケットに設定されている場合(NumberOfNewerVersions 条件はなし)、一部のオブジェクトに有効期限のメタデータがタグ付けされることがあります。オブジェクトの有効期限は、オブジェクトがオブジェクトのライフサイクル管理による削除の対象となる(または対象となった)日時を示します。有効期限は、バケットのライフサイクル構成の変更に応じて変更される場合があります。

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

  • NumberOfNewerVersions 条件も指定されている。この場合、新しいバージョンが追加されるとオブジェクトの古いバージョンは削除されます。

  • CreatedBefore 条件が指定されていて「2013-01-01」に設定されている。オブジェクトはこの条件を満たしていません。

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

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

メタデータが利用可能な場合は、メタデータでオブジェクトの有効期限にアクセスできます。REST API は、x-goog-expiration レスポンス ヘッダーにオブジェクトの有効期限を返します。

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

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

  • Cloud Storage アクセスログ使用します。この機能は、処理と処理を行ったユーザーの両方をログに記録します。ログエントリーの cs_user_agent フィールドの値が GCS Lifecycle Management の場合、ライフサイクルの設定に応じて、Cloud Storage が処理を実行しています。

  • バケット用の Cloud Pub/Sub Notifications for Cloud Storage を有効にします。この機能は、指定された処理が実行されたときに、選択した Cloud Pub/Sub トピックに通知を送信します。この機能では、処理を実行したユーザーは記録されないことに注意してください。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

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

Cloud Storage ドキュメント