AWS体系结构建议-具有动态启动和停止的共享数据库/文件系统的多个EC2实例

Question

我在云架构方面很新，但有不错的应用程序开发经验。现在，我正在通过一个web应用程序使一个大的计算管道对5-10个用户更容易访问，并在AWS中设置所有这些。

我目前的实现是一个轻量级的React应用程序，它使用两个app和一个MySQL后端，允许用户通过web应用程序或运行完成后发送给用户的电子邮件，排队处理带有参数的作业，并访问最终结果。

在这条管道的中间是对一个专有软件的依赖，它需要一台非常强大的机器来计算这些步骤(64 up内存，16核，1TB HDD)，并且仅这一步就可以运行1.5天。这是我整个管道中最大的瓶颈。

为了尽可能节省成本，我试图通过打开多个EC2实例“代理”，运行步骤，发送电子邮件，写入web应用数据库，然后通过available函数停止该实例，从而实现瓶颈/服务块的可扩展/成本效益。

我计划为web应用程序托管一个EC2实例、2个app和MySQL服务器，因为这段代码上的并发/可伸缩性非常小。我还将为瓶颈服务提供另一个1-3个实例，以共享来自5-10个用户的并发运行，这将允许同时运行3次沉重的步骤。

由于瓶颈服务需要类似的文件来运行程序，而且这些步骤的输入有时可以是150‘t的文件大小，所以我考虑使用EFS或S3存储来保存输入，这样我只需要担心将输入文件传输到一个可以跨EC2实例共享的位置，并且我不需要确保它们已经开始执行传输步骤。这是一个手动的部分，我也没有想出一个好的方法来更自动化，因为文件大小太大了。

我的问题是，我的设置听起来合理吗?你认为我的实现思路有什么漏洞吗？目前，我正在为服务实例使用EBS存储，但我希望将150 am传输/维护的输入位置最小化。我也不确定S3和EFS之间的区别，因为它们似乎都是可安装的多实例，但是我应该使用哪一个呢？如果我需要能够在web应用程序、api和数据库完成后写入数据库的web应用程序、api和数据库，这是否有意义呢？这种情况会一直持续下去。

谢谢你的帮助，如果我说了些天真的话，请原谅我。

Answer 1

你的设置听起来很合理。我可能会建议您考虑使用一个API网关来“托管”您的API，如果它对您有用的话，请考虑一下。您还可以考虑将重载的EC2实例放在自动标度组中，并让您的控件Lambda与其交互，而不是直接与实例交互。

S3和EFS是不同的数据存储解决方案。S3是对象存储，EFS是文件存储。S3并不完全是可挂载的，尽管它的出现可能像通过不同的实用程序一样。使用S3或EFS是否正确取决于您如何使用那里的文件。

对于您的数据库，您可能会考虑使用RDS，可能使用可扩展实例类或无服务器选项之一。但这将取决于您的预算和用例。