扩展我们的AWS基础架构 _AWS基础架构

文章插图
> Scaling Our AWS Infrastructure

本文由Kareem Ayesh和Yasser El-Sayed撰写。
Meddy成立于2016年，自那时以来取得了巨大成功，这要归功于它的规模。2019年，我们在A轮融资?的基础上庆祝了第100,000笔预订和300万名用户服务。
在过去的四年中，Meddy经历了许多技术更改。本文是针对不断成长的科技创业公司的基础架构的技术建议。我们将讨论4年前基础架构的起点，多年来我们面临的所有问题以及按照实施顺序实施的增量解决方案。
如果您是一家成长型初创公司的抱负CTO，那么本文将为您带来极大的好处。
我们的整体我记得当首席执行官问我为什么说"因为成千上万的人使用它"时，CEO告诉我说他的代码比我编写的任何代码都要好。
…他是对的。

文章插图
> Monolithic Infrastructure

技术债务单独拥有一个整体不是问题。对于大多数整体而言，这是很自然的，它会优雅地进化并转变为科学怪人，而这正是我们所做的。
话虽如此，这也意味着很多问题将在项目的整个生命周期中显现出来，并且肯定有很多问题确实存在。
但是，我们担心的不是技术问题，而是无法解决的问题。
整体的存在意味着问题等于死胡同。很自然地，要求的功能越多，就会表现出更多的问题，解决这些问题与创建功能一样自然。
最初的重构和基础结构的更新对于建立应用程序的增长至关重要，从而为各个方面的潜在问题提供了潜在的解决方案。这样一来，新功能请求就不会产生一系列呃和或更糟的"我认为现在不可能" 。
踏脚石在当前的整体架构中，数据持久性是一个严重的难题。图像上载，数据库和日志都必须备份在根文件系统上，并在需要启动新实例时使用。由于那时没有暂存实例，因此在生产上进行测试，并且服务器始终都在发生故障，从而危及我们的数据！
需要解决的另一个大问题是部署。部署是通过SSH和git pull从我们的Github起源完成的，没有任何类型的脚本可以自动启动新进程，运行测试和报告失败。
解决方案显然，我们需要一些改变。我们决定，随着应用程序代码的更改，我们将进行小的基础结构更改，从而将数据库和文件上载移至单独的服务。
通过使用三个AWS服务解决了这三个问题：
· 使用RDS管理Postgres数据库
· 使用S3存储媒体上载
· 使用ElasticBeanstalk管理部署

文章插图
> Separate Data Sources ?

重申一下，我们在此项目中所做的总体更改并未带来基础架构的很大改善。这种分离只是意味着应用程序中将来的问题不会损坏任何敏感内容。此外，由于主EC2实例上只有一个应用程序，因此这意味着任何其他资源都可以存在于单独的服务器或服务上而不会出现问题。
这不是完美的：
· Celery和redis与应用程序本身在同一服务器上
· 前端应用程序是AngularJS和Django之间的混合渲染，有时会阻塞处理器
· 日志存储在文件服务器上。
那时，数量很少，我们没有很多服务甚至功能，因此这些问题是可以容忍的。
尽管如此，该项目为最终峰会奠定了非常重要的垫脚石。
搜索特别感谢Yusuf Musleh的帮助
搜索很麻烦，因为它花了很长时间并且不够准确。我们使用Postgres的Trigram相似性实现来实现搜索。在大量记录上，它不是最快的，并且在多个字段上的搜索根本不准确。
最重要的是，您无法真正控制这些搜索的行为。我们想跟踪这些搜索查询所遇到的所有问题。

文章插图
> A google Sheet containing all the improvements to search we want to do

每当我们出现错误的行为时，我们都无法通过当前的实现解决该行为。
解决方案搜索会占用其实例中的大量资源。我们决定不只是扩展实例并在其中运行搜索应用程序，而是决定启动一个单独的服务，该服务在EC2实例上本地运行ElasticSearch 。每当创建或更新新记录时，我们都会在EC2实例中更新索引。还有一个cronjob会定期更新整个索引。