0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@LimeSML

Azureを学ぶ Azure Blob Storage のライフサイクルを管理する

0
Posted at

本記事は Microsoft Learn の「Azure Blob Storage のライフサイクルを管理する」というモジュールをまとめたものである。

Azure BLOB Storage のライフサイクルを調べる

データは作成されてから削除されるまで、その時々で必要性が変化する。

1. 利用頻度の変化

  • 初期段階：作成直後は非常に頻繁にアクセス・更新される
  • 時間の経過：古くなるにつれてアクセスの必要性が急激に低下する
  • 低頻度アクセス：格納直後からほとんど参照されない「死蔵データ」も存在する

2. 保存期間のバリエーション

  • 短命なデータ：数日〜数ヶ月で役割を終え、失効（削除）対象となるもの
  • 長命なデータ：ライフサイクル全体を通じて常に読み書きが行われるアクティブなもの

アクセス層

データの利用頻度に応じて 4 つの階層（層）を使い分けることで、コストを最小限に抑えられる。

1. 各層の特徴

  • ホット (Hot)：
    • 頻繁に読み書きするデータ用
    • 保存料は高いが、アクセス料が最も安い
  • クール (Cool)：
    • 月 1 回程度のアクセス、30 日以上の保存が前提
    • ホットより保存料が安く、アクセス料が高い
  • コールド (Cold)：
    • さらに低頻度、90 日以上の保存が前提
    • クールよりさらに低コストで保存できるが、アクセス料はさらに高い
  • アーカイブ (Archive)：
    • ほぼアクセスせず、180 日以上の保存が前提の「オフライン」層
    • 保存料は最安だが、読み出しには数時間の準備（解凍）が必要

2. 容量制限の考え方

  • アカウント単位：容量の上限は「層ごと」ではなく「ストレージアカウント全体」で計算される
  • 自由な配分：特定の層だけを使い切ることも、複数の層を組み合わせて使うことも可能

データライフサイクルの管理

ルールに基づいた「自動化ポリシー」を設定することで、データの移動や削除を手動で行う手間を省き、コストを最適化できる。

1. ポリシーでできること

  • 階層の自動移動：
    • アクセスがあった際に「クール → ホット」へ戻し、パフォーマンスを確保する
    • 一定期間アクセスや変更がない場合、「ホット → クール → アーカイブ」へ自動で移してコストを下げる
  • 自動削除：ライフサイクルの終わりに、古いバージョンやスナップショットを含めて自動で消去する
  • 柔軟な適用範囲：アカウント全体だけでなく、特定のコンテナや「名前の前方一致（プレフィックス）」、タグを使って対象を絞り込める

2. 活用例（コスト削減のシナリオ）

  • 0〜14日：頻繁に使うため「ホット層」に配置
  • 15日〜：たまにしか使わないため「クール層」へ自動移動
  • 30日〜：ほぼ使わないため「アーカイブ層」へ移動して保存料を最小化

BLOB Storage のライフサイクルポリシーの検出

ライフサイクル管理ポリシーは JSON 形式で記述され、複数の「ルール」をまとめたもの。

1. ポリシーの構成要素
各ルールは、対象を絞り込む「フィルター」と、実行する内容を決める「アクション」で構成される。

  • ルールの数：1つのポリシーに最大 100 個まで定義可能
  • 基本構造：rules という配列の中に、個別のルールオブジェクトを並べる
{
  "rules": [
    {
      "name": "rule1",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {...}
    },
    {
      "name": "rule2",
      "type": "Lifecycle",
      "definition": {...}
    }
  ]
}

2. ルールの主要パラメーター

パラメーター名 型 内容 必須
name 文字列（最大256文字） ポリシー内で一意の名前が必要 必須
enabled ブール値 ルールの有効/無効を切り替える（既定は true） 必須
type 列挙型 現在は Lifecycle のみ指定可能 任意
definition オブジェクト フィルターセットとアクションセットの具体的な定義 必須

ルール

ルールは「どのデータに（フィルター）」、「いつ何をするか（アクション）」を具体的に定義する。

1. フィルター（Filters）：対象の絞り込み
すべてのデータに適用するのではなく、条件に合うものだけを狙い撃ちする。

2. アクション（Actions）：実行する操作
経過日数などの条件（Trigger）を満たした際に実行する内容。

  • 階層移動：最終更新から30日で「クール」、90日で「アーカイブ」へ移動
  • 削除：最終更新から2,555日（7年）で完全に削除
  • スナップショット管理：作成から90日経過した古いバックアップ（スナップショット）のみを削除
{
  "rules": [
    {
      "enabled": true,
      "name": "sample-rule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90,
              "daysAfterLastTierChangeGreaterThan": 7
            },
            "delete": {
              "daysAfterModificationGreaterThan": 2555
            }
          },
          "snapshot": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "sample-container/blob1"
          ]
        }
      }
    }
  ]
}

ルールフィルター

フィルターは、ルールの適用対象を特定のデータだけに絞り込む機能。複数のフィルターを設定した場合は、すべてを満たすもの（論理 AND）が対象となる。

主要なフィルター項目

  • blobTypes（必須）：
    • 対象とする BLOB の種類を指定
    • 例：blockBlob（一般的なファイル）など
  • prefixMatch（任意）：
    • コンテナ名から始まる「名前の前方一致」で絞り込む
    • 1 つのルールにつき最大 10 個まで指定可能
    • 例：mycontainer/logs/ とすれば、その配下のみが対象
  • blobIndexMatch（任意）：
    • BLOB に付与した「インデックス タグ（キーと値のペア）」で絞り込む
    • 1 つのルールにつき最大 10 個まで指定可能
    • 「プロジェクト名：A」といった属性情報で柔軟にターゲットを決められる

ルールアクション

フィルターで絞り込まれたデータに対し、「いつ」「何をするか」の具体的な動作を定義する。

1. サポートされるアクション
データの「現在のバージョン」「スナップショット」「以前のバージョン」それぞれに対して操作を指定できる。

  • 階層移動 (Tiering)：tierToCool / tierToCold / tierToArchive：より安価な層へ移動
  • enableAutoTierToHotFromCool：アクセス時に自動でホット層へ戻す（本体のみ）
  • 削除 (Delete)：不要になったデータを完全に消去。ブロック BLOB だけでなく追加 BLOB も対象

2. 実行条件（トリガー）
「古さ」を判断する基準は、操作対象によって異なる。

  • daysAfterModificationGreaterThan：対象：ベース BLOB（本体）
    • 基準：最終更新日からの経過日数
  • daysAfterCreationGreaterThan：対象：スナップショット / 以前のバージョン
    • 基準：作成日からの経過日数
  • daysAfterLastAccessTimeGreaterThan：基準：最後に読み取られた日からの経過日数（アクセス追跡が有効な場合のみ）
  • daysAfterLastTierChangeGreaterThan：対象：tierToArchive アクション専用
    • 基準：層を変更してからの経過日数。アーカイブから一時的に戻したデータが、すぐに再アーカイブされないよう制御するために使う

BLOB Storage のライフサイクルポリシーの実装

ポリシーを追加、編集、または削除するには、次のいずれかが使用できる。

  • Azure portal
  • Azure PowerShell
  • Azure CLI
  • REST API

Azure portal

Azure Portal では、「リストビュー（画面入力）」と「コードビュー（JSON直接記述）」の 2 通りから設定を選べる。

1. 設定の手順（コードビューの場合）

  1. 対象のストレージアカウントを開く
  2. メニューの「データ管理」セクションにある [ライフサイクル管理] を選択
  3. [コード ビュー] タブに切り替える
  4. JSON エディタにルールを記述して保存する

現在は Storage Actions から設定をするよう。
image.png

Azure CLI

コマンドライン（Azure CLI）を使ってライフサイクル管理ポリシーを適用する方法。

1. 実行手順

  • JSON ファイルの準備：定義内容を policy.json などのファイルとして保存する
  • コマンド実行：az storage account management-policy create を使用
  • 指定パラメータ：ストレージアカウント名、リソースグループ名、そして @ を付けた JSON ファイルパスを指定する
az storage account management-policy create --account-name <storage-account> --policy @policy.json --resource-group <resource-group>

2. 重要な注意点

  • 一括更新：ポリシーは「全体」を一度に書き換える必要がある
  • 部分更新不可：特定のルールだけを修正・追加する「部分的な更新」はできない。変更時は常にポリシー全体の JSON を送り直す

アーカイブ層から BLOB データをリハイドレートする

アーカイブ層にある BLOB は「オフライン」状態のため、そのままでは開くことも編集もできない。利用するにはオンライン層（ホット/クール）へ戻す「リハイドレート」が必要。

1. 2つの復元方法

  • 別の BLOB としてコピー（推奨）：
    • アーカイブ状態の元データはそのままに、ホットまたはクール層に新しいコピーを作成する
    • 利点：ほとんどのケースで推奨される安全な方法
  • 既存 BLOB の層を変更：
    • 「層の設定」操作で、そのファイル自体のステータスをアーカイブからホット/クールへ直接書き換える

2. 実行時の注意点

  • 所要時間：データの取り出しには数時間を要する。即座に読み取ることはできない
  • パフォーマンス：大容量の BLOB をまとめて戻す方が効率が良い
    • 小さなファイルを大量に同時にリハイドレートすると、さらに時間がかかる可能性がある

リハイドレートの優先度

アーカイブ層からデータを戻す際、x-ms-rehydrate-priority ヘッダーを指定することで、復元にかかるスピードを制御できる。

1. 2つの優先度レベル

  • 標準優先度 (Standard)：
    • 処理：リクエストを受けた順に処理される
    • 所要時間：最大で 15 時間。時間に余裕がある場合に適している
  • 高い優先度 (High)：
    • 処理：標準リクエストよりも優先して処理される
    • 所要時間：10 GB 以下のファイルであれば、1 時間以内に完了する可能性がある。急ぎの場合に選択する

2. 進行状況の確認方法

  • 確認手段：Get Blob Properties 操作を呼び出す
  • 確認項目：レスポンス内の x-ms-rehydrate-priority の値を確認する
  • 返り値：tandard または High が返り、現在の設定状況がわかる

アーカイブ済み BLOB をオンライン層にコピーする

アーカイブ層のデータをそのまま残しつつ、別の場所にコピーを作成して「オンライン（読み取り可能）」な状態にする方法。

1. 基本的な仕組み

  • ソースの状態：元のファイル（コピー元）は変更されず、アーカイブ層にそのまま残る
  • コピー先：新しい名前の BLOB、または別のコンテナを指定する必要がある
  • 上書き禁止：同じ名前（自分自身）へのコピーによる上書きはできない

2. アカウント間のコピー（リハイドレート）

  • 従来（2021年2月12日以前）：同じストレージアカウント内でのみコピー可能
  • 現在（サービスバージョン 2021-02-12 以降）：
    • 同一リージョン内であれば、別のストレージアカウントへのコピーによる復元が可能

BLOB のアクセス層をオンライン層に変更する

Set Blob Tier 操作を実行し、アーカイブ層にある BLOB 自体の設定を「ホット」または「クール」に書き換えて復元する方法。

1. 操作の特徴

  • 直接変更：コピーを作成せず、既存の BLOB そのものの階層を変更する
  • 取消不可：一度リハイドレート要求を開始すると、途中でキャンセルすることはできない

2. 処理中のステータス

  • 表示の継続：復元処理（リハイドレート）が完全に終わるまで、管理画面上の表示は「アーカイブ済み」のままとなる
  • 完了のタイミング：処理が終わった段階で、初めて指定したオンライン層（ホット/クール）として認識される
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?