問題タブ [amazon-kinesis-kpl]

Kinesis への接続に使用している次のように、マイクロサービスで Spring Bean を構成しています。

この GH の問題は、KPL がプロキシ構成をサポートしていないと述べていますが、ファイアウォールの背後で KPL を利用する方法があることを願っています。私の主な質問は、KPL がプロキシ構成をサポートしているかどうかです。サポートしていない場合、企業のファイアウォールの背後で KPL/KCL を使用するにはどうすればよいですか? ここでAWS Kinesis VPC エンドポイントについて読んだことがありますが、プロキシ構成で KPL を使用できない場合、これが唯一の代替手段でしょうか?

1 日に数十億のメッセージを Kinesis にストリーミングしています。

1 回限りの保証で Kinesis にメッセージを配信できる実装を探しています。

当社のプロデューサー フレームワークでは、ストリーミング シンクが 1 回限りの配信を保証するために冪等である必要がありますが、Kinesis はそうではありません。そのため、現在、少なくとも 1 回の配信が行われています。(重複は可能であり、プロデューサー側で何らかの理由でストリーミング マイクロバッチを再起動する必要がある場合に発生します)

Kinesis Producer Library (KPL) のコールバック関数を調べ始めました。基本的に、各メッセージに存在するキーに基づいて、配信されたメッセージと DynamoDB にないメッセージの状態を追跡します。メッセージが既に送信されていることがわかっている場合は、配信をスキップして再試行します。次に、2つの懸念事項があります。

1) 私たちが持っている唯一の質問 - コールバック関数の呼び出しが失われる可能性 (例: ネットワーク障害など)、またはコールバック関数自体が失敗する可能性 (例: DynamoDB の制限/停止など) は、これはどこかに文書化されていますか？可能性が高くないことは承知していますが、このような予想される事態に対して回復力のあるシステムを設計したいと考えています。

2) タイミング。何らかの理由で、Kinesis が遅延を伴うコールバック関数を呼び出したとします (DynamoDB で配信状態を保持する上記のコールバック関数のいくつかの仮定を破るには、5 ～ 15 ミリ秒で十分です)。配信の確認を受け取っていませんが、ストリーミング プロデューサー フレームワークは、まだ配信されていないと判断した再配信を試みました。この潜在的な問題の回避策はありますか?

ps。回避策の 1 つは、アプリケーション側 (そのキネシス ストリームからのレシーバー) で重複排除を行うことですが、それは私たちのプロジェクトの範囲外であり、その Kinesis ストリームに 1 回だけ入るという厳しい要件があります。