Azure Blob Storage アクセス層の自動化によるコストの最適化Optimize costs by automating Azure Blob Storage access tiers

データ セットには一意のライフサイクルがあります。Data sets have unique lifecycles. ライフサイクルの早い段階で、一部のデータに頻繁にアクセスされます。Early in the lifecycle, people access some data often. しかし、データが古くなるとアクセスの必要性が急激に低下します。But the need for access drops drastically as the data ages. また、クラウド内で使用されず、格納された後もほとんどアクセスされないデータもあります。Some data stays idle in the cloud and is rarely accessed once stored. データには、作成後数日または数か月で失効するものがあります。また、ライフサイクルにわたってアクティブに読み取られ、変更されるデータ セットもあります。Some data expires days or months after creation, while other data sets are actively read and modified throughout their lifetimes. Azure Blob Storage のライフサイクル管理には、GPv2 アカウントと BLOB ストレージ アカウントに関する、豊富な内容のルールベースのポリシーが用意されています。Azure Blob Storage lifecycle management offers a rich, rule-based policy for GPv2 and blob storage accounts. このポリシーを使用して、適切なアクセス層にデータを移行します。または、データのライフサイクルの終了時に期限切れにします。Use the policy to transition your data to the appropriate access tiers or expire at the end of the data's lifecycle.

ライフサイクル管理ポリシーによって、以下を行えます。The lifecycle management policy lets you:

  • パフォーマンスを最適化するためにアクセスされた場合、BLOB をクールからホットに直ちに移行するTransition blobs from cool to hot immediately if accessed to optimize for performance
  • コストを最適化するために、一定期間にわたってアクセスも変更もされていない場合、BLOB、BLOB のバージョン、BLOB のスナップショットをよりクールなストレージ層に移行する (ホットからクール、ホットからアーカイブ、またはクールからアーカイブ)Transition blobs, blob versions, and blob snapshots to a cooler storage tier (hot to cool, hot to archive, or cool to archive) if not accessed or modified for a period of time to optimize for cost
  • ライフサイクルの最後に BLOB、BLOB のバージョン、BLOB のスナップショットを削除するDelete blobs, blob versions, and blob snapshots at the end of their lifecycles
  • ストレージ アカウント レベルで 1 日に 1 回実行されるようにルールを定義するDefine rules to be run once per day at the storage account level
  • コンテナーまたは BLOB のサブセットにルールを適用する (名前のプレフィックスまたは インデックス タグをフィルターとして使用)Apply rules to containers or a subset of blobs (using name prefixes or blob index tags as filters)

次のようなシナリオについて考えてみましょう。データがライフサイクルの初期段階には頻繁にアクセスされるものの、2 週間後にはたまにしか必要とされなくなります。Consider a scenario where data gets frequent access during the early stages of the lifecycle, but only occasionally after two weeks. 1 か月を超えると、そのデータ セットにはほとんどアクセスされなくなります。Beyond the first month, the data set is rarely accessed. このシナリオの初期段階ではホット ストレージが最適です。In this scenario, hot storage is best during the early stages. ときどきアクセスされるデータにはクール ストレージが適しています。Cool storage is most appropriate for occasional access. 1 か月以上が経過したデータに最も適しているのは、アーカイブ ストレージです。Archive storage is the best tier option after the data ages over a month. データの古さを考慮してストレージ層を調整することで、ニーズに合った最も低コストのストレージ オプションを設計できます。By adjusting storage tiers in respect to the age of data, you can design the least expensive storage options for your needs. この移行を実現するために、ライフサイクル管理ポリシー ルールを使用して、古いデータをよりクールな層に移動することができます。To achieve this transition, lifecycle management policy rules are available to move aging data to cooler tiers.

注意

この記事で説明されている機能は、階層構造の名前空間を持つアカウントで使用できるようになりました。The features described in this article are now available to accounts that have a hierarchical namespace. 制限事項については、「Azure Data Lake Storage Gen2 で使用できる BLOB ストレージ機能」の記事を参照してください。To review limitations, see the Blob storage features available in Azure Data Lake Storage Gen2 article.

注意

