PutBucketLifecycleOSS インターフェイスを使用して OSS のバケットやオブジェクトのライフサイクルルールを設定し、期限切れのオブジェクトとパートを自動削除したり、期限切れオブジェクトのストレージクラスを IA やアーカイブに変更してストレージコストを節約することができます。

PutBucketLifecycle インターフェイスの詳細は、「 PutBucketLifecycle」をご参照ください。

ライフサイクルルールには、次の情報が含まれています。

  • 一致ポリシー:ライフサイクルルールが適用されるオブジェクトとパートを指定します。
    • プレフィックスによる一致:ライフサイクルルールは、指定されたプレフィックスを持つオブジェクトとパートに適用されます。 プレフィックスが異なるオブジェクトとパートに対して、複数のライフサイクルルールを作成できます。 各ルールに指定するプレフィックスは、異なる必要があります。
    • タグによる一致:ライフサイクルルールは、指定されたタグキーとタグ値を持つオブジェクトに適用されます。 指定されたタグを持つすべてのオブジェクトにルールが適用されるように、1 つのライフサイクルルールに複数のタグを指定できます。 パートは、タグによるライフサイクルルールに一致しません。
      オブジェクトのタグ付け機能はベータテスト段階です。 この機能のトライアル版を申し込むには、 チケットを起票し、サポートセンターへお問い合わせください。 オブジェクトのタグ付け機能の詳細は、「 オブジェクトのタグ付け」をご参照ください。
    • プレフィックスとタグによる一致:ライフサイクルルールは、指定されたプレフィックスと 1 つ以上の指定されたタグを持つオブジェクトに適用されます。
    • バケット全体に一致:ライフサイクルルールは、バケット内のすべてのオブジェクトとパートに適用されます。 バケットに適用されるライフサイクルルールは 1 つのみ作成できます。
  • オブジェクトの有効期限ポリシー:オブジェクトの有効期限と、期限切れオブジェクトに対して実行する操作を指定します。
    • 有効期限:有効期限と、期限切れオブジェクトに対して実行する操作を指定します。 指定された日付より前に変更されたオブジェクトは期限切れになり、指定した操作が実行されます。
    期限切れオブジェクトに対して実行可能な操作には、オブジェクトのストレージクラスを IA に変換する、オブジェクトのストレージクラスをアーカイブに変換する、オブジェクトを削除する、などがあります。
  • パートの有効期限ポリシー:パートの有効期限と、期限切れのパートに対して実行する操作を指定します。
    • 有効期間:有効期間 (N 日) を指定します。 パートは、最終変更日から N 日後に削除されます。
    • 有効期限:有効期限を指定します。 指定した日付より前に変更されたすべてのパートが削除されます。

オブジェクト名のプレフィックスが、ルールに指定されたプレフィックスと一致する場合、そのオブジェクトに対してルールが適用されます。 たとえば、バケットに次のオブジェクトが保存されているとします。

logs/program.log.1
logs/program.log.2
logs/program.log.3
doc/readme.txt

ルールに指定されたプレフィックスが "logs/" の場合、"logs/" で始まる 3 つのオブジェクトにルールが適用されます。 ルールに指定されたプレフィックスが "doc/readme.txt" の場合、doc/readme.txt という名前のオブジェクトにのみルールが適用されます。

期限切れ削除ルールを設定することもできます。 たとえば、"logs/" で始まるオブジェクトの最終日が 30 日前の場合、指定した期限切れ削除時間に従ってオブジェクトは削除されます。

オブジェクトが期限切れルールに一致する場合、オブジェクトの GetObject または HeadObject リクエストへのレスポンスに x-oss-expiration ヘッダーが含まれます。 ヘッダーには 2 つのキーと値のペアが含まれます。expiry-date はオブジェクトの有効期限、rule-id は一致したルール ID を示します。

操作方法

方法 説明
OSS コンソール 使いやすい Web アプリケーション
Java SDK さまざまな言語の完全な SDK デモ
Python SDK
PHP SDK
Go SDK
C SDK
.NET SDK
Node.js SDK
Ruby SDK

OSS API を使用して、バケットのライフサイクルルールを設定できます。 次の例に示すように、ライフサイクルルールは XML 形式です。

