第 6 章 ストレージを実装して管理する（15〜20%）
Azure Files と Azure Blob Storage
この章で学ぶこと
- Azure Files でファイル共有を作成して構成する
- Azure Blob Storage でコンテナーを作成して構成する
- ストレージ層を構成する
- BLOB とコンテナーの論理的な削除を構成する
- Azure Files のスナップショットと論理的な削除を構成する
この章に出てくる用語
- Azure Blob Storage
- 大きさも形も決まっていないデータを、名前を付けて置いておくためのサービス。 BLOB は Binary Large Object の略。フォルダー階層を持つファイルシステムではなく、「コンテナー」という入れ物の中に、名前でファイルを出し入れする作りになっている。画像・動画・ログ・バックアップなど、置いて取り出すだけの用途に向く。
- Azure Files
- Windows の共有フォルダーと同じ使い勝手の、クラウド上のファイル共有。 SMB や NFS でマウントできるので、既存のアプリケーションからはネットワークドライブとしてそのまま見える。Blob と違い、フォルダー階層があり、複数のサーバーから同時にマウントできる。ファイルサーバーの置き換えに使う。
Blob Storage は、ストレージアカウントの中にコンテナーを作り、その中に BLOB を置く。コンテナーにはパブリックアクセスレベルがあり、3 段階から選ぶ。
| レベル | 匿名で何ができるか |
|---|---|
| プライベート（既定） | 匿名アクセス不可。認可が必要 |
| BLOB | BLOB を名前で指定すれば匿名で読める。一覧はできない |
| コンテナー | BLOB の一覧も匿名で読める |
BLOB そのものにも 3 種類ある。使い分けは用途で決まる。
| 種類 | 用途 | 特記 |
|---|---|---|
| ブロック BLOB | 文書・画像・動画など一般的なファイル | アクセス層を設定できるのはこれだけ |
| 追加 BLOB | ログのように末尾へ追記していく用途 | 途中の書き換えには向かない |
| ページ BLOB | ランダムな読み書き | アンマネージドディスクの実体 |
アクセス層は「置いておく値段」と「出すときの値段・速さ」のトレードオフだ。安く置ける層ほど、最低限置いておかなければならない期間が長くなる。
| ホット | クール | コールド | アーカイブ | |
|---|---|---|---|---|
| オンライン / オフライン | オンライン | オンライン | オンライン | オフライン |
| 最小保持期間 | なし | 30 日 | 90 日 | 180 日 |
| 取り出しの待ち時間 | ミリ秒 | ミリ秒 | ミリ秒 | 最大 15 時間 |
| 既定アクセス層に設定 | できる | できる | できる | できない |
| 使える冗長性 | すべて | すべて | すべて | LRS / GRS / RA-GRS のみ |
試験では
クールが 30 日、コールドが 90 日。 名前が似ているので取り違えやすい。「めったに読まないが、読むときはすぐ欲しい」ならコールド、「読まない。待てる」ならアーカイブ。
アーカイブ層の BLOB を読むには、オンライン層に戻すリハイドレートが必要で、優先度は標準と高の 2 つ。標準で最大 15 時間かかる。
試験では
最小保持期間より前に削除・上書き・層の移動をすると、早期削除ペナルティとして残り日数分が日割りで課金される。「アーカイブに入れてすぐ消したのに課金された」の理由はこれ。
「最終更新から 30 日でクールへ、90 日でアーカイブへ、365 日で削除」といったルールを自動で実行する機能。手で層を移す必要がなくなる。
試験では
ライフサイクル管理ではリハイドレート（アーカイブからの復帰）はできない。下げる方向にしか動かせない。対象はブロック BLOB と追加 BLOB で、ページ BLOB は対象外。
名前が似た機能が並ぶので、何を守るのかで整理する。
| 機能 | 守る対象 | 既定 |
|---|---|---|
| BLOB の論理的な削除 | 削除・上書きされた BLOB、スナップショット、バージョン | 無効（1〜365 日で設定） |
| コンテナーの論理的な削除 | 削除されたコンテナーそのもの | 無効（別に有効化する） |
| BLOB のバージョン管理 | 上書き前の状態を自動で保持 | 無効 |
| スナップショット | ある時点の状態を手動で作成 | — |
試験では
BLOB の論理的な削除では、削除されたコンテナーは復元できない。 コンテナーを守りたければ「コンテナーの論理的な削除」を別に有効にする。ここが最も定番の引っかけ。
試験では
バージョン管理は自動、スナップショットは手動。「意識せずに上書き前の状態を残したい」ならバージョン管理、「このタイミングの状態を取っておきたい」ならスナップショット。
補足
論理的な削除の保持期間は 1〜365 日で指定でき、推奨される最小は 7 日。バージョン管理を有効にするとバージョンが増え続けてコストになるので、ライフサイクル管理で古いバージョンを整理するのがセットで使われる。
Azure Files は SMB / NFS でマウントできるマネージドなファイル共有だ。Blob と違い、既存のアプリケーションからネットワークドライブとして見える。
スナップショットと論理的な削除
ファイル共有のスナップショットは、共有全体のある時点の読み取り専用コピーで、増分で保存されるため容量効率がよい。論理的な削除も用意されている。
試験では
Azure Files の論理的な削除が守るのはファイル共有そのものであって、共有の中の個々のファイルではない。「誤って消したファイルを戻したい」→ スナップショットから復元する。
Azure File Sync
オンプレミスの Windows ファイルサーバーと Azure Files を同期し、オンプレ側をキャッシュとして使える機能。
試験では
「オンプレのファイルサーバーの容量を減らしたい」→ クラウド階層化。使用頻度の低いファイルの実体をクラウドだけに置き、オンプレにはポインターだけを残す。利用者から見え方は変わらない。
大きなファイル共有
ファイル共有の上限を 100 TiB まで拡張する設定。
試験では
大きなファイル共有を有効にすると、そのストレージアカウントは GRS / GZRS に変換できなくなる。「容量を増やしたら geo 冗長にできなくなった」という筋書きの原因。
# コンテナーを作る
az storage container create --name data \
--account-name <名前> --public-access off
# BLOB のアクセス層を変える
az storage blob set-tier --tier Cool \
--container-name data --name file.txt
# ファイル共有を作る
az storage share-rm create --name share1 \
--storage-account <名前> --quota 1024この章のまとめ
- アクセス層を設定できる BLOB の種類
- クール層の最小保持期間
- コールド層の最小保持期間
- アーカイブ層の最小保持期間
- アーカイブのリハイドレートにかかる最大時間
- アカウントの既定アクセス層に設定できない層