データ ライフサイクルを自動管理してコストを最適化する
Azure Blob Storage のライフサイクル管理にはルールベースのポリシーが用意されており、これを使用すると、最適なアクセス層に BLOB データを移行したり、データ ライフサイクルの最後にデータを期限切れにしたりすることができます。
ライフサイクル管理ポリシーを使用すると、以下を行えます。
- パフォーマンスを最適化するため、BLOB がアクセスされたときに BLOB をクールからホットに直ちに移行します。
- コストを最適化するため、BLOB の現在のバージョン、BLOB の以前のバージョン、BLOB のスナップショットが一定期間アクセスも変更もされていない場合、それらのオブジェクトをよりクールなストレージ層に移行します。
- ライフサイクルの最後に、BLOB の現在のバージョン、BLOB の以前のバージョン、BLOB スナップショットを削除します。
- ストレージ アカウント全体、一部のコンテナー、または名前のプレフィックスや BLOB インデックス タグをフィルターとして使って BLOB のサブセットに規則を適用できます。
ヒント
ライフサイクル管理は 1 つのアカウント内の層間でのデータ移動に役立ちますが、ストレージ タスクを使用すれば、このタスクを複数のアカウント全体で大規模に遂行できます。 ストレージ タスクは Azure Storage Actions で利用できるリソースです。これは、複数のストレージ アカウントにまたがる数百万ものオブジェクトに対して一般的なデータ操作を実行するために使用できるサーバーレス フレームワークです。 詳細については、「Azure Storage Actions とは」を参照してください。
汎用 v2、Premium ブロック BLOB、Blob Storage のアカウントでは、ブロック BLOB と追加 BLOB でライフサイクル管理ポリシーがサポートされています。 ライフサイクル管理は、$logs
コンテナーや $web
コンテナーなどのシステム コンテナーには影響を与えません。
重要
データ セットが読み取り可能である必要がある場合は、BLOB をアーカイブ層に移動するポリシーを設定しないでください。 アーカイブ層の BLOB は、最初にリハイドレートされていない限り読み取ることができません。これは時間とコストがかかる場合があるプロセスです。 詳細については、「アーカイブ層からの BLOB のリハイドレートの概要」を参照してください。 データ セットを頻繁に読み込む必要がある場合は、BLOB をクール層またはコールド層に移動するポリシーを設定しないでください。これにより、トランザクション コストが高くなる可能性があるためです。
データ ライフサイクルを管理してコストを最適化する
データ セットには一意のライフサイクルがあります。 ライフサイクルの早い段階で、一部のデータに頻繁にアクセスされます。 しかし、データが古くなるにつれてアクセスの必要性が急激に低下することがよくあります。 使用されずにクラウドに留まるデータや、いったん格納されるとめったにアクセスされないデータもあります。 データ セットには、作成後数日や数か月で期限切れになるものがある一方で、ライフサイクル全体にわたってアクティブに読み取りと変更が行われるデータ セットもあります。
データがライフサイクルの初期段階には頻繁にアクセスされるものの、2 週間後にはたまにしかアクセスされなくなるというシナリオについて考えてみましょう。 1 か月を超えると、そのデータ セットにはほとんどアクセスされなくなります。 このシナリオの初期段階ではホット ストレージが最適です。 ときどきアクセスされるデータにはクール ストレージが適しています。 1 か月以上が経過したデータに最も適しているのは、アーカイブ ストレージです。 ライフサイクル管理ポリシー ルールを使用して、経過時間に基づいてデータを適切なストレージ層に移動することで、ニーズに合う最もコストのかからないソリューションを設計できます。
ライフサイクル管理ポリシーの定義
ライフサイクル管理ポリシーは、JSON ドキュメントに記述されたルールのコレクションです。 次のサンプル JSON に、完全なルール定義を示します。
{
"rules": [
{
"name": "rule1",
"enabled": true,
"type": "Lifecycle",
"definition": {...}
},
{
"name": "rule2",
"type": "Lifecycle",
"definition": {...}
}
]
}
1 つのポリシーは、次の表で説明するように、ルールのコレクションです。
パラメーター名 | パラメーターのタイプ | Notes |
---|---|---|
rules |
ルール オブジェクトの配列 | ポリシーには少なくとも 1 つのルールが必要です。 ポリシーでは最大 100 のルールを定義できます。 |
ポリシー内の各ルールには、次の表で説明するように、いくつかのパラメーターがあります。
パラメーター名 | パラメーターのタイプ | Notes | 必須 |
---|---|---|---|
name |
String | ルール名には最大 256 の英数字を含めることができます。 ルール名は大文字と小文字が区別されます。 名前は、ポリシー内で一意にする必要があります。 | True |
enabled |
Boolean | ルールを一時的に無効にすることを許可する省略可能なブール値。 設定されていない場合、既定値は true です。 | False |
type |
列挙型の値 | 現在の有効な種類は Lifecycle です。 |
True |
definition |
ライフサイクル ルールを定義するオブジェクト | 各定義は、フィルター セットとアクション セットで構成されます。 | True |
ライフサイクル管理ルールの定義
ポリシー内の各ルール定義には、フィルター セットとアクション セットが含まれます。 フィルター セットは、コンテナー内の特定のオブジェクト セットまたはオブジェクト名にルール アクションを制限します。 アクション セットは、階層化または削除アクションをオブジェクトのフィルター処理されたセットに適用します。
ルールのサンプル
次のサンプル ルールは、sample-container
内に存在し、blob1
で始まるオブジェクトに対してアクションを実行するようにアカウントをフィルター処理します。
- BLOB を最後に変更されたときから 30 日後にクール層に階層化する
- BLOB を最後に変更されたときから 90 日後にアーカイブ層に階層化する
- BLOB を最後に変更されたときから 2,555 日 (7 年) 後に削除する
- 以前のバージョンを作成から 90 日後に削除する
{
"rules": [
{
"enabled": true,
"name": "sample-rule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"delete": {
"daysAfterCreationGreaterThan": 90
}
},
"baseBlob": {
"tierToCool": {
"daysAfterModificationGreaterThan": 30
},
"tierToArchive": {
"daysAfterModificationGreaterThan": 90,
"daysAfterLastTierChangeGreaterThan": 7
},
"delete": {
"daysAfterModificationGreaterThan": 2555
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"sample-container/blob1"
]
}
}
}
]
}
注意
ライフサイクル管理ポリシーの baseBlob 要素は、BLOB の現在のバージョンを参照します。 version要素は、以前のバージョンを参照します。
ルール フィルター
フィルターを使用すると、ルール アクションをストレージ アカウント内の BLOB のサブセットに限定できます。 複数のフィルターが定義されている場合、すべてのフィルターで論理 AND
が実行されます。 フィルターを使用して、含める BLOB を指定できます。 フィルターでは、除外する BLOB を指定する手段はありません。
フィルターには次のものが含まれます。
フィルター名 | フィルターの種類 | Notes | 必須 |
---|---|---|---|
blobTypes | 定義済みの列挙型の値の配列。 | 現在のリリースでは blockBlob および appendBlob をサポートしています。 appendBlob では Delete アクションのみがサポートされています。Set Tier はサポートされていません。 |
はい |
prefixMatch | プレフィックスを照合する文字列の配列。 各ルールで大文字と小文字を区別するプレフィックスを最大 10 個定義できます。 プレフィックス文字列はコンテナー名で始まる必要があります。 たとえば、https://myaccount.blob.core.windows.net/sample-container/blob1/... のすべての BLOB を照合する場合は、prefixMatch を sample-container/blob1 として指定します。 このフィルターは、blob1 で名前が始まるサンプル コンテナー内のすべての BLOB を照合します。。 |
prefixMatch を定義していない場合、ルールはストレージ アカウント内のすべての BLOB に適用されます。 プレフィックス文字列では、ワイルドカード一致はサポートされていません。 * や ? などの文字は、文字列リテラルとして扱われます。 |
いいえ |
blobIndexMatch | 照合する BLOB インデックス タグ キーと値条件で構成されるディクショナリ値の配列。 各ルールには、最大 10 個の BLOB インデックス タグ条件を定義できます。 たとえば、ルールとして https://myaccount.blob.core.windows.net/ の下にあるすべての BLOB を Project = Contoso に一致させたい場合、blobIndexMatch は {"name": "Project","op": "==","value": "Contoso"} になります。 |
blobIndexMatch を定義していない場合、ルールはストレージ アカウント内のすべての BLOB に適用されます。 | いいえ |
BLOB インデックス機能と、既知の問題および制限事項の詳細については、BLOB インデックスを使用して Azure Blob Storage でデータを管理および検索することに関するページを参照してください。
ルールのアクション
実行条件が満たされている場合、アクションはフィルター処理された BLOB に適用されます。
ライフサイクル管理では、BLOB、以前の BLOB バージョン、および BLOB スナップショットの階層化と削除がサポートされています。 各ルールに対して少なくとも 1 つのアクションを定義します。
注意
Premium ブロック BLOB ストレージ アカウントでは、階層化はまだサポートされていません。 他のすべてのアカウントでは、階層化はブロック BLOB でのみ許可され、追加およびページ BLOB では許可されません。
アクション | 現在のバージョン | スナップショット | 以前のバージョン |
---|---|---|---|
tierToCool | blockBlob でサポート |
サポートされています | サポートされています |
tierToCold | blockBlob でサポート |
サポートされています | サポートされています |
enableAutoTierToHotFromCool1 | blockBlob でサポート |
サポートされていません | サポートされていません |
tierToArchive4 | blockBlob でサポート |
サポートされています | サポートされています |
delete2、3 | blockBlob および appendBlob に対してサポートされています |
サポートされています | サポートされています |
1enableAutoTierToHotFromCool
アクションは、daysAfterLastAccessTimeGreaterThan
実行条件で使用する場合にのみ使用できます。 この条件については、次の表で説明します。
2 階層型名前空間が有効になっているアカウントに適用すると、削除アクションによって空のディレクトリが削除されます。 ディレクトリが空でない場合、削除アクションでは、最初のライフサイクル ポリシー実行サイクル内のポリシー条件を満たすオブジェクトが削除されます。 そのアクションの結果、空のディレクトリになり、ポリシー条件も満たされる場合、そのディレクトリは次の実行サイクル内で削除される、というように続きます。
3 ライフサイクル管理ポリシーでは、その BLOB に関連付けられている以前のバージョンまたはスナップショットが削除されるまで、BLOB の現在のバージョンは削除されません。 ストレージ アカウント内の BLOB に以前のバージョンまたはスナップショットがある場合は、ポリシーの一部として削除アクションを指定するときに、以前のバージョンとスナップショットを含める必要があります。
4 アーカイブ アクセス層への BLOB の移動は、LRS、GRS、または RA-GRS 用に構成されたストレージ アカウントでのみサポートされます。 アーカイブ アクセス層は、ZRS、GZRS、RA-GZRS のアカウントではサポートされていません。 このアクションは、アカウントに構成された冗長性に基づいて一覧表示されます。
Note
同じ BLOB に複数のアクションを定義した場合、ライフサイクル管理によって最も低コストのアクションが BLOB に適用されます。 たとえば、delete
アクションは tierToArchive
アクションよりも低コストです。 tierToArchive
アクションは tierToCool
アクションよりも低コストです。
実行条件は、古さに基づいています。 現在のバージョンでは、最終変更時刻または最終アクセス時刻を使用し、以前の BLOB バージョンではバージョン作成時刻を使用し、BLOB スナップショットでは、スナップショットの作成時刻を使用して古さが追跡されます。
アクションの実行条件 | 条件値 | 説明 |
---|---|---|
daysAfterModificationGreaterThan | 古さを日数で示す整数値 | 現在のバージョンの blob に対するアクションの条件 |
daysAfterCreationGreaterThan | 古さを日数で示す整数値 | 現在のバージョンまたは以前のバージョンの BLOB または BLOB のスナップショットに対するアクションの条件 |
daysAfterLastAccessTimeGreaterThan1 | 古さを日数で示す整数値 | アクセス追跡が有効になっている場合の現在のバージョンの blob の条件 |
daysAfterLastTierChangeGreaterThan | BLOB 層の最終変更時刻から経過した日数を示す整数値 | リハイドレートされた BLOB が、アーカイブ アクセス層に戻される前に、ホット、クール、またはコールドのアクセス層に保持される最小期間 (日数)。 この条件は、tierToArchive アクションにのみ適用されます。 |
1最終アクセス時間の追跡が有効でない場合、daysAfterLastAccessTimeGreaterThan には、BLOB の LastAccessTime
プロパティではなく、ライフサイクル ポリシーが有効になった日付が使われます。 この日付は、LastAccessTime
プロパティが null 値の場合にも使用されます。 最終アクセス時刻の追跡の使用の詳細については、「最終アクセス時刻に基づいてデータを移動する」を参照してください。
ライフサイクル ポリシーの実行
ライフサイクル ポリシーを構成または編集すると、変更が有効になり、最初の実行が開始されるまでに最大で 24 時間かかる場合があります。 ポリシー アクションが完了するまでにかかる時間は、評価および操作される BLOB の数によって異なります。
ポリシーを無効にすると、新しいポリシー実行はスケジュールされませんが、実行が既に進行中の場合、その実行は完了まで続行され、実行の完了に必要なアクションがあれば、それに対して課金されます。 「リージョン別の可用性と料金」を参照してください。
ライフサイクル ポリシーが完了したイベント
ライフサイクル管理ポリシーで定義されたアクションが実行されると、LifecyclePolicyCompleted
イベントが生成されます。 次の JSON は、LifecyclePolicyCompleted
エントリの例を示しています。
{
"topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/contosoresourcegroup/providers/Microsoft.Storage/storageAccounts/contosostorageaccount",
"subject": "BlobDataManagement/LifeCycleManagement/SummaryReport",
"eventType": "Microsoft.Storage.LifecyclePolicyCompleted",
"eventTime": "2022-05-26T00:00:40.1880331",
"id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"data": {
"scheduleTime": "2022/05/24 22:57:29.3260160",
"deleteSummary": {
"totalObjectsCount": 16,
"successCount": 14,
"errorList": ""
},
"tierToCoolSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
},
"tierToArchiveSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
}
},
"dataVersion": "1",
"metadataVersion": "1"
}
次の表で、LifecyclePolicyCompleted
イベントのスキーマについて説明します。
フィールド | タイプ | 説明 |
---|---|---|
scheduleTime | string | ライフサイクル ポリシーがスケジュールされた時刻。 |
deleteSummary | ベクター<バイト> | delete 操作のためにスケジュールされた BLOB の結果の概要 |
tierToCoolSummary | ベクター<バイト> | tier-to-cool 操作のためにスケジュールされた BLOB の結果の概要 |
tierToArchiveSummary | ベクター<バイト> | tier-to-archive 操作にスケジュールされた BLOB の結果の概要 |
ライフサイクル ポリシーの例
次の例では、ライフサイクル ポリシー ルールを使用して一般的なシナリオに対処する方法を示します。
古いデータをよりクールな層に移動する
次の例は、プレフィックス sample-container/blob1
または container2/blob2
が付いたブロック BLOB を移行する方法を示しています。 このポリシーでは、30 日以上変更されていない BLOB をクール ストレージに移行し、90 日間変更されていない BLOB をアーカイブ層に移行します。
{
"rules": [
{
"name": "agingRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "sample-container/blob1", "container2/blob2" ]
},
"actions": {
"baseBlob": {
"tierToCool": { "daysAfterModificationGreaterThan": 30 },
"tierToArchive": { "daysAfterModificationGreaterThan": 90 }
}
}
}
}
]
}
最終アクセス時刻に基づいてデータを移動する
最終アクセス時刻の追跡を有効にすると、BLOB データの階層化と保持を管理するためのフィルターとして、BLOB が最後に読み書きされた時刻の記録を保持することができます。 最終アクセス時刻の追跡を有効にする方法については、「オプションであるアクセス時間の追跡を有効にする」を参照してください。
最終アクセス時刻追跡機能が有効になっている場合、BLOB が読み取られるか書き込まれるときに LastAccessTime
という名前の BLOB プロパティが更新されます。 Get Blob 操作はアクセス操作と見なされます。 BLOB プロパティの取得、BLOB メタデータの取得、および BLOB タグの取得は、アクセス操作ではないので、最終アクセス時刻を更新しません。
最終アクセス時間の追跡が有効な場合、ライフサイクル管理は LastAccessTime
を使って実行条件 daysAfterLastAccessTimeGreaterThan が満たされているかどうかを判断します。 ライフサイクル管理では、次の場合、LastAccessTime
ではなく、ライフサイクル ポリシーが有効になった日付が使用されます。
BLOB の
LastAccessTime
プロパティの値が null 値である。Note
最後のアクセス時刻の追跡が有効になってから BLOB へのアクセスがない場合、BLOB の
lastAccessedOn
プロパティは null です。最終アクセス時刻の追跡が有効になっていない。
読み取りアクセス待ち時間への影響を最小限に抑えるために、過去 24 時間の最初の読み取りのみが最終アクセス時刻を更新します。 同じ 24 時間内のその後の読み取りでは、最終アクセス時刻は更新されません。 読み取り間で BLOB が変更された場合、最終アクセス時刻は 2 つの値のうち新しい方になります。
次の例では、BLOB は、30 日間アクセスされない場合に、クール ストレージに移動されます。 enableAutoTierToHotFromCool
プロパティはブール値であり、BLOB がクールに階層化された後で再びアクセスされた場合に、BLOB を自動的にクールからホットに階層化するかどうかを示します。
ヒント
BLOB がクール層に移動され、30 日が経過する前に自動的に戻された場合、早期削除料金が課金されます。 enablAutoTierToHotFromCool
プロパティを設定する前に、予想外の課金を減らせるよう、必ずデータのアクセス パターンを分析してください。
{
"enabled": true,
"name": "last-accessed-thirty-days-ago",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"enableAutoTierToHotFromCool": true,
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"mylifecyclecontainer/log"
]
}
}
}
取り込み後にデータをアーカイブする
クラウド内でアイドル状態に留まり、あったとしてもまれにしかアクセスされないデータもあります。 次のライフサイクル ポリシーは、取り込み直後にデータをアーカイブするように構成されます。 この例では、archivecontainer
という名前のコンテナー内のブロック BLOB をアーカイブ層に移行します。 この移行は、最終変更時刻の 0 日後に BLOB を処理することによって実現されます。
{
"rules": [
{
"name": "archiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "archivecontainer" ]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 0
}
}
}
}
}
]
}
注意
効率を高めるためには、BLOB をアーカイブ層に直接アップロードすることをお勧めします。 アーカイブ層は、Put BLOB または Put Block List 操作の x-ms-access-tier ヘッダーで指定できます。 x-ms-access-tier ヘッダーは、REST バージョン 2018-11-09 以降または最新の BLOB ストレージ クライアント ライブラリでサポートされています。
古さに基づいてデータを期限切れにする
データの中には、作成後数日または数か月後に失効することが想定されているものがあります。 データを古さに基づいて削除することでデータを期限切れに設定するように、ライフサイクル管理ポリシーを構成できます。 次の例は、過去 365 日間に変更されていないすべてのブロック BLOB を削除するポリシーを示しています。
{
"rules": [
{
"name": "expirationRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ]
},
"actions": {
"baseBlob": {
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}
]
}
BLOB インデックス タグを使用してデータを削除する
一部のデータは、削除対象として明示的にマークされている場合のみ有効期限切れになる必要があります。 期限切れにするには、データに BLOB インデックスのキー/値属性でタグ付けして、ライフサイクル管理ポリシーを構成します。 次の例は、Project = Contoso
でタグ付けされたすべてのブロック BLOB を削除するポリシーを示しています。 BLOB インデックスの詳細については、「BLOB インデックスを使用して Azure Blob Storage でデータを管理および検索する」を参照してください。
{
"rules": [
{
"enabled": true,
"name": "DeleteContosoData",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 0
}
}
},
"filters": {
"blobIndexMatch": [
{
"name": "Project",
"op": "==",
"value": "Contoso"
}
],
"blobTypes": [
"blockBlob"
]
}
}
}
]
}
以前のバージョンを管理する
有効期間全体にわたって定期的に変更およびアクセスされるデータの場合は、BLOB ストレージのバージョン管理を有効にすることで、オブジェクトの以前のバージョンを自動的に管理できます。 ポリシーを作成して、以前のバージョンを階層化または削除することができます。 バージョンの古さは、バージョンの作成時刻を評価することによって決定されます。 このポリシー ルールは、バージョンの作成後 90 日以上経過したコンテナー activedata
内の以前のバージョンをクール層に移動し、365 日またはそれ以前のバージョンを削除します。
{
"rules": [
{
"enabled": true,
"name": "versionrule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"tierToCool": {
"daysAfterCreationGreaterThan": 90
},
"delete": {
"daysAfterCreationGreaterThan": 365
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"activedata/"
]
}
}
}
]
}
リージョン別の可用性と料金
ライフサイクル管理機能は、すべての Azure リージョンで使用できます。
ライフサイクル管理ポリシーは無料です。 お客様に課金されるのは、Set Blob Tier API 呼び出しの標準的な操作のコストに対してです。 削除操作は無料です。 ただし、Microsoft Defender for Storage などの他の Azure サービスやユーティリティは、ライフサイクル ポリシーを通じて管理される操作に対して課金される場合があります。
BLOB の最終アクセス時刻が更新されるたびに、その他の操作のカテゴリで請求が行われます。 最後のアクセス時刻の更新は、1 日に数千回アクセスされた場合でも、オブジェクトごとに最大で 24 時間ごとに "他のトランザクション" として課金されます。 これは、読み取りトランザクションの料金とは別です。
価格の詳細については、「ブロック BLOBの料金」を参照してください。
既知の問題と制限事項
Premium ブロック BLOB ストレージ アカウントでは、階層化はまだサポートされていません。 他のすべてのアカウントでは、階層化はブロック BLOB でのみ許可され、追加およびページ BLOB では許可されません。
ライフサイクル管理ポリシーは、その全体の読み取りまたは書き込みを行う必要があります。 部分的な更新はサポートされません。
各ルールには、最大 10 個の大文字と小文字を区別するプレフィックスと、最大 10 個の BLOB インデックス タグ条件を指定できます。
暗号化スコープを使用する BLOB の層をライフサイクル管理ポリシーで変更することはできません。
ライフサイクル管理ポリシーの削除アクションは、不変コンテナー内の BLOB では機能しません。 不変ポリシーを使用すると、オブジェクトを作成および読み取ることはできますが、変更または削除することはできません。 詳細については、「不変ストレージを使用してビジネスに不可欠な BLOB データを保存する」を参照してください。
よく寄せられる質問 (FAQ)
「ライフサイクル管理の FAQ」を参照してください。