StorSimple で使用する場合など、データを読み取れるままにする必要がある場合は、BLOB をアーカイブ層に移動するポリシーを設定しないでください。If you need data to stay readable, for example, when used by StorSimple, do not set a policy to move blobs to the Archive tier.

可用性と料金Availability and pricing

ライフサイクル管理機能は、General Purpose v2 (GPv2) アカウント、BLOB ストレージ アカウント、Premium ブロック BLOB ストレージ アカウント、Azure Data Lake Storage Gen2 アカウントのすべての Azure リージョンで利用できます。The lifecycle management feature is available in all Azure regions for General Purpose v2 (GPv2) accounts, blob storage accounts, Premium Block Blob storage accounts, and Azure Data Lake Storage Gen2 accounts. Azure portal では、既存の General Purpose (GPv1) アカウントを GPv2 アカウントにアップグレードすることができます。In the Azure portal, you can upgrade an existing General Purpose (GPv1) account to a GPv2 account. ストレージ アカウントについて詳しくは、「Azure ストレージ アカウントの概要」をご覧ください。For more information about storage accounts, see Azure storage account overview.

ライフサイクル管理機能は無料です。The lifecycle management feature is free of charge. お客様には、Set Blob Tier API 呼び出しの通常の運用コストが課金されます。Customers are charged the regular operation cost for the Set Blob Tier API calls. 削除操作は無料です。Delete operation is free. 価格の詳細については、「ブロック BLOBの料金」を参照してください。For more information about pricing, see Block Blob pricing.

ポリシーを追加または削除するAdd or remove a policy

ポリシーを追加、編集、または削除するには、次のいずれかを使用します。You can add, edit, or remove a policy by using any of the following methods:

ポリシーは、全体として読み取ったり書き込んだりすることができます。A policy can be read or written in full. 部分的な更新はサポートされません。Partial updates are not supported.

注意

ストレージ アカウントのファイアウォール ルールを有効にしている場合、ライフサイクル管理要求がブロックされることがあります。If you enable firewall rules for your storage account, lifecycle management requests may be blocked. 信頼できる Microsoft サービスに例外を指定することで、このような要求のブロックを解除できます。You can unblock these requests by providing exceptions for trusted Microsoft services. 詳細については、ファイアウォールおよび仮想ネットワークの構成に関するページの「例外」セクションを参照してください。For more information, see the Exceptions section in Configure firewalls and virtual networks.

この記事では、ポータルと PowerShell の方法を使用してポリシーを管理する方法について説明します。This article shows how to manage policy by using the portal and PowerShell methods.

Azure portal を通じてポリシーを追加するには、2つの方法があります。There are two ways to add a policy through the Azure portal.

