2

DynamoDB を ElasticSearch (ES) に複製することを検討しています。この目的のためにlogstash 入力プラグインを評価しましたが、次の欠点が見つかりました。

  • プル モードの logstash には、HA/フェイルオーバー機能がありません。レプリケーション用の SPOF になります
  • ES インデックスでアプリケーション レベルの結合を行いたくないため、複数のテーブルを 1 つの ES ドキュメントにマージしたいと考えています。プラグインは、このユース ケースの機能を提供しません。

したがって、次の 2 つのアプローチを評価しています。

  1. ラムダは DynamoDB ストリームを読み取り、SQS を介して ES にプッシュします
  2. AWS ラムダを置き換える独自の DynamoDB ストリーム プロセッサ

ここで、実際の問題に取り掛かります。Dynamo ストリームから ES にデータをレプリケートするには、同じエンティティに対して複数のミューテーションが存在する可能性があるため、順序付けが重要です。Streams/Lambda のドキュメントから、異なるストリーム シャードのコンテンツがラムダによって同時に処理されることが言及されています。

AWS は、DynamoDB ミューテーションがストリーム シャードにどのようにマッピングされるかについての詳細を文書化していません (または、少なくとも私は見つけることができませんでした)。

ミューテーションがどのストリーム シャードにマッピングされるかを制御できないと、ストリーム処理の並列化を制御する開発者の機能が提供されません。上記のアプローチ #1 では、同じ ES ドキュメントが順不同で更新される可能性があります。アプローチ #2 は順次処理することで解決できますが、シャードの配置戦略に関する契約がない場合、(データ パーティション間であっても) レプリケーションの並列化/スケーリングは許可されません。

スケールする方法と、レプリケーションを障害に対して回復力のあるものにする方法について何か考えはありますか? または、突然変異がdynamodbストリームシャードにどのように配置されるかについて、誰かが光を当てることができますか?

4

1 に答える 1

0

AWS の誰か (またはそれ以上の経験) が明確にする必要がありますが、私の理解では、各 Dynamo パーティションは最初は 1 つのシャードにマップされます。このシャードがいっぱいになると、子シャードが作成されます。各シャードとその子は、単一の KCL ワーカーによって順次処理されます。

アイテムのパーティション キーは宛先シャードを決定するために使用されるため、同じアイテムのミューテーションは同じシャード (またはその子) に配置されます。シャードとその子は、単一の KCL ワーカーによって正しい順序で処理されることが保証されています。各 KCL ワーカーは単一のラムダ インスタンスにもマップされるため、同じアイテムが異なるミューテーションで並行して処理されることはありません。

Dynamo ストリームは Kinesis ストリームとは異なりますが、Kinesis のドキュメントを読むことでパズルのピースをいくつか見つけることができました。非常に役立つ情報が掲載された興味深いブログもあります。

于 2016-10-16T03:02:36.420 に答える