amazon-web-services - 适用于频繁更新的关键小文件的 AWS EFS

Question

我们应用程序的用户群已达到 200 万用户，我们计划使用 AWS 扩展应用程序。

我们面临的主要问题是共享数据的处理，包括缓存、上传、模型、会话等。

一个选项是 AWS EFS，但它会降低应用程序的性能，因为文件非常小，从几字节到几 MB 不等，并且更新非常频繁。

我们可以使用 Memcache/Redis 进行会话，使用 S3 进行上传，但仍然需要管理缓存、模型和其他一些共享文件。

是否有任何替代 EFS 的方法或任何方法可以使 EFS 在这种小文件经常更新的情况下工作？

标签： amazon-web-servicesamazon-efsaws-application-load-balancer

Answer 1

小文件和频繁更新对于 EFS 来说应该不是问题。

一些用户在原始版本中遇到的问题是它有两个紧密耦合在一起的维度——可用吞吐量是你支付多少的函数，你支付多少是总大小的函数文件系统（所有文件组合在一起，无论单个文件大小如何）......所以越大，速度越快。

但从那时起，他们引入了“预置吞吐量”，允许您将这两个维度解耦。

这种默认的 Amazon EFS 吞吐量突增模式提供了适合大多数应用程序的简单体验。现在，借助预置吞吐量，吞吐量要求高于 Amazon EFS 默认吞吐量突增模式所允许的应用程序可以立即且始终如一地达到所需的吞吐量水平，而不受数据量的影响。

https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-efs-now-supports-provisioned-throughput/

如果您使用此功能，您将支付您预置的吞吐量与本来应该包含的吞吐量之间的差额，无论如何，这取决于数据的大小。

另请参阅Amazon Elastic File System 用户指南中的Amazon EFS 性能。

预置吞吐量可以被激活和停用，因此不要将这与还有两种性能模式（称为General Purpose和Max I/O ）混淆，创建文件系统时必须选择其中一种，而这个选择可以以后改不了。这些与底层基础架构中的可选折衷有关，建议的做法是选择通用用途，除非您有理由不这样做，基于观察到的指标。Max I/O模式没有与通用模式相同的元数据一致性模型。