Azure portal リスト ビューAzure portal List view

  1. Azure portal にサインインします。Sign in to the Azure portal.

  2. Azure portal で、自分のストレージ アカウントを検索して選択します。In the Azure portal, search for and select your storage account.

  3. [Blob service] で、 [ライフサイクル管理] を選択してルールを表示または変更します。Under Blob service, select Lifecycle Management to view or change your rules.

  4. [リスト ビュー] タブを選択します。Select the List View tab.

  5. [ルールの追加] を選択し、 [詳細] フォームでルールに名前を付けることができます。Select Add a rule and name your rule on the Details form. また、 [規則のスコープ][BLOB の種類][BLOB のサブタイプ] の各値を設定することもできます。You can also set the Rule scope, Blob type, and Blob subtype values. 次の例では、BLOB をフィルター処理するスコープを設定します。The following example sets the scope to filter blobs. これにより、 [フィルター セット] タブが追加されます。This causes the Filter set tab to be added.

    Azure portal の [ライフサイクル管理] の [ルールの追加] の [詳細] ページ

  6. [Base blobs](ベース BLOB) を選択して、ルールの条件を設定します。Select Base blobs to set the conditions for your rule. 次の例では、BLOB が 30 日間変更されない場合、BLOB はクール ストレージに移動されます。In the following example, blobs are moved to cool storage if they haven't been modified for 30 days.

    Azure portal の [ライフサイクル管理] の [Base blobs]\(ベース BLOB\) ページ

    [最終アクセス日時] オプションは、次のリージョンにおいてプレビューで使用できます。The Last accessed option is available in preview in the following regions:

    • フランス中部France Central
    • カナダ東部Canada East
    • カナダ中部Canada Central

    重要

    最終アクセス時刻追跡プレビューは、非運用環境のみで使用されます。The last access time tracking preview is for non-production use only. 運用環境のサービス レベル契約(SLA) は現在使用できません。Production service-level agreements (SLAs) are not currently available.

    最終アクセス日時 オプションを使用するために、Azure portal の ライフサイクル管理 ページで アクセス追跡有効 を選択します。In order to use the Last accessed option, select Access tracking enabled on the Lifecycle Management page in the Azure portal. [最終アクセス日時] オプションの詳細については、「最終アクセス日付に基づいてデータを移動させる (プレビュー)」を参照してください。For more information about the Last accessed option, see Move data based on last accessed date (preview).

  7. [詳細] ページで [フィルターを使用して BLOB を制限する] を選択した場合は、 [フィルター セット] を選択して省略可能なフィルターを追加します。If you selected Limit blobs with filters on the Details page, select Filter set to add an optional filter. 次の例では、"log" で始まる mylifecyclecontainer コンテナー内の BLOB に対してフィルター処理を行います。The following example filters on blobs in the mylifecyclecontainer container that begin with "log".

    Azure portal の [ライフサイクル管理] の [フィルター セット] ページ

  8. [追加] を選択して新しいポリシーを追加します。Select Add to add the new policy.

Azure portal コード ビューAzure portal Code view

  1. Azure portal にサインインします。Sign in to the Azure portal.

  2. Azure portal で、自分のストレージ アカウントを検索して選択します。In the Azure portal, search for and select your storage account.

  3. [Blob service] で、 [Lifecycle Management](ライフサイクル管理) を選択してポリシーを表示または変更します。Under Blob service, select Lifecycle Management to view or change your policy.

  4. 次の JSON は、 [コード ビュー] タブに貼り付けることができるポリシーの例です。The following JSON is an example of a policy that can be pasted into the Code View tab.

    {
      "rules": [
        {
          "enabled": true,
          "name": "move-to-cool",
          "type": "Lifecycle",
          "definition": {
            "actions": {
              "baseBlob": {
                "tierToCool": {
                  "daysAfterModificationGreaterThan": 30
                }
              }
            },
            "filters": {
              "blobTypes": [
                "blockBlob"
              ],
              "prefixMatch": [
                "mylifecyclecontainer/log"
              ]
            }
          }
        }
      ]
    }
    
  5. [保存] を選択します。Select Save.

  6. この JSON の例の詳細については、「ポリシー」セクションおよび「ルール」セクションを参照してください。For more information about this JSON example, see the Policy and Rules sections.

ポリシーPolicy

ライフサイクル管理ポリシーは、JSON ドキュメントに記述されたルールのコレクションです。A lifecycle management policy is a collection of rules in a JSON document:

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

ポリシーはルールのコレクションです。A policy is a collection of rules:

パラメーター名Parameter name パラメーターのタイプParameter type NotesNotes
rules ルール オブジェクトの配列An array of rule objects ポリシーには少なくとも 1 つのルールが必要です。At least one rule is required in a policy. ポリシーでは最大 100 のルールを定義できます。You can define up to 100 rules in a policy.

ポリシー内の各ルールには、次のいくつかのパラメーターがあります。Each rule within the policy has several parameters:

パラメーター名Parameter name パラメーターのタイプParameter type NotesNotes 必須Required
name StringString ルール名には最大 256 の英数字を含めることができます。A rule name can include up to 256 alphanumeric characters. ルール名は大文字と小文字が区別されます。Rule name is case-sensitive. 名前は、ポリシー内で一意にする必要があります。It must be unique within a policy. TrueTrue
enabled BooleanBoolean ルールを一時的に無効にすることを許可する省略可能なブール値。An optional boolean to allow a rule to be temporary disabled. 設定されていない場合、既定値は true です。Default value is true if it's not set. FalseFalse
type 列挙型の値An enum value 現在の有効な種類は Lifecycle です。The current valid type is Lifecycle. TrueTrue
definition ライフサイクル ルールを定義するオブジェクトAn object that defines the lifecycle rule 各定義は、フィルター セットとアクション セットで構成されます。Each definition is made up of a filter set and an action set. TrueTrue

