Azure Storage ライフサイクル管理ポリシーの概要、設定手順、動作確認
Azure Blob Storageでは、ライフサイクル管理という、BLOBストレージのアクセス層の変更やデータの削除を自動化できる機能が提供されています。
Azure Blob Storage ライフサイクル管理の概要
ライフサイクル管理を利用すると、最終アクセス日から一定期間が経過したファイルをクール層やアーカイブ層へ自動的に移行することで、ストレージコストを削減できます。
逆に、アクセスがあった場合はホット層に変更することも可能です。
-
- ライフサイクル管理の主な特徴
- 最終アクセス日や更新日を条件に、BLOBコンテナのアクセス層を自動で変更可能
- 汎用 v2、Premium ブロック BLOB、Blob Storage アカウントをサポート
- ブロック BLOBおよび追加 BLOBをサポート
- フィルターやBLOBインデックスを利用することで、特定のBLOBコンテナやディレクトリ単位で細かい制御が可能
- スナップショットやバージョン管理されたデータも自動削除が可能
- ライフサイクル管理の主な特徴
今回は、Azure Storage(汎用 v2)アカウントを利用して、ライフサイクル管理の設定から動作確認までの手順を紹介します。
削除やアクセス層の変更についても確認しています。
Azure Blob Storageのライフサイクル管理機能の概要から設定手順
Azure Blob Storageのアクセス層による料金の違い
ライフサイクル管理は、BLOBストレージのアクセス層の移行やデータの削除を自動化する機能ですが、Azure BLOB Storageの各アクセス層で料金がどの程度異なるのでしょうか。
料金差が小さい場合は、ライフサイクル管理によるコスト削減の効果が少なくなります。
クール層はホット層の約75%の価格、アーカイブ層はホット層の約10%（10分の1）の価格となっています。
特にデータ量が大きい場合、アクセス層を適切に移行することで大きなコスト削減が期待できます。
| アクセス層 | 価格 |
| ホット | ¥2.24/GB |
| クール | ¥1.68/GB |
| アーカイブ | ¥0.224/GB |
※東日本リージョンのLRSの場合です。
※価格は最初の 50 テラバイト (TB)/月の場合
テスト用のストレージアカウント設定
テスト用のストレージアカウントと2つのコンテナーを準備します。
今回は検証のため、指定した内容以外はデフォルト値を使用しています。
| 設定項目 | 設定値 |
| アカウントの種類 | StorageV2 (汎用 v2) |
| レプリケーション | ローカル冗長ストレージ (LRS) |
| コンテナー | lifecycletest01 lifecycletest01 |
 |
|
ライフサイクル管理のポリシー設定値
今回は、検証用のポリシーを2つ作成しています。
1つはBLOBの削除、もう1つはクール層への移動を実施します。
| ポリシー名 | アクション | フィルター |
| lifecyclerule-01 | BLOBの削除 | 有り(lifecycletest01) |
| lifecyclerule-02 | クールストレージに移動 | 有り(lifecycletest02) |
ライフサイクル管理のポリシー作成手順
ストレージアカウントでライフサイクル管理の設定を行います。
ストレージアカウントとBLOBコンテナーは既に作成済みの状態で作業を進めています。
※ライフサイクル管理の規則は、公式サイトではポリシーと記載されていますが、Azure Portal上の表記はルールとなっていました。
| ライフサイクル管理設定 | |
|
ライフサイクル管理を利用するには、アクセス追跡の有効化が必須要件となります。 |
 |
| ルールの追加画面が表示されます。 規則名を設定します。 規則名はlifecyclerule-01としています。 コンテナー名に基づいてポリシーを変更するため、規則の範囲でフィルターを使用してBLOBを制限するを選択します。 |
 |
|
ルールの設定画面が表示されます。 |
 |
|
BLOBプレフィックスを設定します。 |
 |
|
同様に、lifecycle-02コンテナーに対するポリシーも作成します。 |
|
|
規則名を設定した後、規則の範囲でフィルターを使用してBLOBを制限するを選択します。 |
 |
|
最終変更日が1日以上前のBLOBを対象にクールストレージへ移動するよう選択し、次に進みます。 |
 |
|
BLOBプレフィックスにコンテナー名、lifecycletest02を入力します。 |
 |
| ライフサイクル管理のメニューでリストを確認すると、2つのルールが作成されていることを確認できます。 |  |
ポリシー実行は最終アクセス日と最終変更日を元に判断される
ライフサイクル管理のポリシーは1日1回動作し、最終アクセス日と最終変更日に基づいて判断されます。
最終アクセス日を設定した場合は、オブジェクトをホット層へ戻すことが可能
最終変更日と最終アクセス日では、結果の設定項目が異なります。
最終アクセス日の設定を利用した場合、クールストレージへ移動後にアクセスが発生すると、オブジェクトをホット層へ戻すことが可能です。
| 最終変更日と最終アクセス日での違い | ||
| 最終変更日 |
|
 |
| 最終アクセス日 |
|
 |
ライフサイクル管理ではスナップショットやバージョンの削除も可能
ルールの追加の詳細画面では、BLOBのサブタイプとしてスナップショットやバージョンの項目があります。
これらにチェックを入れることで、それぞれの削除設定も可能です。
| スナップショットやバージョンの削除設定 | |
| スナップショットは作成日からの日数を基準にして削除する設定が可能です。 |  |
| バージョンは作成日からの日数を基準にして削除する設定が可能です。 |  |
複数の条件を組み合わせたポリシーの設定も可能
設定条件を複数組み合わせることも可能です。
例えば、1日経過したらクール層へ移動し、3日経過したらアーカイブ層へ移動するといった設定もできます。
| 複数条件を組合せたポリシー設定 | |
| 複数の条件を組み合わせて、1つのポリシーを作成することも可能です。 |  |
—広告—
Azure Blob Storageのライフサイクル管理の動作を確認
ライフサイクル管理の動作を確認
lifecycletest01とlifecycletest02にtestfile.txtというファイルをアップロードして動作を確認します。
lifecycletest01には削除するポリシー、lifecycletest02にはクール層に移動するポリシーを設定しています。
| BLOBコンテナーでファイルアップロード | |
|
ファイルをアップロードした直後は、アクセス層がホットになっています。 ※サンプル画面はlifecycletest02のものです。lifecycletest01にも同じファイルをアップロードしています。 |
 |
ファイルをアップロードしてから24時間以上経過した後、BLOBコンテナーで確認します。
想定通りに動作していることが確認できます。
| ファイルの確認 | |
|
lifecycletest01では、アップロードしたファイルtestfile.txtが削除されていることを確認できました。 |
 |
| lifecycletest02では、アップロードしたファイルtestfile.txtのアクセス層がクール層になっていることを確認できました。 |  |
ライフサイクル管理のポリシー設定はすぐに反映されない
ポリシーが動作するのは1日(24時間)に1回です。
この実行日時は公開されておらず、リージョンによっても異なります。
ポリシーの作成時だけでなく、更新時にも最大48時間かかります。
※ポリシーが有効になるまでに最大24時間、ポリシーが実行されるまでに最大24時間かかります。
—広告—
今回は、Azure Blob Storageのライフサイクル管理について、概要から設定手順、動作までを確認しました。
非常に簡単で便利な機能であり、活用次第ではコスト削減にも役立つではないかと思います。
引き続き、いろいろ試してみたいと思います。
Azure Storageでのオブジェクトレプリケーション設定については、こちらで紹介しています。
https://www.tama-negi.com/2021/10/06/azure-storage-object-re...Azure Backup Vaultを使ったBLOBコンテナーのバックアップリスト手順については、こちらで紹介しています。