Azure Cosmos DB の変更フィードの設計パターン
適用対象: 
NoSQL
Azure Cosmos DB の変更フィードは、大量の書き込みを伴う大規模なデータセットの効率的な処理を可能とします。 変更フィードは、データセット全体にクエリを実行して変更内容を確認する方法に代わる機能を提供します。 このドキュメントでは、一般的な変更フィードの設計パターン、設計のトレードオフ、および変更フィードの制限事項に重点を置きます。
Azure Cosmos DB は、IoT、ゲーム、小売、操作ログといったアプリケーションに最適です。 このようなアプリケーションの一般的な設計パターンでは、データの変更を使用して、他のアクションをトリガーします。 そうしたアクションの例を次に示します。
- 項目が挿入、更新、または削除された場合の、通知または API 呼び出しのトリガー。
- IoT のリアルタイム ストリーム処理または運用データのリアルタイム分析処理。
- キャッシュ、検索エンジン、データ ウェアハウス、またはコールド ストレージとの同期などのデータ移動。
Azure Cosmos DB の変更フィードにより、次の図のようにこれらの各パターンに対応する効率的でスケーラブルなソリューションを構築できます。
イベントのコンピューティングと通知
Azure Cosmos DB の変更フィードでは、特定のイベントに基づいて API に通知をトリガーするか呼び出しを送信する必要のあるシナリオを簡略化することができます。 変更フィード プロセッサを使用して、コンテナーの変更を自動的にポーリングし、書き込み、更新、または削除が行われるたびに外部 API を呼び出すことができます。
また、特定の条件に基づいて、選択的に通知をトリガーしたり、API の呼び出しを送信したりすることもできます。 たとえば、Azure 関数を使用して変更フィードからの読み取りを行っている場合、条件が満たされた場合にのみ通知を送信するように、関数にロジックを組み込むことができます。 Azure 関数のコードは変更がある度に実行されますが、通知は条件が満たされた場合にのみ送信されます。
リアルタイム ストリーム処理
Azure Cosmos DB の変更フィードは、IoT のリアルタイム ストリーム処理や運用データのリアルタイム分析処理に使用できます。 たとえば、デバイス、センサー、インフラストラクチャ、アプリケーションからイベント データを受信して保存し、その後に Spark を使用することでこれらのイベントをリアルタイムに処理できます。 次の図は、Azure Cosmos DB の変更フィードを使用して、ラムダ アーキテクチャを実装する方法を示しています。
多くの場合、ストリーム処理の実装では、最初に大量の受信データを、Azure Event Hubs や Apache Kafka などの一時メッセージ キューに受信します。 変更フィードは、高いデータ インジェスト率の持続と、読み取りと書き込みの低待機時間の保証をサポートする Azure Cosmos DB の機能により、優れた代替手段となっています。 メッセージ キューに優る Azure Cosmos DB の変更フィードの利点は次のとおりです。
データの永続化
Azure Cosmos DB に書き込まれたデータは、変更フィードに表示されます。 最新バージョン モードを使用して読み取りを行う場合、データは削除されるまで変更フィードに保持されます。 メッセージ キューには通常、最大保持期間が設けられています。 たとえば、Azure Event Hubs には最大 90 日間のデータ保持期間が設けられています。
クエリ機能
Azure Cosmos DB コンテナーの変更フィードからの読み取りに加えて、Azure Cosmos DB に保存されているデータに対して SQL クエリを実行することもできます。 変更フィードは、コンテナー内に既に存在するデータを複製したものではなく、データを読み取る別のメカニズムにすぎません。 そのため、変更フィードからデータを読み取る場合、そのデータは同じ Azure Cosmos DB コンテナーのクエリと常に整合性があります。
高可用性
Azure Cosmos DB には、最大 99.999% の読み取りと書き込みの可用性が備わっています。 多くのメッセージ キューとは異なり、Azure Cosmos DB のデータは簡単にグローバルに分散させ、目標復旧時間 (RTO) を 0 にして構成することができます。
変更フィードの項目を処理した後で、Azure Cosmos DB に戻って具体化されたビューを構築したり、集計された値を保持したりできます。 たとえば、Azure Cosmos DB を使用してゲームを構築している場合、変更フィードを使用して完了したゲームのスコアに基づくリアルタイムのランキングを実装できます。
データの移動
リアルタイムのデータ移動のために変更フィードからデータを読み取ることもできます。
たとえば、変更フィードを使用すると、次のタスクを効率よく実行できます。
Azure Cosmos DB に保存されているデータを使用して、キャッシュ、検索インデックス、またはデータ ウェアハウスを更新します。
別の Azure Cosmos DB アカウントや異なる論理パーティション キーを持つ別の Azure Cosmos DB コンテナーへのダウンタイムなしの移行を行います。
アプリケーション レベルのデータの階層化とアーカイブを実装する。 たとえば、"ホット データ" を Azure Cosmos DB に格納し、古くなった "コールド データ" を Azure Blob Storage などの他のストレージ システムに格納することができます。
パーティションとコンテナーの間でデータを非正規化する必要がある場合は、こうしたデータ レプリケーションのソースとして、コンテナーの変更フィードから読み取ることができます。 変更フィードを使用したリアルタイムのデータ レプリケーションが保証できるのは最終的な整合性のみです。 Azure Cosmos DB コンテナーでの変更の処理中に変更フィード プロセッサがどのくらい遅れるかを監視できます。
イベント ソーシング
イベント ソーシング パターンでは、追加専用ストアを使用して、そのデータに対する一連のアクションをすべて記録します。 Azure Cosmos DB の変更フィードは、すべてのデータ インジェストが書き込みとしてモデル化されている (更新や削除がない) イベント ソーシング アーキテクチャの主要データ ストアとして最適な選択肢です。 この場合、Azure Cosmos DB への各書き込みは "イベント" です。そのため変更フィードには過去のイベントの完全な記録があります。 主要イベント ストアによって発行されるイベントの一般的な用途は、具体化されたビューを維持したり、外部システムと統合したりすることです。 変更フィードの最新バージョン モードには保持期間の制限がないため、Azure Cosmos DB コンテナーの変更フィードの先頭から読み取ることによって、過去のすべてのイベントを再生できます。 複数の変更フィード コンシューマーが同じコンテナーの変更フィードにサブスクライブするようにすることもできます。
Azure Cosmos DB は、その水平スケーラビリティと高可用性の強みにより、イベント ソーシング パターンの優れた追加専用の中央永続データ ストアになります。 さらに、変更フィード プロセッサは "少なくとも 1 回" の保証を行っているため、どんなイベントも処理し損なうことがありません。
現在の制限
変更フィードには複数のモードがあり、それぞれに理解しておく必要がある重要な制限があります。 最新バージョン モードまたはすべてのバージョンと削除モードのどちらかで変更フィードを使用するアプリケーションを設計する場合、考慮すべきいくつかの領域があります。
中間の更新
最新バージョン モードでは、変更フィードには、特定の項目の最新の変更のみが含まれます。 変更を処理するときは、利用可能な最新バージョンの項目を読み取ります。 短時間のうちに同じ項目に対して複数の更新が発生すると、中間の更新を処理し損なう可能性があります。 項目に対する過去の個々の更新を再生する必要がある場合は、代わりにこれらの更新を一連の書き込みとしてモデル化するか、すべてのバージョンと削除モードを使用します。
Deletes
変更フィードの最新バージョン モードでは、削除はキャプチャされません。 コンテナーから項目を削除すると、その項目は変更フィードからも削除されます。 削除に対処する最も一般的な方法は、削除される項目にソフト マーカーを追加することです。 deleted というプロパティを追加し、削除時にこれを true に設定することができます。 このドキュメントの更新は、変更フィードに表示されます。 この項目が後で自動的に削除されるように、この項目で Time を Live (TTL) に設定することができます。
保持
最新バージョン モードの変更フィードの保持期間は無制限です。 項目がコンテナー内に存在する限り、変更フィードで使用できます。
保証された順序
すべての変更フィード モードで、1 つのパーティション キー値内の順序は保証されていますが、複数のパーティション キー値にまたがっての順序は保証されていません。 意味のある順序を保証するパーティション キーを選択する必要があります。
たとえば、イベント ソーシング設計パターンを使用する小売アプリケーションについて考えてみます。 このアプリケーションでは、さまざまなユーザー操作のそれぞれが、Azure Cosmos DB への書き込みとしてモデル化される "イベント" です。 たとえば、次の順序でイベントが発生した場合を考えてみましょう。
- 顧客が商品 A をショッピング カートに追加します。
- 顧客が商品 B をショッピング カートに追加します。
- 顧客が商品 A をショッピング カートから削除します。
- 顧客が支払いをして、ショッピング カートの中身が発送されます。
現在のショッピング カートの中身のマテリアライズドビューが顧客ごとに保持されます。 このアプリケーションでは、これらのイベントが発生順に処理されるようにする必要があります。 たとえば、商品 A の削除前にカートの支払いが処理されるとすると、顧客が希望する商品 B の代わりに商品 A が顧客に発送されたということが起こり得ます。これらの 4 つのイベントが発生順に処理されることを保証するためには、これらが同じパーティション キー値内に存在する必要があります。 username (顧客ごとに一意のユーザー名がある) をパーティション キーとして選択した場合は、これらのイベントが Azure Cosmos DB に書き込まれるのと同じ順序で変更フィードに表示されることを保証できます。
例
ここでは、提供されるサンプルの範囲を超える、最新バージョン モードの変更フィードの実際のコード例をいくつか紹介します。