Azureでストレージアカウントのライフサイクル管理を利用してblobの階層移動を試してみました。
事前準備
ストレージアカウントを作成する
以下のAzureCLIで作成します。
$rg_name = "Test-001-RG"
$location = "japaneast"
$storage_name = "satestlifecycle8697458"
#リソースグループの作成
az group create `
-l $location `
-g $rg_name
#ストレージアカウントの作成
az storage account create `
-n $storage_name `
-g $rg_name `
-l $location `
--kind StorageV2コンテナーにコンテンツを配置する
以下のようにストレージアカウントのコンテナーにテキストファイルを配置します。
今回は検証のために日にちを分けて格納しています。
ライフサイクル管理を作成する
ストレージアカウントでライフサイクル管理のルールを作成します。
・ストレージアカウントに移動し [ライフサイクル管理] から「アクセス追跡を有効にする」のチェックボックスにチェックを入れて有効化が完了したら [+ルールの追加] をクリックします。
![[ライフサイクル管理] から「アクセス追跡を有効にする」のチェックボックスにチェックを入れて有効化が完了したら [+ルールの追加] をクリック](https://bonjiri-blog.com/wp-content/uploads/use-storage-account-lifecycle-feature-001.png)
・[詳細] タブではルール名と対象の種類を選択します。
![[詳細] タブではルール名と対象の種類を選択](https://bonjiri-blog.com/wp-content/uploads/use-storage-account-lifecycle-feature-002.png)
今回はブロックblobのみを対象として、フィルターはかけずにストレージアカウントすべてに適用されるように設定します。
後述しますが、追加blobは階層移動ができないので今回は対象外にします。
・[基本BLOB] のタブでルールを設定していきます。
![[基本BLOB] のタブでルールを設定１](https://bonjiri-blog.com/wp-content/uploads/use-storage-account-lifecycle-feature-003.png)
![[基本BLOB] のタブでルールを設定２](https://bonjiri-blog.com/wp-content/uploads/use-storage-account-lifecycle-feature-004.png)
今回は最終更新を基準として以下の設定にします。
- 1日経過→クール層に移動
- 2日経過→コールド層に移動
- 3日経過→アーカイブ層に移動
- 4日経過→削除
また、アーカイブへの移動の設定の中で「次の期間にリハイドレードされたBLOBをスキップする」という項目がありますがこれはデフォルト設定のままにしてみます。
アーカイブ層からリハイドレードした場合にこのルールをすぐに適用させなくするというものですのでリハイドレードしない限りはこのルールが処理されるはずです。
しかしこの想定は誤りで、この設定項目はアーカイブ層関係なく層移動がされた場合に適用される設定でした。
下部のライフサイクル設定後から5日後の状態でも記載しています。
ライフサイクル管理の挙動を確認する
今時点では2日前のファイルと先ほど格納したファイルがあるので、それぞれどのように変更されるのかを見ていきます。
・ライフサイクル管理の設定を追加した直後の状態ですが、変化はありません。
・3時間ほど経過しましたがまだ変更されていません。
・6時間ほど経過してもまだ変更されません。
・12時間ほど経過してもまだ変更されません。
以下のMicrosoft公式のドキュメントにも「最大で 24 時間かかる場合があります」と記載があるので気長に待ちます。
ライフサイクル ポリシーを構成または編集すると、変更が有効になり、最初の実行が開始されるまでに最大で 24 時間かかる場合があります。 ポリシー アクションが完了するまでにかかる時間は、評価および操作される BLOB の数によって異なります。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/lifecycle-management-overview#lifecycle-policy-runs
ライフサイクル設定後から1日後の状態
改めて翌日に確認してみました。
すると、9/18に最終更新されたファイルがコールド層に変更されていました。
ライフサイクルのルールを適用すると、ルールで定義されているアクションの最終結果に変更されるようです。
[参考] ライフサイクル管理の実行頻度は低い、かも？
9/20に配置したファイルは24時間経過しましたが、まだクール層に移動されていませんでした。
おそらくライフサイクル管理のルールの実行は1日に一度などの頻度で実行され、その時点で1日経過しているかどうかが判定されるため起きている事象かと思います。
しかし、ライフサイクル管理を利用する際には30日や90日など長い日付で設定することが想定されるので、実行頻度についてはあまり気にする必要はないのかなとも思いました。
ライフサイクル設定後から3日後の状態
2日後のキャプチャの取得に失敗しましたが3日後の状態を確かめてみます。
すると9/18に最終更新したファイルがコンテナーから消えており、9/20のファイルもコールド層に移動していました。
設定上では4日経ったblobは削除としていたので、正しく削除までできていることが分かりました。
ライフサイクル設定後から5日後の状態
キャプチャはありませんが4日後には9/20のファイルがアーカイブ層になっていることが確認できるかと思いきや、コールド層のままでした。
その後、5日後として確認するとblobが削除されていました。
また、診断ログにもアーカイブ層への移動のログはありませんでした。
これはライフサイクル管理のルールを設定する際に「次の期間にリハイドレードされたBLOBをスキップする」の設定を入れたため、アーカイブ層への変更がされなかったのだと思います。
なので、3日後に実施される予定であったアーカイブ層への移動がSKIPされ、4日後の削除でファイルが削除されました。
階層変更時のログ
blobの診断ログを有効化して階層変更時のログを確認することが可能です。
今回は別のストレージアカウントにログを格納して確認してみました。
ログは「insights-logs-storagewrite」のコンテナに格納されています。
9/21に記録されたjsonファイルを見てみると、以下のようなログが確認できます。
{ “time”: “2024-09-21T17:24:55.3200591Z”, “resourceId”: “/subscriptions/———————————————-/resourceGroups/Test-001-RG/providers/Microsoft.Storage/storageAccounts/satestlifecycle8697458/blobServices/default”, “category”: “StorageWrite”, “operationName”: “SetBlobTier”, “operationVersion”: “2021-12-02”, “schemaVersion”: “1.0”, “statusCode”: 200, “statusText”: “Success”, “durationMs”: 4, “callerIpAddress”: “100.72.92.231:33385”, “correlationId”: “0e5f8504-f01e-003d-664b-0c3596000000”, “identity”: {“type”:”TrustedAccessSas”,”tokenHash”:”system-1(———————),SasSignature(———————)”}, “location”: “japaneast”, “properties”: {“accountName”:”satestlifecycle8697458″,“userAgentHeader”:”xAzure/1.0 AzureStorage/1.0 ObjectLifeCycleScanner/0.50″,”clientRequestId”:”satestlifecycle8697458_ms-tyo22prdstr07a_2024-09-21T17:15:15.2871335Z_c9829f01-5b16-4fda-a6f9-4a696a674507_ms-tyo22prdstr06b$XTableServer_IN_137″,”serviceType”:”blob”,”objectKey”:”/satestlifecycle8697458/testcontainer01/test_20240920.txt“,”metricResponseType”:”Success”,”serverLatencyMs”:4,”requestHeaderSize”:740,”responseHeaderSize”:282,”tlsVersion”:”TLS 1.2″,“accessTier”:”Cool“,”sourceAccessTier”:”None”}, “uri”: “https://satestlifecycle8697458.blob.core.windows.net:443/testcontainer01/test_20240920.txt?sv=2020-06-12&ss=b&srt=sco&sp=rwdlacuptx&se=2024-10-05T17%3A17%3A34.1503045Z&spr=https&sk=system-1&sig=XXXXX&timeout=10&comp=tier”, “protocol”: “HTTPS”, “resourceType”: “Microsoft.Storage/storageAccounts/blobServices”}
時刻表期はUTCなので、9/22の日本時間午前2時に実行されており、test_20240920.txt がuserAgent：xAzure/1.0 AzureStorage/1.0 ObjectLifeCycleScanner/0.50 によって Cool層に変更されていることが分かります。
その翌日のログも以下のように同じフォーマットで出力されており、9/23の同じく午前2時頃に実行されており、今度は Cold層に移動されたことが分かります。
{ “time”: “2024-09-22T17:24:33.7213833Z”, “resourceId”: “/subscriptions/———————————————-/resourceGroups/Test-001-RG/providers/Microsoft.Storage/storageAccounts/satestlifecycle8697458/blobServices/default”, “category”: “StorageWrite”, “operationName”: “SetBlobTier”, “operationVersion”: “2021-12-02”, “schemaVersion”: “1.0”, “statusCode”: 200, “statusText”: “Success”, “durationMs”: 7, “callerIpAddress”: “10.172.160.7:62055”, “correlationId”: “04f65de0-501e-0056-7d14-0db262000000”, “identity”: {“type”:”TrustedAccessSas”,”tokenHash”:”system-1(———————),SasSignature(———————)”}, “location”: “japaneast”, “properties”: {“accountName”:”satestlifecycle8697458″,“userAgentHeader”:”xAzure/1.0 AzureStorage/1.0 ObjectLifeCycleScanner/0.50″,”clientRequestId”:”satestlifecycle8697458_ms-tyo22prdstr07a_2024-09-22T17:15:15.2871335Z_38c91ad1-68dd-414c-8a2f-8c0938c95e81_ms-tyo23prdstr01a$XTableServer_IN_91″,”serviceType”:”blob”,”objectKey”:”/satestlifecycle8697458/testcontainer01/test_20240920.txt“,”metricResponseType”:”Success”,”serverLatencyMs”:7,”requestHeaderSize”:739,”responseHeaderSize”:281,”tlsVersion”:”TLS 1.2″,“accessTier”:”Cold“,”sourceAccessTier”:”None”}, “uri”: “https://satestlifecycle8697458.blob.core.windows.net:443/testcontainer01/test_20240920.txt?sv=2020-06-12&ss=b&srt=sco&sp=rwdlacuptx&se=2024-10-06T17%3A17%3A36.0433832Z&spr=https&sk=system-1&sig=XXXXX&timeout=10&comp=tier”, “protocol”: “HTTPS”, “resourceType”: “Microsoft.Storage/storageAccounts/blobServices”}
[参考] 診断ログ（追加blob）は階層移動できない
追加blobは階層移動ができません。
診断設定によってストレージアカウントに格納されるログは追加blobになりますので、階層移動ができません。
実際に診断ログを確認してみると「アクセス層」が空欄なので階層の概念がないことが分かります。
実際の「ライフサイクル管理」の設定でも追加blobを選択した場合には以下の通り、アクションとして「BLOBの削除」しか選択できません。
なので診断設定ログの階層移動はMicrosoftの機能updateを待つしかありません。
ただ、削除はできるのでログを保持する期間の終了に合わせて削除設定を入れるのは有効かもしれません。
[参考] 早期削除ペナルティについて
以下のMicrosoftの公式ドキュメントにも記載がある通り、ライフサイクル管理では早期削除ペナルティがありますので、ライフサイクル管理を設定する場合はこの点にも考慮が必要です。
BLOB は、層に必要な最小日数が経過する前に削除、上書き、または異なる層に移動された場合、早期削除のペナルティの対象となります。 たとえば、汎用 v2 アカウントのクール アクセス層の BLOB は、30 日が経過する前に削除するか異なる層に移動した場合に、早期削除のペナルティの対象となります。 コールド アクセス層の BLOB の場合、90 日が経過する前に削除または別の層に移動された場合、削除ペナルティが適用されます。 この料金は日割り計算されます。 たとえば、BLOB をクール アクセス層に移動させてから 21 日後に削除した場合は、BLOB をクール アクセス層に 9 日間 (30 − 21日) 保存する料金に相当する早期削除料金が発生します。 早期削除の料金は、指定された時間枠内にオブジェクト全体が任意の操作 (つまり、Put Blob、Put Block List、または Copy Blob) によって書き換えられた場合にも発生します。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/access-tiers-overview#online-access-tiers
コメント