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

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

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

結論だけみたい人は[結果サマリ](https://qiita.com/aktsmm/items/31031e6ddbe21a871aab?utm_campaign=post_article&utm_medium=twitter&utm_source=twitter_share#%E7%B5%90%E6%9E%9C%E3%82%B5%E3%83%9E%E3%83%AA)までどうぞです！

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

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

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


https://learn.microsoft.com/ja-jp/azure/storage/blobs/storage-blobs-introduction

https://learn.microsoft.com/ja-jp/azure/storage/blobs/access-tiers-overview

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

:::note 
**BLOB（Binary Large Object）とは？**
以下の略でBLOBです。
* Binary（バイナリ）：0と1のデータ（＝機械が扱う生データ）
* Large（ラージ）：サイズが大きい（数MB〜GB級）
* Object（オブジェクト）：構造を持たないデータのかたまり

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

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

リハイドレートには以下の2種類の優先度があります：
| 優先度              | 概要             
| ---------------- | -------------- | 
| **Standard**（標準） |  緊急性がないデータ復元時 |
| **High**（優先）     |  Standard よりも早く終わる。緊急対応・検証用途など 、<font color="red">追加コストがかかる</font>|

:::note
高優先度のリハイドレードのコストについて
https://azure.microsoft.com/en-us/pricing/details/storage/blobs/
2025/05/22(木) 時点でJapan East Region の場合、以下のコストの違いがある
* Standard の場合 $0.022
* High の場合 $0.145

:::

https://learn.microsoft.com/ja-jp/azure/storage/blobs/archive-rehydrate-overview

### リハイドレードにかかる時間について
MS Learn では以下のように記載されています。
> Archive レベルからの BLOB のリハイドレートには、完了まで数時間かかる場合があります。 Microsoft では、リハイドレード時に最適なパフォーマンスを得るために、大きな BLOB をアーカイブするよう推奨しています。 **大量の小さな BLOB をリハイドレートするには、各 BLOB の処理オーバーヘッドのために追加の時間が必要になる場合があります。** **ストレージ アカウントあたり最大 10 GiB を優先的に取得して 1 時間ごとにリハイドレートできます。**

>標準優先度: リハイドレート要求は受信された順に処理され、サイズが 10 GB 以下のオブジェクトの場合、完了までに最大 15 時間かかることがあります。
高優先度: リハイドレート要求は標準優先度の要求よりも優先され、サイズが 10 GB 以下のオブジェクトの場合、1 時間以内に完了する可能性があります。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/archive-rehydrate-overview


## 今回実施すること
今回は[テストデータ作成スクリプト](https://github.com/aktsmm/Scripts/blob/main/ps/TestDataGen_rand)を使って作ったデータ(128GB)を用いてBlob Storageにアップロードし、これもスクリプトでアーカイブ層に変換。
その後アーカイブ層のデータをリハイドレードをトリガーしその時間を計測。
計測用にもスクリプトを作成した。

[テストデータ作成スクリプト](https://github.com/aktsmm/Scripts/blob/main/ps/TestDataGen_rand)
[Azure Blob Storageアップロードスクリプト](https://github.com/aktsmm/Scripts/tree/main/ps/AzBlobUpload)
[リハイドレードトリガー用スクリプト](https://github.com/aktsmm/Scripts/tree/main/ps/AzBlobRehydrateTrigger)
[リハイドレード 計測用スクリプト](https://github.com/aktsmm/Scripts/tree/main/ps/AzBlobRehydrateWatch)

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2982508/288a9bc9-d4ca-439b-a633-c833e1545760.png)



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

　1. **大量のデータ (101ファイル / 合計128GB)**＆ **優先度 High** のパターン
以下のデータを優先度 High で実施する
[テストデータ作成スクリプト](https://github.com/aktsmm/Scripts/blob/main/ps/TestDataGen_rand)の引数としては以下でテストデータを作成
```-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** のパターン

[テストデータ作成スクリプト](https://github.com/aktsmm/Scripts/blob/main/ps/TestDataGen_rand)の引数としては以下でテストデータを作成
```-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 で実施。

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

+ Azure CLI  on PowerShell 環境
```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
```
+ 実行イメージ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2982508/a7ed9ec1-fe2f-479a-b52c-86b31876d32e.png)
無事終わった
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2982508/41f211a5-d123-4dcd-9995-2941db7683dc.png)

:::

## 結果サマリ
いずれも 合計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** のパターン


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

> **ストレージ アカウントあたり最大 10 GiB を優先的に取得して 1 時間ごとにリハイドレートできます。**
https://learn.microsoft.com/ja-jp/azure/storage/blobs/archive-rehydrate-overview
標準優先度: リハイドレート要求は受信された順に処理され、サイズが 10 GB 以下のオブジェクトの場合、完了までに最大 15 時間かかることがあります。
高優先度: リハイドレート要求は標準優先度の要求よりも優先され、サイズが 10 GB 以下のオブジェクトの場合、1 時間以内に完了する可能性があります。

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

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

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

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