Azure Blob Storage のリハイドレードにかかる時間を計ってみる

こんにちは、アーキテクトのやまぱんです。
補足コメントや質問、いいね、拡散、是非お願いします🥺！
間違ってたら優しく教えてください！

---

今回はAzure Blob Storageのリハイドレードにかかる時間を計ってみました！
実際どれくらいかかるんだろう？って思いますよね。
その時に検証する必要があったりすると思います、その時の参考になればと思います。

結論だけみたい人は結果サマリまでどうぞです！

前提知識

Azure Blob Storage とは

Azure Blob Storage は、Microsoft Azure が提供するオブジェクトストレージサービスです。
画像や動画などの大きな非構造データから、バックアップ、ログファイル、分析データまで、あらゆる種類のデータを高可用・低コストで保存できます。

用途に応じて 3 種類のアクセス階層（アクセス頻度別ストレージ階層）が用意されています

アクセス階層	特徴	想定ユースケース
Hot	頻繁にアクセスまたは変更するデータに最適なオンライン層。ストレージ コストは最も高いが、アクセス コストは最も安い。	Webアプリから頻繁にアクセスされるデータ、アクティブなコンテンツなど
Cool	アクセスおよび変更の頻度が低いデータに最適なオンライン層。最低 30 日間は保存が必要。ストレージ コストが安く、アクセス コストは高い。	バックアップ、DR用途、長期アーカイブなど
Cold	めったにアクセスされず、変更されないが、高速で取得できる必要があるデータに最適化されたオンライン層。最低 90 日間は保存が必要。	長期間アクセスしないが、必要に応じて迅速に取得する必要があるデータ
Archive	めったにアクセスせず、数時間の待機時間の変動を許容できるデータ保存に最適なオフライン層。最低 180 日間は保存が必要。	長期保存、法令順守、アーカイブログなど

今回の フォーカス ポイント Archive

BLOB（Binary Large Object）とは？
以下の略でBLOBです。

• Binary（バイナリ）：0と1のデータ（＝機械が扱う生データ）
• Large（ラージ）：サイズが大きい（数MB〜GB級）
• Object（オブジェクト）：構造を持たないデータのかたまり

なので階層構造を持たないんですね、Azure Portal とかでコンテナーをのぞくと階層構造っぽく見えますが、実態としては持っていません。

リハイドレード とは

リハイドレード（Rehydrate）とは、Archive 階層に保存されていた BLOB を、再び Hot や Cool 層へ戻す処理のことです。
Archive 層は安価ですが、すぐにはアクセスできないという制約があります。そのため「ちょっと読みたい」「検証したい」といったときには、一度 Hot 層などに“復元”する必要があるんですね。
この 復元処理が「リハイドレート」 であり、ここに時間かかるのが最大の特徴です。

リハイドレートには以下の2種類の優先度があります：

優先度	概要
Standard（標準）	緊急性がないデータ復元時
High（優先）	緊急対応・検証用途など

リハイドレードにかかる時間について

MS Learn では以下のように記載されています。

Archive レベルからの BLOB のリハイドレートには、完了まで数時間かかる場合があります。 Microsoft では、リハイドレード時に最適なパフォーマンスを得るために、大きな BLOB をアーカイブするよう推奨しています。 大量の小さな BLOB をリハイドレートするには、各 BLOB の処理オーバーヘッドのために追加の時間が必要になる場合があります。 ストレージ アカウントあたり最大 10 GiB を優先的に取得して 1 時間ごとにリハイドレートできます。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/archive-rehydrate-overview

今回実施すること

今回はテストデータ作成スクリプトを使って作ったデータ(128GB)を用いてBlob Storageにアップロードし、これもスクリプトでアーカイブ層に変換。
その後アーカイブ層のデータをリハイドレードをトリガーしその時間を計測。
計測用にもスクリプトを作成した。

テストデータ作成スクリプト
Azure Blob Storageアップロードスクリプト
リハイドレードトリガー用スクリプト
リハイドレード 計測用スクリプト

リハイドレードをトリガーして、徐々にリハイドレード(アーカイブ層からホット層)されている状態がわかる。

• 試すパターンは以下の3つ
  同じストレージ アカウント(コンテナー)を使うので、並列実行はしない。

