本記事は Microsoft Learn の「Azure Blob Storage の構成」というモジュールをまとめたものである。

Azure Blob ストレージを実装する

Azure Blob Storage は、非構造化データを BLOB（Binary Large OBject）としてクラウドに保存するオブジェクトストレージサービス。

Azure Blob Storage について知っておくべきこと

Azure Blob Storage は、テキストや画像、動画、アプリケーションなど任意の非構造化データを格納できる。データは、ストレージアカウント → コンテナー → BLOB という階層で管理される。実装には、コンテナー設定、BLOB の種類・アップロード方法、アクセス層、ライフサイクルルール、レプリケーションオプションなどの構成が必要となる。

Azure Blob Storage を実装する際に考慮すべき事項

Azure Blob Storage の主な用途は以下の通り：

ブラウザー向け配信：画像やドキュメントを直接提供
分散アクセス：インストーラーや共有ファイルなどの分散アクセス用データの格納
データストリーミング：ビデオやオーディオのストリーミング配信
アーカイブ・回復：バックアップ、復元、ディザスターリカバリー用データの保存
アプリケーションアクセス：オンプレミスや Azure サービスによる分析や利用用のデータ格納

BLOB コンテナーを作成する

Azure Blob Storage では、BLOB は必ずコンテナーに格納され、コンテナーを使って複数の BLOB をグループ化する。BLOB は単独で存在できない。

コンテナーと BLOB について知っておくべきこと

BLOB とコンテナーの特性は以下の通り：

すべての BLOB は必ず 1 つのコンテナーに属する
コンテナーは BLOB の整理単位となる
コンテナー内に格納できる BLOB の数は無制限
1 つのストレージアカウントに作成できるコンテナーの数も無制限
データのアップロード前に、コンテナーを作成する必要がある

コンテナーの構成

Azure ポータルでは、ストレージアカウント内でコンテナーを作成する際に設定を構成できる。作成時には、コンテナー名やアクセスレベルなどの詳細を確認し、自身の用途に応じた構成を検討する必要がある。

コンテナー名のルール：

ストレージアカウント内で一意であること
使用できる文字は小文字、数字、ハイフンのみ
先頭は文字または数字で始める
長さは 3〜63 文字

コンテナーのパブリックアクセスレベル：

非公開（既定）：コンテナーと BLOB への匿名アクセスを禁止
BLOB：BLOB のみ匿名で読み取り可能
コンテナー：コンテナー全体（BLOB を含む）を匿名で読み取り・リスト可能

BLOB アクセス層を割り当てる

Azure Storage では、BLOB データに対して複数のアクセス層があり、データ使用パターンに応じて最適化されている。主なアクセス層は ホット、クール、コールド、アーカイブ。

ホットアクセス層

頻繁に読み書きされるデータ向け。アクティブに利用されるオンラインデータの保存に最適。ストレージコストは高いが、アクセスコストは低い。

クールアクセス層

アクセス頻度が低いデータ向け。30日以上保存されるデータに最適で、短期バックアップやディザスターリカバリー、古いメディアコンテンツなどに適用。ストレージコストはホット層より安いが、アクセスコストは高め。

コールドアクセス層

アクセス頻度の低いデータ向け。少なくとも 90 日間保存されるデータに最適で、クール層よりもストレージコストが低く、アクセスコストは高め。

アーカイブアクセス層

数時間の取得待機が許容されるデータ向けのオフライン層。データは少なくとも 180 日間保持する必要があり、セカンダリバックアップや法的コンプライアンス情報、元の生データなどに適用。ストレージコストは最も低いが、アクセスコストは高い。

BLOB の内容は直接読み書きできず、アクセスには リハイドレート でホット・クール・コールド層に移行する必要がある
メタデータやインデックスタグへのアクセスは可能

アクセス層の比較

Azure Blob Storage のアクセスオプションは、ストレージコストや利用パターンに応じて最適化できる複数の機能とサポートレベルを提供する。アプリケーションのデータ使用パターンに合ったアクセス層やオプションを選ぶことで、コスト効率とパフォーマンスを両立できる。

