Microsoft AZ-140: レジリエンス、回復、移行 — 学習ガイド

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure Virtual Desktop Specialty AZ-140 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Azure Virtual Desktop (AVD)の回復性、復旧、移行計画は、リージョン障害時におけるユーザーの生産性維持、データ（プロファイル、イメージ、アプリケーション）の保護、依存関係のフェイルオーバーのオーケストレーション、そして従来のRemote Desktop Services (RDS)からの予測可能な移行を実現することに焦点を当てています。効果的な設計では、ステートレスなAVDコントロールプレーンをステートフルなデータプレーンから分離し、再構築のための反復可能な自動化を使用し、各コンポーネントに対して明確な復旧目標を定義し、ディスカバリーとキャパシティモデリングによって実際のパフォーマンスを検証します。

リージョンアーキテクチャ、ユーザーアクセス、フェイルオーバー

コントロールプレーンとデータプレーン: AVDのブローカー、Webアクセス、診断、管理サービスはグローバルに回復性があります。セッションホスト、ホストプール、イメージ、ストレージはリージョン固有であり、フェイルオーバーを考慮して設計する必要があります。
リージョン障害戦略:
- ユーザーコーホートごとにセカンダリリージョンにホストプールを作成し、同じVMサイズファミリーとイメージの系譜を使用します。Azure Compute Galleryを使用して、イメージをセカンダリリージョンにレプリケートします。
- 両方のリージョンで同一のアプリケーショングループ（RemoteAppやデスクトップ）を公開し、ユーザーを両方に割り当て、プライマリプールをデフォルトとして、セカンダリをDRターゲットとして設定します。
- DRホストはコールドまたはウォームスタンバイの状態で維持します。プール型ホストの場合、ゼロにスケールインするか電源をオフにし、スケーリングプランとStart VM on Connectを利用して、定常状態のコストを最小限に抑えます。
障害発生時のユーザーアクセス:
- AVDサービスは、接続要求を正常なセッションホストにルーティングします。プライマリホストプールをドレインモードにするか、利用できなくなった場合、ユーザーがセカンダリプールに割り当てられていれば、新しい接続はそのプールに仲介されます。
- 障害が発生したリージョンで開いているセッションは切断され、再接続すると利用可能なリージョンに接続されることをユーザーに周知します。
イメージとMSIX app attachのパリティ:
- イメージには、Azure Image BuilderとAzure Compute Gallery (SIG)をリージョンレプリケーションと組み合わせて使用します。
- MSIX app attachパッケージは、両方のリージョンから到達可能な回復性のあるストレージ場所に保存し、コンテンツをセカンダリリージョンにレプリケートします（例：ANFのクロスリージョンレプリケーションやストレージアカウントのレプリケーション）。
ネットワークとIDの依存関係:
- DNSとID（Active DirectoryまたはAzure AD DS）が両方のリージョンから到達可能であることを確認します。Azure AD DSの場合、ドメイン参加と名前解決を必要とする各リージョンのVNetで、VNetのDNS設定をマネージドドメインのIPに構成します。
- リージョン間でRDP Shortpathの動作を検証し、UDPが妨げられる場合はリバースコネクトにフォールバックします。

イメージバージョンを2つのリージョンにレプリケートする例:

az sig image-version create \
  --resource-group rg-avd-images \
  --gallery-name sig-avd \
  --gallery-image-definition win11-ms \
  --gallery-image-version 1.0.3 \
  --target-regions eastus=1 westus=1

復旧目標とデータ保護の役割

コンポーネントごとに異なるRTO/RPOを定義します:

