アーカイブ層からの BLOB のリハイドレート
BLOB はアーカイブ アクセス層内にある間、その BLOB はオフラインと見なされ、読み取りや変更はできません。 アーカイブされた BLOB 内のデータを読み取りまたは変更するには、まず、ホット層またはクール層のどちらかのオンライン層に BLOB をリハイドレートする必要があります。 アーカイブ層に格納されている BLOB をリハイドレートするには、次の 2 つのオプションがあります。
アーカイブ済み BLOB をオンライン層にコピーする: BLOB のコピー操作でホットまたはクール アクセス層の新しい BLOB にコピーすることで、アーカイブされた BLOB をリハイドレートできます。
アーカイブされたBLOB のアクセス層をオンライン層に変更する: Set Blob Tier操作を使用してその層を変更することにより、アーカイブされた BLOB をホットまたはクール アクセス層にリハイドレートすることができます。
Archive レベルからの BLOB のリハイドレートには、完了まで数時間かかる場合があります。 Microsoft では、リハイドレード時に最適なパフォーマンスを得るために、大きな BLOB をアーカイブするよう推奨しています。 大量の小さな BLOB をリハイドレートするには、各 BLOB の処理オーバーヘッドのために追加の時間が必要になる場合があります。 ストレージ アカウントあたり最大 10 GiB を優先的に取得して 1 時間ごとにリハイドレートできます。
アーカイブ済み BLOB をオンライン層にリハイドレートする方法については、「アーカイブ済み BLOB をオンライン層にリハイドレートする」を参照してください。
リハイドレートの優先度
BLOB をリハイドレートするときは、BLOB 層の設定または BLOB のコピー操作でオプションの x-ms-rehydrate-priority ヘッダーを使用して、リハイドレート操作の優先度を設定できます。 リハイドレート優先順位のオプションは次のとおりです。
- 標準優先度: リハイドレート要求は受信された順に処理され、サイズが 10 GB 以下のオブジェクトの場合、完了までに最大 15 時間かかることがあります。
- 高優先度: リハイドレート要求は標準優先度の要求よりも優先され、サイズが 10 GB 以下のオブジェクトの場合、1 時間以内に完了する可能性があります。
リハイドレートの進行中にその優先順位を確認するには、Get Blob Properties を呼び出して、戻り値の x-ms-rehydrate-priority ヘッダー値を参照します。 リハイドレートの優先度プロパティは標準または高を返します。
標準優先度は、アーカイブでの既定のリハイドレート オプションです。 高優先度のリハイドレートは高速ですが、標準優先度のリハイドレートよりもコストがかかります。 BLOB のサイズと現在の需要によっては、高優先度の処理にかかる時間が 1 時間を超える場合もあります。 Microsoft では、緊急データ復元の状況で使用するために、高優先度のリハイドレートの予約を推奨します。
標準の優先度のリハイドレート操作は保留中ですが、BLOB のリハイドレートの優先度設定を "高" に更新して、BLOB をより迅速にリハイドレートすることができます。 たとえば、大量の BLOB を一括でリハイドレートしている場合は、最初の操作ですべての BLOB に対して「標準」の優先度を指定しておき、後から、より迅速にオンラインにする必要がある個々の BLOB の優先度を「高」に上げることができます (1 時間あたり最大 10 GiB まで)。
保留中の操作では、リハイドレートの優先度設定を「高」から「標準」に下げることはできません。 リハイドレートの優先度設定を更新すると、課金に影響する場合があることに注意してください。
リハイドレートの優先度設定を設定および更新する方法については、「アーカイブ済み BLOB をオンライン層にリハイドレートする」を参照してください。
標準優先度と高優先度のリハイドレート要求の価格の違いの詳細については、「Azure Blob Storage の価格」を参照してください。
アーカイブ済み BLOB をオンライン層にコピーする
BLOB をアーカイブ層からオンライン層に移動するための最初のオプションは、アーカイブされた BLOB をホット、クール、またはコールドのいずれかの層にある新しい宛先 BLOB にコピーする方法です。 BLOB をコピーするには、BLOB のコピー操作を使用します。 アーカイブ済み BLOB をオンライン層の新しい BLOB にコピーすると、ソース BLOB は変更されないままアーカイブ層に残ります。
アーカイブされた BLOB は、別の名前の新しい BLOB または別のコンテナーにコピーする必要があります。 同じ BLOB にコピーして、ソース BLOB を上書きすることはできません。
BLOB をアーカイブ層からオンライン層にコピーすると、必要な 180 日の期間が経過する前に BLOB の階層をアーカイブ階層から変更した場合に評価される早期削除料金を回避できます。 詳しくは、「アーカイブ アクセス層」をご覧ください。
このオプションは、ストレージ アカウントに対して有効なライフサイクル管理ポリシーがあり、ポリシーの各 tierToArchive アクションに daysAfterLastTierChangeGreaterThan 条件が追加されていない場合にも有効です。 その場合、Set Blob Tier を使用して BLOB をリハイドレートすると、最終更新時刻がポリシーで設定されたしきい値を超えるため、ライフサイクル ポリシーによってリハイドレート後に BLOB がアーカイブ層に戻されるというシナリオが発生する可能性があります。 コピー操作では、ソース BLOB がアーカイブ層に残され、別の名前で新しい最終変更時刻の新しい BLOB が作成されるため、リハイドレートされた BLOB がライフサイクル ポリシーによってアーカイブ層に戻されるリスクはありません。
アーカイブ層からの blob のコピーは、選択されたリハイドレートの優先度によっては数時間かかることがあります。 BLOB コピー操作では、バックグラウンドでアーカイブ ソース BLOB が読み取られ、選択された移動先の層に新しいオンライン BLOB が作成されます。 リハイドレート操作が完了する前に親コンテナー内の BLOB の一覧を表示すると、新しい BLOB が表示される場合がありますが、その層はアーカイブに設定されます。 アーカイブ層のコピー元 BLOB からの読み取り操作が完了し、BLOB の内容がオンライン層の新しいコピー先 BLOB に書き込まれるまで、データは使用できません。 新しい BLOB は独立したコピーであるため、変更または削除しても、アーカイブ層のソース BLOB には影響しません。
BLOB をオンライン層にコピーしてリハイドレートする方法については、「コピー操作で BLOB をリハイドレートする」を参照してください。
重要
コピー先でコピーが正常に完了するまでは、コピー元 BLOB を削除しないでください。 コピー元 BLOB が削除された場合、コピー先 BLOB はコピーを完了できず、空になります。 コピー操作の完了で発生するイベントを処理して、ソース BLOB を削除しても安全な場合を確認できます。 詳細については、「BLOB のリハイドレート イベントの処理」を参照してください。
コピー先のオンライン層へのコピーによるアーカイブ済み BLOB のリハイドレートは、2021-02-12 より前のサービス バージョンについて、同じストレージ アカウント内でのみサポートされています。 サービス バージョン 2021-02-12 以降では、コピー先アカウントがコピー元アカウントと同じリージョンにある限り、異なるストレージ アカウントにコピーすることで、アーカイブされた BLOB をリハイドレートできます。 ストレージ アカウント間でリハイドレートすると、運用データとバックアップ データを別のアカウントに保持することで分離できます。 アーカイブされたデータを別のアカウントに分離すると、意図しないリハイドレートによるコストを軽減するのにも役立ちます。
コピー操作のターゲット BLOB は、オンライン層 (ホットまたはクール) にある必要があります。 アーカイブ済み BLOB は、アーカイブ層内にもあるコピー先 BLOB にコピーすることはできません。
次の表は、ソース BLOB とコピー先 BLOB の層に応じた BLOB コピー操作の動作を示しています。
| ホット層のコピー元 | クール層のコピー元 | アーカイブ層のコピー元 | |
|---|---|---|---|
| ホット層のコピー先 | サポートされています | サポートされています | バージョン 2021-02-12 以降では、同じリージョン内の異なるアカウント間でサポートされます。 それより前のバージョンでは、同じストレージ アカウント内でのみサポートされます。 BLOB のリハイドレートが必要です。 |
| クール層のコピー先 | サポートされています | サポートされています | バージョン 2021-02-12 以降では、同じリージョン内の異なるアカウント間でサポートされます。 それより前のバージョンでは、同じストレージ アカウント内でのみサポートされます。 BLOB のリハイドレートが必要です。 |
| アーカイブ層のコピー先 | サポートされています | サポート対象 | サポートされていません |
セカンダリ リージョンからのリハイドレート
読み取りアクセス geo 冗長ストレージ (RA-GRS) を使用するようにストレージ アカウントを構成した場合は、[BLOB のコピー] 操作を使用して、セカンダリ リージョン内の BLOB を同じセカンダリ リージョンにある別のストレージ アカウントにリハイドレートできます。 「セカンダリ リージョンからのリハイドレート」を参照してください。
セカンダリ リージョンへの読み取りアクセス権の取得に関する詳細については、「セカンダリ リージョンのデータへの読み取りアクセス」を参照してください。
BLOB のアクセス層をオンライン層に変更する
BLOB をアーカイブ層からオンライン層にリハイドレートする 2 つ目のオプションは、Set Blob Tier を呼び出して BLOB の層を変更する方法です。 この操作により、アーカイブされた BLOB の層をホットまたはクールに変更できます。
Set Blob Tier 要求が開始された後は、キャンセルできません。 リハイドレート操作中、BLOB のアクセス層の設定は、リハイドレート プロセスが完了するまでアーカイブ済みとして引き続き表示されます。 リハイドレート操作が完了すると、BLOB のアクセス層プロパティが更新され、新しい層が反映されます。
階層をオンライン層に変更して BLOB をリハイドレートする方法については、「その層を変更して BLOB をリハイドレートする」を参照してください。
注意事項
BLOB の層を変更しても、最後に変更された時刻には影響しません。 ストレージ アカウントに対するライフサイクル管理ポリシーが有効な場合、Set Blob Tier で BLOB をリハイドレートさせると、最終更新時刻がポリシーで設定された閾値を超えているため、ライフサイクル ポリシーによってリハイドレート後に BLOB がアーカイブ層に戻されるというシナリオが発生します。
このシナリオを回避するには、ポリシーの tierToArchive アクションに daysAfterLastTierChangeGreaterThan 条件を追加します。 または、「アーカイブ済み BLOB をオンライン層にコピーする」セクションの説明に従って、アーカイブ済み BLOB を代わりにコピーしてリハイドレートする方法もあります。 コピー操作を実行すると、最終更新時刻を更新された BLOB の新しいインスタンスが作成されるため、ライフサイクル管理ポリシーがトリガされることはありません。
BLOB リハイドレート操作の状態を確認する
BLOB のリハイドレート操作中に、Get Blob Properties 操作を呼び出して、その状態を確認できます。 リハイドレート操作の状態を確認する方法については、「リハイドレート操作の状態を確認する」を参照してください。
BLOB リハイドレートでイベントを処理する
アーカイブされた BLOB のリハイドレートには最大 15 時間かかる場合がありますが、リハイドレートが完了したかどうかを判断するために Get Blob Properties を繰り返しポーリングするのは非効率的です。 マイクロソフトでは、パフォーマンスとコストの最適化のために、Azure Event Gridを使用して、リハイドレードが完了したときに発生するイベントをキャプチャすることを推奨しています。
Azure Event Grid では、BLOB リハイドレートの完了時に Microsoft.Storage.BlobTierChanged イベントが発生します。
- Microsoft.Storage.BlobTierChanged イベントは、BLOB の層が変更されたときに発生します。 BLOB リハイドレートのコンテキストでは、このイベントは、宛先 BLOB のアクセス層がアーカイブ層からオンライン層 (ホット、クール、またはコールド層) に正常に変更されたときに発生します。 BLOB 層の設定操作を使用して、アーカイブされた BLOB のアクセス層を変更したり、BLOB のコピー操作を使用してアーカイブされた BLOB をオンライン層の新しいコピー先 BLOB にコピーしたりできます。
リハイドレート時にイベントをキャプチャして Azure Function のイベント ハンドラーに送信する方法については、「BLOB リハイドレート イベントに応答して Azure Function を実行する」を参照してください。
Blob Storage でのイベント処理の詳細については、「Azure Blob Storage のイベントに反応する」、「Event Grid のソースとしてのAzure Blob Storage」を参照してください。
価格と課金
Set Blob Tier を使用したリハイドレートは、データ読み取りトランザクションとデータ取得サイズで課金されます。 高優先度を使用すると、標準優先度と比較して、操作とデータ取得のコストが高くなります。 High 優先度のリハイドレートは、請求書に別の行の項目として表示されます。 10 GB 未満のアーカイブ BLOB を返す高優先度の要求で 5 時間以上かかった場合、高優先度の取得料金は課金されません。 ただし、Standard の取得料金は適用されます。
BLOB のコピーを使用してアーカイブ済み BLOB をオンライン層にコピーする場合は、データ読み取りトランザクションとデータ取得サイズに対して課金されます。 オンライン層での宛先 BLOB の作成は、データ書き込みトランザクションに対して課金されます。 ソース BLOB はアーカイブ層で変更されていないため、オンライン BLOB にコピーする場合、早期削除料金は適用されません。 優先順位の高い取得料金は、選択した場合に適用されます。
アーカイブ層の BLOB は、少なくとも 180 日間格納する必要があります。 180 日の期間が経過する前にアーカイブ済み BLOB のレベルを削除または変更すると、早期削除料金が発生します。 たとえば、BLOB をアーカイブ アクセス層に移動して、45 日後にそれを削除するかホット アクセス層に移動した場合、その BLOB を 135 (180 − 45) 日間アーカイブ アクセス層に保存する料金に相当する早期削除料金が発生します。 詳しくは、「アーカイブ アクセス層」をご覧ください。
ブロック BLOB とデータ ハイドレートの価格の詳細については、Azure Storage の価格に関するページを参照してください。 送信データ転送の価格の詳細については、データ転送料金の詳細に関するページを参照してください。