Azure Blob Storage ライフサイクル管理ポリシーの構造

ライフサイクル管理ポリシーを使用して、BLOB を使用パターンに基づいてコスト効率の高いアクセス層に移行できます。 また、ライフサイクルの最後に BLOB を完全に削除することもできます。 ポリシーは現在のバージョン、以前のバージョン、スナップショットで動作できますが、ポリシーは、$logsコンテナーや $web コンテナーなどのシステム コンテナー内 の BLOB では動作しません。 一般的な情報については、「 Azure Blob Storage ライフサイクル管理の概要」を参照してください。

この記事では、ライフサイクル管理ポリシーの要素について説明します。 ポリシーの例については、次の記事を参照してください。

• ブロブを階層間で移行するライフサイクル管理ポリシー
• BLOB を削除するライフサイクル管理ポリシー

準則

ライフサイクル管理ポリシーは、JSON ドキュメントに記述されたルールのコレクションです。 次のサンプル JSON に、完全なルール定義を示します。

{
  "rules": [
    {
      "name": "rule1",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {...}
    },
    {
      "name": "rule2",
      "type": "Lifecycle",
      "definition": {...}
    }
  ]
}

ポリシー内の各ルールには、次の表で説明するように、いくつかのパラメーターがあります。

フィルター

フィルターは、ストレージ アカウント内の BLOB のサブセットにアクションを制限します。 フィルターを使用して、含める BLOB を指定できます。 フィルターでは、除外する BLOB を指定する手段はありません。 複数のフィルターが定義されている場合、論理 AND はすべてのフィルターに適用されます。 次の表では、各パラメーターについて説明します。

プレフィックス一致フィルター

prefixMatch フィルターを適用すると、各ルールで最大 10 個の大文字と小文字を区別するプレフィックスを定義できます。 プレフィックス文字列はコンテナー名で始まる必要があります。 たとえば、パス https://myaccount.blob.core.windows.net/sample-container/blob1/...の下にあるすべての BLOB を照合する場合は、 prefixMatch を sample-container/blob1として指定します。

このフィルターは、名前が sample-container で始まるblob1内のすべての BLOB と一致します。 プレフィックスの一致を定義しない場合、ルールはストレージ アカウント内のすべての BLOB に適用されます。 プレフィックス文字列では、ワイルドカード一致はサポートされていません。 * や ? などの文字は、文字列リテラルとして扱われます。

BLOB インデックス一致フィルター

blobIndexMatch フィルターを適用すると、各ルールで最大 10 個の BLOB インデックス タグ条件を定義できます。 たとえば、Project = Contoso の下にあるすべての BLOB を https://myaccount.blob.core.windows.net/ と照合する場合、blobIndexMatch フィルターは {"name": "Project","op": "==","value": "Contoso"} となります。 blobIndexMatch フィルターの値を定義しない場合、ルールはストレージ アカウント内のすべての BLOB に適用されます。

アクション

ルールごとに少なくとも 1 つのアクションを定義する必要があります。 実行条件が満たされている場合、アクションはフィルター処理された BLOB に適用されます。 実行条件の詳細については、この記事の 「アクションの実行条件」 セクションを参照してください。 次の表では、ポリシー定義で使用できる各アクションについて説明します。

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

階層型名前空間があるアカウントでの削除アクション

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

バージョンとスナップショットを持つ BLOB に対する削除アクション

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

アクションの実行条件

すべての実行条件は時間ベースです。 経過した日数が条件に指定された数を超えた場合は、関連するアクションが実行されます。 ポリシー条件は、ポリシーの実行中に各オブジェクトで 1 回だけ評価されます。 場合によっては、実行によって既に評価された後に、オブジェクトが条件を満たす場合があります。 このようなオブジェクトは、後続の実行時に処理されます。

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

次の表では、各アクションの実行条件について説明します。

アクセス時間の追跡

アクセス時間の追跡を有効にして、BLOB が最後に読み取られたり書き込まれたりした日時の記録を保持したり、BLOB データの階層化と保持を管理するためのフィルターとして使用することができます。

アクセス時間の追跡を有効にすると、 LastAccessTime と呼ばれる BLOB プロパティは、BLOB の読み取りまたは書き込み時に更新されます。 BLOB の取得操作と Put BLOB 操作はアクセス操作であり、BLOB のアクセス時間が更新されます。 ただし、 BLOB プロパティの取得、 BLOB メタデータの取得、 および BLOB タグの取得 はアクセス操作ではありません。 これらの操作では、BLOB のアクセス時間は更新されません。

daysAfterLastAccessTimeGreaterThan 実行条件をポリシーに適用すると、その条件が満たされているかどうかを判断するためにLastAccessTimeが使用されます。

daysAfterLastAccessTimeGreaterThan 実行条件をポリシーに適用しても、アクセス時間の追跡を有効にしなかった場合、LastAccessTimeは使用されません。 代わりに、ライフサイクル ポリシーが有効になった日付が使用されます。 実際、ライフサイクル ポリシーが有効になった日付は、BLOB の LastAccessTime プロパティが null 値である場合に使用されます。 これは、追跡が有効になってから BLOB にアクセスされていない場合に、アクセス時間の追跡を有効にした場合でも発生する可能性があります。

アクセス時間の追跡を有効にする方法については、「 オプションでアクセス時間の追跡を有効にする」を参照してください。

次のステップ

• Azure Blob Storage ライフサイクル管理の概要。
• ライフサイクル管理ポリシーを構成する
• BLOB データのアクセス層
• ブロブを階層間で移行するライフサイクル管理ポリシー
• BLOB を削除するライフサイクル管理ポリシー
• ライフサイクル管理ポリシーの監視
• BLOB インデックスを使用して Azure Blob Storage でデータを管理および検索する
• BLOB アクセス層を使用するためのベスト プラクティス