技術

Azure Blob Storageでライフサイクル管理を設定する

はじめに

Azure Blob Storageは、大容量のデータを格納するためのスケーラブルなオブジェクトストレージサービスである。
データの保存期間や アクセス頻度によって適切なストレージ階層を選択することで、コストを削減できる。

Azure Blob Storageのライフサイクル管理機能を使用することで、データの経過時間に応じて自動的にストレージ階層を変更したり、不要になったデータを削除したりすることが可能である。
今回は、ライフサイクル管理機能を試してみる。

環境

Azure Subscription
Azure Portal または Azure CLI
Azure Storage Account（General Purpose v2）

Azure Blob Storageのストレージ階層

ライフサイクル管理を理解するために、まずAzure Blob Storageで利用可能なストレージ階層について記載する。

ストレージ階層の種類

階層名特徴用途コスト
Hot頻繁にアクセスされるデータアクティブなデータ高い（ストレージ）/ 低い（アクセス）
Cool月に数回程度アクセスバックアップ、短期アーカイブ中間（ストレージ）/ 中間（アクセス）
Cold年に数回程度アクセス長期バックアップ低い（ストレージ）/ 高い（アクセス）
Archiveほとんどアクセスしない長期保管、コンプライアンス最低（ストレージ）/ 最高（アクセス）

階層間の移行

データは以下のルールに従って階層間を移行できる

  • 上位階層への移行: Archive → Cold → Cool → Hot（任意の階層へ）
  • 下位階層への移行: Hot → Cool → Cold → Archive（段階的または直接）

ライフサイクル管理ポリシーの概要

ライフサイクル管理について

ライフサイクル管理は、指定した条件に基づいてデータを自動的に以下の処理を行う機能となる

  • 階層の移行: より安価な階層への自動移動
  • データの削除: 保存期間を過ぎたデータの自動削除
  • スナップショットの管理: 古いスナップショットの自動削除

ポリシーの構成要素について

ライフサイクルポリシーは以下の要素で構成される

  1. ルール名: ポリシーの識別名
  2. フィルター: 適用対象の指定（プレフィックス、BLOBタイプなど）
  3. アクション: 実行する処理（移行、削除）
  4. 条件: アクションを実行する条件（日数、作成日など）

準備

ストレージアカウントの作成

ストレージアカウント→「作成」を選択

create-storage-account-01

以下で作成をする。

create-storage-account-02

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

新しいポリシーの作成

Azure Portalで先ほど作成したストレージアカウントを選択し、「データ管理」セクションの「ライフサイクル管理」を選択、「規則の追加」を選択する。

create-lifecycle-01

基本設定

  • ルール名: auto-lifecycle-policy
  • ルールの種類: BLOBに適用
create-policy-01

フィルター設定

  • BLOBの種類: ブロックBLOB
  • プレフィックス一致: logs/ （ログファイル用）
create-policy-03

アクションの設定

基本BLOBのアクション
  • 最終変更日から30日後: Coolアクセス層に移行
  • 最終変更日から90日後: Coldアクセス層に移行
  • 最終変更日から365日後: Archiveアクセス層に移行
  • 最終変更日から2555日後（7年）: BLOBを削除

など。

今回は、30日後に削除とした。

create-policy-02

Microsoft公式ドキュメントに基づく実践例

本セクションでは、Microsoft公式ドキュメントの「ライフサイクル管理ポリシーの構成」を参考に、実際の業務で活用できる具体的な実装例をみてみる。

アクセス時間追跡を活用したライフサイクル管理

最終アクセス時間に基づくライフサイクル管理を使用する

1. アクセス時間追跡の有効化

  1. Azure Portalでストレージアカウントに移動
  2. データ管理セクションで「ライフサイクル管理」を選択
  3. 「アクセス追跡を有効にする」チェックボックスをオン

2. 最終アクセス時間に基づくポリシー

{
  "rules": [
    {
      "enabled": true,
      "name": "access-based-lifecycle",
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["documents/", "media/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterLastAccessTimeGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterLastAccessTimeGreaterThan": 90
            }
          }
        }
      }
    }
  ]
}

Microsoft推奨の段階的移行戦略

公式ドキュメントで推奨されている、変更日と最終アクセス日を組み合わせたポリシー例

{
  "rules": [
    {
      "enabled": true,
      "name": "microsoft-recommended-tiering",
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["sample-container/log"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30,
              "daysAfterLastAccessTimeGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90,
              "daysAfterLastAccessTimeGreaterThan": 90
            }
          }
        }
      }
    }
  ]
}

参考

おわりに

Azure Blob Storageのライフサイクル管理機能を使ってみた。
AWSのS3でもライフサイクルポリシーが存在しているので、触ってみた限りそれと同じ機能のようだった。
なので、ライフサイクルポリシーを活用することで手動による管理作業を削減しながら、コスト削減も実現できる。
また、BlobStorageの仮想ディレクトリについて理解ができていないので理解しておきたい。

Azureでは、仮想マシンからBlobStorageをマウントしたりできるようなのでそれもやってみたい。
どうやらマウントした後に、

  1. マウントしたVMから空のディレクトリを作成
  2. その後ディレクトリが空のまま再マウント
  3. 上記を実行するとディレクトリが消える。

ようなので、これが起きるか試してみたい。

※Blobfuse（または他のマウントツール）は、マウント時に Azure Blob Storage 上に存在するBlobのキー（名前）をもとに、仮想的にディレクトリ構造を構築するようだから

© 2020 - 2025 kbushi
Hugo で構築されています。
テーマ Stack は Jimmy によって設計されています。