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

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

Note

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

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

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

データがライフサイクルの初期段階には頻繁にアクセスされるものの、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 です。 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 でサポート サポートされています サポートされています
enableAutoTierToHotFromCool blockBlob でサポート サポートされていません サポートされていません
tierToArchive blockBlob でサポート サポートされています サポートされています
delete1 blockBlob および appendBlob に対してサポートされています サポートされています サポートされています

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

Note

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

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

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

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

次の例では、ライフサイクル ポリシー ルールを使用して一般的なシナリオに対処する方法を示します。

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

次の例は、プレフィックス 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 タグの取得は、アクセス操作ではないので、最終アクセス時刻を更新しません。

読み取りアクセス待ち時間への影響を最小限に抑えるために、過去 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 はホット層からクール層に移動しません。 autoTierToHotFromCool を回避する唯一の方法は、最終アクセス時刻の追跡をオフにすることです。

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

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

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

次のステップ