Get best of the week

在远程站点上x10负载急剧增加的情况下，我们如何生存？得出的结论是什么？

哈Ha！在过去的几个月中，我们生活在一个非常有趣的环境中，我想分享一下我们扩展基础架构的历史。在此期间，SberMarket的订单增长了4倍，并在17个新城市推出了一项服务。送餐需求的爆炸性增长要求我们扩展基础架构。阅读猫下最有趣，最有用的发现。



我叫Dima Bobylev，我是SberMarket的技术总监。由于这是我们博客上的第一篇文章，因此我将对自己和公司说几句话。去年秋天，我参加了Runet青年领袖竞赛。在竞赛中，我写了一个简短的故事，内容涉及我们在SberMarket上如何看待内部文化和服务开发方法。尽管无法赢得竞争，但我为自己制定了开发IT生态系统的基本原则。

在管理团队时，重要的是了解并在业务需求和每个特定开发人员的需求之间找到平衡。现在，SberMarket每年以13倍的速度增长，这影响到产品，需要不断增加其数量和发展速度。尽管如此，我们仍将足够的时间用于开发人员进行初步分析和高质量的代码编写。形成的方法不仅有助于创建有效的产品，而且有助于其进一步扩展和开发。由于这种增长的结果，SberMarket已经成为食品配送服务的领先者：我们提供每天约每天18000台的订单，虽然在二月初有关于他们的3,500。


一旦客户要求SberMarket快递接触地把产品送到他-直接到阳台

但是，让我们继续具体。在过去的几个月中，我们一直在积极扩展公司的基础架构。外部和内部因素解释了这种需求。同时，随着客户群的扩大，关联商店的数量从年初的90家增加到5月中旬的200多家。当然，我们准备，保留了主要基础架构，并依靠Yandex云中所有虚拟机的垂直和水平扩展的可能性。但是，实践表明：“所有可能出错的地方都会出错。” 今天，我想分享一下最近几周发生的最有趣的情况。希望我们的经验对您有所帮助。

从机处于完全警报状态


甚至在大流行开始之前，我们就面临着对后端服务器的请求数量增加的问题。通过送货上门订购产品的趋势开始流行，并且随着与COVID-19相关的首批自我隔离措施的推出，整天的负担急剧增加。需要快速卸载主数据库的主服务器，并将部分读取请求传输到副本服务器（从服务器）。

我们正在为此步骤提前做准备，为此，已经启动了2个从属服务器。他们主要从事批处理任务，生成用于与合作伙伴交换数据的信息提要。这些过程造成了额外的负担，而且很正确地在几个月前就被“搁置了”。 

由于从站上存在复制，因此我们坚持以下概念：应用程序只能以只读模式与它们一起使用。灾难恢复计划建议，在发生灾难时，我们可以简单地将从站安装在主站上，然后将所有写入和读取请求切换到从站。但是，我们还希望使用副本来满足分析部门的需求，因此服务器并没有完全转移到只读状态，并且每个主机都有自己的一组用户，有些主机具有保存中间计算结果的写权限。

在一定的负载水平下，我们有足够的向导来处理HTTP请求时进行读写。 3月中旬，就在Sbermarket决定完全切换到远程站点时，我们开始大幅提高RPS。越来越多的客户选择自我隔离或在家工作，这在负载指标中得到了体现。

“母版”的性能不再足够，因此我们开始忍受某些对副本的最重读取请求。为了透明地发送写入主机的请求和读取从机的请求，我们使用了ruby宝石`` 章鱼''”。我们使用_readonly后缀创建了一个没有写权限的特殊用户。但是由于其中一台主机的配置错误，部分写请求代表具有适当权限的用户转到从属服务器。

问题并没有立即显现出来，因为增加负载会增加从属延迟。数据不一致是在早晨发现的，当时，在每晚导入之后，奴隶没有“跟上”主人。我们将其归因于服务本身的高负载以及与新商店的推出相关的导入。但它是不能接受的，以递交用一个多小时的延迟数据，我们切换过程的第二个分析的奴隶，因为它有更多的资源，并没有装载读取请求（这是我们对自己解释缺乏复制滞后）。

当我们弄清主从设备“蠕变”的原因时，由于相同的原因分析已经失败了。尽管存在两个额外的服务器，但由于不幸的错误，我们计划在主服务器崩溃时将负载转移到这两个服务器，但事实证明，在关键时刻都没有。

但是，由于我们不仅转储了数据库（当时剩下的时间约为5个小时），而且还对主服务器进行了快照，因此我们设法在2小时内启动了副本。没错，在那之后我们应该长时间滚动复制日志（因为该过程处于单线程模式，但这是一个完全不同的故事）。

: , readonly . , .

« »


尽管我们会不断更新站点上的目录，但是对从服务器的请求使Master稍有滞后。我们发现并消除了“突然掉线”奴隶问题的时间不仅仅是一个“心理障碍”（在这段时间内价格可能已经更新，客户会看到过时的数据），我们不得不将所有请求切换到主数据库服务器。结果，该网站运行缓慢...但是至少可以运行。在从属恢复期间，我们别无选择，只能进行优化。 

当从服务器恢复时，几分钟慢慢过去，Master仍然超负荷，我们根据帕累托规则致力于优化活动任务：我们选择了承担大部分负载的TOP请求并开始进行调整。这是“即时”完成的。

一个有趣的效果是，装载到眼球的MySQL甚至对流程的轻微改进做出了响应。一对请求的优化（仅占总负载的5％）已经显示出切实的CPU卸载。结果，我们能够为Master提供可接受的资源来使用数据库，并获得必要的时间来还原副本。 

结论：即使是很小的优化，您也可以在过载几个小时内“幸存”。这对于带有副本的服务器恢复期间就足够了。顺便说一句，我们将在以下文章之一中讨论查询优化的技术方面。因此，如果对您有用，请订阅我们的博客。

组织合作伙伴服务的绩效监控


我们一直在处理来自客户的订单，因此我们的服务不断与第三方API交互-这些是用于发送SMS的网关，支付平台，路由系统，地址编码器，联邦税务局和许多其他系统。当负载开始快速增长时，我们开始抵制我们的服务合作伙伴的API限制，这是我们之前从未考虑过的。

联盟服务配额意外超出限额可能导致您自己的停机时间。许多API会阻止超出限制的客户端，在某些情况下，过多的请求可能会使合作伙伴的生产超负荷。 

例如，在交付数量增加时，伴随的服务无法应付其分发，确定路线的任务。结果，事实证明已下订单，并且创建路线的服务不起作用。我必须说，在这种情况下，我们的后勤人员几乎不可能做到这一点，并且团队之间的明确互动有助于弥补临时性服务故障。但是，如此大量的应用程序无法手动进行手动处理，并且一段时间后，我们将在订单及其执行之间遇到无法接受的差距。 

在我们就新条件达成一致并等待一些合作伙伴提供的服务现代化的同时，采取了许多组织措施，团队的协调工作有助于赢得时间。还有其他一些API可以在流量高的情况下以较高的耐用性和令人难以置信的价格吸引您。例如，在开始时，我们使用了一个众所周知的映射API来确定传递点的地址。但是在月底，他们收到了近200万卢布的整齐账单。之后，他们决定迅速更换它。我不会从事广告，但是我会说我们的费用已大大减少。

: . , « », , . , ,   . 

, « » ()


我们习惯于“插入”主数据库或应用程序服务器，但是当进行扩展时，可能会在原本不希望出现的地方出现问题，对于全文搜索，我们使用Apache Solr引擎。随着负载的增加，我们注意到响应时间减少了，服务器处理器的负载达到了100％。可能更简单-我们将使用Solr向容器提供更多资源。

服务器没有达到预期的性能提升，而是“死亡”。它立即加载了100％，响应速度更加缓慢。最初，我们有2个内核和2 GB RAM。我们决定做通常有帮助的事情-我们为服务器提供8个内核和32 GB。一切都变得更糟了（确切地说是如何以及为什么-我们将在另一篇文章中讲述）。 

几天来，我们弄清了这个问题的复杂性，并通过8个内核和32 GB获得了最佳性能。这种配置使我们今天可以继续增加负载，这非常重要，因为增长不仅取决于客户，而且取决于所连接商店的数量-在过去2个月中，其数量增长了一倍。 

结论： “添加更多铁”等标准方法并非总能奏效。因此，在扩展任何服务时，您需要充分了解它如何使用资源并在新条件下进行预测试。 

无状态-轻松进行水平扩展的关键


通常，我们的团队遵循一种众所周知的方法：服务不应具有无状态，并且应独立于运行时环境。这使我们能够通过简单的水平缩放来承受负载增长。但是我们有一个服务异常-一个处理长后台任务的处理程序。他从事发送电子邮件和短信，处理事件，生成提要，导入价格和股票以及处理图像的工作。碰巧的是，它依赖于本地文件存储，并且位于单个副本中。 

当处理器队列中的任务数量增加时（这自然会随着订单数量的增加而发生），托管处理器和文件存储的主机的性能成为限制因素。结果，商品种类和价格的更新，向用户的通知发送以及排队中滞留的许多其他关键功能都停止了。Ops团队迅速将文件存储迁移到类似S3的网络存储中，这使我们能够提升一些强大的计算机来扩展后台任务处理程序。

结论：无状态规则必须毫无例外地遵守所有组成部分，即使看起来“我们绝对不会打扰”。最好花一点时间来正确组织所有系统的工作，而不是着急重写代码并修复出现过载的服务。

强劲增长的7条原则


尽管有额外的容量可用，但在增长过程中，我们还是采取了一些措施。在此期间，订单数量增加了4倍以上。现在，我们已经在62个城市每天交付超过17,000个订单，并计划进一步扩大我们的地理范围-2020年上半年，服务预计将在整个俄罗斯推出。为了应对不断增长的工作量，考虑到已经发生的颠簸，我们为自己制定了在持续增长的条件下工作的7条基本原则：

  1. -. Jira,   . . — . , , , , .
  2. . « » . , , . , .
  3. . -, . -, , .
  4. stateless. , . . , , S3. https://12factor.net. , .
  5. . , . , , - . , . 
  6. . , . , SMS . , .
  7. . , . , , . API, -. .


并非没有损失，但是我们在这个阶段中幸存下来，今天我们努力遵守所有已发现的原则，每台机器都能够轻松提高x4性能以应对任何意外情况。 

在以下帖子中，我们将分享我们在Apache Solr中调查性能下沉的经验，并讨论查询优化以及与联邦税务局的互动如何帮助公司节省资金。订阅我们的博客，以便您不会错过任何内容，并在评论中告诉我们在流量增长期间是否遇到此类麻烦。

More articles:


All Articles