OSS に保存されているデータへのアクセス頻度は、通常、時間の経過とともに低下します。コールドデータをコストの高い標準ストレージクラスに保存するのは経済的ではありません。また、大量のログファイルやバックアップを手動でクリーンアップするのも非効率です。ライフサイクル管理を使用すると、自動化されたルールを作成できます。これらのルールは、指定された期間 (たとえば 30 日間) が経過すると、オブジェクトを低頻度アクセスやアーカイブなどの低コストのストレージクラスに自動的に移行できます。また、ルールによってオブジェクトを削除することもできます。これにより、データのライフサイクル全体をインテリジェントかつ低コストで管理できます。
仕組み
ライフサイクル管理は、ユーザー定義のルールを使用して、バケット内のオブジェクトに対して自動化された操作を実行します。OSS は、ライフサイクルルールが作成されてから 24 時間以内にロードします。ルールがロードされると、OSS は毎日決まった時間に、通常は翌日の 00:00 (UTC)、つまり 08:00 (UTC+8) 以降に、一致するルールをスキャンして実行します。
ライフサイクルルールは、主に次の 3 つの部分で構成されます：
管理対象オブジェクト：ルールを適用するオブジェクトを定義します。オブジェクトプレフィックス (Prefix)、オブジェクトタグ (Tag)、またはオブジェクトサイズ (ObjectSize) に基づいてターゲットオブジェクトをフィルターできます。
ライフサイクルルールは、ワイルドカード文字、サフィックスマッチング、正規表現をサポートしていません。
実行するアクション：フィルターされたオブジェクトに対して何を行うかを定義します。主なアクションは次のとおりです：
ストレージクラスの移行 (Transition)：オブジェクトを低頻度アクセス、アーカイブ、コールドアーカイブなどの低コストのストレージクラスに移行します。
有効期限切れと削除 (Expiration)：指定されたライフサイクル期間に達したオブジェクトを削除します。
フラグメントのクリーンアップ (AbortMultipartUpload)：未完了のマルチパートアップロードのパートを指定した時間後に自動的に削除します。
トリガーポリシー：フィルターされたオブジェクトに対するアクションをトリガーする条件を定義します：
最終更新日時 (Last-Modified-Time)：最終更新日時に基づいてオブジェクトを移行または削除します。これは、ログやバックアップなど、明確なライフサイクルを持つデータに適しています。ストレージクラスを自動的に移行したり、オブジェクトを削除したりして、コストを節約できます。
最終アクセス日時 (Last-Access-Time)：アクセス追跡機能を有効にすると、オブジェクトの最終アクセス時間に基づいてストレージクラスをインテリジェントに切り替えることができます。これは、素材ライブラリなど、アクセスパターンが予測できないシナリオで役立ちます。データがコールドになるとストレージクラスをダウングレードし、データがアクセスされると自動的に復元できます。
ライフサイクルポリシーの設定方法の詳細については、「ライフサイクル設定要素」をご参照ください。
設定シナリオ
期限切れログファイルの自動クリーンアップ
サーバーは毎日多くのログを生成し、指定されたディレクトリにアップロードします。最終更新時間に基づくライフサイクルルールを設定して、指定した日数後にバケット内のすべてのオブジェクトを削除できます。これにより、ストレージ容量が解放され、ストレージコストが削減されます。
ホットデータとコールドデータの自動ストレージ階層化
ウェブサイトの画像、オンライン動画、ドキュメントなど、アクセス頻度が不確かなデータについては、アクセス追跡機能を有効にできます。その後、最終アクセス時間に基づくライフサイクルルールを使用して、インテリジェントなデータ階層化を実装できます。システムは、実際のアクセスパターンに基づいて、コールドデータを低頻度アクセス、アーカイブ、またはコールドアーカイブストレージクラスに自動的に移行します。これにより、インテリジェントな階層化とコストの最適化が実現します。
旧バージョンの自動クリーンアップ
バージョン管理を有効にすると、データに対する上書きおよび削除操作は旧バージョンとして保存されます。バケットに多くの旧バージョンまたは期限切れの削除マーカーが蓄積された場合、最終更新時間に基づくライフサイクルルールをバージョン管理と組み合わせて使用し、ストレージコストを削減できます。オブジェクトは指定された時間後に自動的に削除されます。これにより、ストレージコストが削減され、オブジェクトのリスト表示のパフォーマンスが向上します。
マルチパートアップロードのフラグメントの自動クリーンアップ
大きなファイルのマルチパートアップロードが中断された場合、システムはマージされていないパートを保持し、それらは引き続き課金対象となります。ライフサイクルルールを設定して、不要なリソース使用量を避けるために、指定した時間後に未完了のパートを自動的にクリーンアップできます。
前述のシナリオに加えて、より詳細なデータ管理ポリシーを実装できます。詳細については、「ライフサイクル設定例」をご参照ください。必要に応じて、さまざまなルールを組み合わせて、バケット内のデータの詳細な管理を実現できます。
複数のライフサイクルルール
複数のライフサイクルルールが期待どおりに機能するようにするには、ルール実行の優先順位と設定の上書きメカニズムという 2 つのコアメカニズムを理解する必要があります。
ルール実行の優先順位
同じバケットに複数のライフサイクルルールを設定できます。ルールは独立しているため、同じオブジェクトが複数のルールに一致する可能性があります。最終的なアクションは、すべての一致するルールの結果に基づいて決定されます。
複数のルールが同時に同じオブジェクトに一致する場合、それらは次の優先順位で実行されます：オブジェクトの削除 > ディープコールドアーカイブへの移行 > コールドアーカイブへの移行 > アーカイブへの移行 > 低頻度アクセスへの移行 > 標準への移行。
削除アクションは、常にストレージクラスの移行よりも優先度が高くなります。移行が完了する前にオブジェクトが削除されるのを防ぐために、削除ルールの時間を移行ルールの時間よりも長く設定してください。
実行例
次の 2 つのライフサイクルルールを指定し、両方のルールが同じオブジェクトに一致すると仮定します。
ルール 1：最終更新から 365 日以上経過したオブジェクトを低頻度アクセスストレージクラスに移行することを指定します。
ルール 2：最終更新から 365 日以上経過したオブジェクトを削除することを指定します。
結果：ルールに一致するオブジェクトは、最終更新時刻から 365 日以上経過した後に削除されます。
設定の上書きメカニズム
コンソールを使用する場合、設定の上書きについて心配する必要はありません。ルールを追加または変更するたびに、コンソールは現在の設定を自動的に読み取り、変更をマージして結果を送信します。これにより、既存のルールが誤って失われるのを防ぎます。ただし、ossutil、SDK、または API を直接呼び出してライフサイクルルールを設定する場合は注意が必要です。各 PutBucketLifecycle 呼び出しは、バケットの既存のすべてのライフサイクル設定を完全に上書きします。既存のルールを含めずに新しいルールを送信すると、既存のルールは削除され、有効ではなくなります。
例
既存のルールに新しいルールを追加する場合は、次の手順を実行します：
現在有効なすべてのライフサイクルルール (例：ルール 1) を取得します。
新しいルール (例：ルール 2) を追加します。
すべてのルール (ルール 1 + ルール 2) を含む完全な設定を再送信します。
注意：既存のルール (ルール 1) を含めずに新しいルール (ルール 2) のみを含む設定を送信すると、ルール 1 は削除され、有効ではなくなります。
公開
本番環境でライフサイクル管理を安全かつ効率的に使用するには、次のことを推奨します：
デプロイ前のテスト：まずテストバケットでルールを作成します。本番バケットに適用する前に、それらの動作が期待どおりであることを確認してください。
削除ルールの慎重な使用：有効期限切れと削除が設定されたルールについては、プレフィックスを正確に設定してください。これにより、ルールの範囲が拡大して重要なデータが誤って削除されるのを防ぎます。
安全策としてのバージョン管理の有効化：重要なビジネスデータについては、バケットのバージョン管理機能を有効にします。これにより、ライフサイクルルールによってオブジェクトの現在のバージョンが誤って削除された場合でも、旧バージョンからデータを回復できます。
追加料金を回避するための段階的な移行の使用：ストレージクラスの移行ポリシーを設計する際は、後の段階のトリガー時間が、前の段階のトリガー時間とそのストレージクラスの最低ストレージ期間の合計後になるようにしてください。これにより、早期の移行による料金を回避できます。
誤った例：標準
30 日-> 低頻度アクセス40 日-> アーカイブストレージ。この設定では、オブジェクトは IA ストレージクラスに 10 日間 (< 30 日) しか保存されずに再度移行されるため、料金が発生します。正しい例：標準
30 日-> 低頻度アクセス90 日-> アーカイブストレージ。(オブジェクトは 30 日後に IA ストレージクラスに移行されます。IA ストレージクラスに 60 日間保持された後、アーカイブストレージに移行され、合計 90 日間になります)。
課金
ライフサイクルルールの設定は無料です。ルールが実行され、その結果としてストレージの状態が変更されると、料金が発生します。
リクエスト料金：ライフサイクルルールがストレージクラスの移行、オブジェクトの削除、またはパートの削除を実行すると、システムは
Putタイプのリクエストを開始します。リクエスト料金はリクエスト数に基づいて課金されます。課金ルールの詳細については、「ライフサイクル料金の説明」をご参照ください。多数の小さなファイルを含むバケットの場合、この料金はかなりの額になる可能性があります。ルールを設定する前に、これを評価してください。
ストレージ料金：オブジェクトが新しいストレージクラスに移行されると、新しいクラスの単価で課金されます。
重要低頻度アクセス、アーカイブ、コールドアーカイブなどのストレージクラスには、最低ストレージ期間の要件があります (例：低頻度アクセスは 30 日、アーカイブは 60 日)。ライフサイクルルールが最低ストレージ期間を満たす前にオブジェクトを削除または移行した場合、残りのストレージ期間分の料金を支払う必要があります。移行または削除による指定期間より短いストレージに対する条件付き容量料金を回避する方法については、「指定期間より短いストレージに対する容量料金を回避するにはどうすればよいですか？」をご参照ください。移行または削除する前に、最低ストレージ期間が満たされていることを確認してください。
データ取得料金：ライフサイクルルール自体はデータ取得料金を発生させません。ただし、低頻度アクセスやアーカイブなどのストレージクラスに移行されたオブジェクトにアクセスすると、対応するデータ取得料金が発生します。
低頻度アクセス (IA) オブジェクトを直接読み取ると、データ取得料金が発生します。
アーカイブオブジェクトを直接読み取ると、リアルタイムアクセスのためのデータ取得容量料金が発生します。
アーカイブオブジェクトを解凍すると、Put タイプのリクエスト料金とデータ取得容量料金が発生します。
コールドアーカイブまたはディープコールドアーカイブオブジェクトを解凍すると、取得リクエスト料金、取得容量料金、および一時的な解凍済み容量料金が発生します。
重要コールドアーカイブおよびディープコールドアーカイブオブジェクトの場合、料金は選択した取得の優先度によって異なります。優先度が高いほど、料金も高くなります。
よくある質問
バージョン管理が無効なバケット
バージョン管理が無効なバケットの場合、1 つのライフサイクルルールを設定するだけで、すべてのファイルと未完了のマルチパートアップロードのパートを自動的かつ迅速にクリーンアップできます。
OSS コンソールにログインし、バケットリストページに移動して、ターゲットバケットを見つけます。
左側のナビゲーションウィンドウで、 を選択し、バケットのバージョン管理が無効になっていることを確認します。
左側のナビゲーションウィンドウで、 を選択します。ライフサイクルルールを設定して、最終更新から 1 日後にバケット内のすべてのファイルを自動的に削除します。また、1 日以上前に作成された未完了のマルチパートアップロードのパートを自動的にクリーンアップします。
バージョン管理が有効なバケット
バケットでバージョン管理を有効にすると、現在のバージョンのオブジェクト、旧バージョンのオブジェクト、未完了のマルチパートアップロードのパート、および削除マーカーが生成されます。1 つのライフサイクルルールを設定するだけで、これらすべてを自動的かつ迅速にクリーンアップできます。
OSS コンソールにログインし、バケットリストページに移動して、ターゲットバケットを見つけます。
左側のナビゲーションウィンドウで、 を選択し、バケットのバージョン管理が有効になっていることを確認します。
左側のナビゲーションウィンドウで、 を選択します。ライフサイクルルールを設定して、最終更新から 1 日後にバケット内のすべての現在および旧バージョンのオブジェクトを自動的に削除します。また、1 日以上前に作成された未完了のマルチパートアップロードのパートを自動的にクリーンアップします。このルールは削除マーカーもクリーンアップします。
