Amazon Batch 的最佳实践

短作业 - 如果作业仅运行几秒钟，则调度批处理作业所需的开销可能比作业本身的运行时更长。解决方法是，在 Amazon Batch 中提交任务之前，请将任务一起 binpack。然后，将您的 Amazon Batch 作业配置为迭代任务。例如，将单个任务参数暂存到 Amazon DynamoDB 表或作为文件存入 Amazon S3 存储桶。考虑对任务进行分组，使每个作业运行 3-5 分钟。在 binpack 作业后，在 Amazon Batch 作业中循环遍历任务组。

必须立即运行的作业Amazon Batch – 可以快速处理作业。但是，Amazon Batch 是一个调度程序，可针对性价比、作业优先级和吞吐量进行优化。Amazon Batch 可能需要时间来处理您的请求。如果您需要在几秒钟内得到响应，那么使用 Amazon ECS 或 Amazon EKS 的基于服务的方法更合适。

查看您的 Amazon EC2 限额 – 在 Amazon Web Services Management Console 的“服务限额”面板中查看您的 Amazon EC2 限额（也称为限制）。如有必要，可以申请增加您的 Amazon EC2 实例峰值数量的限额。请记住，Amazon EC2 竞价型和 Amazon 按需型实例有单独的限额。有关更多信息，请参阅服务限额入门。

验证每个区域的 Amazon Elastic Block Store 限额 – 每个实例对操作系统使用 GP2 或 GP3 卷。默认情况下，每个 Amazon Web Services 区域 限额为 300 TiB。但是，每个实例都使用计数作为此限额的一部分。因此，在验证每个区域的 Amazon Elastic Block Store 限额时，请务必将其考虑在内。如果达到限额，则无法创建更多实例。有关更多信息，请参阅 Amazon Elastic Block Store 端点和限额

使用 Amazon S3 进行存储 – Amazon S3 提供高吞吐量，有助于消除根据每个可用区域中的作业和实例数量来猜测要配置多少存储空间。有关更多信息，请参阅最佳实践设计模式：优化 Amazon S3 性能。

逐步扩展以尽早发现瓶颈 – 对于在一百万或更多 vCPU 上运行的作业，从较低的起点开始并逐渐增加，这样您就可以尽早发现瓶颈。例如，首先在 5 万个 vCPU 上运行。然后，将计数增加到 20 万 vCPU，然后增加到 50 万 vCPU，依此类推。换句话说，继续逐渐增加 vCPU 数量，直到达到所需的 vCPU 数量。

监控以尽早发现潜在问题 – 为了避免在大规模运行时出现潜在的中断和问题，请务必同时监控您的应用程序和架构。即使从 1 千个 vCPU 扩展到 5 千个 vCPU，也可能会出现中断。您可以使用 Amazon CloudWatch Logs 来查看日志数据，也可以使用客户端库使用 CloudWatch 嵌入式指标。有关更多信息，请参阅 CloudWatch Logs 代理参考和aws-embedded-metrics

较小的容器可以更快地获取 – 较小的容器可以缩短应用程序的启动时间。要减小容器大小，请将不经常更新的库或文件卸载到亚马逊机器映像（AMI）。您也可以使用绑定挂载，为容器授予访问权限。有关更多信息，请参阅 绑定挂载。

创建大小均匀的层并分解大型层 — 每个层都由一个线程检索。因此，较大的层可能会显著影响您的作业启动时间。我们建议最大层大小为 2 GB，以便在更大的容器大小和更快的启动时间之间进行权衡。您可以运行 docker history your_image_id 命令来检查您的容器映像结构和层大小。有关更多信息，请参阅 Docker 文档。

使用 Amazon Elastic Container Registry 作为您的容器存储库 – 当您并行运行数千个作业时，自我管理的存储库可能会失败或限制吞吐量。Amazon ECR 可以大规模运行，可以处理多达一百多万个 vCPU 的工作负载。

作业必须快速启动，具体时间少于 30 秒。

您的作业要求为 16 个 vCPU 或更少、没有 GPU 和 120 GiB 或更少的内存。

您需要加强对实例选择的控制，或者需要使用特定的实例类型。

您的作业需要 Amazon Fargate 无法提供的资源，例如 GPU、更多内存、自定义 AMI 或 Amazon Elastic Fabric 适配器。

您需要较高的吞吐量或并发度。

您需要自定义 AMI、Amazon EC2 启动模板或访问特殊的 Linux 参数。

作业的运行时超过一个小时，您不能容忍工作负载中断。

您的总体工作负载有严格的 SLO（服务级别目标），并且不能增加计算时间。

您需要的实例更有可能出现中断。

作业的运行时通常为 30 分钟或更短。

您可以容忍潜在的中断，以及作业重新安排作为工作负载的一部分。有关更多信息，请参阅竞价型实例。

如果中断，可以从检查点重新启动长时间运行的作业。

选择 SPOT_CAPACITY_OPTIMIZED 分配策略 – Amazon Batch 从最深的 Amazon EC2 Spot 容量池中选择 Amazon EC2 实例。如果您担心中断，这是一个合适的选择。有关更多信息，请参阅 分配策略。

多样化实例类型 – 要使您的实例类型多样化，请考虑兼容的大小和系列，然后根据价格或可用性进行 Amazon Batch 选择。例如，考虑将 c5.24xlarge 作为 c5.12xlarge 或 c5a、c5n、c5d、m5 和 m5d 系列的替代方案。有关更多信息，请参阅灵活选择实例类型和可用区。

减少作业运行时或检查点 – 我们建议不要在使用 Amazon EC2 竞价型实例运行需要一小时或更长时间的作业，以免中断。如果将作业分成小部分或设置检查点，时间不超过 30 分钟，则可以显著降低中断的可能性。

