Instiq
第5章 · 運用・保守·v1.0.0·更新 2026/8/6·読了目安 約13分

変更要約: DP-420 第5章を新規作成し参考書を完結(ドメイン5: 監視(Normalized RU Consumption ホットパーティション検出/ステータスコード 429-449-503-408/サーバー側遅延/Azure Monitor アラート/リソースログ 診断設定→Log Analytics/パーティション間監視)、バックアップと復元(定期 vs 継続/PITR/復元ポイント/新アカウントへ復元)、セキュリティ・データ移動・DevOps(サービス管理 vs CMK Key Vault/Private Endpoint・IP・VNet/コントロールプレーン Azure RBAC・データプレーン Entra ID RBAC/Always Encrypted/CORS/データ移動 ADF・Spark・Kafka・Stream Analytics・IoT Hub/DevOps 宣言的 ARM・命令的 PowerShell-CLI 標準⇔オートスケール・フェイルオーバー))。

5.1監視とトラブルシュート

この節の要点

応答ステータスコードと失敗メトリクス、Normalized RU Consumption とサーバー側遅延の Azure Monitor 監視、レプリケーション監視、アラートとリソースログ、パーティション間スループット/データ分散の監視を理解します。

運用フェーズでは、RU の偏りやスロットリング、遅延、可用性を可視化して問題を早期に捉えます。Cosmos DB は Azure Monitor でメトリクス/ログ/アラートを提供します。

5.1.1主要メトリクスとステータスコード

Normalized RU Consumption は、最も忙しいパーティションの RU 使用率(0〜100%)を示し、ホットパーティション(特定パーティションに偏った消費)を検出する最重要メトリクス=高止まりは 429 の前兆。応答ステータスコード/失敗メトリクス429 レート制限・449 同時実行再試行・503 一時的・408 タイムアウト)で失敗の性質を見分ける。サーバー側遅延(server-side latency) でサービス内処理の遅さを切り分ける(クライアント/ネットワーク要因と区別)。パーティション間のスループット/データ分散 を監視し、偏りがあればパーティションキー設計を見直す。

5.1.2アラート・リソースログ・監査

Azure Monitor アラート を Normalized RU やスロットリング率に設定し、閾値超過で通知/自動対応する。リソースログ(診断設定) を Log Analytics に送って KQL でクエリし、データプレーン要求やコントロールプレーン操作を分析する。ログと監査 でセキュリティ監視(誰がいつどのデータにアクセスしたか)を行う。レプリケーションの遅延と可用性も監視し、リージョン間の健全性を確認する。

試験ポイント

決め手:「ホットパーティション/RU 偏りを検出」=Normalized RU Consumption。「レート制限」=429。「サービス内の遅さ」=サーバー側遅延。「閾値超過で通知」=Azure Monitor アラート。「要求/操作を KQL 分析」=リソースログ(診断設定→Log Analytics)。偏りはパーティションキー再設計のサイン。

注意

混同に注意:
①Normalized RU(最も忙しいパーティションの使用率)と平均 RU を取り違えない=偏りは Normalized で見る。
②429(スループット不足)は SDK リトライ+RU 増 or キー再設計で根治。
③サーバー側遅延とクライアント/ネットワーク遅延を切り分ける。
④リソースログは診断設定で明示的に有効化が要る。

Normalized RU Consumption で最も忙しいパーティションの偏り(ホットパーティション・429 前兆)を検出、ステータスコード(429/449/503/408)とサーバー側遅延で切り分け、Azure Monitor アラート+リソースログ(診断設定→Log Analytics/KQL)で運用監視を示す図。
偏りと失敗を見る

5.1.3この節のまとめ

  • Normalized RU Consumption で最も忙しいパーティションの偏り(ホットパーティション)と 429 前兆を検出
  • ステータスコード(429/449/503/408)・サーバー側遅延で失敗と遅さを切り分け
  • Azure Monitor アラート+リソースログ(診断設定→Log Analytics/KQL)+監査で運用/セキュリティ監視

進捗の記録にはログインが必要です。

理解度チェック

(軽い確認用)

Q1. 特定のパーティションに RU 消費が偏っていないか(ホットパーティション)を検出したい。最適なメトリクスはどれですか?

Q2. Cosmos DB がプロビジョニング RU 不足でレート制限したときに返すステータスコードはどれですか?

Q3. Normalized RU が継続的に高い閾値を超えたら通知し、自動対応につなげたい。最適なのはどれですか?

Q4. データプレーン要求やコントロールプレーン操作を後から KQL で分析したい。最適なのはどれですか?

Q5. Normalized RU が高止まりしてホットパーティションが疑われる場合の根本対処として正しいのはどれですか?

理解度を確認第5章「運用・保守」の問題を解く

学習の記録を残しませんか

参考書はすべて無料で読めます。無料登録すると、問題集での演習・既読と進捗の記録・間違えた問題の復習・ハイライトが使えます。