0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@LimeSML

Azureを学ぶ Azure Blob Storage を調べる

0
Posted at

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

Azure Blob Storage を調べる

Microsoft Azure が提供する、画像やログなどの「形が決まっていないデータ（非構造化データ）」を保存するための巨大な倉庫。

1. 主な用途

  • コンテンツ配信：ブラウザへの画像・ドキュメント直接表示、動画・音声のストリーミング
  • データ保管：ログファイルの書き出し、バックアップ、アーカイブ（長期保存）
  • 分析用基盤：オンプレミスや Azure 上の解析サービスで使うデータの一次置き場

2. アクセス方法

  • どこからでもアクセス可能：世界中から HTTP/HTTPS 経由でデータにアクセスできる
  • 豊富な手段：REST API、PowerShell、Azure CLI のほか、プログラム用のライブラリが用意されている

3. ストレージアカウント（最上位の器）

  • 名前空間の提供：ストレージアカウントは、すべてのデータの最上位コンテナ
  • 一意の識別：アカウント名によって、世界中で唯一のアクセス用 URL（名前空間）が決まる

ストレージアカウントの種類

Azure Storage には、コスト重視の Standard と、速度重視の Premium がある。

1. Standard パフォーマンス（汎用 v2）
最も一般的で、幅広い用途に対応する標準タイプ。

  • 対象サービス：Blob, Queue, Table, Azure Files すべてに対応
  • 特徴：コストパフォーマンスに優れ、ほとんどのシナリオで第一選択となる
  • 冗長性：LRS（1拠点内）から GRS（遠隔地含む）まで、多様なデータ保護オプションを選択可能

2. Premium パフォーマンス
SSD（ソリッドステートドライブ）を使用し、低遅延・高速レスポンスを実現するタイプ。用途別に 3 種類のアカウントに分かれている。

種類 推奨される主なシナリオ
Premium ブロック BLOB 高頻度な読み書き、小さなデータの大量処理、一貫した低レイテンシが必要な場合。
Premium ファイル共有 高性能なファイル共有が必要な大規模エンタープライズ用途。
Premium ページ BLOB OS ディスクやデータベースなど、ランダム読み書きが激しい用途。

ブロック BLOB のアクセス層

データの「使う頻度」に合わせて保存場所（層）を選ぶことで、料金を最適化できる。

1. 4つのアクセス層
使用頻度が高いほど保存料が高く、低いほど保存料が安い。

  • ホット (Hot)：
    • 用途：頻繁に読み書きするデータ
    • 特徴：保存料は高いが、アクセス料（取り出し）が最も安い。初期設定はこれ
  • クール (Cool)：
    • 用途：月1回程度の低頻度アクセス。30日以上の保存が前提
    • 特徴：ホットより保存料が安く、アクセス料が高い
  • コールド (Cold)：
    • 用途：さらに低頻度。90日以上の保存が前提
    • 特徴：クールよりさらに保存料を抑えられるが、取り出し費用は高め
  • アーカイブ (Archive)：
    • 用途：ほぼアクセスしない長期バックアップ。180日以上の保存が前提
    • 特徴：保存料が極めて安い。ただし、データの取り出しに数時間の「解凍作業」が必要

2. 層の切り替え

  • 柔軟性：データの利用状況が変われば、いつでも層を変更可能
  • ライフサイクル管理：「作成から30日経ったらクールへ移動」といった自動化もできる

Azure Blob Storage リソースの種類を検出する

ストレージアカウント

Azure Storage 内のデータには、世界で唯一の「住所（URL）」が割り当てられる。

1. 一意の名前空間

  • アカウント名の重要性：ストレージアカウント名は Azure 全体で重複が許されない。この名前が URL の一部になるため
  • ベースアドレスの構成：「アカウント名」と「サービス固有のエンドポイント」を組み合わせて、データへの入り口が決まる

2. エンドポイントの構造（Blob の例）

  • 基本形式：http://(アカウント名).blob.core.windows.net
  • 具体例：アカウント名が mystorageaccount なら、URL は http://mystorageaccount.blob.core.windows.net となる

コンテナ

コンテナは、ストレージアカウント内でファイルを整理するための「フォルダ」のような役割。

1. 収容量と階層

  • 無制限：1つのストレージアカウント内に作成できるコンテナ数に制限はない
  • BLOBの保持：各コンテナ内には、無制限にファイルを保存できる

2. コンテナ名の命名規則（重要）
URL（URI）の一部になるため、DNSのルールに沿った正確な命名が必要。

  • 長さ：3文字以上、63文字以内
  • 使用可能文字：小文字、数字、ダッシュ（-）のみ
    • 大文字は使用不可
    • 先頭は文字か数字
  • 禁止事項：ダッシュを2つ以上連続させる（--）ことはできない

3. URI（アクセス用URL）の形式
コンテナを特定するための住所は以下のようになる。

BLOB

BLOBは、コンテナの中に保存される「ファイル本体」。用途に合わせて3つのタイプがある。