比較項目	ホットアクセス層	クールアクセス層	コールドアクセス層	アーカイブアクセス層
可用性	99.9%	99%	99%	99%
可用性 (RA-GRS 読み取り)	99.99%	99.9%	99.9%	99.9%
待機時間 (最初のバイトまでの時間)	ミリ秒	ミリ秒	ミリ秒	時間
最小ストレージ期間	N/A	30 日	90 日間	180 日間

BLOB ライフサイクル管理規則を追加する

データは作成直後はよく使われるものの、時間が経つとほとんどアクセスされなくなることが多い。Azure Blob Storage では、ライフサイクル管理機能を使って、データの利用状況に応じて自動でアクセス層を変えたり、不要になったデータを期限切れで削除したりできる。

ライフサイクル管理について知っておくべきこと

Azure Blob Storage の ライフサイクル管理ポリシー では、次のようなことが可能：

アクセス層の自動移行：データ使用状況に応じて、ホット → クール、ホット → アーカイブ、クール → アーカイブなどに切り替えてコスト最適化
データの自動削除：ライフサイクル終了時に、BLOB の現在バージョン、以前のバージョン、スナップショットを削除
ルールの適用範囲指定：ストレージアカウント全体、一部のコンテナー、BLOB 名のプレフィックス、インデックスタグなどで対象を絞り込んでルールを適用

ライフサイクル管理ポリシールールを構成する

Azure ポータルでは、ストレージアカウントのライフサイクル管理ポリシーを設定する際に、複数の条件とアクションを組み合わせた If - Then ブロック を作成できる。これにより、データの使用状況や有効期限に応じて自動でアクセス層を変更したり削除したりできる。設定時には、自分のデータセットに最適なルールをどう組むかを検討することが重要。

Azure Blob Storage のライフサイクル管理ポリシーでは、If - Then ブロックで条件とアクションを指定する。

If 句：評価条件を設定。指定した日数以上アクセスや変更がなかった BLOB を対象にする。
Then 句：条件が true の場合に実行されるアクション。主なアクションは以下：
- クール層に移動：BLOB をクールストレージに移行
- コールド層に移動：BLOB をコールドストレージに移行
- アーカイブ層に移動：BLOB をアーカイブストレージに移行
- 削除：BLOB を削除

データの古さに応じて自動的にストレージ層を調整することで、コスト効率の高いストレージ運用が可能になる。

BLOB オブジェクトレプリケーションを決定する

オブジェクトレプリケーションでは、構成したポリシーに基づき、コンテナー内の BLOB を非同期でコピーできる。コピーされるのは BLOB の コンテンツ、メタデータ、バージョン で、リージョン間での非同期レプリケーションも可能。

BLOB オブジェクトのレプリケーションについて知っておくべきこと

BLOB オブジェクトのレプリケーションを計画する際のポイント：

バージョン管理必須：ソースと宛先の両方で BLOB のバージョン管理を有効にする必要がある。以前のバージョンにアクセスできるため、変更や削除されたデータを復旧可能
スナップショット非対応：BLOB のスナップショットはレプリケーションされない
アクセス層の互換性：ホット、クール、コールド層間でのレプリケーションが可能。コピー元とコピー先が異なる層でも問題なし
レプリケーションポリシー作成：コピー元とコピー先のストレージアカウントを指定するポリシーを作成
ルールの設定：ポリシーには、コピー元とコピー先のコンテナーを指定する 1 つ以上のルールが含まれ、レプリケート対象の BLOB を識別す

BLOB オブジェクトレプリケーションを構成するときに考慮すべきこと

BLOB オブジェクトレプリケーションの利点と活用シナリオ：

待機時間の短縮
- データを物理的に近いリージョンにレプリケートすることで、読み取り要求の待ち時間を減らせる
コンピューティングワークロードの効率化
- 異なるリージョンで同じ BLOB セットを処理できるため、ワークロードの分散と効率向上に役立つ
データ分散
- データを 1 つの場所で処理・分析し、必要に応じて結果のみ他のリージョンにレプリケートすることで、効率的なデータ分散が可能
コスト最適化
- レプリケート後にライフサイクル管理ポリシーでデータをアーカイブ層に移動することで、ストレージコストを削減できる

