Tweet

Pocket

はじめに

Azure のストレージ アカウントは、よく利用されているサービスではないでしょうか。
特に Azure Blob Storage は、様々な場面で活躍していると思います。

この記事では、Azure Blob Storage の便利機能である「ライフサイクル管理」について、ちょっとした検証をしてみたいと思います。

※ この記事で検証した結果は、Azure の公式情報ではなく、
  同条件で検証していただいたとしても、同じ結果となることを保証するものではありません。
  あくまでも参考程度としてお読みください。

ライフサイクル管理とは？

BLOB の最終変更日が xx 日以上前だったら、その BLOB をクール層に移動したり、削除したりすることができる機能 です。
詳細は、こちらのページをご覧ください。

• Azure Blob Storage アクセス層の自動化によるコストの最適化

たとえば、ログを 90 日間 Azure Blob Storage に保管する仕様の場合、それ以上古いログは不要なので削除する必要があります。
今までは、BLOB のリストを取得して、最終変更日を取得して、90 日以上前だったら削除する… という、なんらかの仕組みを用意しなければいけませんでした。
バッチを作成したり、もしかしたら、Azure Functions のタイマー トリガー関数で解決した方もいるかもしれません。

しかし、これからは「ライフサイクル管理」の設定をするだけで、BLOB のアクセス層の移動や削除ができてしまいます！

何を検証するのか？

Azure Blob Storage アクセス層の自動化によるコストの最適化 のページの「よく寄せられる質問」に、下記の FAQ があります。

新しいポリシーを作成しましたが、アクションがすぐに実行されないのはなぜですか。

ライフサイクル ポリシーは、プラットフォームによって 1 日に 1 回実行されます。
ポリシーを構成した後、アクションによっては、初回実行時に最大 24 時間かかる場合があります。

「1 日に 1 回実行されます。」
具体的に、何時頃に実行されるのでしょうか？

ということで、本日の トリビア 検証内容はこちらになります。

Azure Blob Storage のライフサイクル ポリシーは、
東日本リージョンは xx 時、西日本リージョンは xx 時に実行される。

検証方法

今回は、下図のような環境を構築し、検証しました。

環境構成図

ストレージ アカウント

• コンテナー (1)
  • 「最終変更日が 1 日以上前の BLOB は削除する」というライフサイクル ポリシーを定義します。
  • BLOB 名称は yyyyMMdd-HHmm.txt です。
• コンテナー (2)
  • ライフサイクル ポリシーは定義しません。(BLOB は残り続けます。)
  • BLOB 名称は yyyyMMdd-HHmm__{その時点における コンテナー (1) の BLOB の数}.txt です。

※ BLOB 名称に含む日時は UTC としています。

Azure Functions

タイマートリガー関数で、下記の処理を 15 分ごとに実行します。
(東日本リージョン、西日本リージョンの両方で同じ処理を実行します。)

1. ストレージ アカウントの コンテナー (1) に BLOB を追加します。
2. ストレージ アカウントの コンテナー (1) に格納されている BLOB の数を取得します。
3. ストレージ アカウントの コンテナー (2) に BLOB を追加します。

どのように検証するか？

コンテナー (1) は、BLOB が 1 つずつ増えていきます。
コンテナー (2) の BLOB 名称には、 コンテナー (1) の BLOB の数 が含まれるため、
時間が経過するごとに、 こんな感じで数が増えていきます。

• 20201219-0930__1.txt
• 20201219-0945__2.txt
• 20201219-1000__3.txt

ただし、 コンテナー (1) は、ライフサイクル管理によって どこかのタイミングで BLOB が削除されます。
そのため、 コンテナー (2) の BLOB 名称は、数が減るタイミングがあります。

この「数が減ったときの BLOB 名称の日時」と「その 1 つ前の BLOB 名称の日時」の間で、
ライフサイクル ポリシーが実行されているはずです。

検証結果

上述の検証環境を 1 週間以上 動作させました。
BLOB も十分に作成されたので、結果を確認していきます。
下記のように項目を定義し、結果を下表にまとめました。

• 削除前日時
  • 数が減ったときの BLOB 名称の 1 つ前の BLOB 名称の日時
• 削除後日時
  • 数が減ったときの BLOB 名称の日時

東日本リージョン

※ 日時は UTC

西日本リージョン

※ 日時は UTC

検証結果まとめ

下記の時間帯にライフサイクル ポリシーが実行されているようです。

• 東日本リージョン
  • 16 時 (UTC) = 1 時 (JST) くらい
• 西日本リージョン
  • 19 時 (UTC) = 4 時 (JST) くらい

Azure 全体で同じ時間帯に実行されるのではなく、時間差があることがわかりました。

今回の検証では、リージョンごとに 1 つのストレージ アカウントだけで検証したので、
下記の謎は残ってしまいますが、 キリがないので ここで筆を置くことにします。

• リージョンごとに時間帯が異なるのか？
• 同じリージョンでもストレージ アカウントごとに時間帯が異なるのか？
  • この場合、何が要因で時間差が発生するのか。

おわりに

ライフサイクル ポリシーが実行される時間は指定できませんが、
最終変更日を基準にアクセス層の変更や、削除ができる「ライフサイクル管理」は、様々な場面で活用できそうです。
ぜひ、この便利な機能を役立てていただければと思います。

Tweet

Pocket