　1. 大量のデータ (101ファイル / 合計128GB)＆ 優先度 High のパターン
以下のデータを優先度 High で実施する
テストデータ作成スクリプトの引数としては以下でテストデータを作成
-TotalFiles 101 -DepthLevel1 3 -DepthLevel2 3 -DepthLevel3 3 -TotalSizeGB 128 -RootDir "TestData_128GB

項目	内容
作成されるディレクトリ総数（level3_）	3 × 3 × 3 = 27個
総ファイル数	101ファイル
合計サイズ	128GB（実測は端数で若干異なる可能性あり）
各ファイルのサイズ	約 1.27 GB（= 128 GB ÷ 101）
出力先	TestData_128GB フォルダ配下

　2. 単一のデータ (1ファイル / 合計128GB) ＆ 優先度 High のパターン

テストデータ作成スクリプトの引数としては以下でテストデータを作成
-TotalFiles 1 -DepthLevel1 1 -DepthLevel2 1 -DepthLevel3 1 -TotalSizeGB 128 -RootDir "TestData_128GB_Single

項目	内容
作成されるディレクトリ総数（level3_）	1 × 1 × 1 = 1個
総ファイル数	1ファイル
合計サイズ	128GB（実測は端数で若干異なる可能性あり）
各ファイルのサイズ	約128GB（= 128 GB ÷ 1）
出力先	TestData_128GB_Single フォルダ配下

　3. 大量のデータ(101ファイル / 合計128GB) ＆ 優先度 Standard のパターン
用いるデータは 1のパターンと同じ で優先度 Standard で実施。

Azure Portal (GUI) 経由で UPLOAD だと失敗するパターンがあったので以下のような感じで CLI で実施。

• Azure CLI on PowerShell 環境

$TenantId       = "<YOUR_TENANT_ID>"
$SubscriptionId = "<YOUR_SUBSCRIPTION_ID>"
$AccountName    = "<YOUR_STORAGE_ACCOUNT_NAME>"
$ContainerName  = "<YOUR_BLOB_CONTAINER_NAME>"
$SourcePath     = "<LOCAL_SOURCE_FOLDER_PATH>"

# ① ログイン ＆ サブスクリプション切替

az login --tenant $TenantId
az account set --subscription $SubscriptionId

# ② バッチアップロード
az storage blob upload-batch `
  --account-name $AccountName `
  --destination   $ContainerName `
  --source        $SourcePath `
  --auth-mode     login

• 実行イメージ
  
  無事終わった
  

結果サマリ

いずれも 合計128GB

#	パターン	処理時間	優先度	備考
1	101ファイル / High	約63分	高	高優先度により迅速に処理されるが、若干遅延もあり
2	1ファイル / High	約49分	高	単一ファイルで処理が効率化され、最も早く完了
3	101ファイル / Normal	約100分	標準	完了まで時間がかかるが、コスト重視で利用可能

1. 大量のデータ (101ファイル / 合計128GB)＆ 優先度 High のパターン
2. 単一のデータ (1ファイル / 合計128GB) ＆ 優先度 High のパターン
3. 大量のデータ(101ファイル / 合計128GB) ＆ 優先度 Standard のパターン

高優先度だといずれも MS Learn 通り１時間程度未満で終わっていることがわかります。

ストレージ アカウントあたり最大 10 GiB を優先的に取得して 1 時間ごとにリハイドレートできます。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/archive-rehydrate-overview

まとめ

リハイドレート処理にかかる時間は、使用するファイル数や優先度、データのサイズによって大きく変動することがわかりました。特に、単一ファイルの場合は処理が効率化されて最も早く完了し、大量のデータを扱う場合は優先度を高く設定することで、リハイドレート時間を大幅に短縮できることが確認できました。

とはいえ、これはあくまでも検証ベースの 1 事例です。
クラウド、マルチテナント環境のクラウドでは、毎回同じ結果が得られるとは限りません。
ネットワークの混雑具合やストレージアカウントの状態、他の要因によって、リハイドレートの処理速度や完了までの時間が変動することもあります。したがって、実際の運用環境でどれくらいの時間がかかるかを正確に見積もることは難しいです。

今後、リハイドレートの処理を効率化したい場合や、時間的な制約がある場合には、優先度 Highを選択することをお勧めします。しかし、コストを抑えることが最重要である場合やそこまで急がない場合には、Standard での実行を選ぶのが適切です。

また、今回紹介したスクリプトや手順は、Azure環境でのリハイドレート処理の理解と活用に役立つでしょう。これを参考にして、より効率的にデータの復元を行うことができるはずです。