Azure Cosmos DB の変更フィードの読み取り
適用対象: 
NoSQL
Azure Cosmos DB の変更フィードは、プッシュ モデルかプル モデルのいずれかを使用して操作できます。 プッシュ モデルでは、変更フィード プロセッサによって、作業が、その作業を処理するためのビジネス ロジックを備えたクライアントにプッシュされます。 ただし、作業を確認して最後に処理された作業の状態を保存する場合の複雑さは、変更フィード プロセッサ内で処理されます。
プル モデルでは、クライアントによって作業がサーバーからプルされる必要があります。 この場合、クライアントでは、作業を処理するだけでなく、最後に処理された作業の状態を格納したり、作業を並列処理する複数のクライアント間での負荷分散を処理したり、エラーを処理したりするためのビジネス ロジックが使用されます。
Azure Cosmos DB の変更フィードからデータを読み取る場合は、次のことを心配する必要がないため、通常はプッシュ モデルを使用することをお勧めします。
- 今後の変更のために変更フィードをポーリングする。
- 最後に処理された変更の状態を格納する。 変更フィード プロセッサから読み取る場合、状態はリース コンテナーに自動的に格納されます。
- 変更を使用する複数のクライアント間での負荷分散。 たとえば、あるクライアントが変更の処理を維持できない場合で、別のクライアントには使用可能な容量がある場合などです。
- エラーの処理。 たとえば、コード内の処理されない例外や一時的なネットワークの問題が発生した後に、正常に処理されなかった変更が自動的に再試行されます。
Azure Cosmos DB の変更フィードを使用するシナリオのほとんどでは、プッシュ モデルのオプションが使用されます。 ただし、シナリオによっては、プル モデルによる低レベルな制御が必要になる場合もあります。 これには以下が含まれます。
- 特定のパーティション キーから変更を読み取る
- クライアントが処理のために変更を受け取るペースを制御する
- 変更フィードの既存のデータを 1 回だけ読み取る (データ移行を行う場合など)
プッシュ モデルを使用した変更フィードの読み取り
プッシュ モデルは、変更フィードからデータを読み取るための最も簡単な方法です。 変更フィードからの読み取りをプッシュ モデルで行うには、2 つの方法があります。Azure Functions Azure Cosmos DB トリガーを使う方法と、変更フィード プロセッサを使う方法です。 Azure Functions では、変更フィード プロセッサがバックグラウンドで使用されます。そのため、これらはどちらも似た変更フィードの読み取り方法となります。 Azure Functions は、まったく異なる読み取り方法ではなく、単に変更フィード プロセッサのホスティング プラットフォームであると考えてください。
Azure Functions
変更フィードの使用にまだ慣れていない場合は、Azure Functions を使用するのが最も簡単な方法です。 シンプルな方法なので、変更フィードのほとんどのユース ケースで推奨されるオプションでもあります。 Azure Cosmos DB 用の Azure Functions トリガーを作成する場合、接続先のコンテナーを選択すれば、そのコンテナーに変更が加えられるたびに Azure Function がトリガーされます。 Azure Functions では、変更フィード プロセッサがバックグラウンドで使用されるため、変更処理がコンテナーのパーティション間で自動的に並列化されます。
Azure Functions を使うと開発作業が簡単ですし、自分で変更フィード プロセッサをデプロイするよりもスピーディです。 トリガーは、Azure Functions ポータルを使用して作成することもできますし、SDK を使用してプログラムで作成することもできます。 Visual Studio と VS Code では、Azure Functions の作成がサポートされ、クロスプラットフォーム開発のために Azure Functions CLI を使用することもできます。 デスクトップでコードを記述してデバッグを行い、1 回のボタン操作で関数をデプロイできます。 詳しくは、Azure Functions を使用したサーバーレス データベース コンピューティングおよび変更フィードと Azure Functions の使用に関する記事をご覧ください。
変更フィード プロセッサ ライブラリ
サポートされる SDK
| .Net V3 | Java | Node.JS | Python |
|---|---|---|---|
| ✓ | ✓ | ✕ | ✕ |
変更フィード プロセッサは、変更フィードをより細かく制御するために使用されますが、複雑な操作の多くはバックグラウンドで実行されます。 変更フィード プロセッサ ライブラリはオブザーバー パターンに従い、処理関数はライブラリによって呼び出されます。 変更フィード プロセッサは、変更があるかどうかを自動的に確認し、変更が見つかった場合は、それらをクライアントに "プッシュ" します。 高スループットの変更フィードがあれば、変更フィードを読み取るための複数のクライアントをインスタンス化できます。 変更フィード プロセッサでは、負荷がクライアント間で自動的に分割されます。 複数のクライアント間で負荷を分散するためのロジックや、リースの状態を維持するためのロジックを実装する必要はありません。
変更フィード プロセッサでは、すべての変更が "最低 1 回" 配信されることが保証されます。 つまり、変更フィード プロセッサを使用した場合、変更フィード内のすべての項目に対して処理関数が正常に呼び出されます。 処理関数のビジネス ロジックで処理されない例外が発生した場合、失敗した変更は正常に処理されるまで再試行されます。 変更フィード プロセッサが同じ変更を何度も再試行して処理が "行き詰まる" ことのないよう、例外の発生時に配信不能キューにドキュメントを書き込むためのロジックを、処理関数に追加するようにしましょう。 エラー処理の詳細については、こちらを参照してください。
Azure Functions でも、エラー処理の推奨事項は同じです。 やはり、例外が発生した場合に配信不能キューにドキュメントを書き込めるよう、委任コードにロジックを追加する必要があります。 ただし、Azure Function で処理されない例外が発生した場合、例外を生成した変更は自動的には再試行されません。 ビジネス ロジックで処理されない例外が発生した場合、Azure Function は次の変更の処理に移ります。 Azure Function では、変更が失敗しても、同じ変更の再試行は行われません。
Azure Functions と同様、変更フィード プロセッサ ライブラリを使用した開発も簡単です。 ただし、変更フィード プロセッサ用のホストを 1 つ以上デプロイする作業は、開発者の責任で行う必要があります。 ホストは、変更フィード プロセッサを使って変更をリッスンするアプリケーション インスタンスです。 Azure Functions には自動スケーリング機能がありますが、ホストの拡張はお客様が行う必要があります。 詳しくは、変更フィード プロセッサの使用に関する記事をご覧ください。 変更フィード プロセッサ ライブラリは Azure Cosmos DB SDK V3 の一部です。
プル モデルを使用した変更フィードの読み取り
変更フィードのプル モデルでは、Azure Cosmos DB の変更フィードを自分のペースで使用できます。 変更はクライアントによって要求される必要があり、変更の自動ポーリングは行われません。 最後に処理された変更を (プッシュ モデルのリース コンテナーのように) 永続的に "ブックマーク" する場合は、継続トークンを保存する必要があります。
変更フィードのプル モデルを使用すると、変更フィードをより緩やかに制御できます。 変更フィードをプルモデルで読み取る場合、次の 3 つのオプションがあります。
- コンテナー全体を対象に変更を読み取る
- 特定のフィード範囲を対象に変更を読み取る
- 特定のパーティション キー値を対象に変更を読み取る
変更フィード プロセッサと同様に、変更の処理を複数のクライアント間で並列化することができます。 ただし、プルモデルでは、クライアント間の負荷分散が自動的に処理されるわけではありません。 プルモデルを使用して変更フィードの処理を並列化する場合は、まず、フィード範囲の一覧を取得します。 フィード範囲には、パーティション キー値の範囲が指定されています。 フィード範囲を取得し、それらをコンピューター間で分散するオーケストレーター プロセスが必要となります。 その後、それらのフィード範囲を使用して、複数のマシンで同時に変更フィードを読み取れるようになります。
プル モデルでは、"最低 1 回" の配信保証は組み込まれていません。 プル モデルは、エラーの処理方法を決定するための、低レベルな制御を提供するものでます。
Cassandra と MongoDB の API の変更フィード
変更フィード機能は、MongoDB 用 API では変更ストリームとして表示され、Cassandra 用 API では述語を含むクエリとして表示されます。 MongoDB 用 API の実装の詳細については、Azure Cosmos DB for MongoDB の変更ストリームに関するページを参照してください。
ネイティブ Apache Cassandra には、変更データ キャプチャ (CDC) が用意されています。これは、特定のテーブルに対してアーカイブのフラグを設定し、CDC ログ用に構成可能なディスク上のサイズに達すると、そのテーブルへの書き込みを拒否するメカニズムです。 Azure Cosmos DB for Apache Cassandra の変更フィード機能により、CQL を介して述語を使って変更をクエリする機能が向上します。 実装の詳細については、Azure Cosmos DB for Apache Cassandra の変更フィードに関するページを参照してください。
次のステップ
以下の記事では、変更フィードについて引き続き詳しく知ることができます。