ルールRules

各ルール定義には、フィルター セットとアクション セットが含まれます。Each rule definition includes a filter set and an action set. フィルター セットは、コンテナー内の特定のオブジェクト セットまたはオブジェクト名にルール アクションを制限します。The filter set limits rule actions to a certain set of objects within a container or objects names. アクション セットは、階層化または削除アクションをオブジェクトのフィルター処理されたセットに適用します。The action set applies the tier or delete actions to the filtered set of objects.

ルールのサンプルSample rule

次のサンプル ルールは、container1 内に存在し、foo で始まるオブジェクトに対してアクションを実行するようにアカウントをフィルター処理します。The following sample rule filters the account to run the actions on objects that exist inside container1 and start with foo.

注意

  • ライフサイクル管理では、ブロック BLOB と追加 BLOB の種類がサポートされます。Lifecycle management supports block blob and append blob types.
  • ライフサイクル管理は、$logs や $web などのシステム コンテナーには影響しません。Lifecycle management does not affect system containers like $logs and $web.
  • BLOB を最後に変更されたときから 30 日後にクール層に階層化するTier blob to cool tier 30 days after last modification
  • BLOB を最後に変更されたときから 90 日後にアーカイブ層に階層化するTier blob to archive tier 90 days after last modification
  • BLOB を最後に変更されたときから 2,555 日 (7 年) 後に削除するDelete blob 2,555 days (seven years) after last modification
  • 以前のバージョンの BLOB を作成から 90 日後に削除するDelete previous blob versions 90 days after creation
{
  "rules": [
    {
      "enabled": true,
      "name": "rulefoo",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          },
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90
            },
            "delete": {
              "daysAfterModificationGreaterThan": 2555
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "container1/foo"
          ]
        }
      }
    }
  ]
}

ルール フィルターRule filters

フィルターを使用すると、ルール アクションをストレージ アカウント内の BLOB のサブセットに限定できます。Filters limit rule actions to a subset of blobs within the storage account. 複数のフィルターが定義されている場合、すべてのフィルターで論理 AND が実行されます。If more than one filter is defined, a logical AND runs on all filters.

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

フィルター名Filter name フィルターの種類Filter type NotesNotes 必須Is Required
blobTypesblobTypes 定義済みの列挙型の値の配列。An array of predefined enum values. 現在のリリースでは blockBlob および appendBlob をサポートしています。The current release supports blockBlob and appendBlob. appendBlob では削除のみがサポートされています。既定の層はサポートされていません。Only delete is supported for appendBlob, set tier is not supported. はいYes
prefixMatchprefixMatch プレフィックスを照合する文字列の配列。An array of strings for prefixes to be matched. 各ルールで最大 10 個のプレフィックスを定義できます。Each rule can define up to 10 prefixes. プレフィックス文字列はコンテナー名で始まる必要があります。A prefix string must start with a container name. たとえば、https://myaccount.blob.core.windows.net/container1/foo/... の下にあるすべての BLOB をルールに一致させたい場合、prefixMatch は container1/foo です。For example, if you want to match all blobs under https://myaccount.blob.core.windows.net/container1/foo/... for a rule, the prefixMatch is container1/foo. prefixMatch を定義していない場合、ルールはストレージ アカウント内のすべての BLOB に適用されます。If you don't define prefixMatch, the rule applies to all blobs within the storage account. いいえNo
blobIndexMatchblobIndexMatch 照合する BLOB インデックス タグ キーと値条件で構成されるディクショナリ値の配列。An array of dictionary values consisting of Blob Index tag key and value conditions to be matched. 各ルールには、最大 10 個の BLOB インデックス タグ条件を定義できます。Each rule can define up to 10 Blob Index tag condition. たとえば、ルールとして https://myaccount.blob.core.windows.net/ の下にあるすべての BLOB を Project = Contoso に一致させたい場合、blobIndexMatch は {"name": "Project","op": "==","value": "Contoso"} になります。For example, if you want to match all blobs with Project = Contoso under https://myaccount.blob.core.windows.net/ for a rule, the blobIndexMatch is {"name": "Project","op": "==","value": "Contoso"}. blobIndexMatch を定義していない場合、ルールはストレージ アカウント内のすべての BLOB に適用されます。If you don't define blobIndexMatch, the rule applies to all blobs within the storage account. いいえNo

