Object Storage Service:ライフサイクル

仕組み

ライフサイクル管理では、ユーザーが定義したルールを使用して、バケット内のオブジェクトに対して自動操作を実行します。OSS では、ライフサイクルルールを作成後、最大 24 時間以内にそのルールを読み込みます。ルールが読み込まれると、OSS は毎日固定時刻（通常は翌日の 00:00 (UTC) 以降、すなわち UTC + 08:00 の 08:00）に、該当するルールをスキャンし、実行します。

ライフサイクルルールは、以下の 3 つの主要な構成要素からなります：

1. 対象オブジェクト： ルールを適用するオブジェクトを定義します。対象オブジェクトは、オブジェクトプレフィックス (Prefix)、オブジェクトタグ (Tag)、または オブジェクトサイズ (ObjectSize) を基準にフィルター処理できます。

   ライフサイクルルールでは、ワイルドカード、サフィックスマッチング、正規表現はサポートされていません。

2. 実行アクション： フィルター処理されたオブジェクトに対して実行する操作を定義します。主なアクションは以下のとおりです：

   • ストレージクラスのトランジション (Transition)： オブジェクトを低コストのストレージクラス（例：低頻度アクセス、アーカイブ、コールドアーカイブストレージ）へトランジションさせます。

   • 有効期限切れおよび削除 (Expiration)： 指定されたライフサイクル期間が経過した後にオブジェクトを削除します。

   • マルチパートアップロードのフラグメントクリーンアップ (AbortMultipartUpload)： 指定された時間経過後に、未完了のマルチパートアップロードからパーツを自動的に削除します。

3. トリガーポリシー： フィルター処理されたオブジェクトに対してアクションを実行する条件を定義します：

   • 最終更新日時 (Last-Modified-Time)： オブジェクトの最終更新日時を基準に、トランジションまたは削除を実行します。これは、ログやバックアップなど、明確なライフサイクルを持つデータに適しています。ストレージクラスの自動トランジションやオブジェクトの自動削除により、コストを削減できます。

   • 最終アクセス日時 (Last-Access-Time)： アクセス追跡 機能を有効化した後、オブジェクトの最終アクセス日時を基準に、ストレージクラスを知的に切り替えることができます。これは、素材ライブラリなど、アクセスパターンが予測できないシナリオに有用です。データがコールド化するとストレージクラスがダウングレードされ、アクセス時に自動的に復元されます。

ライフサイクルポリシーの設定方法について詳しくは、「ライフサイクル設定要素」をご参照ください。

バケットで ObjectWorm が有効になっている場合、ライフサイクルルールにおけるストレージクラスのトランジション (Transition) 操作には影響しませんが、保持期間中のオブジェクトはライフサイクルルールによる自動削除 (Expiration) の対象になりません。

適用範囲/利用シーン

上記のシナリオに加えて、さらに詳細なデータ管理ポリシーを実装できます。詳しくは、「ライフサイクル設定の例」をご参照ください。必要に応じて、複数のルールを組み合わせることで、バケット内のデータを細かく制御できます。

複数のライフサイクルルール

複数のライフサイクルルールが期待通りに有効になるようにするには、以下の 2 つのコアメカニズムを理解しておく必要があります：ルール実行優先度 および 構成上書きメカニズム。

本番環境に適用

本番環境でライフサイクル管理を安全かつ効率的に活用するには、以下の点を推奨します：

• 導入前にテスト： 最初にテスト用バケットでルールを作成し、本番バケットに適用する前に、その動作が期待通りであることを確認します。

• 削除ルールは慎重に使用： 有効期限切れおよび削除を設定するルールでは、プレフィックスを正確に設定してください。これにより、ルールの適用範囲が広がり、重要なデータが誤って削除されるのを防げます。

• 保護措置としてバージョン管理を有効化： 重要な業務データについては、バケットに対してバージョン管理機能を有効化してください。これにより、ライフサイクルルールによって現在のバージョンのオブジェクトが誤って削除された場合でも、以前のバージョンからデータを復元できます。

• 追加料金を回避するための階層化トランジション： ストレージクラスのトランジションポリシーを設計する際は、後段のステップのトリガー時間が、前段のステップのトリガー時間とそのストレージクラスの最低保存期間の合計より後になるよう設定してください。これにより、早期トランジションによる追加料金を回避できます。

  • 誤った例： 標準 30 日 → 低頻度アクセス 40 日 → アーカイブストレージ。この設定では、オブジェクトが IA ストレージクラスに 10 日間（< 30 日）しか保存されないため、追加料金が発生します。

  • 正しい例： 標準 30 日 → 低頻度アクセス 90 日 → アーカイブストレージ。（オブジェクトは 30 日後に IA ストレージクラスへトランジションされ、その後 60 日間 IA ストレージクラスに残り、合計 90 日後にアーカイブストレージへトランジションされます）。

課金

ライフサイクルルールの設定自体は無料です。ルールが実行され、その結果としてストレージ状態が変更された際にのみ課金されます。

1. リクエスト料金： ライフサイクルルールがストレージクラスのトランジション、オブジェクトの削除、またはパーツの削除を実行すると、システムは Put 型リクエストを開始します。リクエスト料金は、リクエスト数に応じて課金されます。課金ルールの詳細については、「ライフサイクル料金の説明」をご参照ください。

   多数の小規模ファイルを含むバケットでは、この料金が高額になる可能性があります。ルールを設定する前に、事前に評価してください。

2. ストレージ料金： オブジェクトが新しいストレージクラスへトランジションされた後は、その新しいクラスの単位価格で課金されます。

   重要

   低頻度アクセス、アーカイブ、コールドアーカイブストレージなどのストレージクラスには、最低保存期間 の要件があります（例：低頻度アクセスは 30 日、アーカイブは 60 日）。ライフサイクルルールにより、最低保存期間を満たさないままオブジェクトが削除またはトランジションされた場合、残りの保存期間分の料金を支払う必要があります。トランジションまたは削除による、指定期間未満の保存に対する条件付き容量料金 を回避するには、「指定期間未満の保存に対する容量料金を回避する方法」をご参照ください。トランジションまたは削除を実行する前に、最低保存期間が満たされていることを確認してください。

3. データ取得料金： ライフサイクルルール自体はデータ取得料金を発生させません。ただし、低頻度アクセスまたはアーカイブなどのストレージクラスへトランジションされたオブジェクトにアクセスした場合、対応するデータ取得料金が発生します。

   • 低頻度アクセス (IA) オブジェクトを直接読み取ると、データ取得料金が発生します。

   • アーカイブオブジェクトを直接読み取ると、リアルタイムアクセス用のデータ取得容量料金が発生します。

   • アーカイブオブジェクトを復元すると、Put 型リクエスト料金およびデータ取得容量料金が発生します。

   • コールドアーカイブまたはディープコールドアーカイブオブジェクトを復元すると、取得リクエスト料金、取得容量料金、および一時復元容量料金が発生します。

   重要

   コールドアーカイブおよびディープコールドアーカイブオブジェクトの場合、選択した復元優先度に応じて料金が異なります。優先度が高いほど、料金も高くなります。

よくある質問