BLOB を管理する

Azure Blob Storage では、あらゆる種類やサイズのデータを格納可能で、BLOB の種類は以下の 3 種類：

ブロック BLOB
- データをブロック単位で構成し、それらを組み立てて BLOB を作成
- ほとんどのシナリオで使用され、ファイル、画像、動画などのテキスト・バイナリデータの格納に最適
- 新しい BLOB の既定の種類で、特に指定がなければブロック BLOB として作成される
追加 BLOB
- ブロック BLOB に似ており、データのブロックで構成される
- 追記操作に最適化されており、ログ記録のようにデータが増加していくシナリオに適用
ページ BLOB
- 最大サイズ 8 TB
- 読み書き操作を頻繁に行う場合に効率的
- Azure 仮想マシンの OS ディスクやデータディスクに使用される

BLOB ストレージを管理するときに考慮すべきこと

Azure ポータルでは、少数のファイルを対象に BLOB のアップロードや管理 が可能。アップロード時には次を設定できる：

BLOB の種類とブロックサイズ
保存先のコンテナーやフォルダー
アクセス層（ホット、クール、コールド、アーカイブ）
暗号化スコープ

大量のファイルを扱う場合は、Azure ポータルより 専用ツールの利用 が推奨される。ニーズに応じて、最適なツールを選択して構成を検討するとよい。

大量データのアップロードや管理には、次のツールやサービスが利用可能：

Azure Storage Explorer
- BLOB、ファイル、キュー、テーブル、Data Lake Storage、マネージドディスクの操作が可能
- データのアップロード・ダウンロード・管理、プレビュー、アクセス許可やアクセス制御の設定も行える
AzCopy
- Windows と Linux 向けのコマンドラインツール
- コンテナーやストレージアカウント間での高速データコピーに最適
Azure Data Box Disk
- ネットワーク経由のアップロードが非現実的な大規模データセット向け
- Microsoft から SSD ディスクを受け取り、データをコピーして返送することで BLOB ストレージにアップロード可能

Blob Storage の価格を決定する

Azure Blob Storage のコスト管理では、アクセスパターンを理解し、データの持続性や可用性のニーズと関連付けることが重要。

料金に影響する主な要素
- 月間の保存データ量
- 実行する操作の種類と回数、およびデータ転送コスト
- 選択したデータ冗長オプション
コスト見積もりツール
- Azure 料金計算ツールを使うと、ワークロードに基づいて移行や毎月のコスト、将来の価格を計算できる

Blob Storage の価格について知っておくべきこと

Azure Blob Storage の課金に関する主な考慮事項：

パフォーマンスレベル
- ストレージ層（ホット、クール、アーカイブ）によって、ギガバイトあたりの格納コストが変動
- クール層になるほど、保存コストは低くなる
データアクセスコスト
- クール層やアーカイブ層では、データの読み取りごとにギガバイト単位で料金が発生
トランザクションコスト
- すべての層で操作ごとの料金が発生し、クール層ほど高くなる
Geo レプリケーションデータ転送コスト
- GRS（Geo-Redundant Storage）や RA-GRS（Read-Access GRS）を構成している場合に適用
- ギガバイト単位で課金される
送信データ転送コスト
- 帯域幅に応じてギガバイト単位で課金される
ストレージ層の変更コスト
- クール → ホット：既存データの読み取り相当の料金が発生
- ホット → クール：既存データの書き込み相当の料金が発生（GPv2 アカウントのみ）

パブリック Web サイトのストレージを提供する

この会社のウェブサイトでは、製品の画像や動画、マーケティング資料、顧客の成功事例を公開している。利用者は世界中に広がっており、需要は急速に拡大している。コンテンツは事業にとって極めて重要で、低レイテンシでの読み込みが求められる。さらに、ドキュメントのバージョンを追跡し、削除された場合でも迅速に復元できることが重要となる。

アーキテクチャ図

ストレージアカウントの作成（高可用性 + 公開用サイト対応）

Azure ポータルで検索
- ポータルで「Storage accounts」を検索し選択
新規作成
- 「+ Create」をクリック
リソースグループ
- 「新規作成」を選び、名前をつけて OK
ストレージアカウント名
- 名前を publicwebsite に設定
- グローバルで一意にするために識別子を追加（例: publicwebsite12345）
その他の設定
- デフォルトを利用
確認と作成
- 「Review」→「Create」を選択
デプロイ完了後
- 「Go to resource」をクリックし、作成したストレージアカウントに移動

高可用性とセカンダリリージョンの読み取り有効化（RA-GRS 設定）

作成した Storage account を開く
左メニューの Data management セクションから Redundancy を選択
冗長性のオプションで Read-access geo-redundant storage (RA-GRS) を選択
- これにより、プライマリリージョンで障害が発生した場合でも、セカンダリリージョンから読み取りが可能になる
画面に表示される Primary location と Secondary location の情報を確認

パブリックアクセスの有効化（匿名アクセス設定）

ストレージアカウントを開く
左メニューの Settings セクションから Configuration を選択
Allow blob anonymous access を Enabled に設定
- これにより、利用者はログインせずに公開コンテンツへアクセスできる
Save をクリックして変更を反映

公開用コンテンツのコンテナー作成

ストレージアカウントを開く
左メニューの Data storage セクションから Containers を選択
+ Container をクリック
Name に public を入力
Create を選択

コンテナーの匿名読み取りアクセスを有効化

ストレージアカウントを開き、Containers に移動
作成した public コンテナーを選択
左メニューの Overview ブレードで Change access level をクリック
Public access level を Blob (anonymous read access for blobs only) に設定
- これで、コンテナー内の BLOB（画像やドキュメント）はログイン不要で閲覧可能
- コンテナー一覧は公開されない
OK を選択して保存

公開コンテナーへのファイルアップロード（テスト用）

ストレージアカウントを開き、Containers から public コンテナーを表示
上部メニューで Upload を選択
Browse for files をクリックし、任意のファイル（小さな画像やテキストファイルなど）を選択
Upload をクリックしてアップロード実行
アップロード完了後、ウィンドウを閉じて Refresh を押し、ファイルがコンテナーに追加されたことを確認

アップロードしたファイルの URL を確認・テストする

public コンテナーを開き、アップロードしたファイルを選択
Overview タブを表示
表示される URL をコピー
コピーした URL をブラウザの新しいタブに貼り付けて開く
- 画像ファイルならブラウザ上に表示される
- テキストやその他のファイルならダウンロードが始まる

BLOB のソフトデリート（削除復元）を有効化

ストレージアカウントを開き、Overview ブレードを表示
Properties ページで Blob service セクションを探す
Blob soft delete 設定を選択
Enable soft delete for blobs にチェックを入れる
Keep deleted blobs for (in days) を 21 に設定
- 必要に応じて Enable soft delete for containers も有効化可能
Save をクリックして設定を反映

ソフトデリートを使って削除ファイルを復元する手順

public コンテナーを開き、アップロードしたファイルを選択
Delete をクリックし、確認ダイアログで OK を選択して削除
コンテナーの Overview ページで、検索ボックス右側の Show deleted blobs スライダーをオンにする
削除されたファイルを選択し、右端の …（省略メニュー） から Undelete を選択
コンテナーを Refresh して、ファイルが復元されていることを確認

BLOB のバージョン管理（Versioning）を有効化

ストレージアカウントを開き、Overview ブレードを表示
Properties セクションで Blob service を探す
Versioning 設定を選択
Enable versioning for blobs にチェックを入れる
- 必要に応じて、古いバージョンをすべて保持するか、一定期間後に削除するかを設定可能
Save をクリックして変更を反映

BLOB バージョンの復元を試す

public コンテナーの既存ファイルを上書きする形で、別のバージョンのファイルをアップロード
アップロードすると、元のファイルは新しいバージョンとして上書きされる
コンテナーの Show deleted blobs ページで、以前のファイルバージョンが一覧として確認可能
必要に応じて、古いバージョンを選択して Restore することで復元できる