每小时批量查询处理方案及执行追踪架构咨询

ECS Worker方案：简洁适配需求 #

当前100条/小时、最大5并行的查询任务，用「定时Lambda + SQS + ECS Worker」的组合完全合理，不算复杂：

• 定时Lambda逻辑简单：每小时从DynamoDB批量拉取查询元数据写入SQS，无需复杂逻辑
• ECS可配置基于SQS队列长度的自动扩缩容：队列有消息时自动扩容到最大5个实例，队列空时缩容到最小（甚至0），全程托管无需手动干预
• 所有组件都是AWS托管服务，运维成本低，且能轻松应对未来查询量增长（只需调整扩缩容阈值或SQS并发数）

EKS方案：当前场景下过度设计 #

EKS针对的是复杂容器编排场景（比如多服务混合部署、大规模集群、自定义网络策略等），你的需求只是简单的批量任务处理，用EKS会徒增复杂度：

• 需要维护K8s集群的节点、Pod调度、RBAC权限等，远超当前需求的运维成本
• 定时Lambda启动EKS的逻辑还要额外处理集群启停、节点组扩缩容，增加了不必要的故障点

• 结构化日志打点：在ECS Worker的查询执行代码中，给每个关键阶段（接收消息、开始执行、执行成功/失败、结束）打印JSON格式的结构化日志，包含query_name、query_id、status、duration、error_detail等字段，日志直接输出到CloudWatch Logs，方便后续检索和分析
• DynamoDB状态更新：在查询开始时，将DynamoDB中对应元数据的状态改为running，执行完成后更新为success或failed，同时记录执行时间、错误信息，快速查询单条查询的历史执行状态
• 全链路追踪（X-Ray）：如果需要追踪从Lambda入队到Worker执行的完整流程，给定时Lambda和ECS Worker开启X-Ray集成，通过统一的trace_id串联各个环节，直观查看每个步骤的耗时和故障节点
• SQS死信队列+重试机制：配置SQS的可见性超时（设为查询最长执行时间的2倍），执行失败的消息会自动重回队列重试；同时配置死信队列，将多次重试失败的消息转发，集中排查异常原因

内容的提问来源于stack exchange，提问作者Abhi