• 4 min read

Azure Archive Storage の機能強化でさらに高速、シンプル、便利に

Azure Archive Storage は 2017 年 12 月の提供開始以来、さまざまな業界からこれまでにないほどの関心を集め、革新的に活用されてきました。このスケーラブルなサービスを利用すれば、アクセス頻度のきわめて低いデータを長期にわたって低コストで保存できます。

Azure Archive Storage は、提供開始以来さまざまな業界からこれまでにないほどの関心を集め、革新的に活用されてきました。このスケーラブルなサービスを利用すれば、アクセス頻度のきわめて低いデータを長期にわたって低コストで保存できます。以前なら削除していたようなアプリケーションのバックアップ、診療記録、自動走行記録といったコールド データを、Azure Storage のアーカイブ層にオフライン状態で保存し、後から必要に応じてオンライン層にリハイドレートすることができます。今月初旬には、最もコスト効率の高いデータ ストレージ サービスを提供する取り組みの一環として、Azure Archive Storage の価格が一部のリージョンで最大 50% 引き下げ (英語) となり、さらにお求めやすくなりました。

Azure Storage チームは、皆様からお寄せいただいたフィードバックを基に改良を重ねてまいりました。そして本日、このサービスがもっと便利になる、アーカイブに関する 3 つの機能強化のパブリック プレビューを発表いたします。

1.Azure Archive からの優先取得

Azure Archive Storage に保存したデータを読み込むには、まず BLOB の層をホットまたはクールに変更する必要があります。このプロセスが「リハイドレート」と呼ばれ、完了までに数時間かかります。本日、アーカイブから優先的に取得する機能のパブリック プレビューをリリースします。これにより、オフライン データへのアクセスが大幅に高速化されます。この優先取得では、オフラインのアーカイブ層のデータをオンラインのホット層またはクール層に戻すリハイドレートを、高優先度のアクションとして設定することができます。わずかな追加料金を支払うことで優先的なリハイドレート処理が可能となり、アーカイブの取得要求が他の要求よりも優先され、オフライン データが通常 1 時間以内に返されます。

優先取得は、アーカイブのデータセットの一部を緊急で要求する場合に使用することをお勧めします。お客様のほとんどのユース ケースでは、15 時間以内に完了する標準のアーカイブ取得が利用されています。しかしまれに 1 時間以内の取得が必要になることもあります。優先取得を要求すると、標準の処理の数分の 1 の時間でアーカイブ層のデータを取得できます。このためお客様は、何事もなかったかのように速やかに業務を再開できます。詳細については、Blob Storage のリハイドレートに関するドキュメントをご確認ください。

現在、任意のパラメーターで利用できるリハイドレート優先オプションは以下の 2 つです。

  • Standard: 過去 2 年間アーカイブ層で提供されてきたリハイドレートに相当します。アーカイブの SetBlobTier 要求と CopyBlob 要求における既定のオプションであり、取得に最大 15 時間かかります。
  • High: 緊急でアーカイブのデータにアクセスしたいというニーズに応えるオプションで、10 GB 未満の BLOB なら通常 1 時間以内に完了します。

要求時にそのリージョン内で優先取得の需要が高いと、データのリハイドレート速度に影響が出ることもあります。ほとんど場合は、リハイドレート優先オプションが High の要求では、通常 1 時間もかからずにアーカイブのデータが返されます。まれなケースですが、アーカイブに対して膨大な量の優先度 High の要求が同時に送られた場合、その要求は依然として Standard よりも高い優先度で扱われますが、アーカイブのデータが返されるまでに 1 ~ 5 時間かかる可能性があります。さらに、きわめてまれなことですが、優先度 High の要求で、数 GB 未満のアーカイブ BLOB が返されるのに 5 時間を超えた場合、優先取得の料金は請求されません。

2.任意のアクセス層 (ホット、クール、アーカイブ) への BLOB の直接アップロード

General Purpose v2 アカウントと BLOB ストレージ アカウントでは、BLOB レベルの階層制御機能により、BLOB のアクセス層 (ホット、クール、アーカイブ) を同じコンテナー内で簡単に変更できます。ただし、これまではオブジェクトをコンテナーにアップロードすると、アカウントのアクセス層が引き継がれていたため、BLOB のアクセス層はアカウントの設定に応じて「ホット (推定)」または「クール (推定)」という表示となっていました。そのため、データの利用パターンの変化に合わせて BLOB のアクセス層を SetBlobTier API を使って手動で変更するか、BLOB のライフサイクル管理ルールで自動的に変更する必要がありました。

本日、任意のアクセス層に BLOB を直接アップロードする機能のパブリック プレビューをリリースします。これにより、Put Blob または Put Block List でオプション パラメーター x-ms-access-tier を使用して、任意のアクセス層に直接 BLOB をアップロードすることができます。アカウントの既定のアクセス層の設定にかかわらず、オブジェクトをホット、クール、アーカイブのいずれかの層に直接アップロードできます。この新機能により、1 つのトランザクションでオブジェクトを直接 Azure Archive に簡単にアップロードできるようになります。詳細については、Blob Storage のアクセス層のドキュメントをご覧ください。

3.CopyBlob の機能強化

特定のシナリオでは、元のデータはそのまま保持しつつ一時的なコピーで作業したいこともあります。特にアーカイブ層のデータはなおさら、読み込む必要があっても元のまま保持しておきたい場合があります。今回パブリック プレビューでリリースする CopyBlob の機能強化は、既存の CopyBlob API を基に、アーカイブ アクセス層のサポートを追加したほか、アーカイブからの優先取得、任意のアクセス層の直接指定が可能になりました。

CopyBlob API でアーカイブ アクセス層がサポートされるようになり、同じストレージ アカウント内でデータをアーカイブのアクセス層にコピーしたり、アーカイブのアクセス層からコピーしたりすることができます。アクセス層の指定に関する機能強化により、オプション パラメーター x-ms-access-tier を設定することで、データ コピーの継承先のアクセス層を指定できます。また、BLOB をアーカイブ層からコピーする場合に、x-ms-rehydrate-priority を指定して、継承先のホット層またはクール層にコピーを作成する優先度を設定できます。Blob Storage リハイドレートに関するドキュメントや、CopyBlob のアクセス層のサポートをまとめた以下の表をご覧ください。

 

ホット層 (コピー元)

クール層 (コピー元)

アーカイブ層 (コピー元)

ホット層 (コピー先)

サポート

サポート

同じアカウント内でサポート。リハイドレートについては保留

クール層 (コピー先)

サポート

サポート

同じアカウント内でサポート。リハイドレートについては保留

アーカイブ層 (コピー先)

サポート

サポート

サポート対象外

利用を開始するには

本日ご紹介したすべての機能 (アーカイブからの優先取得、任意のアクセス層への BLOB の直接アップロード、CopyBlob の強化) は、Azure Portal.NET クライアント ライブラリ (英語)Java クライアント ライブラリ (英語)Python クライアント ライブラリ (英語) の最新リリースでサポートされます。従来どおり、直接 Storage Services REST API (英語) (バージョン 2019-02-02 以降) を使用することもできます。一般的には、これらの新機能を使用するかどうかにかかわらず、最新バージョンの使用が推奨されます。

せひご利用になり、フィードバックをお寄せください。

引き続き Archive Storage と Blob Storage の改良に取り組んでまいります。これらの機能に関する皆様からのフィードバックをお待ちしております。ArchiveFeedback@microsoft.com までお気軽にお寄せください。新しいアイデアやご提案は Azure Storage フィードバック フォーラム (英語) から投稿していただけます。

Azure Storage チーム一同