Azure Blob Storage を使用すると、データ ボリュームの増加や使用パターンの進化に伴い、組織はデータ ストレージのニーズを効率的に管理およびスケーリングできます。 BLOB ライフサイクル管理を使用することで、お客様はルールベースのポリシーを実装することで、データをよりクールな層に自動的に移行したり、不要になったときに期限切れになったりすることで、コストを事前に最適化できます。
このシームレスな自動化により、データは常に最もコスト効率の高い方法で格納され、簡単なアクセスと堅牢なデータ管理を維持しながら、予算効率を最大化できます。 BLOB ライフサイクル管理を使用すると、組織は、コストが最適化され、実際の使用状況に従ってデータが管理されることを知りながら、ストレージ環境を自信を持ってスケーリングできます。
ライフサイクル管理ポリシーを使用すると、以下を行えます。
コストを最適化するために、BLOB の現在のバージョン、BLOB の以前のバージョン、または BLOB スナップショットが一定期間アクセスまたは変更されない場合に、これらのオブジェクトをよりクールなストレージ層に移行します。
BLOB がアクセスされたときに BLOB をクールからホットに直ちに戻します。
ライフサイクルの最後に、BLOB の現在のバージョン、BLOB の以前のバージョン、BLOB スナップショットを削除します。
ストレージ アカウント全体、一部のコンテナー、または名前のプレフィックスや BLOB インデックス タグをフィルターとして使って BLOB のサブセットに規則を適用できます。
ヒント
ライフサイクル管理は 1 つのアカウントのコストを最適化するのに役立ちますが、 Azure Storage Actions を 使用して、複数のアカウント間で大規模な複数のデータ操作を実行できます。
ライフサイクル管理ポリシーの機能
ライフサイクル管理ポリシーは、JSON ドキュメントに記述されたルールのコレクションです。 詳細については、 Azure Blob Storage ライフサイクル管理ポリシーの構造に関するページを参照してください。
汎用 v2、Premium ブロック BLOB、Blob Storage のアカウントでは、ブロック BLOB と追加 BLOB でライフサイクル管理ポリシーがサポートされています。 ライフサイクル管理は、$logs コンテナーや $web コンテナーなどのシステム コンテナーには影響を与えません。
ルールは、オブジェクトの処理に使用される関連付けられたアクションとフィルターと共に、条件の定義です。 次の表では、各ルール要素について説明します。
| ルール要素 | 説明 |
|---|---|
| 条件 | 条件は、次の 3 つの BLOB プロパティに基づいています。作成時刻、最終変更時刻、最終アクセス時刻 (アクセス時間の追跡が有効な場合) |
| アクション | アクションは、関連付けられた条件を満たすフィルター処理された BLOB に適用されます。 BLOB 層のクール層への変更や BLOB の削除など、ルールごとに少なくとも 1 つのアクションを定義する必要があります。 |
| フィルター | フィルターは、パス プレフィックスと BLOB タグを使用して、ストレージ アカウント内の BLOB のサブセットにルール アクションを制限します。 複数のフィルターが定義されている場合は、すべてのフィルターで論理 AND が実行されます。 フィルターを使用して、含める BLOB を指定できます。 フィルターでは、除外する BLOB を指定する手段はありません。 |
ポリシーの実行
ライフサイクル ポリシーのルールを追加または編集すると、変更が有効になり、最初の実行が開始されるまでに最大で 24 時間かかる場合があります。
アクティブ ポリシーでは定期的にオブジェクトが処理され、ポリシーに変更が行われた場合は中断されます。 ポリシーを削除した場合、新しいポリシー実行はスケジュールされませんが、実行が既に進行中の場合、その実行は完了するまで続行され、実行を完了するために必要なすべてのアクションに対して課金されます。 ポリシー内のすべてのルールを無効にすると、ポリシーは非アクティブになります。 実行が既に進行中の場合、その実行は 24 時間以内に停止し、新しい実行はスケジュールされません。 最初にポリシーを無効にし、24 時間待ってからポリシーを削除することをお勧めします。
実行が完了するまでに必要な時間は、評価および操作される BLOB の数によって異なります。 ストレージ アカウントの要求レートがストレージ アカウントの制限に近づくと、BLOB の評価と操作の待機時間が長くなる可能性があります。 ポリシーの実行によって行われる要求など、ストレージ アカウントに対して行われるすべての要求は、秒単位の要求の同じ上限に対して計上され、上限に近づくと、ワークロードによって行われる要求に優先度が付与されます。 アカウント制限の引き上げを希望する場合は、Azure サポートにお問い合わせください。
既定のスケールの上限を表示するには、次の記事を参照してください。
- BLOB ストレージのスケーラビリティとパフォーマンスのターゲット
- 標準ストレージ アカウントのスケーラビリティとパフォーマンスのターゲット
- Premium ブロック BLOB ストレージ アカウントのスケーラビリティ ターゲット
詳細については、「ライフサイクル管理のパフォーマンス特性」を参照してください。
LifecyclePolicyCompleted イベントをサブスクライブし、メトリックとログを使用してエラーを診断することで、ポリシー実行の結果を監視できます。 ライフサイクル管理ポリシーの監視を参照してください。
請求書
ライフサイクル管理ポリシーは無料です。 お客様に課金されるのは、Set Blob Tier API 呼び出しの標準的な操作のコストに対してです。 削除操作は無料です。 ただし、 Microsoft Defender for Storage などの他の Azure サービスやユーティリティは、ライフサイクル ポリシーを通じて管理される操作に対して課金される場合があります。
BLOB の最終アクセス時刻が更新されるたびに、その他の操作のカテゴリで請求が行われます。 最後のアクセス時刻の更新は、1 日に数千回アクセスされた場合でも、オブジェクトごとに最大 24 時間に 1 回、"他のトランザクション" として課金されます。 これは、読み取りトランザクションの料金とは別です。
価格の詳細については、「ブロック BLOBの料金」を参照してください。
既知の問題と制限事項
Premium ブロック BLOB ストレージ アカウントでは、階層化はまだサポートされていません。 他のすべてのアカウントでは、階層化はブロック BLOB でのみ許可され、追加およびページ BLOB では許可されません。
ライフサイクル管理ポリシーは、その全体の読み取りまたは書き込みを行う必要があります。 部分的な更新はサポートされません。
各ルールには、最大 10 個の大文字と小文字を区別するプレフィックスと、最大 10 個の BLOB インデックス タグ条件を指定できます。
ライフサイクル管理ポリシーを使用して、暗号化スコープを使用する BLOB の層をアーカイブ層に変更することはできません。
ライフサイクル管理ポリシーの削除アクションは、不変コンテナー内の BLOB では機能しません。 不変ポリシーを使用すると、オブジェクトを作成および読み取ることはできますが、変更または削除することはできません。 詳細については、「不変ストレージを使用してビジネスに不可欠な BLOB データを保存する」を参照してください。
ライフサイクル管理は、
$logsや$web containersなどのシステム コンテナーには影響しません。
よく寄せられる質問 (FAQ)
「ライフサイクル管理の FAQ」を参照してください。