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

Transcript

1. Azure Cosmos DB パフォーマンス最適化入門 設計・開発・運用の実践テクニック Azure勉強会 - Entra ID と Log Analytics と Cosmos DB - Tatsuro Shibamura @shibayan
2. 私について 芝村 達郎 @shibayan ZEN Architects Distinguished Engineer Microsoft MVP for Microsoft Azure Blog : https://blog.shibayan.jp GitHub : https://github.com/shibayan
3. 注意 2025 年 3 月 6 日の情報に基づいています 今後のアップデートで状況が変わる可能性は大きくあります 常にパフォーマンス向上は Cosmos DB の重要事項らしいです 5 月の Microsoft Build にも期待しましょう
4. 今日お話しする内容 Cosmos DB を使ったアプリケーション開発時に失敗しないコツ 主に Cosmos DB の仕組みとデータモデリングの考え方 アプリケーションが稼働した後にパフォーマンスの問題が出た時の対応 Azure Monitor を最初から設定・利用のポイント
5. Cosmos DB を使ったサービスの良くある話 RDB と同じ感覚でモデルを作って運用を始める 雑に使っても 7 割ぐらいの性能が出る 自動的に作成されるインデックスが強力 複雑なクエリでも思ったより高速に返してしまう性能の良さ しかしサービスが成長すると急に遅くなる、コストが高くなる 突然 429 Too Many Request が大量に出るようになった 処理は何も変えていないのに必要な RU が増えてしまった
6. 何故このような問題が発生するのか 大前提 : Cosmos DB 自体は高くない・遅くない 適切に使えば RDB よりも優れている ただし適切に使うのは仕組みを少しでも知らないと難しい 大半はデータモデリングに失敗しているのが原因 Id / パーティションキーの設計に失敗 設計の問題をクエリやアプリケーションで吸収しようとして失敗 データモデリングから見直す必要あり
7. 設計
8. Cosmos DB のアーキテクチャを知る 物理パーティション 最大 10000 RU/sec と 50GB ストレージを持つコンピューティング クエリの実行は物理パーティション単位で行われる Azure Cosmos DB の物理パーティションを深く理解する - しばやん雑記 論理パーティション 同一パーティションキーを持つデータ 最大 20GB までのデータを保持可能 1 つの論理パーティションは必ず同じ物理パーティションに格納される
9. 物理パーティション
10. 論理パーティション
11. Cosmos DB のデータモデリングの考え方 最初に Id とパーティションキーを決める クエリ時にパーティションキーは必須ではないがパフォーマンスに影響 クロスパーティションクエリが必要な場面を減らす 最近では階層パーティションキーの利用も検討する RDB とは異なり非正規化を何処まで行うかが肝 Cosmos DB にはトランザクションはない しかし単一アイテムへの書き込み処理はアトミック 非正規化して埋め込みエンティティとして扱う
13. 階層パーティションキーの利用を検討する 3 階層までパーティションキーのパスを指定できる これまで合成パーティションキーを使っていたのが不要に 合成パーティションキーとは異なり、最適なルーティングが実現される
14. Change Feed で変更されたデータの同期 非正規化された (埋め込みされた) データの変更をトリガーにする
15. Change Feed で Materialized View を作成 Change Feed を使ってパーティションキーを変更したデータを作る パーティションキーを跨いだクエリが必要な場合に有用 Materialized View の作成までにラグが発生することは考慮 実際の利用例 集計用のデータを Change Feed でリアルタイム集計 イベントソーシングの実装
16. 開発
17. 最新の SDK を利用する Cosmos DB SDK (特に C# と Java) はパフォーマンスが良い 物理パーティションを認識した最適化が行われている（若干チート） ダイレクトモード / ReadMany API / バルク処理など 最近ではオプティミスティック直接実行 (ODE) も Azure Cosmos DB SDK を使用するクエリでの Azure Cosmos DB のパフォーマ ンスに関するヒント | Microsoft Learn 高頻度でアップデートが行われているので追従しておきたい
18. Query Metrics を取得する RDB で言うところの EXPLAIN に相当する機能 最適化を行うためには正しく RU の消費を把握するのが絶対条件 ローカル開発環境や Data Explorer で取得する SQL クエリのパフォーマンスと実行メトリックを取得する | Microsoft Learn Azure Portal で実行した場合はパーティション単位でのメトリックも
20. Index Advisor を利用する 不足している Index の情報を返してくれる機能 PopulateIndexMetrics に true を指定してクエリを実行 使われている Index と不足している Index が返却される General Availability: Index Metrics in Azure Cosmos DB for NoSQL - Azure Cosmos DB Blog Index の最適化は最後の方に行うくらいで良い
21. Index Policy を最適化する Cosmos DB の RU は Index の読み書き分も含まれている 書き込み時には Index の作成に必要だった RU が乗ってきている プロパティの数が多くなると Index の作成コストが高くなる Vector Search に使う配列は Index 作成から除外するのが推奨
22. 運用
23. 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 を活用するのもお勧め
24. Workbooks の例
25. デフォルトで用意されている 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
27. OpenTelemetry を使った監視を有効化する 最新の C# / Java SDK では OpenTelemetry 対応済み 自動的に失敗したリクエストと遅いリクエストを収集してくれる Azure Cosmos DB SDK の監視 | Microsoft Learn Application Insights と組み合わせ利用するのがベスト 特定ユーザーの場合のみ処理が遅いケースにも対応可能 アラートの仕込みも容易
28. 終わりに Cosmos DB のパフォーマンス最適化 == データモデリングの最適化 Cosmos DB の仕組みを知ると理解が進む データモデリングに時間を掛ける その後の開発と運用が楽になるため十分ペイできる 階層パーティションキー・Change Feed でパーティションキーの制約を超える RDB 脳を捨てて Cosmos DB 脳になろう
29. ご清聴ありがとうございました