<LifecycleConfiguration>
<Rule>
<ID>delete logs after 10 days</ID>
<Prefix>logs/</Prefix>
<Status>Enabled</Status>
<Expiration>
<Days>10</Days>
</Expiration>
</Rule>
<Rule>
<ID>delete doc</ID>
<Prefix>doc/</Prefix>
<Status>Disabled</Status>
<Expiration>
<CreatedBeforeDate>2017-12-31T00:00:00.000Z</CreatedBeforeDate>
</Expiration>
</Rule>
<Rule>
<ID>delete xx=1</ID>
<Prefix>rule2</Prefix>
<Tag><Key>xx</Key><Value>1</Value></Tag>
<Status>Enabled</Status>
<Transition>
<Days>60</Days>
<StorageClass>Archive</StorageClass>
</Transition>
</Rule>
</LifecycleConfiguration>
			

上の例にある要素は、次のとおりです。

  • <ID>:ルールの一意の識別子。
  • <Status>:ライフサイクルルールのステータス。2 つの値 (Enabled または Disabled) があります。 ステータスが Enabled のルールのみが適用されます。
  • <Prefix>:指定したプレフィックスを持つオブジェクトにのみルールが適用されます。
  • <Expiration>:操作の有効期間。 サブ要素の <CreatedBeforeDate> は絶対的な有効期間、<Days> は相対的な有効期間です。
    • CreatedBeforeDate:有効期限と、期限切れオブジェクトに対して実行される操作を指定します。 指定された日付より前に変更されたオブジェクトは期限切れになり、指定した操作が実行されます。
    • Days:有効期間 (N 日) と、期限切れオブジェクトに対して実行される操作を指定します。 最後に変更されてから N 日後にオブジェクトは期限切れになり、指定した操作が実行されます。

1 番目のルールでは、プレフィックスが logs/ で、10 日前に変更されたオブジェクトが削除されます。 2 番目のルールでは、プレフィックスが doc/ で、2014 年 12 月 31 日より前に変更されたオブジェクトが削除されます。 ただし、ルールのステータスが Disabled なので、このルールは有効になりません。 3 番目のルールでは、タグが "xx=1" で、60 日前に変更されたオブジェクトのストレージクラスはアーカイブに変更されます。

詳細分析

  • プレフィックスとタグ
    • プレフィックスの命名規則は、オブジェクトの命名規則と同じです。
    • ルールのプレフィックスが空の場合、バケット内のすべてのオブジェクトにルールが適用されます。
    • バケットのルールに指定するプレフィックスは、一意である必要があります。 たとえば、バケットに 2 つのルールを設定し、ルールのプレフィックスがそれぞれ logs/ と logs/program の場合、エラーが返されます。
    • タグのキーを空にすることはできません。 タグには、文字、数字、スペース、および次の記号を含めることができます。

      + ‑ = . _ : /

    • 異なるルールの一致ポリシー (プレフィックスとタグによる一致) のプレフィックスは、重複可能です。 たとえば、同じバケットにルール 1 とルール 2 が設定されているとします。 ルール 1 では、プレフィックスに logs/、タグに "K1=V1" が指定されています。 ルール 2 では、プレフィックスに logs/program、タグに"K1=V2" が指定されています。 ルール 1 は、プレフィックスが logslogs/program で、タグが "K1=V1" のオブジェクトに適用されます。 ルール 2 は、プレフィックスが logs で、タグが "K1=V1" のオブジェクトに適用されます。
  • 有効期間
    • 特定の日付にオブジェクトを削除するようにルールが設定されている場合、日付は UTC 午前 0 時で、ISO8601 形式 (2017-01-01T00:00:00.000Z など) に準拠する必要があります。 この例では、2017 年 1 月 1 日の午前 0 時以降にオブジェクトが削除されます。
    • 特定の日数以降にオブジェクトを削除するようにルールが設定されている場合、最終更新時刻 (最終変更日) と指定された日数を合計し、合計を UTC 午前 0 時のタイムスタンプに丸められます。 たとえば、オブジェクトの最終更新時刻が 2014 年 4 月 12 日の午前 01:00 で、一致ルールに指定された日数が 3 の場合、有効期限は 2017 年 4 月 16 日の 0 時です。
    • ルールに一致するオブジェクトは、指定された時間に削除されます。 通常、指定された時間の直後にオブジェクトは削除されます。
    • 変更されていないオブジェクトの場合、通常、更新時刻は作成時刻になります。 Put 操作が複数回実行されたオブジェクトの場合、最終更新時刻は、最後の Put 操作の時刻です。 オブジェクトを同じオブジェクトにコピーした場合、最終更新時刻は、オブジェクトを最後にコピーした時刻になります。
  • 料金

    成功したライフサイクル非同期リクエスト操作のみが記録、課金されます。

  • ルールが競合したときに実行されるアクション
    • 2 つのルールに指定されたプレフィックスとタグが同じ。
      ルール プレフィックス タグ アクション
      rule1 abc a=1 一致するオブジェクトを 20 日後に削除する。
      rule2 abc a=1 一致するオブジェクトのストレージクラスを 20 日後にアーカイブに変更する。

      結果:プレフィックスが abc、タグが "a=1" のオブジェクトは、20 日後に削除されます (最初に削除が実行されます)。 一致するオブジェクトは既に削除されているため、2 番目のルールは有効になりません。

      ルール プレフィックス タグ アクション
      rule1 abc a=1 一致するオブジェクトのストレージクラスを 365 日後 に IA に変更する。
      rule2 abc a=1 一致するオブジェクトのストレージクラスを 2018 年 3 月 1 日までにアーカイブに変更する。

      結果:プレフィックスが abc、タグが "a=1" のオブジェクトが同時に 2 つのルールに一致する場合、オブジェクトのストレージはアーカイブに変更されます。 オブジェクトが一方のルールにのみ一致する場合、そのルールに指定されたアクションが実行されます。

    • 2 つのルールに指定されたタグが同じで、ルールに指定されたプレフィックスが重複。
      ルール プレフィックス タグ アクション
      rule1 a=1 一致するオブジェクトのストレージクラスを 20 日後に IA に変更する。
      rule2 abc a=1 一致するオブジェクトを 120 日後に削除する。

      結果:タグが "a=1" の全オブジェクトのストレージクラスが、20 日後に IA に変更されます。 プレフィックスが abc、タグが "a=1" のオブジェクトは、120 日後に削除されます。

      ルール プレフィックス タグ アクション
      rule1 a=1 一致するオブジェクトのストレージクラスを、10 日後にアーカイブに変更する。
      rule2 abc a=1 一致するオブジェクトのストレージクラスを 20 日後に IA に変更する。

      結果:タグが "a=1" の全オブジェクトのストレージクラスがアーカイブに変更されます。 アーカイブオブジェクトのストレージクラスを IA に変更することができないため、プレフィックスが abc でタグが "a=1" のオブジェクトに対して、2 番目のルールは適用されません。

