# Azure Cosmos DB パフォーマンス最適化入門 - 設計・開発・運用の実践テクニック

Azure Cosmos DB パフォーマンス最適化入門設計・開発・運用の実践テクニック Azure勉強会 - Entra ID と
Log Analytics と Cosmos DB - Tatsuro Shibamura @shibayan

私について芝村達郎 @shibayan ZEN Architects Distinguished Engineer Microsoft MVP
for Microsoft Azure Blog : https://blog.shibayan.jp GitHub : https://github.com/shibayan

注意 2025 年 3 月 6 日の情報に基づいています今後のアップデートで状況が変わる可能性は大きくあります常にパフォーマンス向上は Cosmos
DB の重要事項らしいです 5 月の Microsoft Build にも期待しましょう

今日お話しする内容 Cosmos DB を使ったアプリケーション開発時に失敗しないコツ主に Cosmos DB の仕組みとデータモデリングの考え方アプリケーションが稼働した後にパフォーマンスの問題が出た時の対応 Azure
Monitor を最初から設定・利用のポイント

Cosmos DB を使ったサービスの良くある話 RDB と同じ感覚でモデルを作って運用を始める雑に使っても 7 割ぐらいの性能が出る自動的に作成されるインデックスが強力複雑なクエリでも思ったより高速に返してしまう性能の良さ
しかしサービスが成長すると急に遅くなる、コストが高くなる突然 429 Too Many Request が大量に出るようになった処理は何も変えていないのに必要な RU が増えてしまった

何故このような問題が発生するのか大前提 : Cosmos DB 自体は高くない・遅くない適切に使えば RDB よりも優れているただし適切に使うのは仕組みを少しでも知らないと難しい
大半はデータモデリングに失敗しているのが原因 Id / パーティションキーの設計に失敗設計の問題をクエリやアプリケーションで吸収しようとして失敗データモデリングから見直す必要あり

設計

Cosmos DB のアーキテクチャを知る物理パーティション最大 10000 RU/sec と 50GB ストレージを持つコンピューティング
クエリの実行は物理パーティション単位で行われる Azure Cosmos DB の物理パーティションを深く理解する - しばやん雑記論理パーティション同一パーティションキーを持つデータ最大 20GB までのデータを保持可能 1 つの論理パーティションは必ず同じ物理パーティションに格納される

物理パーティション

論理パーティション

Cosmos DB のデータモデリングの考え方最初に Id とパーティションキーを決めるクエリ時にパーティションキーは必須ではないがパフォーマンスに影響クロスパーティションクエリが必要な場面を減らす最近では階層パーティションキーの利用も検討する RDB
とは異なり非正規化を何処まで行うかが肝 Cosmos DB にはトランザクションはないしかし単一アイテムへの書き込み処理はアトミック非正規化して埋め込みエンティティとして扱う

階層パーティションキーの利用を検討する 3 階層までパーティションキーのパスを指定できるこれまで合成パーティションキーを使っていたのが不要に合成パーティションキーとは異なり、最適なルーティングが実現される

Change Feed で変更されたデータの同期非正規化された (埋め込みされた) データの変更をトリガーにする

Change Feed で Materialized View を作成 Change Feed を使ってパーティションキーを変更したデータを作るパーティションキーを跨いだクエリが必要な場合に有用
Materialized View の作成までにラグが発生することは考慮実際の利用例集計用のデータを Change Feed でリアルタイム集計イベントソーシングの実装

開発

最新の SDK を利用する Cosmos DB SDK (特に C# と Java)
はパフォーマンスが良い物理パーティションを認識した最適化が行われている（若干チート）ダイレクトモード / ReadMany API / バルク処理など最近ではオプティミスティック直接実行 (ODE) も Azure Cosmos DB SDK を使用するクエリでの Azure Cosmos DB のパフォーマンスに関するヒント | Microsoft Learn 高頻度でアップデートが行われているので追従しておきたい

Query Metrics を取得する RDB で言うところの EXPLAIN に相当する機能最適化を行うためには正しく RU の消費を把握するのが絶対条件
ローカル開発環境や Data Explorer で取得する SQL クエリのパフォーマンスと実行メトリックを取得する | Microsoft Learn Azure Portal で実行した場合はパーティション単位でのメトリックも

Index Advisor を利用する不足している Index の情報を返してくれる機能 PopulateIndexMetrics に true を指定してクエリを実行
使われている Index と不足している Index が返却される General Availability: Index Metrics in Azure Cosmos DB for NoSQL - Azure Cosmos DB Blog Index の最適化は最後の方に行うくらいで良い

Index Policy を最適化する Cosmos DB の RU は Index の読み書き分も含まれている
書き込み時には Index の作成に必要だった RU が乗ってきているプロパティの数が多くなると Index の作成コストが高くなる Vector Search に使う配列は Index 作成から除外するのが推奨

運用

Azure Monitor / Log Analytics を活用するまずは Cosmos DB の
Metrics から始める Normalized RU Consumption や Total Request Units など Splitting と組み合わせると効果絶大 Azure Monitor Azure Cosmos DB 分析情報で Azure Cosmos DB を監視する | Microsoft Learn Log Analytics に診断ログを送信する DataPlaneRequests と QueryRuntimeStatistics は必須診断クエリに関する問題のトラブルシューティング - Azure Cosmos DB | Microsoft Learn Workbooks を活用するのもお勧め

Workbooks の例

デフォルトで用意されている Workbooks Azure Cosmos DB Resource insights Cosmos DB のリソース情報を分かりやすく表示してくれる
Optimize my API for MongoDB cost and performance MongoDB のコストとパフォーマンス最適化向け Optimizing Your Throughput Model 対話式で Cosmos DB の RU を最適化出来る Log Analytics Troubleshooting Workbook 診断ログを使ったトラブルシューティング関連クエリ詰め合わせ Activity Logs Insights

OpenTelemetry を使った監視を有効化する最新の C# / Java SDK では OpenTelemetry 対応済み
自動的に失敗したリクエストと遅いリクエストを収集してくれる Azure Cosmos DB SDK の監視 | Microsoft Learn Application Insights と組み合わせ利用するのがベスト特定ユーザーの場合のみ処理が遅いケースにも対応可能アラートの仕込みも容易

終わりに Cosmos DB のパフォーマンス最適化 == データモデリングの最適化 Cosmos DB の仕組みを知ると理解が進むデータモデリングに時間を掛ける
その後の開発と運用が楽になるため十分ペイできる階層パーティションキー・Change Feed でパーティションキーの制約を超える RDB 脳を捨てて Cosmos DB 脳になろう

ご清聴ありがとうございました

# Azure Cosmos DB パフォーマンス最適化入門 - 設計・開発・運用の実践テクニック

# Azure Cosmos DB パフォーマンス最適化入門 - 設計・開発・運用の実践テクニック

Tatsuro Shibamura

More Decks by Tatsuro Shibamura

Other Decks in Technology

Featured

Transcript