1 日に数十億のメッセージを Kinesis にストリーミングしています。
1 回限りの保証で Kinesis にメッセージを配信できる実装を探しています。
当社のプロデューサー フレームワークでは、ストリーミング シンクが 1 回限りの配信を保証するために冪等である必要がありますが、Kinesis はそうではありません。そのため、現在、少なくとも 1 回の配信が行われています。(重複は可能であり、プロデューサー側で何らかの理由でストリーミング マイクロバッチを再起動する必要がある場合に発生します)
Kinesis Producer Library (KPL) のコールバック関数を調べ始めました。基本的に、各メッセージに存在するキーに基づいて、配信されたメッセージと DynamoDB にないメッセージの状態を追跡します。メッセージが既に送信されていることがわかっている場合は、配信をスキップして再試行します。次に、2つの懸念事項があります。
1) 私たちが持っている唯一の質問 - コールバック関数の呼び出しが失われる可能性 (例: ネットワーク障害など)、またはコールバック関数自体が失敗する可能性 (例: DynamoDB の制限/停止など) は、これはどこかに文書化されていますか？可能性が高くないことは承知していますが、このような予想される事態に対して回復力のあるシステムを設計したいと考えています。
2) タイミング。何らかの理由で、Kinesis が遅延を伴うコールバック関数を呼び出したとします (DynamoDB で配信状態を保持する上記のコールバック関数のいくつかの仮定を破るには、5 ～ 15 ミリ秒で十分です)。配信の確認を受け取っていませんが、ストリーミング プロデューサー フレームワークは、まだ配信されていないと判断した再配信を試みました。この潜在的な問題の回避策はありますか?
ps。回避策の 1 つは、アプリケーション側 (そのキネシス ストリームからのレシーバー) で重複排除を行うことですが、それは私たちのプロジェクトの範囲外であり、その Kinesis ストリームに 1 回だけ入るという厳しい要件があります。