我对云架构还很陌生，但有相当多的应用程序开发经验。目前，我正在通过 Web 应用程序让 5-10 位用户更方便地访问大型计算管道，并在 AWS 中完成所有设置。
我当前的实现是一个轻量级的 React Web 应用程序，它使用两个 API 和一个 MySQL 后端，允许用户使用参数排队作业，并通过 Web 应用程序或运行完成后发送给用户的电子邮件访问最终结果。
这条管道的中间部分依赖于一个专有软件，它需要一台非常强大的机器来计算这些步骤（64GB RAM、16 核、1TB HDD），并且仅这一步就可能运行长达 1.5 天。这是我整个管道中最大的瓶颈。
为了尽可能地节省成本，我尝试通过启动多个 EC2 实例“代理”来使瓶颈/服务部分可扩展/经济高效，运行步骤，发送电子邮件，写入 Web 应用程序数据库，然后通过由 Web 应用程序的操作触发的 AWS lambda 函数停止实例。
我计划为 Web 应用程序、2 个 API 和 MySQL 服务器托管一个 EC2 实例，因为这部分的并发性/可扩展性非常小。我还将为瓶颈服务提供另外 1-3 个实例，以共享来自 5-10 个用户的并发运行，这样最多可以同时运行 3 个繁重的步骤。
由于瓶颈服务需要类似的文件来运行程序，并且这些步骤的输入有时可能是 150GB 的文件大小，因此我正在考虑使用 EFS 或 S3 存储来保存输入，这样我只需要担心将输入文件传输到一个可以在 EC2 实例之间共享的地方，而不需要确保它们已启动以执行传输步骤。这是一个手动操作，由于文件大小太大，我还没有找到一个更好的自动化方法。
我的问题是，我的设置听起来合理吗？您是否发现我的实施思路存在漏洞？目前，我正在使用 EBS 存储服务实例，但我想尽量减少 150GB 传输/维护的输入位置。我也不确定 S3 和 EFS 之间的区别，因为它们似乎都可以安装多实例，但我应该使用哪一个？如果我需要服务实例在完成后能够写入数据库，那么将 Web 应用程序、API 和数据库放在一个 EC2 实例上是否有意义？该实例将一直处于打开状态。
谢谢您的帮助，如果我说了什么天真的话，请原谅我。
答案1
您的设置听起来确实合理。我建议您考虑使用 API 网关来“托管”您的 API，并考虑一下它是否适合您。您还可以考虑将重负载 EC2 实例放在 Autoscaling 组中，并让您的控制 Lambda 与其交互，而不是直接与实例交互。
S3 和 EFS 是不同的数据存储解决方案。S3 是对象存储，而 EFS 是文件存储。S3 并非完全可挂载，尽管它可能看起来像是通过不同的实用程序呈现的。无论是正确的使用 S3 还是 EFS 取决于您如何使用其中的文件。
对于数据库，您可以考虑使用 RDS，也许可以使用可突发实例类或无服务器选项之一。但这取决于您的预算和用例。
答案2
总体而言，在云中尝试使用服务而不是服务器是明智之举。您必须关注成本，但它可以使解决方案更强大、更快速、更合规。
对于你的工作量，我有几点想法：
- 您可以使用 AWS Step Functions 之类的编排器调用许多 AWS lambda 函数来进行计算吗？我确实注意到 lambda 可能是 AWS 上计算时间最昂贵的，因此可能并不理想。如果设置了正确的限制和合适的工作负载，也许您可以启动 10,000 个 lambda 并在 15 分钟内并行完成作业。
- 除了 EFS / S3，如何创建一个黄金 EC2 映像 / AMI，然后为每个作业启动一个足够大的现货 / 动态 EC2 实例来处理该作业，并在作业完成后关闭？Lambda 也许可以根据某种类型的事件来协调作业？这样可以避免数据传输费用 - 虽然不确定是否要向 EBS / S3 收取费用。现货计算非常便宜，如果您正确选择区域 / AZ / 实例大小，中断应该很少发生。中断的实例将被关闭，EBS 卷将被保留，因此如果您的作业定期写入磁盘并可以重新启动，这将更好地发挥作用。
我或许还会花一些时间来优化这项巨大的工作。