Azure Storage ライフサイクル管理ポリシーの設定から確認までやってみた

Azure,Storage

Azure Storageではデータライフサイクル管理と言うBLOBストレージのアクセス層を変更、削除する機能が提供されています。

データ ライフサイクルを自動管理してコストを最適化する(マイクロソフト社公式)

データライフルサイクル管理を使うと最終アクセス日から一定期間経過したようなファイルをクール層やアーカイブ層へ移行する事でコスト削減出来ます。
逆にアクセスがあった場合にホット層に変更する事も可能です。

    • データライフルサイクル管理の主な特徴
      • 最終アクセス日や更新日をキーにBLOBコンテナのアクセス層を変更する事が出来る
      • 汎用 v2、Premium ブロック BLOB、Blob Storage のアカウントをサポート
      • ブロック BLOB と追加 BLOBをサポート
      • フィルターやBLOBインデックスを利用する事で特定のBLOBコンテナーやディレクトリ指定と言った細かい制御も可能
      • スナップショットやバージョン管理も削除する事が可能

今回はAzure Storage(汎用 v2)を使ってライフサイクル管理の設定から動作確認までやってみました。
確認では削除やアクセス層の変更をやってみてます。

スポンサーリンク

 Azureストレージアカウントでライフサイクル管理設定してみた

ストレージアカウントのアクセス層でどの位料金が違うのでしょうか

ライフサイクル管理はアクセス層の移行や削除に関する機能なのですが、Azure BLOB Storageそれぞれの層で料金がどの位違うのでしょうか。
大きく変わらないのであればそんなに意味がありません。
Azure Storageの料金をこちらで確認しています。

クール層はホット層の75%の価格になり、アーカイブ層は10%と10分の1の価格になります。データ量が大きければ結構な価格差になりそうです。(東日本リージョンのLRSの場合)

アクセス層 価格
ホット ¥2.24/GB
クール ¥1.68/GB
アーカイブ ¥0.224/GB

※価格は最初の 50 テラバイト (TB)/月の場合

テスト用のストレージアカウント設定

テスト用ストレージアカウントとコンテナーを事前に準備しています。コンテナーは2つ作成しています。
今回は検証ですので指定した内容以外はデフォルト値にしています。

設定項目 設定値
アカウントの種類 StorageV2 (汎用 v2)
レプリケーション ローカル冗長ストレージ (LRS)
コンテナー lifecycletest01
lifecycletest01

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

今回はポリシーを2つ作成します。
BLOBの削除とクール層への移動を試します。

ポリシー名 アクション フィルター
lifecyclerule-01 BLOBの削除 有り(lifecycletest01)
lifecyclerule-02 クールストレージに移動 有り(lifecycletest02)

ライフサイクル管理のポリシーを作成

ストレージアカウントでライフサイクル管理の設定をします。ストレージアカウント、BLOBコンテナーは作成済みの状態で実施します。公式サイトの手順を参考に実施します。
なおライフサイクル管理の規則の事を公式サイトではポリシーと記載されていますが、画面上はルールになっています。

ライフサイクル管理設定

ライフサイクル管理はアクセス追跡の有効化が必須要件になります。
チェックを入れルールの追加を選択します。
規則名を設定します。
今回はコンテナー名でポリシーを変更する為、規則の範囲でフィルターを使用してBLOBを制限するを選択します。

ルールの設定画面です。
検証用の設定として最終変更日、1日以上前、BLOBの削除を選択し次に進みます。

BLOBプレフィックスを設定します。
BLOBコンテナー名lifecycletest01に対するルールにしたいのでBLOBプレフィックスにコンテナー名を入力します。

最後に追加をクリックしてライフサイクル管理の規則を作成します。

同様にlifecycle-02のポリシーを作成します。

規則名を設定後、規則の範囲でフィルターを使用してBLOBを制限するを選択します。

検証用の設定として最終変更日、1日以上前、クールストレージに移動するを選択し次に進みます。

BLOBプレフィックスにlifecycletest02を入力します。
最後に追加をクリックしてライフサイクル管理の規則を作成します。
ライフサイクル管理で確認すると2つのルールが作成されている事が分かります。

ライフサイクル管理のポリシー実行は最終アクセス日と最終変更日を元に判断される

ライフサイクル管理のポリシーは1日1回動作するのですが、最終アクセス日と最終変更日により判断されます。最終変更日と最終アクセス日では設定内容が少し異なります。最終アクセス日の設定の場合はクールストレージ移動後にアクセスがあった場合にホット層に戻す事が可能です。

最終変更日と最終アクセス日での違い
最終変更日
  • クールストレージに移動する
  • アーカイブストレージに移動する
  • BLOBの削除
最終アクセス日
  • クールストレージに移動します。アクセスすると元の場所に移動します。
  • クールストレージに移動する
  • アーカイブストレージに移動する
  • BLOBの削除

ライフサイクル管理ではスナップショットやバージョンの削除も可能

ルールの追加の詳細画面でBLOBのサブタイプにスナップショットやバージョンの項目があります。こちらにチェックを入れる事でそれぞれの削除設定も可能です。

スナップショットやバージョンの削除設定
スナップショットは作成日からの日数で削除する設定が可能です。
バージョンは作成日からの日数で削除する設定が可能です。

ポリシーの設定は複数組み合わせる事が可能

設定条件を複数組み合わせる事も鹿野です。1日経過したらクール層へ移動、3日経過したらアーカイブ層に移動と言ったような設定も可能です。

複数条件を組合せたポリシー設定
複数の条件組合せて1つのポリシーを作成する事も可能です。

Azureストレージでライフサイクル管理の挙動を確認する

ライフサイクル管理の動作確認

lifecycletest01と02にtestfile.txtと言うファイルをアップロードして確認してみます。lifecycletest01には削除するポリシー、lifecycletest02にはクール層に移動するポリシーを設定しています。

BLOBコンテナーでファイルアップロード

ファイルアップロード後はアクセス層がホットになっています。

※サンプルの画面はlifecycletest02になります。lifecycletest01にも同じファイルをアップロードしています。

ファイルアップロード後24時間以上経過した後にBLOBコンテナーで確認してみます。

ファイルの確認

lifecycletest01ではアップロードしたファイルtestfile.txtが削除されている事が確認出来ました。
lifecycletest02ではアップロードしたファイルtestfile.txtのアクセス層がクール層になっている事が確認出来ました。

想定通りの挙動している事が確認出来ました。非常に簡単に設定できて便利に使えそうです。

ライフサイクル管理のポリシー設定はすぐに反映されないし動作もしない

ポリシーが動作するのは1日(24時間)1回になります。この日時は非公開でリージョンによっても異なるようです。
こちらに記載がありますが、ポリシーを作成時だけではなく更新時も最大48時間(ポリシーが有効になるのに24時間、ポリシーが実行されるのに最大24時間で合計48時間)掛かります。

検証していた時に、更新時はすぐに反映されるだろうと勘違いしていてドはまりしました。

Azure Storageでのオブジェクトレプリケーション設定についてはこちら。

Azure Backup Vaultを使ったBLOBコンテナーのバックアップリストはこちら。

スポンサーリンク

Azure,Storage