使用自动重试 – 为避免 Amazon Batch 作业中断，请为作业设置自动重试。批处理作业可能由于以下任何原因而中断：返回非零的退出代码、发生服务错误或发生实例回收。您最多可以设置 10 次自动重试。首先，我们建议您至少设置 1-3 自动重试。有关跟踪 Amazon EC2 Spot 中断的信息，请参阅 Spot 中断控制面板。

对于 Amazon Batch，如果您设置了重试参数，则作业将放在作业队列的前面。也就是说，作业被优先考虑。在 Amazon CLI 中创建作业定义或提交作业时，可以配置重试策略。有关更多信息，请参阅 提交任务。

$ aws batch submit-job --job-name MyJob \
    --job-queue MyJQ \
    --job-definition MyJD \
    --retry-strategy attempts=2

使用自定义重试次数 – 您可以将作业重试策略配置为特定的应用程序退出代码或实例回收。在以下示例中，如果主机导致故障，则作业最多可以重试五次。但是，如果作业由于其他原因失败，则作业将退出并将状态设置为 FAILED。

"retryStrategy": {
    "attempts": 5,
    "evaluateOnExit":
    [{
        "onStatusReason" :"Host EC2*",
        "action": "RETRY"
    },{
      "onReason" : "*"
        "action": "EXIT"
    }]
}

使用 Spot 中断控制面板 – 您可以使用 Spot 中断控制面板来跟踪 Spot 中断情况。应用程序提供有关已回收的 Amazon EC2 竞价型实例以及竞价型实例所在的可用区的指标。有关更多信息，请参阅 Spot 中断控制面板

查看 Amazon EC2 Spot vCPU 限额 – 验证您当前的服务限额是否符合作业要求。例如，假设您当前的服务限额为 256 个 vCPU，而作业需要 10,000 个 vCPU。则服务限额不符合作业要求。有关更多信息和疑难解答说明，请参阅 Amazon EC2 服务限额和如何增加 Amazon EC2Resources 的服务限额？ 。

作业在应用程序运行之前失败 – 有些作业可能因为 DockerTimeoutError 错误或 CannotPullContainerError 错误而失败。有关疑难解答信息，请参阅如何解决 Amazon Batch 中的"DockerTimeoutError"错误？。

IP 地址不足 - 您的 VPC 和子网中的 IP 地址数量可能会限制您可以创建的实例数量。使用无类别域间路由，可提供多于运行工作负载所需的 IP 地址。如有必要，您还可以构建具有较大地址空间的专用 VPC。例如，您可以在 10.x.0.0/16 中创建一个包含多个 CIDR 的 VPC，并在每个可用区中创建一个子网，CIDR 为 10.x.y.0/17。在此示例中，x 介于 1-4 之间，y 为 0 或 128。此配置在每个子网中提供 36,000 个 IP 地址。

验证实例是否已在 Amazon EC2 中注册 – 如果您在 Amazon EC2 控制台中看到您的实例，但在 Amazon ECS 集群中看不到 Amazon Elastic Container Service 容器实例，则可能未在亚马逊机器映像（AMI）上安装 Amazon ECS 代理。Amazon ECS 代理、AMI 中的 Amazon EC2 数据或启动模板也可能配置不正确。要找出根本原因，请创建单独的 Amazon EC2 实例或使用 SSH 连接到现有实例。有关更多信息，请参阅 Amazon ECS 容器代理配置、Amazon ECS 日志文件位置和 计算资源 &AMI;。

查看 Amazon 控制面板 - 查看 Amazon 控制面板以验证预期的作业状态以及计算环境是否按预期扩展。您也可以查看 CloudWatch 中的作业日志。

验证您的实例是否已创建 - 如果创建了实例，则意味着您的计算环境按预期进行扩展。如果您的实例未创建，请在计算环境中找到要更改的关联子网。有关更多信息，请参阅验证自动扩缩组的扩展活动。

我们还建议您验证实例是否可以满足相关作业要求。例如，一项作业可能需要 1 TiB 的内存，但计算环境使用的 C5 实例类型限制为 192 GB 内存。

确认您的实例是由 Amazon Batch 请求的 – 查看自动扩缩组历史记录以验证您的实例是否由 Amazon Batch 请求过。这表明了 Amazon EC2 是如何尝试获取实例的。如果您收到错误消息，指出 Amazon EC2 Spot 无法在特定可用区获取实例，这可能是因为该可用区不提供特定的实例系列。

验证实例是否在 Amazon ECS 中注册 – 如果您在 Amazon EC2 控制台中看到实例，但在 Amazon ECS 集群中看不到任何 Amazon ECS 容器实例，则可能未在亚马逊机器映像（AMI）上安装 Amazon ECS 代理。此外，Amazon ECS 代理、AMI 中的 Amazon EC2 数据或启动模板可能配置不正确。要找出根本原因，请创建单独的 Amazon EC2 实例或使用 SSH 连接到现有实例。有关更多信息，请参阅 CloudWatch 代理配置文件：日志部分、Amazon ECS 日志文件位置 和 计算资源 &AMI;。

打开支持请求单 – 如果您在进行故障排除后仍遇到问题并且已经制定了支持计划，请打开支持请求单。在支持请求中，请务必包含有关问题、工作负载细节、配置和测试结果的信息。有关更多信息，请参阅比较 Amazon Web Services Support 计划。

查看 Amazon Batch 和 HPC 论坛 – 如需更多信息，请参阅Amazon Batch和 HPC 论坛。

查看 Amazon Batch 运行时监测控制面板 – 此控制面板使用无服务器架构捕获来自 Amazon ECS 的事件，Amazon Batch，和 Amazon EC2 来提供对作业和实例的见解。有关更多信息，请参阅Amazon Batch运行时监控面板解决方案。