こんにちは、サイオステクノロジー 技術2部 水倉です。
Microsoft Build 2019 初日のセッション「Building event driven apps with Azure Functions and Azure Cosmos DB change feed」をレポートします。
わかりやすく、実践的な内容で素晴らしかったです。セッション全体の流れについては、一緒に Build に参加している弊社・武井がいち早く記事を公開していますので、私からは補足的にその他の内容をお伝えします。
そもそも Cosmos DB の変更フィードとは何か?
まず最初に、Cosmos DB のリソースモデルをおさらいしておきましょう。
アカウント -> DB -> コンテナ -> ドキュメント
(※) 左から右の要素に対して 1 対 N の多重度(例:1 つのアカウントに対して DB は N 件)
ドキュメントが JSON で保持されるレコードで、コンテナはドキュメントのコレクションになります。
Cosmos DB の変更フィードとは、コンテナ内のドキュメントの変更履歴です。更新順に一覧で保持されます。全ての変更履歴を保持していますので、Cosmos DB コンテナ作成からの変更内容をリプレイして、最新状態を作成することが可能です。いわゆるイベントソーシング (参考:Microsoft のクラウドデザインパーンの解説)ですね。
変更フィードをサブスクライブする方法(要は変更フィードに対するトリガー処理ですね)は 3 通りあり、下に行くほど細かな制御が可能です。
- Azure Functions
- 変更フィードプロセッサライブラリの利用
- SQL API SDK を用いた実装
本セッションではこの変更フィードを使って Cosmos DB をイベントソースとすることでリアルタイム性のあるイベントドリブンアプリの実現例を示してくれました。(全体の内容は弊社・武井の記事を参照)
参考:Azure Cosmos DB の変更フィード – 概要
データ量が増大しても一定のレイテンシをキープするためのパーティション設計
セッション終盤、データ量が増大しても一定のレイテンシーをキープするための設計について紹介がありました。
ユーザー情報をユーザー名で検索する場合、パーティションキーをユーザー名とすることで、同じユーザー名のユーザー情報は同じパーティションに格納されることが保証されるため、データ量が増えても性能劣化を抑えることができます。
コンテナはパーティションキーによって水平スケーリングされます。パーティションの考え方については<href=”https://docs.microsoft.com/ja-jp/azure/cosmos-db/partition-data” target=”_blank”>こちらが参考になります。。
セッションではスピーカーから興味深い質問が投げかけられました。
質問:何をパーティションキーにすべきか?
- Eメールアドレスで検索したい場合、パーティションキーに何を指定するべきか?
- ユーザー名、Eメールアドレスそれぞれで検索したいシナリオがある場合、パーティションキーに何を指定するべきか?
回答
- パーティションキーをEメールアドレスとする。
- ユーザー名、Eメールアドレスそれぞれをパーティションキーとした 2 つのコンテナを用意する。
KVS など、パーティションの概念があるデータストアでは同様の設計パターンを適用することがあります。重複したデータを保持することになるため、データの同期を取る仕組みを考える必要がありますが、Cosmos DB では変更フィードを利用できます。
変更フィードによって一方のコンテナへの変更を一方へ反映する。
Cosmos DB では秒間に消費する Request Units (RU)」が課金に関わってきますので、性能劣化を防ぐと同時にコストも抑える事が可能となります。
ユーザー名、Eメールアドレスそれぞれをパーティションキーとした 2 つのコンテナとした場合の RU 消費
このパーティションの設計パターンは Microsoft が Cosmos DB パーティショニングデザインパターンとしてまとめていますので、興味のある方はせひ読んでみてください。
参考:Azure Cosmos DB partitioning design patterns – Part 1
参考:Azure Cosmos DB partitioning design patterns – Part 1(Microsoft のさとうなおきさんによる日本語訳)
具体的なシナリオで段階的に設計を改善していく非常にわかりやすい素敵なセッションでした。資料もわかりやすい!
STI 水倉