扩展我们的AWS基础架构( 三 ) _AWS基础架构

文章插图
> Move Redis and Celery to Separate Services ?

我们称此新服务为Celery Beet，是因为我们认为Celery Beat库错过了这么好的机会。
这有一个主要的缺点：调用请求是通过HTTP完成的，因此您无法泡菜。但是，由于Celery建议不要使用Pickle，因此我们从未在代码中使用它。
重定向和链接缩短缩短链接的重定向发生在客户端应用程序上。转移到纯客户端应用程序意味着服务器无法在链接上提供301服务，因为所有请求都发送到了S3存储桶。当必须从/ x重定向到/ y时，客户端应用程序必须向服务器检查有关/ x的信息，并通过向DOM添加一个额外的参数来通知Prerenderer该页面将被重定向。为了确保Prerenderer能够继续使用，我们创建了一个页面，上面写着"重定向您，请稍等片刻"，并添加了额外的参数。
这对于内部重定向来说很好，因为我们没有那么多。对于缩短链接而言，这不是理想的选择，因为我们希望用户无需等待就可以直接进入那些缩短的链接，尤其是当我们需要在Meddy外部重定向时。
解决方案为了解决这个问题，我们创建了两个Lambda函数，这些函数提供了具有哈希和链接的Dynamo表。一个Lambda函数的任务是缩短，而另一个Lambda函数的任务是重定向缩短的链接。
此外，我们使用API网关作为重定向lambda函数的入口，并将其附加到这些URL的新（较短）域中。

文章插图
> Add Link Redirection using Lambda ?

这非常有效，因为Lambda实际上不提供维护，使用情况图，并且我们的数据库不必包含这些重定向的大型表。
记录与监控迫切需要更好的日志记录。服务器请求数量的增加意味着我们不再依赖旋转文件系统上的日志，因为文件旋转得如此之快。最重要的是，我们正在使用的服务数量正在增加，并且从不同文件系统中提取文件是一场噩梦。为所有服务使用集中式日志记录系统是一个挑战。
解决方案我们决定使用Grafana Loki构建日志记录和监视服务。Loki是受Prometheus启发的开源水平可伸缩的多租户日志聚合系统。而Grafana是开源分析和交互式可视化软件。本质上，我们使用Loki作为日志聚合工具，使用Grafana可视化这些日志。
想法是让我们的不同服务将日志推送到在Loki服务中打开的HTTP端点。然后，Loki将为它们建立索引并将日志以二进制格式存储在S3中，并将索引存储在DynamoDB表中。这为我们提供了一种在日志中查找某些标签的方法，例如特定的状态代码或特定的日志级别。它还使我们能够查询日志，甚至可以对它们应用聚合功能，例如计算最近5分钟内具有特定标签的日志数量。

文章插图
> Add Logging & Monitoring using Grafana Loki ?

对于事件监视，我们使用Grafana，但这次使用AWS CloudWatch 。Grafana充当CloudWatch的客户端，并按需轮询数据以使其可视化。
为了能够如上所述将日志推送到Loki，我们必须使用来自不同服务的不同技术，例如在应用程序服务器上构建处理程序以及附加到数据转储的Lambda函数。Lambda函数用于解析S3中的Load Balancer和CloudFront日志，然后将它们推送到Loki 。

文章插图
> One of our many screens on Grafana

结合使用数据处理程序和CloudWatch，我们能够为基础架构中的所有内容提供集中式日志记录和监视系统，您可以在一个位置监视所有内容。
全部一起

文章插图
> All done!

这可能是迄今为止我们最喜欢的文章！由于我们经历了许多挑战，因此显示出了很大的增长。最令人兴奋的是，这仍然是Meddy的开始。
感谢您的阅读！敬请期待更多！
(本文翻译自Yasser的文章《Scaling Our AWS Infrastructure》，参考：https://medium.com/swlh/scaling-our-aws-infrastructure-9e64e6817b8c)

【扩展我们的AWS基础架构】