0

AWS スタック上に Lambda アーキテクチャを構築しています。DevOps の知識が不足しているため、カスタム デプロイよりも AWS マネージド ソリューションを優先せざるを得なくなりました。

私たちのワークフロー:

[Batch layer] 
Kinesys Firehouse -> S3 -Glue-> EMR (Spark) -Glue-> S3 views -----+                                                   
                                                                  |===> Serving layer (ECS) => Users                                                
Kinesys -> EMR (Spark Streaming) -> DynamoDB/ElasticCache views --+
[Speed layer]

ElasticCache、DynamoDB、S3 (Athena でクエリ) の 3 つのデータストアを既に使用しています。毎時 500,000 列から 6,000,000 列までのバッチ層を生成します。低レイテンシーのランダム読み取りでレイヤーを提供することで、過去 1 時間の結果のみをクエリする必要があります。

どちらのデータベースも、バッチ挿入とランダム読み取りの要件に適合しません。DynamoDB はバッチ挿入に適合しません。バッチ挿入に必要なスループットのためにコストがかかりすぎます。Athena は MPP であり、さらに 20 の同時クエリの制限があります。ElasticCache はストリーミング レイヤーで使用されますが、そこでバッチ挿入を実行することをお勧めします。

4 番目のストレージ ソリューションを導入するか、既存のソリューションを維持する必要がありますか?

考慮されるオプション:

  1. バッチ出力を DynamoDB および ElasticCache に永続化します (ほとんど更新されず、圧縮/集約できるデータの一部は DynamoDB に移動します。頻繁に更新されるデータ ~8GB/日は ElasticCache に移動します)。
  2. 別のデータベース (HBase on EMR over S3/ Amazon redshift?) をソリューションとして導入する
  3. S3 Select を parquetで使用して、Athena の同時クエリ制限を克服します。これにより、クエリのレイテンシも短縮されます。しかし、S3 Select には同時クエリ制限がありますか? 関連情報が見つかりません。

最初のオプションは、ストリーミングで使用される ElasticCache への一括挿入のために不適切です。また、Lambda アーキテクチャに従っていますか? バッチとスピード レイヤー ビューを同じデータ ストアに保持しますか?

4 番目のデータベース ストレージがあるため、2 番目のソリューションは良くありませんね。

4

1 に答える 1