注意

BLOB インデックスはパブリック プレビュー中であり、カナダ中部カナダ東部フランス中部、および フランス南部 リージョンで利用できます。Blob Index is in public preview, and is available in the Canada Central, Canada East, France Central, and France South regions. この機能と既知の問題と制限の詳細については、「BLOB インデックスを使用して Azure Blob Storage でデータを管理および検索する (プレビュー)」を参照してください。To learn more about this feature along with known issues and limitations, see Manage and find data on Azure Blob Storage with Blob Index (Preview).

ルールのアクションRule actions

実行条件が満たされている場合、アクションはフィルター処理された BLOB に適用されます。Actions are applied to the filtered blobs when the run condition is met.

ライフサイクル管理では、BLOB、以前の BLOB バージョン、および BLOB スナップショットの階層化と削除がサポートされています。Lifecycle management supports tiering and deletion of blobs, previous blob versions, and blob snapshots. ベース BLOB、以前の BLOB バージョン、または BLOB スナップショットの各ルールに対して 1 つ以上のアクションを定義します。Define at least one action for each rule on base blobs, previous blob versions, or blob snapshots.

アクションAction ベース BLOBBase Blob スナップショットSnapshot VersionVersion
tierToCooltierToCool blockBlob でサポートSupported for blockBlob サポートされていますSupported サポートされていますSupported
enableAutoTierToHotFromCoolenableAutoTierToHotFromCool blockBlob でサポートSupported for blockBlob サポートされていませんNot supported サポートされていませんNot supported
tierToArchivetierToArchive blockBlob でサポートSupported for blockBlob サポートされていますSupported サポートされていますSupported
deletedelete blockBlob および appendBlob に対してサポートされていますSupported for blockBlob and appendBlob サポートされていますSupported サポートされていますSupported

注意

同じ BLOB に複数のアクションを定義した場合、ライフサイクル管理によって最も低コストのアクションが BLOB に適用されます。If you define more than one action on the same blob, lifecycle management applies the least expensive action to the blob. たとえば、delete アクションは tierToArchive アクションよりも低コストです。For example, action delete is cheaper than action tierToArchive. tierToArchive アクションは tierToCool アクションよりも低コストです。Action tierToArchive is cheaper than action tierToCool.

実行条件は、古さに基づいています。The run conditions are based on age. ベース BLOB では、最終変更時刻を使用し、BLOB バージョンではバージョン作成時刻を使用し、BLOB スナップショットでは、スナップショットの作成時刻を使用して古さが追跡されます。Base blobs use the last modified time, blob versions use the version creation time, and blob snapshots use the snapshot creation time to track age.

アクションの実行条件Action run condition 条件値Condition value 説明Description
daysAfterModificationGreaterThandaysAfterModificationGreaterThan 古さを日数で示す整数値Integer value indicating the age in days ベース BLOB のアクションの条件The condition for base blob actions
daysAfterCreationGreaterThandaysAfterCreationGreaterThan 古さを日数で示す整数値Integer value indicating the age in days BLOB バージョンおよび BLOB スナップショットのアクションの条件The condition for blob version and blob snapshot actions
daysAfterLastAccessTimeGreaterThandaysAfterLastAccessTimeGreaterThan 古さを日数で示す整数値Integer value indicating the age in days (プレビュー) 最終アクセス日時が有効になっているときのベース BLOB アクションの条件(preview) The condition for base blob actions when last accessed time is enabled

Examples

次の例では、ライフサイクル ポリシー ルールを使用して一般的なシナリオに対処する方法を示します。The following examples demonstrate how to address common scenarios with lifecycle policy rules.

