问题描述
希望在 AWS 环境下实现以下目标：
– 能够执行 CPU 密集型（非并行）计算，每个任务至少分配 8 个虚拟 CPU（vCPU）。
– 设置任务的最小超时限制为 1800 秒（AWS Lambda 的限制为 900 秒）。
– 能够自动按需缩放任务数量，包括从 0 缩放到 1。
– 实现快速的任务扩展（不超过 30 秒）。
– 使用事件驱动的执行模型，每个任务分配给一个节点，任务结束后节点被销毁。
– 对每种事件/任务/作业类型分配所需的 vCPU 数量（3 种预定义类型）。
本文将介绍两种已尝试的方案，以及每种方案存在的问题。
解决方案
请注意，以下解决方案可能基于不同的 AWS 产品和版本，部分解决方案可能需要根据实际情况进行适当调整。
方案1 – AWS Lambda
架构图
方案说明
- 使用 AWS SQS 标准队列作为优化请求消息的入口，消息进入队列时触发 AWS Lambda（ROE）处理。
- AWS Lambda（配置为 3008 MB 内存）根据 SQS 队列中的消息触发，处理所有新添加到队列中的消息。AWS Lambda 的最大超时限制为 15 分钟。
存在问题
- AWS Lambda 无法手动配置更多的 CPU 资源，因此在处理中等复杂度的 VRP 时可能需要较长时间。
- AWS Lambda 的最大超时设置为 15 分钟，这使得用 Lambda 处理高复杂度的 VRP 问题变得不可能。
方案2 – AWS Batch
架构图
方案说明
- WA（Web Application）向 API 发送优化请求。
- API 创建一个 VRP（Vehicle Routing Problem）并将其存储在 S3 中。
- API 根据 VRP 复杂度（低、中、高）评估 VRP 的复杂度。
- API 创建一个 AWS Batch 作业，并为作业分配正确数量的 vCPU 和内存，作业的参数基于 VRP 的复杂度。
- API 将 AWS Batch 作业添加到相应的作业队列中。
- API 向 WA 返回 200 – OK 响应。
- AWS Batch 作业被从队列中取出并执行。
- AWS Batch 作业从 S3 获取 VRP，并解决问题，然后将解决方案存储在 S3 中。
- WA 从 API 请求解决方案。
- API 从 S3 中获取解决方案并将其返回给 WA。
存在问题
- 扩展需要的时间太长。
- 从 0 扩展到 1 节点所需时间过长（300+ 秒）。
- 从 1 扩展到 X 节点所需时间过长（60/300+ 秒）。
建议的解决方案 – AWS Fargate
AWS Fargate 是一个适合您需求的选择，以下是一种可能的实现方案。
方案说明
- 将任务提交到 AWS SQS 队列，触发一个调度 Lambda 函数。
- 调度 Lambda 函数获取任务并启动一个 AWS Fargate 任务。
- Fargate 任务执行任务，可以根据任务的类型为其分配所需的 vCPU 和内存。
注意事项
- 调度 Lambda 函数需要处理 SQS 消息并启动 Fargate 任务。需要另一个 Lambda 函数来处理任务执行失败的情况，以便处理重试。
- Fargate 最多支持 4 个 vCPU。
- 可以通过环境变量或命令行参数将数据传递给容器。
- Fargate 的启动时间不如 Lambda 快速，但比 Batch 和 EC2 要好。
- 处理死信（未处理消息）和重试是有一些麻烦的，但只要进程表现良好，实施起来并不难。
替代方案 – 使用 ECS
如果不介意支付额外的费用以获取未使用的容量，可以考虑使用 ECS 替代 Fargate。
方案说明
- 在 ECS 中创建一个具有足够未使用容量的集群，以便可以在需要时立即启动新容器。
注意事项
- 这样可以消除对 vCPU 数量的限制，但需要管理集群的大小并支付未使用的容量的费用。
以上是针对您问题的解决方案示例，具体方案可能会根据您的具体要求和 AWS 版本有所不同。请根据实际情况进行适当调整和测试。
正文完