在 AWS 中扩展内存消耗高但计算能力低的作业并使用 Docker：寻找最佳解决方案
Scale out jobs with high memory consumption but low computing power within AWS and using Docker: finding best solution
满口的标题，但重点是，我有一些符合这些要求的数据科学管道（基于python）：
- 使用基于服务器的“内部”编排器进行编排
- 运行 跨越许多 users/products /etc，其中 N 可能相对较高
- 我想分配的这个作业的“负载”，而不是被 orchestrator 服务器束缚
- 这些工作由 docker 图片支持
- 这些作业相对 运行（从 1 秒到 20 秒，post 数据加载）
- 这些工作通常需要大量 I/O 进出。
- 不需要
spark
- 我希望 scaling/provisioning/etc
的麻烦最少
- 数据 (in/out) 将存储在集群中的
HDFS space 或 AWS S3 中
docker 图片会比较大（包含数据科学堆栈）
我试图了解最多的 (a) cost-efficient 但 (b) 并行化这个东西的快速解决方案。到目前为止的候选人：
AWS ECSAWS lambda 支持容器镜像
请注意所有意图和目的scaling/computing在集群内是不可行的
我的问题是我担心大量数据传输（总体而言）的权衡，多次调用 docker 图像的巨大成本，你会花时间在服务器中设置容器但非常很少有时间做其他事情，无服务器管理和在 lambda 函数出现问题时进行调试。
一般是如何处理这类案件的？
这是个很好的问题。首先，我假设您将 Lambda 与 ECS/Fargate 进行比较（更多 here 用于 Fargate 背景）。虽然许多考虑因素适用于 ECS/EC2，但 ECS/Fargate 是更接近 Lambda 的模型。
话虽如此，Fargate 和 Lambda 差异很大，如果不考虑它们不同的编程和执行模型（事件驱动与基于服务），很难对两者进行同类比较。这并不是说您不能像调用 Lambda 那样在 Fargate 上将批处理作业调用到 运行，而是 1) 执行时间相对较短（1-20 秒）和 2) 在您所指的规模......按需调用每个执行单元的 Fargate 任务可能过于不利（例如，由于任务大小的粒度有限以及任务启动时间相比之下在 30-60 秒范围内）到 Lambda 的毫秒）。在这种情况下，更好的比较是每个作业的 Lambda 调用模型与多个 运行ning（并且可水平扩展）ECS/Fargate 任务，每个任务可以支持多个作业。
您在分析中没有提到的是这些工作是否已经存在，或者它们是否存在并且需要针对这些不同模型中的一个或多个进行调整（Lambda 1:1、Fargate 1:1, Fargate 1:many).有些客户可能会决定坚持使用特定模型，因为他们无力调整现有代码库。
总的来说，如果需要从头开始创建软件，Lambda 模型及其不干涉方法似乎更适合这种用例。
但就什么会更便宜而言，“理论上”很难做出决定。
满口的标题，但重点是，我有一些符合这些要求的数据科学管道（基于python）：
- 使用基于服务器的“内部”编排器进行编排
- 运行 跨越许多 users/products /etc，其中 N 可能相对较高
- 我想分配的这个作业的“负载”，而不是被 orchestrator 服务器束缚
- 这些工作由 docker 图片支持
- 这些作业相对 运行（从 1 秒到 20 秒，post 数据加载）
- 这些工作通常需要大量 I/O 进出。
- 不需要
spark - 我希望 scaling/provisioning/etc 的麻烦最少
- 数据 (in/out) 将存储在集群中的
HDFSspace 或AWS S3 中
docker图片会比较大（包含数据科学堆栈）
我试图了解最多的 (a) cost-efficient 但 (b) 并行化这个东西的快速解决方案。到目前为止的候选人：
AWS ECSAWS lambda支持容器镜像
请注意所有意图和目的scaling/computing在集群内是不可行的
我的问题是我担心大量数据传输（总体而言）的权衡，多次调用 docker 图像的巨大成本，你会花时间在服务器中设置容器但非常很少有时间做其他事情，无服务器管理和在 lambda 函数出现问题时进行调试。
一般是如何处理这类案件的？
这是个很好的问题。首先，我假设您将 Lambda 与 ECS/Fargate 进行比较（更多 here 用于 Fargate 背景）。虽然许多考虑因素适用于 ECS/EC2，但 ECS/Fargate 是更接近 Lambda 的模型。
话虽如此，Fargate 和 Lambda 差异很大，如果不考虑它们不同的编程和执行模型（事件驱动与基于服务），很难对两者进行同类比较。这并不是说您不能像调用 Lambda 那样在 Fargate 上将批处理作业调用到 运行，而是 1) 执行时间相对较短（1-20 秒）和 2) 在您所指的规模......按需调用每个执行单元的 Fargate 任务可能过于不利（例如，由于任务大小的粒度有限以及任务启动时间相比之下在 30-60 秒范围内）到 Lambda 的毫秒）。在这种情况下，更好的比较是每个作业的 Lambda 调用模型与多个 运行ning（并且可水平扩展）ECS/Fargate 任务，每个任务可以支持多个作业。
您在分析中没有提到的是这些工作是否已经存在，或者它们是否存在并且需要针对这些不同模型中的一个或多个进行调整（Lambda 1:1、Fargate 1:1, Fargate 1:many).有些客户可能会决定坚持使用特定模型，因为他们无力调整现有代码库。
总的来说，如果需要从头开始创建软件，Lambda 模型及其不干涉方法似乎更适合这种用例。
但就什么会更便宜而言，“理论上”很难做出决定。