問題タブ [resiliency]

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

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

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

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

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

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

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

AWS Lambda のエラー処理について多くのことを読んでも、実行中の Lambda コンテナが単にクラッシュするというトピックはカバーされていません。

1つのように見えるので、これは可能性ですか？S3 へのファイルのアップロードによってトリガーされる Lambda を使用してイベント駆動型システムを構築していますが、ラムダが停止した場合に処理をピックアップするロジックを構築する必要があるかどうかは不明です。

例: S3 でファイル オブジェクトが作成される -> S3 が Lambda にイベントを通知する -> 処理を開始する前に Lambda インスタンスがクラッシュする -> イベントが永久に失われる* (ここでの仮定、それが正しいかどうかはわかりませんが、できます逆に言うことは何も見つかりません）。

S3 にあるものと毎日処理されたものを調整するためのロジックを構築することについて議論しているので、(まれではありますが) ラムダが死亡した (死亡し、DLQ に失敗を書き込むことができなかった) シナリオを検出できます。これらのファイルを処理します。これは価値がありますか？S3 は、ラムダが停止し、イベントを独自の DLQ に配置する必要があることをどうにかして知るでしょうか?