Skip to content

MS_AzureStorage

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 2 revisions

Azureのストレージ

概要

Azureのストレージ。

ストレージの種類

種類 内容 エンドポイント
Blob エクサバイト単位の非構造化データ用オブジェクト ストレージ https://<account>.blob.core.windows.net
Table 大規模な半構造化データセットを使える NoSQL KVS https://<account>.table.core.windows.net
Queue 大容量のクラウド サービス向けの永続 Queue https://<account>.queue.core.windows.net
File SMBプロトコルでアクセスできる管理されたファイル共有 https://<account>.file.core.windows.net
Disk 仮想マシンのディスク（Azureのディスク ストレージ） －
Data Lake Blob をベースにしたビッグ データ分析専用の機能群 https://<account>.dfs.core.windows.net

Blob の 3 種類

種類 最適化 用途
ブロック Blob 大量データの効率的なアップロード 通常のファイル。最大 50,000 ブロック
追加 Blob 追加操作（末尾への追記のみ） ログ
ページ Blob ランダムな読み書き VHD（Disk として使用）
  • コンテナ: BLOB のセットを整理する論理的な入れ物。

補足（3 種類の選び分け）: 実務ではほぼブロック Blob を使う。

  • 追加 Blob は「ログを追記し続ける」用途に特化しており、
    ブロックの更新・削除ができない（改ざん防止にもなる）。
  • ページ Blob は VM のディスク用で、
    アプリから直接使うことは通常ない。

「とりあえず Blob」と言うときはブロック Blob を指す、と覚えてよい。

ストレージ・アカウント

Azure Storage データ オブジェクトの格納およびアクセスのための
一意の名前空間を提供する。

オプション

汎用ストレージ・アカウント

サービス：Blob、Table、Queue、File、Data Lake Storage

種別 内容
GPv1（汎用 v1） アクセス層を選択する機能がなく、すべてホット層扱い
GPv2（汎用 v2） GPv1 にアクセス層とストレージ・イベントなどを追加

アクセス層

# 層 説明
1 ホット 頻繁にアクセスされる普通のデータ向け
2 クール 30 日以上更新されないデータ向け
3 アーカイブ 180 日以上更新されないデータ向け（Blob 単体にのみ適用）

補足（アクセス層はコスト設計の要）: 階層によって
保管料と読み出し料が逆方向に動く。

層 保管料 読み出し料 取り出し時間
ホット 高い 安い 即時
クール 安い 高い 即時
コールド より安い より高い 即時
アーカイブ 最も安い 最も高い 数時間（リハイドレート）

「めったに読まない」データをホットに置き続けると保管料が無駄になり、
逆に頻繁に読むデータをアーカイブに置くと
読み出し料が保管料の節約を上回る。

ライフサイクル管理ポリシーで
「30 日でクール、180 日でアーカイブ」といった自動移行を組むのが定石である。
なお、アーカイブは即座には読めない（数時間）点が
バックアップ設計に影響する。

その他のアカウント種別

種別 サービス 冗長オプション
BlobStorage（従来の BLOB 専用） ブロック / 追加 BLOB のみ LRS / ZRS / GRS
BlockBlobStorage（Premium） ブロック / 追加 BLOB のみ LRS / ZRS
FileStorage（Premium） File LRS / ZRS

移行メモ（表記）: 元ページは「BlockStorage アカウント」と
記しているが、従来の BLOB 専用アカウントの正しい種別名は
BlobStorage である（Premium 版が BlockBlobStorage）。

タイプ（Standard / Premium）

媒体 用途
Standard 磁気媒体（HDD） あらゆるタイプのデータ。開発/テスト、アクセス頻度の少ないワークロード
Premium SSD ハイパフォーマンスのストレージ

推奨の組合せ

組合せ サービス 冗長オプション
Standard GPv2 Blob / Table / Queue / File / Data Lake LRS / ZRS / GRS / GZRS / RA-GRS / RA-GZRS
Premium ブロック BLOB ブロック Blob のみ LRS / ZRS
Premium ファイル共有 File のみ LRS / ZRS
Premium ページ BLOB ページ Blob のみ LRS

補足（迷ったら Standard GPv2）: 選択肢が多いが、
特別な要件が無ければ Standard GPv2 一択である。
全サービスが使え、全冗長オプションが選べ、アクセス層も使える。
GPv1 は新規に選ぶ理由が無い（機能が少ないだけで安くもない）。

その他のトピック

データ冗長オプション

各オプション環境下で、3 多重化される。

略称 名称 内容
LRS ローカル冗長ストレージ 1 つのデータセンター内で 3 多重化（ラック分散）
ZRS ゾーン冗長ストレージ 3 つの可用性ゾーンに分散
GRS Geo 冗長ストレージ LRS + 別リージョンに非同期複製
GZRS Geo ゾーン冗長 ZRS + 別リージョン
RA-GRS 読み取りアクセス Geo 冗長 GRS + セカンダリを読み取り可能
RA-GZRS － GZRS + 同上

補足（RA- が付くかどうかが重要）: GRS でセカンダリにコピーは
されているが、RA- が無いとセカンダリを読めない。

障害時にできること
GRS Microsoft がフェールオーバーを実施するまで何もできない
RA-GRS すぐにセカンダリから読める（読み取り専用）

「リージョン障害でも参照系だけは継続したい」なら RA- が必要になる。
また、GRS の複製は非同期なので、
障害時に直近のデータが失われうる（RPO がゼロではない）点も
設計上の前提になる。

ツール

  • Storage Explorer（GUI）
  • azcopy（コマンドライン。大量転送に最適化）

認証・認可

方式 内容
RBAC Entra ID の ID にロールを割り当てる。推奨
SAS トークン（トークン） 期限・権限を絞った URL 署名（バレット キー パターン）
ストレージ・キー アカウント全体へのフル アクセス。取り扱い注意

補足（ストレージ キーは避ける）: 3 つのうち、
ストレージ キーは最後の手段である。

権限の粒度 失効 監査
ストレージ キー アカウント全体（全削除も可能） キー再生成のみ（全アプリに影響） 誰が使ったか分からない
SAS 絞れる 期限で自動失効 △
RBAC + マネージド ID 細かく絞れる ID を無効化するだけ Entra ID のログに残る

Key Vaultで述べたのと同じ理由で、
マネージド ID + RBAC が第一選択になる。
ストレージ キーは「そもそも保存しない」構成を目指す。

なお、SAS はクラウド設計パターンの
バレット キー パターンの実装であり、
「大きなファイルをアプリ経由で中継しない」ために有効である。

参考

Microsoft Learn

Tags: 移行, インフラストラクチャ, クラウド, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally