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 ユース ケースに関するページを参照してください。
- 詳細については、変更フィードを中心としたリテールのユース ケースに関するページを参照してください。