ホストプールとセッションホスト:
- プール型: セッションホストをエフェメラル（一時的）なものとして扱います。RTOは数分（自動再デプロイ）、RPOはN/A（ホストの状態なし）です。復旧にVMバックアップを頼らず、イメージからの再デプロイと自動スケーリングを利用します。
- 個人用: ユーザーステートがOSディスク上にある場合は、Azure BackupまたはAzure Site Recovery (ASR)で保護します。DRを簡素化するために、ユーザーステートをFSLogixプロファイルにオフロードすることを推奨します。
イメージ:
- Compute Galleryのレプリケーションを使用することで、イメージの可用性に対するRPOはほぼゼロです。RTOは新しいホストをデプロイするための数分です。ゴールデンイメージのパイプラインは、バージョン管理され、再現可能に保ちます。
プロファイルとOfficeキャッシュ (FSLogix):
- RPO: レプリケーションとバックアップのスケジュールに応じて数分から数時間。RTO: Cloud Cacheが構成されていればセカンダリリージョンでのマウントに数分、そうでなければボリューム/共有の復元とセッションの再ポイントにかかる時間。
アプリケーション:
- イメージ内のアプリケーションについては、イメージのRTO/RPOに合わせます。MSIX app attachについては、パッケージストレージのレプリケーションと再登録時間に合わせて調整します。

Azure BackupとASR:

Azure Backup:
- FSLogixプロファイルとODFCコンテナをホストするAzure Files共有をバックアップします。RPOターゲットを達成するために頻繁なスナップショットを使用し、個々のVHD/VHDXまたは共有全体を復元します。ユーザーがログオンしている間のスナップショットはクラッシュ整合性があることを伝えます。正確な復元のためには、ユーザーのコンテナを帯域外でコピー/名前変更し、ユーザーに再ログオンを指示します。
- 必要に応じて、個人用デスクトップのOSディスクをバックアップします。プール型ホストは通常、VMバックアップを必要としません。
Azure Site Recovery:
- AVDにとって重要なステートフルなインフラコンポーネント（例：管理サーバー、該当する場合はライセンスサーバー、LOBサーバー）や、VMの状態を維持する必要がある個人用ホストプールにはASRを使用します。
- プール型のAVDホストにはASRを使用しないでください。イメージ/スケーリングプランからの再デプロイの方が高速で安価です。

プロファイルストレージの回復性、Cloud Cache、バックアップ、復元

FSLogixのストレージオプション:
- Azure NetApp Files (ANF): 大規模環境で最高のIOPS/最低のレイテンシを提供し、DRのためのクロスリージョンレプリケーションをサポートします。非常に大規模な環境や、高い同時実行性とプロファイルのIO要求がある場合に最適です。
- Azure Files Premium: リージョン内の回復性のためのZRSを備えたSSDベースのPaaSファイル共有で、パフォーマンスと管理のバランスに優れています。クロスリージョンDRのためには、Cloud Cacheと共有レベルのバックアップ/復元を組み合わせるか、デュアルリージョン共有を設計します。
- IaaS上のStorage Spaces Direct (S2D): PaaSが利用できない場合にのみ使用します。クォーラムのためには、Cloud Witnessなしで最低3台のVMが必要です。運用オーバーヘッドはPaaSの代替手段よりも高くなります。
Cloud Cache:
- 複数のプロバイダー（例：異なるゾーン/リージョンにある2つのAzure FilesまたはANFエンドポイント）を構成します。リージョン障害の間、FSLogixは生き残ったプロバイダーに対して動作を継続し、キャッシュされた書き込みは結果整合性で処理されます。
- 構成例:

# PowerShell on session host
New-Item -Path HKLM:\SOFTWARE\FSLogix\Profiles -Force | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name Enabled -Type DWord -Value 1 | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name CCDLocations -Type String `
  -Value "type=smb,connectionString=\\files-pri.file.core.windows.net\profiles;type=smb,connectionString=\\files-dr.file.core.windows.net\profiles" | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name DeleteLocalProfileWhenVHDShouldApply -Type DWord -Value 1 | Out-Null

バックアップと復元のパターン:
- プロファイル共有に対して、1時間ごとまたは数時間ごとにAzure Backupスナップショットを実装します。破損したユーザープロファイルの場合、現在のVHDXを隔離し、前のスナップショットを別の場所に復元して、ユーザーのコンテナをコピーまたは再アタッチします。
- ANFの場合、スナップショットとクロスリージョンレプリケーションを使用し、スナップショットディレクトリ経由でボリュームレベルまたは単一ファイルを復元します。
テスト:
- DR訓練には、マウント/アタッチの検証、破損シミュレーション、ユーザーレベルのロールバックを含めます。

トラフィック、DNS、依存関係のフェイルオーバー

アプリケーションの依存関係:
- 多くのAVDアプリは、HTTP/S API、Webフロントエンド、またはデータベースに依存しています。これらの依存関係をグローバルな負荷分散とリージョン展開で設計し、依存関係のフェイルオーバーが発生しても、他の正常なセッションのユーザーが取り残されないようにします。
Azure Front DoorとTraffic Manager:
- AVDユーザーが使用するアプリの依存関係に対して、グローバルなHTTP/Sレイヤー7負荷分散、WAF、パスベースルーティングのためにAzure Front Doorを使用します。各リージョンでゾーン冗長なバックエンドと組み合わせます。
- パブリックに公開され、ヘルスプローブをサポートする非HTTPエンドポイントに対しては、DNSベースの負荷分散のためにAzure Traffic Managerを使用します。
プライベートDNSと名前解決:
- Azure DNS Private Resolverを使用して条件付きフォワーダーを一元管理し、オンプレミス、Azure VNet、マネージドドメイン間のクエリをルーティングします。迅速なフェイルオーバーが必要になる可能性のあるエンドポイントには、低TTLのレコードを公開します。
- ネイティブでシームレスにフェイルオーバーできないストレージエンドポイントについては、内部DNSの背後で抽象化された二重の名前を持つエンドポイントを検討し、インシデント発生時にプライマリ共有とDR共有を切り替えられるようにします。
ネットワークのQoSとアクセス:
- WAN全体でリアルタイムのAVDトラフィック（UDP/TCP）を優先します。ブランチルーターのQoSを調整し、AVDトラフィッククラスが接続エラーと遅延を削減するのに十分な帯域幅を確保できるようにします。
- Shortpathの到達可能性とファイアウォールのピンホール（開放ポート）を検証します。エグレス帯域幅の計画が、同時実行数とワークロードの組み合わせに合致していることを確認します。

RDSからの移行、検出、密度、容量

RDSのアセスメント:
- Connection Broker、RD Gateway、RD Web、RD Session Host、RDライセンス、およびファイルサーバー/プロファイルストアのインベントリを作成します。GPO、FSLogixの構成、アプリケーション配信方法を文書化します。
- 既存のロールをAVDの構成要素（ホストプール、ワークスペース、アプリケーショングループ、プロファイルストレージ、AVD管理のブローカリング）にマッピングします。AzureではRD GatewayとBrokerが不要になります。
Azure Migrateと検出:
- Azure Migrateアプライアンスを使用して、既存のRDS VM、パフォーマンスベースライン、依存関係を検出します。AVDセッションホストの配置とデータグラビティを考慮するために、アプリとサーバーの関係を特定します。
ユーザー密度の分析:
- ワークロードごと（タスクワーカー/ナレッジワーカー/パワーユーザー）に密度モデルを構築します。CPU Ready、メモリプレッシャー、プロファイルIOのベースラインを使用して、VMあたりのセッション数を導き出します。候補となるVM SKU（例: Dv5/Esv5/Dasv5、グラフィックス用のGPU搭載モデル）でパイロットベンチマークを実施して検証します。
- Azure Virtual Desktop Experience Estimatorを使用して、ユーザーからホストへの遅延が最も低いリージョンを選択します。
容量モデリング:
- 密度をプールごとのホスト数に変換し、N+1バッファとメンテナンスのオーバーヘッドを考慮します。スケーリングプランで、スケールアウトのしきい値とホストの最小/最大数を定義します。コストを予測可能にし、混雑したリージョンでコアを確保するために、容量予約を検討します。
- サブスクリプションとリージョンのクォータ（vCPU、ファミリーごとのコア数、IP、NIC、ディスク）が事前に引き上げられていることを確認します。クォータの引き上げリクエストは早めに提出します。

← 監視、診断、トラブルシューティング · すべてのドメイン

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →