データライフサイクルを自動管理してコストを最適化する

[アーティクル]
05/02/2023

データセットには一意のライフサイクルがあります。ライフサイクルの早い段階で、一部のデータに頻繁にアクセスされます。しかし、データが古くなるにつれてアクセスの必要性が急激に低下することがよくあります。使用されずにクラウドに留まるデータや、いったん格納されるとめったにアクセスされないデータもあります。データセットには、作成後数日や数か月で期限切れになるものがある一方で、ライフサイクル全体にわたってアクティブに読み取りと変更が行われるデータセットもあります。 Azure Storage のライフサイクル管理にはルールベースのポリシーが用意されており、これを使用すると、最適なアクセス層に BLOB データを移行したり、データライフサイクルの最後にデータを期限切れにしたりすることができます。

Note

最後のアクセス時刻の更新は、1 日に数千回アクセスされた場合でも、オブジェクトごとに最大で 24 時間ごとに "他のトランザクション" として課金されます。これは、読み取りトランザクションの料金とは別です。

ライフサイクル管理ポリシーを使用すると、以下を行えます。

パフォーマンスを最適化するため、BLOB がアクセスされたときに BLOB をクールまたはコールドからホットに直ちに移行します。
コストを最適化するため、BLOB の現在のバージョン、BLOB の以前のバージョン、BLOB のスナップショットが一定期間アクセスも変更もされていない場合、それらのオブジェクトをよりクールなストレージ層に移行します。
ライフサイクルの最後に、BLOB の現在のバージョン、BLOB の以前のバージョン、BLOB スナップショットを削除します。
ストレージアカウントレベルで、1 日 1 回実行される規則を定義する。
名前のプレフィックスまたは BLOB インデックスタグをフィルターとして使用して、コンテナーまたは BLOB のサブセットにルールを適用します。

重要

コールドアクセス層は現在プレビュー段階であり、カナダ中部、カナダ東部、フランス中部、フランス南部、韓国中部の各リージョンで利用できます。ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。登録するには、「コールドアクセス層 (プレビュー)」を参照してください。

データがライフサイクルの初期段階には頻繁にアクセスされるものの、2 週間後にはたまにしかアクセスされなくなるというシナリオについて考えてみましょう。 1 か月を超えると、そのデータセットにはほとんどアクセスされなくなります。このシナリオの初期段階ではホットストレージが最適です。ときどきアクセスされるデータにはクールストレージが適しています。 1 か月以上が経過したデータに最も適しているのは、アーカイブストレージです。ライフサイクル管理ポリシールールを使用して、経過時間に基づいてデータを適切なストレージ層に移動することで、ニーズに合う最もコストのかからないソリューションを設計できます。

汎用 v2、Premium ブロック BLOB、Blob Storage のアカウントでは、ブロック BLOB と追加 BLOB でライフサイクル管理ポリシーがサポートされています。ライフサイクル管理は、$logs コンテナーや $web コンテナーなどのシステムコンテナーには影響を与えません。

重要

データセットが読み取り可能である必要がある場合は、BLOB をアーカイブ層に移動するポリシーを設定しないでください。アーカイブ層の BLOB は、最初にリハイドレートされていない限り読み取ることができません。これは時間とコストがかかる場合があるプロセスです。詳細については、「アーカイブ層からの BLOB のリハイドレートの概要」を参照してください。

ライフサイクル管理ポリシーの定義

ライフサイクル管理ポリシーは、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 が実行されます。

フィルターには次のものが含まれます。