1. 3つのBLOBタイプ

  • ブロック BLOB (Block Blobs)：
    • 用途：一般的なファイル（画像、動画、ドキュメントなど）
    • 特徴：データを「ブロック」単位で管理。最大約190.7 TiBという超大容量まで対応
  • 追加 BLOB (Append Blobs)：
    • 用途：ログ記録（ロギング）
    • 特徴：既存データの末尾に新しいデータを「追記」することに特化している
  • ページ BLOB (Page Blobs)：
    • 用途：仮想マシンのディスク（VHDファイル）
    • 特徴：最大8 TB。ランダムな読み書き（特定箇所への素早いアクセス）に最適化されている

2. BLOB の住所 (URI)
ファイルへのアクセスは、以下の階層構造を反映したURLで行う。

  • 基本形式：https://[アカウント名].blob.core.windows.net/[コンテナ名]/[ファイル名]
  • 仮想ディレクトリ（フォルダ分け風）：https://[アカウント名].blob.core.windows.net/[コンテナ名]/[フォルダ名]/[ファイル名] ※実際にはフラットな構造だが、名前に / を入れることでフォルダ分けされているように見せられる

Azure Storage のセキュリティ機能を確認する

データ漏洩を防ぎ、セキュリティ基準を満たすための暗号化の仕組み。

1. サーバー側暗号化 (SSE: Server-Side Encryption)

  • 自動実行：データがクラウドに保存される際、ユーザーが意識することなく自動で暗号化される
  • 標準採用：Microsoft が推奨する最も一般的な方法
  • 目的：クラウド上の物理的なストレージにデータが残る際のセキュリティとコンプライアンス（法令順守）の確保

2. クライアント側暗号化 (Client-Side Encryption)

  • 実行場所: Azure に送信する前に、ユーザー側のアプリケーション（クライアントライブラリ）で暗号化する
  • 対象: Blob Storage と Queue Storage で利用可能
  • 目的: 「クラウド事業者にもデータの中身を見せたくない」など、より厳格なセキュリティ要件がある場合に使用

保存データに対する Azure Storage 暗号化

Azure Storage に保存されるすべてのデータは、意識せずとも強力な保護下に置かれる。

1. 暗号化の仕組み

  • 自動かつ透過的：データ保存時に自動で暗号化、読み取り時に自動で復号される
  • 強力なアルゴリズム：256ビット AES（米国連邦情報処理規格 FIPS 140-2 準拠）を採用。Windows の BitLocker に近い仕組み
  • 無効化不可：すべてのアカウントで強制有効。コード変更や特別な設定は一切不要

2. 対象範囲（すべてが対象）

  • データ種別：ブロック/追加/ページ BLOB、ファイル、キュー、テーブルのすべて
  • 階層・モデル：ホット/クール/アーカイブの各層、新旧すべてのデプロイモデル
  • メタデータ：ファイル本体だけでなく、付随する管理情報（メタデータ）も暗号化
  • 冗長性：セカンダリリージョンへの複製（geo レプリケーション）データも同様に保護される

3. コスト

  • 完全無料：セキュリティ機能としての追加料金は発生しない

暗号化キーの管理オプション

Azure Storage の暗号化に使う「鍵」を誰がどこで管理するか、3つの選択肢がある。

1. 3つの管理方式

  • Microsoft マネージド キー (既定)
    • 概要：Microsoft が鍵の作成・保管・更新（ローテーション）をすべて代行
    • メリット：管理の手間がゼロ。すべてのストレージサービスに適用
  • カスタマー マネージド キー (CMK)
    • 概要：ユーザーが Azure Key Vault 等に保存した自前の鍵を使用
    • メリット：鍵の更新タイミングなどを自分で制御できる。高いコンプライアンス要件に対応
  • カスタマー指定のキー (CPK)
    • 概要：読み書きの「リクエストごと」にクライアントが鍵を添えて送る方式
    • メリット：BLOB単位で極めて細かい制御が可能。鍵は Azure 側に保存されない

2. 機能比較まとめ

比較項目 Microsoft マネージド カスタマー マネージド (CMK) カスタマー指定 (CPK)
鍵の保管場所 Microsoft キー ストア Azure Key Vault / HSM お客様独自のストア
ローテーション責任 Microsoft お客様 お客様
対象サービス 全サービス Blob / Files Blob のみ
鍵の制御権 Microsoft お客様 お客様

クライアント側暗号化（Client-Side Encryption）

Azure に送信する前に手元のアプリで暗号化し、ダウンロードした後に復号する仕組み。

1. 概要と対応状況

  • 場所：クライアントアプリケーション内で処理を完結させる
  • 対応言語：.NET、Java、Python の各ライブラリ。
  • 対象サービス：Blob Storage（.NET, Java, Python）
    • Queue Storage（.NET, Python）
    • Table Storage（v1 のみ対応）

2. 利用可能な 2 つのバージョン
暗号化アルゴリズムはどちらも AES を使用するが、方式（モード）が異なる。

  • バージョン 2（推奨）：方式: AES-GCM (Galois/Counter Mode)
    • 特徴：最新の安全なモード。Blob と Queue で利用可能
  • バージョン 1：
    • 方式：AES-CBC (Cipher Block Chaining)
    • 特徴：従来からあるモード。Blob、Queue に加え Table でも利用可能

3. メリットと注意点

  • 高い機密性：Azure 側にデータが届く時点で既に暗号化されているため、クラウド事業者ですら中身を閲覧できない
  • 鍵管理の責任：暗号化に使う鍵はユーザー自身が管理する必要がある（Azure Key Vault 等の利用を推奨）
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?