第 5 章 ストレージを実装して管理する（15〜20%）
ストレージアカウントを構成して管理する
この章で学ぶこと
- ストレージ アカウントの作成および構成
- Azure Storage の冗長性を構成する
- オブジェクト レプリケーションの構成
- ストレージ アカウントの暗号化を構成する
- Azure Storage Explorer と AzCopy を使用してデータを管理する
この章に出てくる用語
- ストレージアカウント
- Azure Storage を使うための器であり、課金と設定の単位。 名前（世界中で一意）、リージョン、冗長性、性能のグレードをここで決める。Blob のコンテナーやファイル共有は、すべてこの器の中に作る。エンドポイントは
https://<アカウント名>.blob.core.windows.netのような形になる。
最初に選ぶのがアカウントの種類だ。実務でも試験でも、特に指定がなければ Standard 汎用 v2 が答えになる。Blob・ファイル・キュー・テーブルをすべて扱え、アクセス層も冗長性も一通り選べるからだ。
| 種類 | 扱えるもの | 使える冗長性 | こう聞かれたら |
|---|---|---|---|
| Standard 汎用 v2 | Blob / Files / Queue / Table | すべて | 特に指定がなければこれ |
| Premium ブロック BLOB | ブロック BLOB | LRS / ZRS のみ | 高トランザクション・低遅延 |
| Premium ファイル共有 | Azure Files | LRS / ZRS のみ | SSD の高性能ファイル共有 |
試験では
Premium 系は LRS と ZRS しか使えない。「高性能で、かつ別リージョンにもコピーしたい」という要件はそのままでは満たせない点に注意する。
冗長性は「コピーをどこに置くか」で決まる。同じデータセンターの中だけか、複数の可用性ゾーンか、別リージョンまでか。
| コピー先 | ゾーン障害 | リージョン障害 | セカンダリ読み取り | 持続性 | |
|---|---|---|---|---|---|
| LRS | 1 データセンターに 3 つ | × | × | × | 9 が 11 個 |
| ZRS | 3 つ以上の可用性ゾーン | ○ | × | × | 9 が 12 個 |
| GRS | LRS ＋ 別リージョン | × | ○（要フェールオーバー） | × | 9 が 16 個 |
| RA-GRS | GRS と同じ | × | ○ | ○ | 9 が 16 個 |
| GZRS | ZRS ＋ 別リージョン | ○ | ○（要フェールオーバー） | × | 9 が 16 個 |
| RA-GZRS | GZRS と同じ | ○ | ○ | ○ | 9 が 16 個 |
覚え方は単純だ。先頭の G が付けば別リージョンへ、Z が入ればゾーン分散、RA- が付けばセカンダリを読める。この 3 つの文字の意味がわかれば組み合わせで理解できる。
試験では
GRS / GZRS のセカンダリは、フェールオーバーしない限り読めない。「普段からセカンダリを読んで負荷分散したい」なら RA- が付いたものを選ぶ。セカンダリのエンドポイントは名前の末尾に -secondary が付く。
アカウントのフェールオーバー
プライマリのリージョンが復旧不能になったとき、セカンダリをプライマリに昇格させる操作。レプリケーションは非同期なので、直近の書き込みが失われる可能性がある。この失われうる時間差を RPO（回復ポイントの目標） と呼ぶ。
ここは覚えることが少ない。出発点は「常に有効」だ。
試験では
保存時の暗号化（SSE）は無効にできない。「暗号化を有効にする」という選択肢は、そもそも前提が間違っている。選べるのは鍵の持ち主（Microsoft か自分か）と、もう一段重ねるかどうかだけ。
試験では
インフラストラクチャ暗号化はアカウント作成時にしか有効にできない。「既存のアカウントで二重暗号化を有効にしたい」→ できない。作り直しになる。
補足
カスタマーマネージドキー（CMK）は Azure Key Vault に置く。鍵のローテーションや失効を自分で制御したい、コンプライアンス要件で鍵の管理責任を持つ必要がある、という場合に選ぶ。
あるストレージアカウントのコンテナーから、別のアカウントのコンテナーへブロック BLOB を非同期でコピーする機能だ。冗長性（同じアカウントの中の話）とは別物なので混同しないこと。
試験では
前提条件が問われる。コピー元とコピー先の両方で「BLOB のバージョン管理」と「変更フィード」が有効になっている必要がある。対象はブロック BLOB だけ。
補足
使いどころは「書き込みは東日本、読み取りは利用者の近くの西日本から」といった読み取り遅延の削減や、分析用に別アカウントへ集約する、といったケース。災害対策としての冗長性とは目的が違う。
| ツール | 形態 | こう聞かれたら選ぶ |
|---|---|---|
| AzCopy | コマンドライン | スクリプトで自動化したい／大量データを高速に |
| Azure Storage Explorer | デスクトップ GUI アプリ | 画面で見ながら操作したい |
# ストレージアカウントを作る （PowerShell: New-AzStorageAccount）
az storage account create --name <名前> \
--resource-group rg --sku Standard_GRS \
--kind StorageV2
# ローカルから BLOB へコピーする
azcopy copy "C:\data\*" \
"https://<名前>.blob.core.windows.net/<コンテナー>?<SAS>" \
--recursive
# 差分だけ同期する
azcopy sync <ソース> <宛先> --delete-destination=true補足
AzCopy の認証は SAS か Microsoft Entra ID（azcopy login）で行う。スクリプトに書くならユーザー委任 SAS か、マネージド ID を使うのが安全。
この章のまとめ
- 特に指定がないときに選ぶアカウントの種類
- Premium 系で使える冗長性
- ゾーン障害に耐える最小の冗長性
- ゾーン障害とリージョン障害の両方に耐える構成
- LRS / ZRS / GRS の持続性（9 の数）
- フェールオーバーせずにセカンダリを読むには