フィルター名	フィルターの種類	Notes	必須
blobTypes	定義済みの列挙型の値の配列。	現在のリリースでは `blockBlob` および `appendBlob` をサポートしています。 `appendBlob` では削除のみがサポートされています。既定の層はサポートされていません。	はい
prefixMatch	プレフィックスを照合する文字列の配列。各ルールで大文字と小文字を区別するプレフィックスを最大 10 個定義できます。プレフィックス文字列はコンテナー名で始まる必要があります。たとえば、`https://myaccount.blob.core.windows.net/sample-container/blob1/...` の下にあるすべての BLOB をルールに一致させたい場合、prefixMatch は `sample-container/blob1` です。コンテナーまたは BLOB 名を厳密に一致させるには、後ろにフォワードスラッシュ ('/') を付け、"たとえば" `sample-container/` や `sample-container/blob1/` のようにします。コンテナーまたは BLOB 名のパターンを合わせるには、後ろのフォワードスラッシュを省略し、"たとえば" `sample-container` や `sample-container/blob1` のようにします。	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` でサポート	サポートされています	サポートされています
enableAutoTierToHotFromCool¹	`blockBlob` でサポート	サポートされていません	サポートされていません
tierToArchive⁴	`blockBlob` でサポート	サポートされています	サポートされています
delete^2、3	`blockBlob` および `appendBlob` に対してサポートされています	サポートされています	サポートされています

¹enableAutoTierToHotFromCool アクションは、daysAfterLastAccessTimeGreaterThan 実行条件で使用する場合にのみ使用できます。この条件については、次の表で説明します。

² 階層型名前空間が有効になっているアカウントに適用すると、delete アクションによって空のディレクトリが削除されます。ディレクトリが空でない場合、delete アクションでは、最初の 24 時間サイクル内にポリシー条件を満たすオブジェクトが削除されます。そのアクションの結果、空のディレクトリになり、ポリシー条件も満たされる場合、そのディレクトリは次の 24 時間サイクル内に削除されます。

³ ライフサイクル管理ポリシーでは、その BLOB に関連付けられている以前のバージョンまたはスナップショットが削除されるまで、BLOB の現在のバージョンは削除されません。ストレージアカウント内の BLOB に以前のバージョンまたはスナップショットがある場合は、ポリシーの一部として削除アクションを指定するときに、以前のバージョンとスナップショットを含める必要があります。

⁴ アーカイブアクセス層への BLOB の移動は、LRS、GRS、または RA-GRS 用に構成されたストレージアカウントでのみサポートされます。アーカイブアクセス層は、ZRS、GZRS、RA-GZRS のアカウントではサポートされていません。このアクションは、アカウントに構成された冗長性に基づいて一覧表示されます。

Note

同じ BLOB に複数のアクションを定義した場合、ライフサイクル管理によって最も低コストのアクションが BLOB に適用されます。たとえば、delete アクションは tierToArchive アクションよりも低コストです。 tierToArchive アクションは tierToCool アクションよりも低コストです。

実行条件は、古さに基づいています。現在のバージョンでは、最終変更時刻または最終アクセス時刻を使用し、以前の BLOB バージョンではバージョン作成時刻を使用し、BLOB スナップショットでは、スナップショットの作成時刻を使用して古さが追跡されます。

アクションの実行条件	条件値	説明
daysAfterModificationGreaterThan	古さを日数で示す整数値	現在のバージョンの blob に対するアクションの条件
daysAfterCreationGreaterThan	古さを日数で示す整数値	現在のバージョンまたは以前のバージョンの BLOB または BLOB のスナップショットに対するアクションの条件
daysAfterLastAccessTimeGreaterThan¹	古さを日数で示す整数値	アクセス追跡が有効になっている場合の現在のバージョンの blob の条件
daysAfterLastTierChangeGreaterThan	BLOB 層の最終変更時刻から経過した日数を示す整数値	この条件は `tierToArchive` アクションにのみ適用され、`daysAfterModificationGreaterThan` 条件との併用でのみ使用できます。

¹最終アクセス時間の追跡が有効でない場合、daysAfterLastAccessTimeGreaterThan には、BLOB の LastAccessTime プロパティではなく、ライフサイクルポリシーが有効になった日付が使われます。この日付は、LastAccessTime プロパティが null 値の場合にも使用されます。最終アクセス時刻の追跡の使用の詳細については、「最終アクセス時刻に基づいてデータを移動する」を参照してください。

ライフサイクルポリシーが完了したイベント

ライフサイクル管理ポリシーで定義されたアクションが実行されると、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 の LastAccessTime プロパティは null です。
最終アクセス時刻の追跡が有効になっていない。

読み取りアクセス待ち時間への影響を最小限に抑えるために、過去 24 時間の最初の読み取りのみが最終アクセス時刻を更新します。同じ 24 時間内のその後の読み取りでは、最終アクセス時刻は更新されません。読み取り間で BLOB が変更された場合、最終アクセス時刻は 2 つの値のうち新しい方になります。

次の例では、BLOB は、30 日間アクセスされない場合に、クールストレージに移動されます。 enableAutoTierToHotFromCool プロパティはブール値であり、BLOB がクールに階層化された後で再びアクセスされた場合に、BLOB を自動的にクールからホットに階層化するかどうかを示します。

{
  "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/"
          ]
        }
      }
    }
  ]
}

機能サポート

Data Lake Storage Gen2、Network File System (NFS) 3.0 プロトコル、または SSH ファイル転送プロトコル (SFTP) を有効にすると、この機能のサポートが影響を受ける場合があります。

これらの機能のいずれかを有効にした場合は、「Azure ストレージアカウントにおける Blob Storage 機能のサポート」を参照して、この機能のサポートを評価してください。

リージョン別の可用性と料金

ライフサイクル管理機能は、すべての Azure リージョンで使用できます。

ライフサイクル管理ポリシーは無料です。お客様に課金されるのは、Set Blob Tier API 呼び出しの標準的な操作のコストに対してです。削除操作は無料です。ただし、Microsoft Defender for Storage などの他の Azure サービスやユーティリティは、ライフサイクルポリシーを通じて管理される操作に対して課金される場合があります。

BLOB の最終アクセス時刻が更新されるたびに、その他の操作のカテゴリで請求が行われます。

価格の詳細については、「ブロック BLOBの料金」を参照してください。

よく寄せられる質問

新規ポリシーを作成しました。アクションがすぐに実行されないのはなぜですか?

ライフサイクルポリシーは、プラットフォームによって 1 日に 1 回実行されます。ポリシーの構成後、有効になるまでに最大 24 時間かかることがあります。ポリシーの有効化後、アクションが最初に実行されるまでに最大で 24 時間かかることがあります。

既存のポリシーを更新した場合、アクションの実行にはどのくらいの時間がかかりますか。

更新されたポリシーは、有効になるまで最大 24 時間かかります。ポリシーが有効になると、アクションが実行されるまでに最大で 24 時間かかることがあります。このため、ポリシーのアクションが完了するまでに最大 48 時間かかる可能性があります。更新によってルールが無効になるか、削除されるとき、enableAutoTierToHotFromCool が使用された場合でも、ホット層に自動的に階層化されます。たとえば、最後のアクセスに基づき、enableAutoTierToHotFromCool を含むルールが設定されます。このルールが無効化または削除された場合、BLOB が現在クールまたはコールド層にあり、その後アクセスされると、BLOB はホット層に戻されます。そのルールがライフサイクル管理外のアクセスに対して適用されるためです。その後は、ライフサイクル管理ルールが無効化または削除されていれば、BLOB はホット層からクールまたはコールド層に移動しません。 autoTierToHotFromCool を回避する唯一の方法は、最終アクセス時刻の追跡をオフにすることです。

実行は完了しますが、一部の BLOB は移動も削除もされません

ストレージアカウントに含まれるオブジェクトのサイズや数によっては、全オブジェクトを処理するために複数の実行が必要になることがあります。また、ストレージリソースログを確認して、ライフサイクル管理ポリシーによって操作が実行されているかどうかを確認することもできます。

ポリシーが実行され、BLOB を削除しているにもかかわらず、容量の変更が表示されない

ストレージアカウントで論理的な削除やバージョン管理などのデータ保護機能が有効になっているかどうかを確認します。ポリシーが BLOB を削除している場合でも、これらの BLOB は、これらの機能の構成方法によっては、論理的に削除された状態または古いバージョンとして存在する可能性があります。

アーカイブされた BLOB をリハイドレートしました。一時的にアーカイブ層に戻されないようにするにはどうすればよいですか?

ストレージアカウントに対するライフサイクル管理ポリシーが有効な場合、層を変更して BLOB をリハイドレートすると、ライフサイクルポリシーによって BLOB がアーカイブ層に戻されるというシナリオが発生する可能性があります。これは、最終更新時刻、作成時刻、または最終アクセス時刻がポリシーに設定されたしきい値を超えている場合に発生する可能性があります。この問題が発生しないようにするには、次の 3 つの方法があります。

daysAfterLastTierChangeGreaterThan 条件を tierToArchive アクションに追加します。この条件は、最終変更時刻にのみ適用されます。「ライフサイクル管理ポリシーを使用して BLOB をアーカイブする」を参照してください。
この BLOB に影響を与えるルールを一時的に無効にして、再びアーカイブされないようにします。 BLOB が安全にアーカイブ層に移動されたら、ルールを再度有効にします。
BLOB をホット層、クール層、またはコールド層に永続的に保持する必要がある場合は、ライフサイクル管理ポリシーが有効でない別の場所に BLOB をコピーします。

BLOB のプレフィックス一致文字列は予想される BLOB へのポリシーに適用されません

ポリシーの BLOB プレフィックス一致フィールドは BLOB の完全または部分的なパスであり、ポリシーのアクションを適用したい BLOB に照合するために使用します。パスは、コンテナー名で始まる必要があります。プレフィックス一致が指定されていない場合、ポリシーはストレージアカウントのすべての BLOB に適用されます。プレフィックス一致文字列の形式は [container name]/[blob name]です。

プレフィックス一致文字列について以下の点に注意してください:

container1/ のようなプレフィックス一致文字列は、container1 という名前のコンテナー内のすべての BLOB に適用されます。後続のスラッシュ文字 (/) のない container1 のプレフィックス一致文字列は、コンテナー名が文字列 container1 で始まるすべてのコンテナー内のすべての BLOB に適用されます。プレフィックスは、 container11、 container1234、container1ab などの名前のコンテナーと一致します。
container1/sub1/ のプレフィックス一致文字列は、文字列 sub1/で始まる container1 という名前のコンテナー内のすべての BLOB に適用されます。たとえば、プレフィックスは container1/sub1/test.txtまたは container1/sub1/ sub2/test.txtという名前の BLOB と一致します。
アスタリスク文字 * は、 BLOB 名で有効な文字です。プレフィックスにアスタリスク文字が使用されている場合、プレフィックスは、名前にアスタリスクを持つ BLOB と一致します。アスタリスクはワイルドカード文字として機能しません。
疑問符文字 ? は、BLOB 名で有効な文字です。プレフィックスに疑問符文字が使用されている場合、プレフィックスは名前に疑問符が付いた BLOB と一致します。疑問符はワイルドカード文字として機能しません。
プレフィックスの一致では、正の (=) 論理比較のみが考慮されます。負の (!=) 論理比較は無視されます。

ポリシーが実行されるtimeを特定する方法はありますか?

残念ながら、バックグラウンドスケジューリングプロセスであるため、ポリシーが実行される time を追跡する方法はありません。ただし、プラットフォームは 1 日に 1 回ポリシーを実行します。

データライフサイクルを自動管理してコストを最適化する

ライフサイクル管理ポリシーの定義

ライフサイクル管理ルールの定義

ルールのサンプル

ルールフィルター

ルールのアクション

ライフサイクルポリシーが完了したイベント

ライフサイクルポリシーの例

古いデータをよりクールな層に移動する

最終アクセス時刻に基づいてデータを移動する

取り込み後にデータをアーカイブする

古さに基づいてデータを期限切れにする

BLOB インデックスタグを使用してデータを削除する

以前のバージョンを管理する

機能サポート

リージョン別の可用性と料金

よく寄せられる質問

新規ポリシーを作成しました。アクションがすぐに実行されないのはなぜですか?

既存のポリシーを更新した場合、アクションの実行にはどのくらいの時間がかかりますか。

実行は完了しますが、一部の BLOB は移動も削除もされません

ポリシーが実行され、BLOB を削除しているにもかかわらず、容量の変更が表示されない

アーカイブされた BLOB をリハイドレートしました。一時的にアーカイブ層に戻されないようにするにはどうすればよいですか?

BLOB のプレフィックス一致文字列は予想される BLOB へのポリシーに適用されません

ポリシーが実行されるtimeを特定する方法はありますか?

次のステップ

その他のリソース

その他のリソース

データ ライフサイクルを自動管理してコストを最適化する

ライフサイクル管理ポリシーの定義

ライフサイクル管理ルールの定義

ルールのサンプル

ルール フィルター

ルールのアクション

ライフサイクル ポリシーが完了したイベント

ライフサイクル ポリシーの例

古いデータをよりクールな層に移動する

最終アクセス時刻に基づいてデータを移動する

取り込み後にデータをアーカイブする

古さに基づいてデータを期限切れにする

BLOB インデックス タグを使用してデータを削除する

以前のバージョンを管理する

機能サポート

リージョン別の可用性と料金

よく寄せられる質問

新規ポリシーを作成しました。 アクションがすぐに実行されないのはなぜですか?

既存のポリシーを更新した場合、アクションの実行にはどのくらいの時間がかかりますか。

実行は完了しますが、一部の BLOB は移動も削除もされません

ポリシーが実行され、BLOB を削除しているにもかかわらず、容量の変更が表示されない

アーカイブされた BLOB をリハイドレートしました。 一時的にアーカイブ層に戻されないようにするにはどうすればよいですか?

BLOB のプレフィックス一致文字列は予想される BLOB へのポリシーに適用されません

ポリシーが実行されるtimeを特定する方法はありますか?

次のステップ

その他のリソース

その他のリソース

データライフサイクルを自動管理してコストを最適化する

ルールフィルター

ライフサイクルポリシーが完了したイベント

ライフサイクルポリシーの例

BLOB インデックスタグを使用してデータを削除する

新規ポリシーを作成しました。アクションがすぐに実行されないのはなぜですか?

アーカイブされた BLOB をリハイドレートしました。一時的にアーカイブ層に戻されないようにするにはどうすればよいですか?