DP300-CS04#3
【Case Study】Northwind 社 DR + パフォーマンス監視統合
【背景】
Northwind 社は グローバル EC プラットフォーム で Azure SQL Database を運用しており Primary (East US) + DR (West US 2) 構成 で運用中です。最近 ピーク 時間帯 に レスポンス 遅延 + DTU 95% 到達 が発生し パフォーマンス監視 + 自動最適化 強化 を計画 します。
【既存環境】
Azure SQL Database Business Critical 8 vCore (Primary), 同等 (DR), Microsoft Entra ID テナント, Defender for SQL 有効化済み, TDE CMK 運用, Auditing を Central Log Analytics に転送 設定済み。
【要件】
- Query Store + Automatic Tuning で Plan Regression / Missing Index を 自動 対処
- Wait Statistics + Top CPU クエリ を Log Analytics で 統合 分析
- OLTP ピーク 時 の Read Workload を Read-only Replica に分散
- CPU 80% + DTU 80% でアラート + Action Group で 自動 通知
- 夜間バッチ (大規模 集計) は別 Workload Group で リソース 分離
【質問 3/3】
本シナリオで CPU 80% + DTU 80% でアラート + Action Group で 自動 通知 を実現 する 構成 はどれですか?
解説
【正解: A】の理由
Azure Monitor の Metric Alert で CPU Percentage > 80% + 5 min 連続 等の閾値 設定 + Action Group (Email / Teams Webhook / Logic App / Function App 連携) で 自動 通知 + 自動 対応 (例: Service Tier 自動 アップ) を実現 できます。Azure SQL Database は Azure Monitor とネイティブ統合 されており Metric 取得 設定 不要 で アラートルール のみ 追加 すれば 動作 します。
【他選択肢が違う理由】
- B: SQL Agent は Azure SQL DB では 利用不可 で SQL MI / SQL VM のみです。
- C: Storage 保管 のみ では アラート 通知 機能 が ありません。
- D: PowerShell ポーリング は リアルタイム 性 + 運用 性 が 劣り Azure Monitor が 正規 手段 です。

コメント