古いデータをよりクールな層に移動するMove aging data to a cooler tier

次の例は、プレフィックス container1/foo または container2/bar が付いたブロック BLOB を移行する方法を示しています。This example shows how to transition block blobs prefixed with container1/foo or container2/bar. このポリシーでは、30 日以上変更されていない BLOB をクール ストレージに移行し、90 日間変更されていない BLOB をアーカイブ層に移行します。The policy transitions blobs that haven't been modified in over 30 days to cool storage, and blobs not modified in 90 days to the archive tier:

{
  "rules": [
    {
      "name": "agingRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "container1/foo", "container2/bar" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

最終アクセス日付に基づいてデータを移動させる (プレビュー)Move data based on last accessed date (preview)

最終アクセス時刻追跡機能を有効にして、BLOB が最後に読み書きされた時間を記録できます。You can enable last access time tracking to keep a record of when your blob is last read or written. BLOB データの階層化と保持を管理するためのフィルターとして、最終アクセス時刻を使用できます。You can use last access time as a filter to manage tiering and retention of your blob data.

[最終アクセス日時] オプションは、次のリージョンにおいてプレビューで使用できます。The Last accessed option is available in preview in the following regions:

  • フランス中部France Central
  • カナダ東部Canada East
  • カナダ中部Canada Central

重要

最終アクセス時刻追跡プレビューは、非運用環境のみで使用されます。The last access time tracking preview is for non-production use only. 運用環境のサービス レベル契約(SLA) は現在使用できません。Production service-level agreements (SLAs) are not currently available.

最終アクセス日時 オプションを使用するために、Azure portal の ライフサイクル管理 ページで アクセス追跡有効 を選択します。In order to use the Last accessed option, select Access tracking enabled on the Lifecycle Management page in the Azure portal.

最終アクセス時刻追跡機能のしくみHow last access time tracking works

最終アクセス時刻追跡機能が有効になっている場合、BLOB が読み取られるか書き込まれるときに LastAccessTime という名前の BLOB プロパティが更新されます。When last access time tracking is enabled, the blob property called LastAccessTime is updated when a blob is read or written. Get Blob 操作はアクセス操作と見なされます。A Get Blob operation is considered an access operation. BLOB プロパティの取得BLOB メタデータの取得、および BLOB タグの取得は、アクセス操作ではないので、最終アクセス時刻を更新しません。Get Blob Properties, Get Blob Metadata, and Get Blob Tags are not access operations, and therefore don't update the last access time.

読み取りアクセス待ち時間への影響を最小限に抑えるために、過去 24 時間の最初の読み取りのみが最終アクセス時刻を更新します。To minimize the impact on read access latency, only the first read of the last 24 hours updates the last access time. 同じ 24 時間内のその後の読み取りでは、最終アクセス時刻は更新されません。Subsequent reads in the same 24-hour period do not update the last access time. 読み取り間で BLOB が変更された場合、最終アクセス時刻は 2 つの値のうち新しい方になります。If a blob is modified between reads, the last access time is the more recent of the two values.

次の例では、BLOB は、30 日間アクセスされない場合に、クール ストレージに移動されます。In the following example, blobs are moved to cool storage if they haven't been accessed for 30 days. enableAutoTierToHotFromCool プロパティはブール値であり、BLOB がクールに階層化された後で再びアクセスされた場合に自動的にクールからホットに階層化するかどうかを示します。The enableAutoTierToHotFromCool property is a Boolean value that indicates if a blob should automatically be tiered from cool back to hot if it is accessed again after being tiered to cool.

{
  "enabled": true,
  "name": "last-accessed-thirty-days-ago",
  "type": "Lifecycle",
  "definition": {
    "actions": {
      "baseBlob": {
        "enableAutoTierToHotFromCool": true,
        "tierToCool": {
          "daysAfterLastAccessTimeGreaterThan": 30
        }
      }
    },
    "filters": {
      "blobTypes": [
        "blockBlob"
      ],
      "prefixMatch": [
        "mylifecyclecontainer/log"
      ]
    }
  }
}

ストレージ アカウントのサポートStorage account support

最終アクセス時刻追跡機能は、次の種類のストレージ アカウントで使用できます。Last access time tracking is available for the following types of storage accounts:

  • 汎用 v2 ストレージ アカウントGeneral-purpose v2 storage accounts
  • ブロック BLOB ストレージ アカウントBlock blob storage accounts
  • BLOB ストレージ アカウントBlob storage accounts

ストレージ アカウントが汎用 v1 アカウントの場合は、Azure portal を使用して、汎用 v2 アカウントにアップグレードします。If your storage account is a general-purpose v1 account, use the Azure portal to upgrade to a general-purpose v2 account.

階層型名前空間が Azure Data Lake Storage Gen2 で使用可能になっているストレージ アカウントがサポートされるようになりました。Storage accounts with a hierarchical namespace enabled for use with Azure Data Lake Storage Gen2 are now supported.

価格と課金Pricing and billing

最終アクセス時刻のそれぞれの更新は、その他の操作と見なされます。Each last access time update is considered an other operation.

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

また、クラウド内でアイドル状態のままとなり、格納されてからはほとんどアクセスされないデータもあります。Some data stays idle in the cloud and is rarely, if ever, accessed once stored. 次のライフサイクル ポリシーは、取り込み直後にデータをアーカイブするように構成されます。The following lifecycle policy is configured to archive data shortly after it is ingested. この例では、コンテナー archivecontainer 内のストレージ アカウントのブロック BLOB をアーカイブ層に移行します。This example transitions block blobs in the storage account within container archivecontainer into an archive tier. この移行は、最終変更時刻の 0 日後に BLOB を処理することによって実現されます。The transition is accomplished by acting on blobs 0 days after last modified time:

注意

より効率的な方法として、BLOB をアーカイブ層に直接アップロードすることをお勧めします。It is recommended to upload your blobs directly the archive tier to be more efficient. PutBlob または PutBlockList の x-ms-access-tier ヘッダーを REST バージョン 2018-11-09 以降または最新の BLOB ストレージ クライアント ライブラリと使用できます。You can use the x-ms-access-tier header for PutBlob or PutBlockList with REST version 2018-11-09 and newer or our latest blob storage client libraries.

{
  "rules": [
    {
      "name": "archiveRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "archivecontainer" ]
        },
        "actions": {
          "baseBlob": {
              "tierToArchive": { "daysAfterModificationGreaterThan": 0 }
          }
        }
      }
    }
  ]
}

古さに基づいてデータを期限切れにするExpire data based on age

データの中には、作成後数日または数か月後に失効することが想定されているものがあります。Some data is expected to expire days or months after creation. データを古さに基づいて削除することでデータを期限切れに設定するように、ライフサイクル管理ポリシーを構成できます。You can configure a lifecycle management policy to expire data by deletion based on data age. 次の例は、365 日より古いすべてのブロック BLOB を削除するポリシーを示しています。The following example shows a policy that deletes all block blobs older than 365 days.

{
  "rules": [
    {
      "name": "expirationRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ]
        },
        "actions": {
          "baseBlob": {
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

BLOB インデックス タグを使用したデータを削除するDelete data with Blob Index tags

一部のデータは、削除対象として明示的にマークされている場合のみ有効期限切れになる必要があります。Some data should only be expired if explicitly marked for deletion. 期限切れにするには、データに BLOB インデックスのキー/値属性でタグ付けして、ライフサイクル管理ポリシーを構成します。You can configure a lifecycle management policy to expire data that are tagged with blob index key/value attributes. 次の例は、Project = Contoso でタグ付けされたすべてのブロック BLOB を削除するポリシーを示しています。The following example shows a policy that deletes all block blobs tagged with Project = Contoso. BLOB インデックスの詳細については、BLOB インデックスを使用した Azure Blob Storage でのデータの管理および検索 (プレビュー) に関するページを参照してください。To learn more about the Blob Index, see Manage and find data on Azure Blob Storage with Blob Index (Preview).

{
    "rules": [
        {
            "enabled": true,
            "name": "DeleteContosoData",
            "type": "Lifecycle",
            "definition": {
                "actions": {
                    "baseBlob": {
                        "delete": {
                            "daysAfterModificationGreaterThan": 0
                        }
                    }
                },
                "filters": {
                    "blobIndexMatch": [
                        {
                            "name": "Project",
                            "op": "==",
                            "value": "Contoso"
                        }
                    ],
                    "blobTypes": [
                        "blockBlob"
                    ]
                }
            }
        }
    ]
}

バージョンの管理Manage versions

有効期間全体にわたって定期的に変更およびアクセスされるデータの場合は、BLOB ストレージのバージョン管理を有効にすることで、オブジェクトの以前のバージョンを自動的に管理できます。For data that is modified and accessed regularly throughout its lifetime, you can enable blob storage versioning to automatically maintain previous versions of an object. ポリシーを作成して、以前のバージョンを階層化または削除することができます。You can create a policy to tier or delete previous versions. バージョンの古さは、バージョンの作成時刻を評価することによって決定されます。The version age is determined by evaluating the version creation time. このポリシー ルールは、バージョンの作成後 90 日以上経過したコンテナー activedata 内の以前のバージョンをクール層に階層化し、365 日またはそれ以前のバージョンを削除します。This policy rule tiers previous versions within container activedata that are 90 days or older after version creation to cool tier, and deletes previous versions that are 365 days or older.

{
  "rules": [
    {
      "enabled": true,
      "name": "versionrule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "tierToCool": {
              "daysAfterCreationGreaterThan": 90
            },
            "delete": {
              "daysAfterCreationGreaterThan": 365
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "activedata"
          ]
        }
      }
    }
  ]
}

よく寄せられる質問FAQ

新しいポリシーを作成しましたが、アクションがすぐに実行されないのはなぜですか。I created a new policy, why do the actions not run immediately?

ライフサイクル ポリシーは、プラットフォームによって 1 日に 1 回実行されます。The platform runs the lifecycle policy once a day. ポリシーを構成した後、アクションによっては、初回実行時に最大 24 時間かかる場合があります。Once you configure a policy, it can take up to 24 hours for some actions to run for the first time.

既存のポリシーを更新した場合、アクションの実行にはどのくらいの時間がかかりますか。If I update an existing policy, how long does it take for the actions to run?

更新されたポリシーは、有効になるまで最大 24 時間かかります。The updated policy takes up to 24 hours to go into effect. ポリシーが有効になると、アクションが実行されるまでに最大で 24 時間かかることがあります。Once the policy is in effect, it could take up to 24 hours for the actions to run. このため、ポリシーのアクションが完了するまでに最大 48 時間かかる可能性があります。Therefore, the policy actions may take up to 48 hours to complete.

アーカイブ済み BLOB を手動でリハイドレートしました。これが一時的にアーカイブ層に戻されないようにするにはどうすればよいですか。I manually rehydrated an archived blob, how do I prevent it from being moved back to the Archive tier temporarily?

あるアクセス層から別のアクセス層に BLOB が移動されても、その BLOB の最終変更時刻は変わりません。When a blob is moved from one access tier to another, its last modification time doesn't change. アーカイブ済み BLOB を手動でホット層にリハイドレートすると、その BLOB は、ライフサイクル管理エンジンによりアーカイブ層に戻されます。If you manually rehydrate an archived blob to hot tier, it would be moved back to archive tier by the lifecycle management engine. この BLOB に影響を与えるルールを一時的に無効にして、再びアーカイブされないようにします。Disable the rule that affects this blob temporarily to prevent it from being archived again. BLOB が安全にアーカイブ層に移動されたら、ルールを再度有効にします。Re-enable the rule when the blob can be safely moved back to archive tier. BLOB を別の場所にコピーして、ホット層またはクール層から永続的に離れないようにすることもできます。You may also copy the blob to another location if it needs to stay in hot or cool tier permanently.

次のステップNext steps

誤って削除したデータを回復する方法を学習します。Learn how to recover data after accidental deletion:

BLOB インデックスを使用してデータを管理および検索する方法について説明します。Learn how to manage and find data with Blob Index: