技术栈
Python (Monolith API) - Flask 框架
PostgreSQL
我们已经部署了docker容器如下
我们现在面临 OOM(内存不足)问题的停机时间，然后给定 EC2 实例中的容器开始移动到另一个 EC2 实例，当由于某种原因第三个 EC2 实例不可用时会发生这种情况，所以直到第二个实例启动并运行，我们面临着给定容器集的停机时间。
所以想检查我们使用的策略是否正确？
我们现在还计划让小型 EC2 实例容纳较少数量的容器，因此如果发生问题，那么至少有少量站点关闭，而不是所有 15 个站点都关闭，我们是否朝着正确的方向前进？
我们应该搬到 Fargate 吗？与使用 ECS 相比，成本影响是什么？
如果有人帮助我为此类问题找到完美的解决方案，那就太好了。
在不久的将来，我们将在 100 秒内拥有容器，并且可能会达到 500 秒，因此我们必须决定部署、故障转移、高可用性的最佳策略。
最佳答案
如果您收到 OOM 错误，则意味着您的 EC2 机器被过度配置 - 您在这些机器上运行了太多容器。每个实例有 15 个容器，每个容器最多有 3072 个容器，这意味着在 16GB 的机器上可能有 46GB 的内存使用量。一旦有足够多的容器使用它们分配的内存，您的机器就会倒下，并带走所有其他任务。
因此，您现在可以做的第一件事是降低每台机器的任务数量或降低最大内存，以便任务总体使用更少的内存。由于每台机器上只有 2 个 CPU，我建议您对其进行调整，以便每台机器总共运行两个任务，并在它们之间分配内存，确保相应地提高其他设置(最大连接数、工作人员等)。
您还询问了 Fargate。我的公司将 EC2 和 Fargate 用于我们的容器，我们有一项政策，如果没有特定原因在 EC2 上运行东西(例如需要 GPU)，我们会将其放在 Fargate 上。虽然它多一点钱(与 Compute Savings Plans 相比没有那么多，但仍然更多)，但好处非常好。这意味着每个任务都是单独运行的，从而减少了一个任务取代一堆其他任务的机会。这也意味着更快的扩展周期，因为我们不必等待 EC2 实例扩展并加入集群 - 如果您使用应用程序自动扩展来响应突然涌入的流量，这非常重要。
Fargate 的最大好处是降低了复杂性，这反过来意味着我们的团队不必担心 - 为开发人员节省的时间和压力可能比花费的额外资金更有值(value)。简单的事实是，我们永远不必担心升级 ECS 代理、与补丁管理器集成以进行安全更新之类的事情，而且我们不需要定期循环机器以用新版本替换它们，这意味着我们可以将时间花在其他部分上取而代之的是我们的基础设施。
正如我上面提到的，虽然在某些情况下 Fargate 不合适。对我们来说，在 EC2 实例上运行的最大用例是能够选择我们用于运行 ML 的 GPU 类型。为此 we built our own AWS Machine Image适用于 AWS 提供的各种 GPU 实例。这基本上是我唯一不使用 Fargate 的地方，因为这些模型需要 EC2 实例 GPU。
关于amazon-web-services - 在 AWS ECS 服务中管理 Docker 容器的最佳实践，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/66022631/