【AZ-305】合格への道(DAY2) — ストレージアカウント、データベース
Microsoft Learn を教材にした AZ-305（Designing Microsoft Azure Infrastructure Solutions）4日間研修の受講メモ、第2弾です。
今回は 認証と認可 / 監視とログ / 高可用性とディザスターリカバリー / 非リレーショナルストレージ の範囲をまとめます。
講師の解説のうち「Learn の本文だけでは拾いにくい判断基準」を中心に記録しています。
前提知識として、AZ-104合格後です。
⚠️ 本記事は受講メモをベースにした個人の整理です。正確な仕様は必ず公式ドキュメントをご確認ください。
研修全体の構成
| 内容 | |
|---|---|
| DAY1 | ID・ガバナンス |
| DAY2 | ストレージアカウント、データベース |
| DAY3 | バックアップとサイトリカバリ |
| DAY4 | インフラストラクチャ ソリューション設計 |
1. 認証と認可のソリューションを設計する
参考: ケーススタディ: アクセス
対象を「オンプレミスユーザー」「パートナーユーザー」「アプリケーション」の3つに分けて考えます。
1-1. オンプレミスユーザー
Entra Connect で同期します。
- 今後はクラウド同期が推奨。デバイス同期にも対応した（管理ツールがすべてクラウドに寄った）
- オンプレ → クラウドだけでなく、クラウド → オンプレのレプリケーションも可能になった
- パスワードとグループメンバーはライトバック可能
- Entra Connect でレプリケーションした後に Entra Connect を切断すると、クラウドの Entra ID 側をマスターにできる
- ID / パスワードの同期
1-2. パートナーユーザー
Entra B2B を使います。
- 認証の独立性（ゲストユーザはデフォルトで社員リストが見えない）
- MFA（多要素認証）
- 管理対象デバイスからのみアクセス許可
- 信頼されていないソースからのアクセスをブロック
- ユーザーリスクポリシー、サインインリスクポリシー
- アクセスレビュー
- RBAC（グループレベルで制限）
1-3. アプリケーション
| 対象 | 方式 |
|---|---|
| 仮想マシン | マネージド ID を付与する |
| SQL データベース | マネージド ID からのアクセスを許可する |
| オンプレミスアプリケーション | Entra ID に登録（サービスプリンシパル）／RBAC によるアクセス許可／VPN または ExpressRoute（プライベートリンク・プライベートエンドポイント経由でオンプレからクラウドへアクセス） |
「Key Vault に Azure SQL アクセス用のキーを保管する」案について
一見よさそうですが、Entra ID 認証に対応したアプリケーション、もしくは Key Vault にアクセスするためのプログラムを別途作らなければならず、手間がかかります。
現実的な選択肢は以下。
- アプリケーションを Web アプリとして Entra ID にサービスプリンシパルとして登録する
- アプリケーションアクセスが可能になる
- シークレットまたは証明書が使える
- アプリケーションが稼働している環境が Windows であれば Credential Manager があること
-
Azure Arc を使い、オンプレミスのサーバにマネージド ID を付与する方法
- Azure Arc はインストールが必要。無料
2. Azure リソースをログに記録して監視するソリューションを設計する
2-1. Azure Monitor のデータソース
| 種類 | 内容 |
|---|---|
| メトリック | リアルタイム情報 |
| ログ | ファイル記録 |
Monitor 自身が表示機能を持ち、様々な機能と連携もできます。
ログは Log Analytics ワークスペースに保管されます。
2-2. Log Analytics ワークスペース
リレーショナルではなくキーバリュー型です。設計時に決めるのは以下。
- データストレージの地理的な場所
- 価格レベル、リテンション期間、データの上限値
ログの取り込み量をコミットできれば割引があります。
日次の上限を設定することも可能です。
データは 1ヶ月間の保存が無料、最長2年間データ保持が可能。
2-3. 一元化か、分散型か
データ保存の設計方針です。
| 方式 | 特徴 |
|---|---|
| 一元化 | 分析が全ての情報を扱える |
| 分散型 | 分析が速い。アプリケーション毎に分けられる（監査・管理でセキュリティ機能の一部として） |
| ハイブリッド型 | リージョン毎に1つ設定する。リージョン内のネットワークは課金対象外 |
2-4. アクセスモードとアクセス許可
- ワークスペースからクエリで分析することが可能
- Log Analytics ワークスペースから実行すると、すべての Log ワークスペースやテーブルにアクセス可能
- ロール: Log Analytics 閲覧者権限でログの読み取りが可能
- 検索時に「リソース」「ワークスペース」のどちらを対象にするか選択可能
アクセス基準の流れ
リソースの読み取りロール（ログの表示）
→ リソース
→ 診断設定
→ Log Analytics ワークスペース ← Log Analytics Data Reader などのロール
一般原則（Log Analytics ワークスペースの分割方針）
| 方針 | 向いている相手 | コンテキスト |
|---|---|---|
| 1. リージョン毎に分離（パフォーマンスおよび料金） | 管理者向け | ワークスペース コンテキスト |
| 2. アプリケーション毎に分離 | アプリケーション管理者向け | リソース コンテキスト中心 |
2-5. Workbook と Insights
Application Insights を有効にすると、アプリケーションログの収集ができます（Web Apps、VM、コンテナなど）。
- Application Insights は拡張機能。アプリケーションに対して組み込むことができる
- リクエストや応答時間などが取れる（HTTP）
- 仮想マシンについてはメモリ使用率などが見える
- Application Insights を使う場合、Log Analytics ワークスペースにログを配置する必要がある
参考: Application Insights の使用状況分析
2-6. Azure Data Explorer の設計
Log Analytics ワークスペースはログの保管コストが結構高い（1ヶ月は無料だが、それ以降）。
そこで、データレイクにログを移行して保管し、Data Explorer で分析するという構成が選択肢になります。
3. 高可用性とディザスターリカバリーの戦略
3-1. 2つの指標
障害発生時、バックアップから復旧する際の指標です。
| 指標 | 意味 |
|---|---|
| RTO（目標復旧時間） | システムが使えない時間 |
| RPO（目標復旧時点） | 失われたデータの時間 |
3-2. 高可用性と DR の違い
| 高可用性（HA） | ディザスターリカバリー（DR） | |
|---|---|---|
| 状態 | 一部止まっても使える | いったん全部停止 |
| 復旧 | — | ビジネス上の判断 |
| 停止時間 | 多少認められる。数分〜数十分が多い | 数時間〜数日を想定することが多い |
3-3. 仮想マシンの可用性
仮想マシン自体に高可用性機能はありません。「障害を意識する機能」があるだけ、という整理です。
- 複数台構成にする
- 可用性セット: 異なるハードウェアに分散する
- 可用性ゾーン: 異なるデータセンターに分散する（距離は推測で30km程度ではないかと言われている）
いずれも「1台の仮想マシンが壊れても、もう1台は稼働している」ことを最低限保証するものです。
高可用性（Always On）
- フェールオーバークラスター: 組むには共有ディスクが必要。現在は実現できるようになっている
- SQL Server の場合: Always On 可用性グループを使うとフェールオーバーが速い
- ログ配布: ディザスターリカバリーでトランザクションログを使う
3-4. PaaS の HA / DR
PaaS は機能として組み込まれていることが多い、というのが基本の考え方です。
4. バックアップと回復を計画する
4-1. Azure Backup の2つのコンテナ（Vault）
| コンテナ | 対象 | 使い分け |
|---|---|---|
| Recovery Services コンテナ | Azure VM、オンプレミスファイル、Azure Files（スナップショット）など | Azure VM 全体であればこちら |
| Backup コンテナ | マネージドディスク、Blob（スナップショット）、オープンソース DB（PostgreSQL、MySQL）など | Azure VM のディスクのみ取得するならこちら |
それぞれ管理アプリが違って管理しにくいため、**Azure レジリエンス（管理ツールのみを提供するサービス）**ができました。ここから以下を選択できます。
補足: ポータル上では「ビジネス継続センター（Business Continuity Center）」として提供されている機能です。名称は確認しておくとよさそうです。
Azure Backup
- 定期的にバックアップしていく（1日1回 / 3回、4時間に1回 など）
- どれくらい保存するか＝保持ポリシー（リテンション期間）。最長99年
Site Recovery
- ビジネスの BCP を対象としている。最新データの保持については強い
- 長期間のデータを戻すような用途はない。リテンションは24時間（最大72時間）
- Azure VM の場合はリアルタイム、保存間隔は30秒〜5分間隔
- 部分的な復元はできない。ファイル単位での復元は不可で、VM 自身の復元しかできない
4-2. Azure Blob のバックアップと回復
復旧時間が **1〜365日の論理的な削除（論理削除）**を検討します。
最近のランサムウェアは、バックアップを消してから攻撃を仕掛けてくることがある。
そのため Blob Storage には不変 BLOB ストレージがあり、ポリシーを設定できます。
- 誤って削除できない
- ログの改ざんができない
ポイントインタイムリストアに関する考慮事項
バックアップ自体は定期的に行っているものの、リストア時の指定が結構手間であること、そしてバックアップデータの信ぴょう性が論点になります。
★ Blob のバックアップはスナップショットであり、バックアップソリューションを使っているわけではない。
4-3. Azure Files のバックアップと回復
- Azure Files のバックアップもスナップショット
- Azure Files は共有フォルダなので、クライアントのエクスプローラーのプロパティからでも復元可能
4-4. Azure 仮想マシンのバックアップと回復
Azure Backup は Recovery Services コンテナの機能として作成します。
バックアップ整合性の3レベル
| レベル | 内容 |
|---|---|
| クラッシュ整合性 | いきなり電源 OFF したのと同じ状態（VM 停止状態） |
| ファイルシステム整合性 | ディスクキャッシュのみ考慮 |
| アプリ整合性 | アプリケーションの独自キャッシュまで考慮 |
VSS（ボリューム シャドウ コピー サービス）の役割
アプリケーションがファイルにアクセスしてメモリ上に展開している状態で、バックアップツールがそのファイルにアクセスしようとすると衝突します。このとき、ファイルを使っている持ち主（アプリケーション）を助けるのが VSS です。
- バックアップサービスが VSS に依頼する
- VSS がアプリケーションに働きかけて、バックアップのタイミングを制御する
★ Oracle データベースは VSS に対応していない。 そのため Oracle 側のバックアップの仕組みでバックアップする必要がある。
Geo 冗長の場合は別リージョンにコピーできますが、リージョン間復元（CRR）はペアリージョンだけです。
4-5. Azure SQL のバックアップと回復
SQL Database と SQL Managed Instance は自動的にバックアップされます。
- 週に1回の完全バックアップ
- 12〜24時間ごとの差分バックアップ
- 5〜10分ごとのトランザクションログバックアップ
- データベースの保持期間（デフォルト35日、最大10年）
一方、Azure VM 上の SQL Server は Recovery Services コンテナを使うことが可能です。
Azure SQL は直接バックアップが見えません。
4-6. Azure Site Recovery（ASR）を設計する
★ BCP プランで Site Recovery が使えるのは VM のみ。PaaS に Site Recovery 機能はない（スクリプトを組んで自動化する必要がある）。
構成パターン
| パターン | 内容 |
|---|---|
| オンプレミス - Azure（ネットワーク） - オンプレミス | オンプレミス間のレプリケーションに Azure ネットワークのバックボーンを使える。System Center 必須 |
| オンプレミス - Azure | Hyper-V / VMware / その他（物理マシン、AWS EC2、Google Cloud VM） |
| Azure - Azure | 通常はリージョンペアで設定するが、リージョンペアでなくても OK |
復元ポイントの選び方は「一番新しいものを使って、ダメだったら整合性の高いものを選ぶ」。
5. 非リレーショナルデータ用のデータストレージ ソリューション
5-1. データストレージの分類
5-2. Azure Storage アカウントのために設計する
Standard 汎用ストレージ
| サービス | 内容 |
|---|---|
| BLOB | HTTPS ベース。階層なし（管理ツールが整形して階層があるように見えるだけ） |
| Data Lake Gen2 | 階層ありの BLOB。HDFS 互換 |
| Files | SMB ベース（Windows ファイル共有） |
| Queue | 非同期通信 |
| Table | キーバリューストア（NoSQL の一種） |
Premium ストレージ
- ページ BLOB（「汎用」とも表示される）※ ほとんど使わない
- Premium Files: SMB / NFS 4.1
- Block Blob: 普通の BLOB
設計時の検討軸: 場所、各種規制コンプライアンスへの準拠、コスト、レプリケーション、管理オーバーヘッド、セキュリティ・データの機密性
冗長性の考え方
ローカル冗長 → Geo 冗長 （読み取りアクセスあり / なし）
ゾーン冗長 → Geo ゾーン冗長 （読み取りアクセスあり / なし）
5-3. Azure Blob Storage のために設計する
★ Premium と Standard は互換がないので行き来できない。
Standard のアクセス層
| 層 | 想定するストレージ継続期間 |
|---|---|
| ホット | 継続期間なし。アクティブで頻繁に使用される |
| クール | 30日を超える（30日以上の保管が目的） |
| コールド | 90日を超える（90日以上の保管が目的） |
| アーカイブ | 180日を超える（180日以上の保管が目的） |
ポイント:
- アーカイブに向かうほど保存料金は安くなるが、書き込み・データ転送の料金は高くなる
- ホット・クール・コールドの速度差はない
- アーカイブだけは全く違う位置づけ。いったん保存すると読み取りができず、クールかコールドへの変換料金がかかるので高い
ライフサイクル管理
- ストレージ層を移動してコストを最適化する
- アーカイブストレージへの移動には、一定期間アーカイブ以外に戻さないというオプションあり（リハイドレート）
- 1日1回ライフサイクルが動くイメージ
不変ストレージ
ログファイルをエクスポートしたときなど、要件によって変更できないようにするポリシーです。
| 種類 | 用途 | 管理者の権限 |
|---|---|---|
| 訴訟ホールド | 裁判の証拠として保存（無期限） | 設定の「削除」のみ可能。管理者の判断で期間の制限なくキャンセルすることはできない |
| 時間ベース保持 | コンプライアンス対応 | 設定の「削除」のみ可能。管理者であっても期間内はキャンセルできない |
5-4. Azure Files のために設計する
★ NFS 4.1 が使えるのは Premium の Azure Files のみ。
| プロトコル | |
|---|---|
| Standard 汎用 Files | SMB 3.0（規定）/ 2.1（オプション）、REST（HTTP） |
| Premium Files | SMB 3.0（規定）/ 2.1（オプション）、REST（HTTP）、NFS 4.1（ネットワーク制限が必要） |
- SMB はネットワークパケットを暗号化する
- NFS はネットワークパケットを暗号化しない
- Azure Blob は Data Lake Gen2 を使うときのみ NFS 3.0 が使える
整理すると:
NFS 3.0 → Data Lake Gen2（階層化有効）
NFS 4.1 → Premium Files
SMB → Standard / Premium Files
Azure Files のティア
- Premium
- トランザクション最適化: 保存料金は高いがアクセス料金が安い
- ホット
- クール
5-5. Azure ディスクソリューションを設計する
仮想マシン専用のディスクで、データの読み書きは VM から行います。
よく使うのは Premium SSD、Standard SSD、Standard HDD の3つ。
| 種類 | 特徴 |
|---|---|
| Ultra Disk SSD | システムディスクには使えない |
| Premium SSD v2 | システムディスクには使えない |
| Premium SSD | あらかじめ容量が決まっている。バーストの速度は高いが、基準速度は Standard SSD / HDD と変わらない。容量によって性能が大きく変わる |
| Standard SSD | あらかじめ容量が決まっている |
| Standard HDD | あらかじめ容量が決まっている。システムディスクとしては使えなくなる予定（2028/9/8） |
ディスクキャッシュ
読み取り・書き込みのアクセスを最適化します。
- システムディスクは「書き込み・読み取り」がデフォルト
- データディスクは「読み取り専用」がデフォルト
- キャッシュがいらないものはキャッシュなしにする
理由は、キャッシュあり / なしで通信パスが変わり、パフォーマンスに影響するためです。
参考: ディスクのパフォーマンス - Microsoft Learn
ディスクの暗号化
現在はホスト暗号化を使います（以前は Azure Disk Encryption）。
| キー管理 | 動作場所 | |
|---|---|---|
| Azure Disk Encryption | カスタマー管理（Key Vault） | OS 上で動作 |
| ホスト暗号化 | Microsoft 管理のキーのみ | ホスト側 |
自身でキーを管理したい場合は、ディスク暗号化を使い、ディスク暗号化セットというパラメータを作ってディスク装置を暗号化します。
- ディスク暗号化できるのはマネージドディスクのみ
- 一時ディスクの暗号化はできない
おすすめの順序
- ホスト暗号化
- ユーザー定義のキーを使いたければディスク暗号化
5-6. ストレージセキュリティのために設計する
ストレージアカウントの基本設定
- 安全な転送が必須: 有効（HTTPS、SMB 暗号化）
ネットワークの3方式
| 方式 | 内容 |
|---|---|
| パブリックエンドポイント | インターネット経由でストレージアカウントにアクセス。パブリックアクセスを拒否すると、Azure ポータルからもコンテナまでは見えるがオブジェクトが見えなくなる |
| サービスエンドポイント | サブネット側でサービスエンドポイントを設定する。Azure のバックボーンネットワークへ直接アクセス。サブネットのルーティングが変更されるため、サブネットを通る必要がある |
| プライベートエンドポイント | オンプレミスネットワークとつなぐ場合は、VNet と VPN Gateway をつなげる必要がある。ストレージアカウント側にあるエンドポイントの NIC を VNet 側に持ってくる |
- プライベートエンドポイントを作る作業を Private Link という
- ホスト名とプライベート名を解決するため、プライベート DNS ゾーンの作成が必須（自動的に作られる）
暗号化キー: Microsoft マネージドキー / カスタマーマネージドキー
5-7. 演習: 非リレーショナルストレージのケーススタディ
6. 今回の重点ポイント
- Blob のバックアップはスナップショットであって、バックアップソリューションではない
- Oracle は VSS 非対応。アプリ整合性が必要なら Oracle 側の仕組みを使う
- Site Recovery は VM のみ。PaaS には機能がないのでスクリプトで自動化
- Backup と Site Recovery の使い分けは「長期保持なら Backup / 最新データ保持なら Site Recovery」
- Blob の Premium と Standard は行き来できない
- NFS 4.1 は Premium Files のみ、NFS 3.0 は Data Lake Gen2 のみ
- Ultra Disk SSD と Premium SSD v2 はシステムディスクに使えない
- ディスク暗号化はマネージドディスクのみ。一時ディスクは不可
おわりに
AZ-104 では「サービスの使い方」が中心でしたが、AZ-305 は明確に「どれを選ぶか、なぜそれを選ぶか」を問われる内容になっています。DAY3も投稿していきたいと思います。