FAQ

  • ストレージクラスを変更するか、期限切れオブジェクトを削除するようにライフサイクルルールが設定されている場合、このルールに最小保存期間はありますか。

    オブジェクトのストレージクラスを変更 (標準から IA かアーカイブ、または IA からアーカイブ) するようにライフサイクルルールが設定されている場合、このルールに最小保存期間は不要です。 ただし、有効期限が切れたオブジェクトを削除するように設定されたライフサイクルルールには、最小保存期間が必要です。 IA ストレージクラスのオブジェクトの場合、最小保存期間は 30 日、アーカイブストレージクラスのオブジェクトの場合は 60 日です。

    期限切れオブジェクトを削除するように設定されたライフサイクルルールの最小保存期間とは、オブジェクトが作成されてから削除されるまでの期間を示します。 この期間中にオブジェクトが変更された場合 (CopyObject 操作か AppendObject 操作などで)、最小保存期間は最終変更日から計算されます。

    例 1:オブジェクトの作成から 10 日後にストレージクラスを IA からアーカイブに変更します。 オブジェクトの作成時間は変更されません。 変更したオブジェクトは、50 日間以上保存する必要があります。
    例 2:オブジェクトの作成から 10 日後に、CopyObject 操作でストレージクラスを IA からアーカイブに変更する場合、削除には 20 日分の料金が発生します。 オブジェクトの作成時間は更新されます。 変更したオブジェクトは、60 日間以上保存する必要があります。
  • リクエストの課金ロジック

    ライフサイクルルールに従ってストレージクラスを変更したり、期限切れオブジェクトを削除した場合、リクエストが生成されます。 リクエストは、OSS で課金されます。 例:

    • ライフサイクルルールに従って、1000 個のオブジェクトのストレージクラスが標準からアーカイブに変更された場合、1000 個の POST リクエストが生成されます。
    • ライフサイクルルールに従って、1000 個の期限切れオブジェクトが削除された場合、1000 個の削除リクエストが生成されます。

    詳細は、「課金方法」をご参照ください。

  • ライフサイクルルールに従ってストレージクラスの変更や期限切れオブジェクト削除が実行された場合、記録されますか。
    ライフサイクルルールに従って実行されたストレージクラスの変更や期限切れオブジェクトの削除は、ログに記録されます。 ログのフィールドは次のとおりです。
    • Operation
      • CommitTransition:オブジェクトのストレージクラスを変更するようにルールが設定されていることを示します。
      • ExpireObject:期限切れオブジェクトを削除するようにルールが設定されていることを示します。
    • Sync Request
      • lifecycle:ライフサイクルルールによって実行される操作を示します。