Azure Cosmos DB の変更フィードを使用すると、書き込み量が多い大規模なデータセットを効率的に処理できます。 データセット全体に対してクエリを実行して変更を識別する代わりに使用できます。 この記事では、スケーラブルなソリューションの構築に役立つ一般的な変更フィードの設計パターン、そのトレードオフ、および制限事項について説明します。
シナリオ
Azure Cosmos DB は、IoT、ゲーム、小売、運用ログアプリケーションに最適です。 このようなアプリケーションの一般的な設計パターンでは、データの変更を使用して、他のアクションをトリガーします。 これらのアクションは次のとおりです。
- 項目が挿入、更新、または削除された場合の、通知または API 呼び出しのトリガー。
- IoT または運用データに対する分析のためのリアルタイム ストリーム処理。
- キャッシュ、検索エンジン、データ ウェアハウス、またはコールド ストレージとの同期などのデータ移動。
Azure Cosmos DB の変更フィードを使用すると、次の図に示すように、これらのパターンに対して効率的でスケーラブルなソリューションを構築できます。
イベントのコンピューティングと通知
Azure Cosmos DB の変更フィードは、特定のイベントに基づいて通知をトリガーしたり API を呼び出したりするシナリオを簡略化します。 変更フィード プロセッサを使用して、変更についてコンテナーを自動的にポーリングし、書き込み、更新、または削除ごとに外部 API を呼び出します。
特定の条件に基づいて、通知を選択的にトリガーするか、API を呼び出します。 たとえば、 Azure Functions を使用して変更フィードから読み取る場合は、条件が満たされた場合にのみ通知を送信するロジックを関数に追加します。 Azure 関数コードは変更ごとに実行されますが、通知は条件が満たされた場合にのみ送信されます。
リアルタイム ストリーム処理
Azure Cosmos DB の変更フィードを使用すると、IoT のリアルタイム ストリーム処理または運用データに対するリアルタイム分析を実行できます。 たとえば、デバイス、センサー、インフラストラクチャ、アプリケーションからイベント データを受信して格納し、 Spark を使用してこれらのイベントをリアルタイムで処理します。 次の図は、Azure Cosmos DB 変更フィードを使用してラムダ アーキテクチャを実装する方法を示しています。
多くの場合、ストリーム処理の実装では、最初に大量の受信データを、Azure Event Hubs や Apache Kafka などの一時メッセージ キューに受信します。 変更フィードは、高いデータ インジェスト率の持続と、読み取りと書き込みの低待機時間の保証をサポートする 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 to Live」（TTL）を設定することで、後で自動的に削除されるようにできます。
保持
最新バージョン モードの変更フィードの保持期間は無制限です。 項目がコンテナー内に存在する限り、変更フィードで使用できます。
保証された順序
すべての変更フィード モードで、1 つのパーティション キー値内の順序は保証されていますが、複数のパーティション キー値にまたがっての順序は保証されていません。 意味のある順序を保証するパーティション キーを選択する必要があります。
イベント ソーシング設計パターンを使用するリテール アプリケーションについて考えてみましょう。 このアプリケーションでは、さまざまなユーザー操作のそれぞれが、Azure Cosmos DB への書き込みとしてモデル化される "イベント" です。 たとえば、次の順序でイベントが発生した場合を考えてみましょう。
- 顧客が商品 A をショッピング カートに追加します。
- 顧客が商品 B をショッピング カートに追加します。
- 顧客が商品 A をショッピング カートから削除します。
- 顧客が支払いをして、ショッピング カートの中身が発送されます。
現在のショッピング カートの中身のマテリアライズドビューが顧客ごとに保持されます。 このアプリケーションでは、これらのイベントが発生順に処理されるようにする必要があります。 たとえば、カートのチェックアウトがアイテム A の削除前に処理される場合、顧客が代わりに必要とするアイテム B ではなく、アイテム A が顧客に出荷された可能性があります。 これら 4 つのイベントが順番に処理されるようにするには、同じパーティション キー値内に収まるようにする必要があります。
username (顧客ごとに一意のユーザー名がある) をパーティション キーとして選択した場合は、これらのイベントが Azure Cosmos DB に書き込まれるのと同じ順序で変更フィードに表示されることを保証できます。
例
提供されているサンプルの範囲を超えた最新バージョン モードの実際の変更フィード コードの例を次に示します。
- 詳細については、「 変更フィードの概要」を参照してください。
- 詳細については、 変更フィードを中心とした IoT ユース ケースを参照してください。
- 詳細については、 変更フィードを中心とした小売のユース ケースに関するページを参照してください。