使用S3存储应用程序配置文件

Question

我正在创建一个需要部署到AWS中多个区域的简单Web应用程序。该应用程序需要一些动态配置，该配置由单独的服务管理。通过此服务更改配置时，我需要将这些更改传播到所有区域中的所有Web应用程序实例。

我考虑过使用DynamoDB进行跨区域复制来实现这一点，但我不想在每个区域和复制控制台中增加运行DynamoDB的成本。然后我想到了使用本身就是跨区域的S3。

基本上，配置服务会将所有配置作为静态JSON文件写入S3。每个Web应用程序实例将定期检查S3，以查看自上次检查后是否有任何配置文件已更改，并在必要时下载新配置。配置更改不是时间敏感的，因此每隔5/10分钟轮换更改就足够了。

您之前是否有人使用过类似的方法来管理应用配置？你认为这是一个聪明的解决方案，还是你有更好的建议？

Answer 1

此配置的正确工具取决于配置的大小和所需的粒度。

您可以在单个区域中同时使用DynamoDB和S3来为所有区域的应用程序提供服务。您可以从S3中读取所有区域中的配置文件，并且可以从所有区域的单个DynamoDB表中读取配置记录。由于全球各地的距离存在一些延迟，但对于阅读配置而言，这应该不是什么大问题。

如果每次加载配置时都需要整套配置，则使用S3可能更有意义。但是，如果您需要阅读大型配置的小部分，应用程序的不同部分以及不同的时间和日程安排，那么将它存储在DynamoDB中会更有意义。

在这两个选项中，配置的成本很小，因为S3中的文本文件和少数文件到该文件的成本几乎是免费的。预计DynamoDB的成本相同，因为您可能只有几KB的数据，而且每秒的读取数量非常低（每秒5个读取容量就足够了）。即使您决定将数据复制到所有区域，它仍然几乎是免费的。

Answer 2

我有一个我写的应用程序，它的工作方式完全符合您的建议，而且效果非常好。正如所指出的那样，S3不是“固有的跨区域”，但它在多个可用区域内具有固有的持久性，并且与跨区域复制相结合应该绰绰有余。

在我的情况下，我的应用程序对配置更改也没有时间敏感性，但是除了定期进行应用程序轮询之外（在我的情况下每小时1次或每次长时间运行之后）我还让每个应用程序订阅了SNS端点，这样当配置文件在S3上发生更改时，会引发SNS事件并通知应用程序发生了更改 - 因此在某些情况下应用程序会立即获得配置更改，但是如果无论出于何种原因，他们都无法立即处理SNS事件，当服务器重新启动时，它们将在每小时的顶部“赶上”和/或在最坏的情况下，每隔60分钟轮询S3一次更改。